Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="toc" />

<h2>Information</h2>

<ul>
<li>Date: 07 March 2012, 18:00-19:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-03-07 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 14 March 2012</li>
</ul>

<h2>Summary</h2>

<h3>WIP pull requests</h3>

<p>(Search for 18:04 in the log.)</p>

<p>Some time ago, we adopted a policy to close pull requests that were not ready to merge. Marco Pivetta (nick: ocramius) has suggested we allow "Work in Progress" pull requests, to allow for better visibility into ongoing development of features.</p>

<p>Matthew (nick: weierophinney) indicated that while he generally favors the idea, he sees potential issues:</p>

<ul>
<li>GitHub has no ability to filter pull requests by anything other than the criteria "open", "closed", and "read"...</li>
<li>... which means the only way to flag a PR as a WIP is to do so via the PR's subject line. These are only editable by the PR author.</li>
</ul>

<p>Basically, there's no easy way to use GH to separate WIP pull requests from those that are ready. Rob Allen (nick: Akrabat) indicated that having many PRs open can also lend to the idea that support is slow or, worse, stalled.</p>

<p>Several other ideas were floated at this time:</p>

<ul>
<li>Opening up GitHub issues, to allow linking commits to issues, which would allow creating features as issues and thus exposing commits more readily. The problem with this is it duplicates the official issue tracker (<a class="external-link" href="http://framework.zend.com/issues">http://framework.zend.com/issues</a>), leading to issues of where to report bugs/request features.</li>
<li>Linking the repository to the <a href="http://framework.zend.com/zf2/board">Kanban board</a>. This would allow linking commits to stories, and also commenting as to where development is happening.</li>
</ul>

<p>Because no consensus was reached, and new ideas were floated, Marco will bring the discussion to the list, with the goal of either a vote or an RFC in the near future.</p>

<p><strong>tl;dr</strong>: something needs to be done to make feature branch development more visible; we're just not sure what.</p>

<h3>Escaper RFC</h3>

<p>(Search for 18:21 in the log.)</p>

<p>Padraic Brady (nick: PadraicB) created a new <ac:link><ri:page ri:content-title="RFC - Escaper Class" /><ac:link-body>RFC on Escaping</ac:link-body></ac:link> to address the need for context-specific escaping strategies in ZF2.</p>

<p>The only concerns/issues raised were:</p>

<ul>
<li>Artur Bodera (nick: Thinkscape) wants to ensure that if escaping cannot occur due to a missing extension (e.g., mbstring not installed), then an exception will occur. In other words, escape at all costs, or fail dramatically. Padraic indicated that the only parts that absolutely require mbstring at this time are opt-in mechanisms anyways.</li>
<li>Rob Allen (nick: Akrabat) suggested having the class in its own component, Zend\Escaper.</li>
</ul>

<p>With these concerns/suggestions raised, the general consensus is that the component is much-needed and ready for development. We did an impromptu vote, and accepted the RFC for immediate development.</p>

<p><strong>tl;dr</strong>: security in ZF2 is going to improve dramatically soon.</p>

<h3>Service classes</h3>

<p>(Search for 18:38 in the log.)</p>

<p>Matthew (nick: weierophinney) noted that we've had several calls to remove the various Zend\Service classes from the main repository and support them separately. Rationale includes:</p>

<ul>
<li>Ability to release on an independent schedule. Considering APIs often change with little notice, this is important.</li>
<li>Simplifies the story of installing one or a selection of Service classes without requiring the entire framework.</li>
</ul>

<p>Immediate general consensus is that this is a good move. However, the details<br />
and logistics are uncertain:</p>

<ul>
<li>Should all service APIs be moved out? Should we allow exceptions for classes that are used elsewhere in the framework (e.g., cloud APIs, which are consumed in a number of locations)</li>
<li>Should these service APIs be officially supported by the project? (General consensus was yes, with a few people dissenting)</li>
<li>If supported by the project, would they be part of the zendframework GitHub organization? If so, as separate repositories, or lumped together? (General consensus was to keep them under the zendframework organization, with one repository per Service)</li>
<li>What namespace would these use?</li>
<li>What happens when a maintainer abandons a component? or somebody develops an alternate implementation that's judged better or is better adopted?</li>
</ul>

<p>We decided we need to answer some of these questions before taking action. Mike Willbanks (nick: mwillbanks) volunteered to create and post an RFC this week.</p>

<p><strong>tl;dr</strong>: We need to iron out details, but Service classes will likely be separate from the core framework.</p>

<h2>Log</h2>

<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
<style>
pre.log {
white-space: -moz-pre-wrap; /* Mozilla, supported since 1999 */
white-space: -pre-wrap; /* Opera 4 - 6 */
white-space: -o-pre-wrap; /* Opera 7 */
white-space: pre-wrap; /* CSS3 - Text module (Candidate Recommendation) http://www.w3.org/TR/css3-text/#white-space */
word-wrap: break-word; /* IE 5.5+ */
border: 1px solid darkgray;
padding: 0.5em;
}
</style>
<pre class="log">
Mar 07 18:00 <weierophinney> greets, everone
Mar 07 18:01 <weierophinney> Agenda this week: 2012-03-07-#zf2-meeting.log
Mar 07 18:01 <matuszemi> hi there!
Mar 07 18:01 <weierophinney> ugh, wrong
Mar 07 18:01 <ezimuel> hey guys
Mar 07 18:01 <weierophinney> Agenda this week: http://bit.ly/wJAQGM
Mar 07 18:01 <Maks3w> Hi weierophinney
Mar 07 18:02 <weierophinney> Should I wait for straggelrs, or get started?
Mar 07 18:02 <mwillbanks> let's get this party started!
Mar 07 18:02 <mwillbanks> :-D
Mar 07 18:03 <PadraicB> Does everyone have a party hat? mwillbanks has spares...
Mar 07 18:03 <Thinkscape> One for me please.
Mar 07 18:03 * Akrabat has managed to make it one time for once
Mar 07 18:03 <weierophinney> w00t! I think we actually have a majority of the CR Team for once!
Mar 07 18:03 * mwillbanks passes Thinkscape a hat w/ st. patty day icons
Mar 07 18:04 <Thinkscape>
Mar 07 18:04 <weierophinney> mwillbanks: you're 10 days early
Mar 07 18:04 <weierophinney> okay...
Mar 07 18:04 <PadraicB> weierophinney, we had to break a few physics laws to achieve that.
Mar 07 18:04 <mwillbanks> better to start early than late
Mar 07 18:04 <weierophinney> ocramius: want to open the floor with the WIP pull request agenda item?
Mar 07 18:04 <weierophinney> ocramius....
Mar 07 18:04 <ocramius> yeah
Mar 07 18:05 <weierophinney> So, to recap the agenda item:
Mar 07 18:05 <ocramius> so what comes up is that I missed a meeting in which following was decided:
Mar 07 18:05 <weierophinney> go for it, ocramius
Mar 07 18:05 <ocramius> pull requests that are not ready to be merged should be closed
Mar 07 18:06 <ocramius> the basic functionality of a pull request consists in commits + discussion + code revision + merge
Mar 07 18:06 <ocramius> we're actually just using the "merge" part of the potential of github hereby
Mar 07 18:07 <ocramius> what I suggest is that pull requests should be allowed to live for a longer time in the https://github.com/zendframework/zf2/pulls page
Mar 07 18:07 <weierophinney> ocramius: well, yes and no. Something that often happens is that the PR isn't quite ready, and we do end up doing discussion. But it's not a "I'm working on this feature, but it's not complete yet" approach
Mar 07 18:07 <ocramius> that is exactly the point. What is needed is more exposure of the work in progress to the community that is still unaware of zf2 development
Mar 07 18:07 <weierophinney> ocramius: my ONLY issue with moving to a WIP style PR system is that GitHub doesn't provide much in the way of filtering PRs
Mar 07 18:07 <matuszemi> is it possible to categorize PR on github?
Mar 07 18:08 <weierophinney> Only "read" "open" and "closed"
Mar 07 18:08 <Thinkscape> Are there any similar (preferably big) projects on GH we can see, that do this?
Mar 07 18:08 <ocramius> matuszemi: only by enabling the issue tracker, which is disabled for zf2
Mar 07 18:08 <ocramius> Thinkscape: I use doctrine as an example
Mar 07 18:08 <weierophinney> which means if we get a lot of WIP's in the queue, it's harder to determine what can be merged at any given point.
Mar 07 18:08 <Akrabat> how long can something be WIP? a week? a month? a year? 2 years?
Mar 07 18:08 <Thinkscape> doctrine doesn't have bug tracker enabled either...
Mar 07 18:09 <ocramius> yes weierophinney, that is surely a problem for the CR team. But some feedback from the PR author (or some convention, like tagging PRs with [WIP]) would work
Mar 07 18:09 <mwillbanks> does this mean that it could be possible too lock down the issue tracking system; make an API integration to state that there is some work in progress (likely from the kanban board) and then we could manage it that way?
Mar 07 18:09 <ocramius> Thinkscape: yes, doctrine uses the [wip] title prefix
Mar 07 18:09 <Thinkscape> The oldest they have is 4 months old.
Mar 07 18:09 <weierophinney> ocramius: right now, the only way to tag PRs is via the subject line, though.
Mar 07 18:09 <mwillbanks> or what about just using the kanban board for doing process?
Mar 07 18:09 <ocramius> yes, exactly weierophinney
Mar 07 18:09 <Akrabat> I worry that this is just "publicity" at the expense of making the PR queue harder to use
Mar 07 18:09 <Thinkscape> but, you cannot filter by that subject line
Mar 07 18:10 <weierophinney> I like mwillbanks' suggestion – the kanban allows us to provide comments, descriptions, etc., allowing linking to the WIP branch
Mar 07 18:10 <Akrabat> Also, when I see a large PR number, I assume that that project isn't looking after its contributors
Mar 07 18:10 <ocramius> Akrabat: from what I've seen right now, the main problem is that bigger PRs like the ones of ralphschindler and weierophinney about view and db, or the work done by ezimuel is hidden to the rest of the world
Mar 07 18:10 <weierophinney> However, mwillbanks, problem with that is it's harder to find the diffs and comment on them.
Mar 07 18:10 <PadraicB> I see nothing wrong with this in principle - but at what point is a WIP PR just unusable code making the queue harder to use>
Mar 07 18:10 <ocramius> only a small number of elected people that join IRC Regularly know about those branches
Mar 07 18:10 <ocramius> (sadly)
Mar 07 18:10 <mwillbanks> weierophinney: that is true...
Mar 07 18:11 <Akrabat> ocramius: WIP wouldnt't have helped - a lot of people weren't prepared to touch it until in master
Mar 07 18:11 <Thinkscape> ocramius: you're right :\
Mar 07 18:11 <ocramius> Akrabat: but a lot of people would have read through it
Mar 07 18:11 <Akrabat> even after ralphschindler created a phar and explicitly asked for help
Mar 07 18:11 <weierophinney> ocramius: I'm not entirely convinced of that. Even once I posted my PR for the view layer, I really only had 2-3 people comment on it, and it was up for a good week before merging.
Mar 07 18:12 <weierophinney> ocramius: again, I like the idea in principle. I have doubts about it in practice. What do you think of the idea of linking via the kanban board?
Mar 07 18:13 <ocramius> Akrabat: doesn't even matter if they use or not zf2
Mar 07 18:13 <Akrabat> ocramius: no. They wouldn't.
Mar 07 18:13 <mwillbanks> alternatively; another option is to make a page on the ZF2 website that can track the pull requests; we would have to create a small filtering system through the github API thus ensuring a convention... however, whenever you put people in charge of a convention this will cause issues
Mar 07 18:13 <Akrabat> large PRs are hard to read through
Mar 07 18:13 <ocramius> github is about exposing work to the community
Mar 07 18:13 <_netzzitrone> hi. i'm here for the first time. first i just read ¶
Mar 07 18:13 <mwillbanks> weierophinney: i viewed it
Mar 07 18:13 <ralphschindler> why does WIP have to be a pull request? Perhaps a select few branches should go on the /zf2 page, and perhaps a nightly script sum up progress on those branches for the zf-contributors mailing list
Mar 07 18:13 <ocramius> weierophinney: as Akrabat said, that is because the PR was enormous
Mar 07 18:13 <ralphschindler> we can comment on commits, no?
Mar 07 18:13 <ralphschindler> basically, it would be cleaning up evans original git watcher
Mar 07 18:13 <PadraicB> ralphschindler - there was supposed to be frequent ML summaries anyway...cough...cough
Mar 07 18:13 <mwillbanks> ralphschindler: i know that comments could be made in each individual repository
Mar 07 18:13 <Akrabat> view-layer is another good example -very few people touch stuff until its in master
Mar 07 18:13 <ocramius> ralphschindler: didn't use any zend site in about a month...
Mar 07 18:13 <ralphschindler> PadraicB: i mean automated
Mar 07 18:13 <weierophinney> (particularly if we get links actually linked off of /zf2/board)
Mar 07 18:13 <ocramius> ralphschindler: only github
Mar 07 18:13 <ralphschindler> not hand written
Mar 07 18:13 <Thinkscape> Guys, think about the future. It's not really as important today, but we have to account for what will come after zf2 ships.
Mar 07 18:13 <ocramius> weierophinney: I like the idea, I don't know what the potential of the kanban board is
Mar 07 18:14 <MikeA> Thinkscape: +1 – my concern is that it could obfuscate present efforts by a well-embedded team
Mar 07 18:14 <Akrabat> My two main thoughts: 1. I don't want to lose the ability to find and merge PRs that are ready. and 2. I don't want RPs hanging around for months.
Mar 07 18:14 <ocramius> ralphschindler, weierophinney, eventually, some reference about WIP on the github page could be needed
Mar 07 18:14 <Akrabat> I do want more people reviewing code though
Mar 07 18:14 <Thinkscape> Another idea: how does enabling bug tracker on GH help us ? (even if it was used ONLY for WIP)
Mar 07 18:15 <Akrabat> It felt that there was maybe 4 of us that looked at \Db outside of the Zend guys.
Mar 07 18:15 <ocramius> Thinkscape: it allows tagging PRs and so filter them
Mar 07 18:15 <mwillbanks> alright; this can be far more simple than we are making it
Mar 07 18:15 <weierophinney> Thinkscape: it would give us tagging, and linking between the issues and the PRs. But that's about it.
Mar 07 18:15 <ezimuel> in each stories of the kanban board we can add a link to the github repository of the source code
Mar 07 18:15 <mwillbanks> weierophinney: in comparison, we could use the kanban board; if they have a github repo you can link to the branch with the comparison feature inside of the branch - aka - https://github.com/mwillbanks/zf2/compare/topic/zend-session-savehandler-db
Mar 07 18:15 <PadraicB> I think an obvious solution is keeping our kanban board and the ZF2 GH repo tightly linked - cross link them more obviously
Mar 07 18:15 <weierophinney> mwillbanks: yep
Mar 07 18:16 <Thinkscape> Well, If we can enable bug tracker only for that purpose and get tagging = that solves the problem. Does it not?
Mar 07 18:16 <mwillbanks> comments would still need to be made on the kanban board and code comments couldn't happen until it went to a PR but it might be enough to get by for now
Mar 07 18:16 <ocramius> mwillbanks: that is quite good
Mar 07 18:16 <weierophinney> mwillbanks, PadraicB there are also hooks for AgileZen that allow commits to link to stories and vice versa
Mar 07 18:16 <PadraicB> I mean, https://github.com/zendframework/zf2 - most people would prefer the README to carry more information of relevant I'd think - e.g. links to kanban board and wiki
Mar 07 18:16 <weierophinney> we could also open up permissions for the "invitation" role to allow commenting on stories.
Mar 07 18:16 <weierophinney> PadraicB: good point.
Mar 07 18:17 * weierophinney missed that for this release announcement
Mar 07 18:17 <PadraicB> weierophinney, how hard is it for people to view the AgileZen board?
Mar 07 18:17 <Akrabat> yes - the README should be more useful
Mar 07 18:17 <Thinkscape> PadraicB: as hard as using yet another website...
Mar 07 18:17 <weierophinney> PadraicB: we have a synced version on the ZF2 site now, and it includes comments.
Mar 07 18:17 <ezimuel> http://framework.zend.com/zf2/board
Mar 07 18:17 <weierophinney> PadraicB: if you want to interact, there's a form for getting an invite, which is an instantaneous process ... as long as you register with AgileZen
Mar 07 18:17 <PadraicB> weierophinney, true - but it's not exactly the same as AgileZen's sexy version
Mar 07 18:18 <weierophinney> PadraicB: Akrabat has some ideas to make it better.
Mar 07 18:18 <ocramius> so to sum up, for now there's 3 ideas: go with WIP PR and issues / better README / Kanban board integration?
Mar 07 18:18 <ocramius> did I miss one?
Mar 07 18:18 <weierophinney> We're getting the ZF2 site repo cleaned up a bit so folks can help with stuff like that
Mar 07 18:18 <ezimuel> PadraicB: we can improve the UI of course
Mar 07 18:18 <weierophinney> ocramius: nope, those sound about right.
Mar 07 18:18 <weierophinney> Let's take the options to the ML and discuss more there.
Mar 07 18:19 <ocramius> weierophinney: I was also thinking of readmes in various paths, not just at the root of the repo. Should I bring that up later on the other chan?
Mar 07 18:19 <Thinkscape> I dislike current website. I've got nothing against linking GH with AgileZen, but ^^ is another place to look for info... and that sucks.
Mar 07 18:19 <weierophinney> ocramius: yes, later, on ML or in #zftalk.2
Mar 07 18:19 <Akrabat> I think better README is independent
Mar 07 18:19 <ocramius> Thinkscape: exactly what I was thinking
Mar 07 18:19 <Thinkscape> Info duplication is better than scattering ...
Mar 07 18:20 <ocramius> ok, fine for me, we could settle this to ML imo. Is there other ideas?
Mar 07 18:20 <weierophinney> Thinkscape: we're simply trying to duplicate the board on the site, not do more.
Mar 07 18:20 <weierophinney> let's move on to the next topic.
Mar 07 18:20 <PadraicB> None here - just basically what Thinkscape is saying - duplicate/cross-link the heck out of things so it's easier to find info.
Mar 07 18:20 <Thinkscape> The thing I like most about ZF2 moving to GH is some form of integration. And it's convenient and fast to look up info, jump from branch to branch, review, communicate etc.
Mar 07 18:20 <ocramius> ok
Mar 07 18:20 <weierophinney> Again, agenda is here: http://bit.ly/wJAQGM
Mar 07 18:20 <ocramius> guys, gotta leave this, will ask for logs later
Mar 07 18:20 <weierophinney> Escaper class RFC
Mar 07 18:20 <ocramius> ciao all
Mar 07 18:21 <weierophinney> bye, ocra|afk
Mar 07 18:21 <weierophinney> PadraicB: YOU HAVE THE FLOOR
Mar 07 18:21 <Thinkscape> PadraicB:
Mar 07 18:21 <weierophinney> PadraicB:
Mar 07 18:21 <PadraicB> Summary: Escaping in PHP sucks - let's set a new standard
Mar 07 18:21 <weierophinney> and cheers erupted from the crowd...
Mar 07 18:21 <PadraicB>
Mar 07 18:22 <PadraicB> Anyone not read the RFC?
Mar 07 18:22 <Thinkscape> silence is golden
Mar 07 18:22 <matuszemi> do you some other implementation examples?
Mar 07 18:22 <PadraicB> Basically the idea is that htmlspecialchars() has evolved for single level HTML escaping
Mar 07 18:23 <PadraicB> But there is far more to it: Javascript, CSS, URI, etc. All context sensitive and horribly complicated.
Mar 07 18:23 <PadraicB> matuszemi, none yet - will have if the RFC is accepted
Mar 07 18:23 <_netzzitrone> @weierophinney site with agenda won't load here
Mar 07 18:23 <matuszemi> I mean.. other projects which have done something similar..
Mar 07 18:23 <weierophinney> _netzzitrone: problem is on your end – loads for me.
Mar 07 18:24 <PadraicB> matuszemi, no - that's the point really. It hasn't been done very well or consistently before
Mar 07 18:24 <PadraicB> As weird as that sounds now
Mar 07 18:24 <_netzzitrone> @weierophinney just you wrote it, it loads ¶
Mar 07 18:24 <weierophinney> PadraicB: my only comment is I think we need to ensure we have helpers for each context-specific escaping mechanism we offer.
Mar 07 18:25 <weierophinney> but otherwise, you and I have discussed a lot of this, and it's more than sane as far as I'm concerned.
Mar 07 18:25 <Akrabat> Generally, It think the proposal is clear. I'd like it in Zend\Escaper really so that it's a trivially easy component to reuse
Mar 07 18:25 <weierophinney> Akrabat: +1
Mar 07 18:25 <PadraicB> weierophinney, true - I didn't address direct integration with Zend\View, but individual helpers would exist
Mar 07 18:25 <matuszemi> and what if you don't know what a content you want to escape is exactly?
Mar 07 18:25 <Akrabat> and obviously, we'll need view helpers / registration with the viewlayer
Mar 07 18:25 <Thinkscape> PadraicB: I've proposed a discussion about security vs performance (on ML), but that ended abruptly. I got a feeling that you leave some space for compromise. I despise the idea that depending on some environmental factors I can have proper (planned) protection level, or there will be a catalog of vulnerabilities that I do not protect myself against.
Mar 07 18:26 <PadraicB> matuszemi, you need to learn about that - I've recommended adding to the docs to make that very clear for users
Mar 07 18:26 <Akrabat> matuszemi: it's not the content that you need to know about. it's where you are going to put that content
Mar 07 18:26 <PadraicB> Clear, as in the docs will teach you the basics
Mar 07 18:26 <Thinkscape> PadraicB: I believe the component should adhere to (peer-reviewed) rules and provide a consistent level or protection, or throw an exception. Nothing in between.
Mar 07 18:27 <MikeA> Is this a proposal for Beta 4?
Mar 07 18:27 <PadraicB> Thinkscape, I'll get back to that but it's not all performance vs security. Outside of htmlspecialchars, PHP has zero native escaping functions so it's moot - we need to write userland code anyway
Mar 07 18:27 <Akrabat> Thinkscape: realistically, we can't have a situation where we say "ZF offers no protection unless you install this long list of php extensions"
Mar 07 18:27 <weierophinney> MikeA: yes
Mar 07 18:28 <PadraicB> MikeA, I haven't set an objective yet - but it's very likely
Mar 07 18:28 <cballou> Agreed, I've been using a custom view helper for awhile and it's not ideal
Mar 07 18:28 <Thinkscape> Akrabat: that's an overstatement. It boils down to: can iconv() provide us with enough to provide the same level of security as mb.
Mar 07 18:28 <weierophinney> PadraicB: thoughts re: iconv?
Mar 07 18:28 <weierophinney> I'd forgotten about that part of the ML discussion.
Mar 07 18:28 <MikeA> weierophinney: a quantum leap in security included with ZF2 then
Mar 07 18:28 <weierophinney> In the past, we've assumed iconv support is okay, as it's installed by default in a vanilla PHP install.
Mar 07 18:28 <PadraicB> Thinkscape, it's goal is to adhere to OWASP recommendations - except for HTML escaping which can use htmlspecialchars() in many cases with a bit of care
Mar 07 18:28 <Thinkscape> I'd stand by a general assumption, that if we find ourselves unable to work around that limitation, the component MUST require an extension that provides full security against XSS.
Mar 07 18:29 <weierophinney> mb, on the other hand, needs to be explicitly selected and enabled.
Mar 07 18:29 <PadraicB> weierophinney, checked and it would need to be mbstring for some items - all optional anyway
Mar 07 18:29 <weierophinney> PadraicB: kk, good.
Mar 07 18:29 <Akrabat> iconv as a minimum requirement is fine. mb is not.
Mar 07 18:29 <MikeA> PadraicB: I think your idea is marvelous but wonder if it would extend lead time to ZF2 release
Mar 07 18:29 <Thinkscape> If there's lesser security without that component, then there should be a secondary component (i.e. EscaperLesser) that does work without it.
Mar 07 18:30 <PadraicB> Thinkscape, not needed - the defaults are secure if use correctly. Look, if we require X and Y, nobody will use this - I know how PHP programmers think
Mar 07 18:30 <weierophinney> MikeA: it's a single component, and the changes necessary to the view would not take long to implement.
Mar 07 18:30 <Akrabat> We may as well not bother writing Escaper if it requires mb
Mar 07 18:30 <mwillbanks> MikeA: it might add to the time for a beta4 release depending on the amount of time, however, that doesn't mean that it must ship with zf2 beta 4
Mar 07 18:30 <MikeA> mwillbanks: clever
Mar 07 18:30 <Thinkscape> PadraicB: I know you know, but security is either there (against given set of attacks) or it isn't.
Mar 07 18:31 <cballou> I think a good solution instead of EscaperLesser would be EscaperMorer, i.e. the optimal solution with required module and exceptions if not included
Mar 07 18:31 <weierophinney> MikeA: what mwillbanks said. I evaluate around 2 weeks prior to a release to see if the component is on track, and drop them from the release if not.
Mar 07 18:31 <PadraicB> Akrabat, it requires mb optionally . It add a strict escaping mode to HTML escaping. Can be ignored if you know what you're doing.
Mar 07 18:31 <Thinkscape> PadraicB: at the expense of smaller consumption, due to laziness in installing mbstring.
Mar 07 18:31 <mwillbanks> MikeA: hey man; its agile if it don't fit it get's moved
Mar 07 18:31 <PadraicB> MikeA - single component, easy to integrate
Mar 07 18:31 <MikeA>
Mar 07 18:31 <weierophinney> MikeA: I did so with console and log for beta3.
Mar 07 18:32 <MikeA>

Unknown macro: {sits peacefully in awe}

Mar 07 18:32 <weierophinney> So... based on discussion... Shall we accept the escaper RFC immediately?
Mar 07 18:32 <Akrabat> PadraicB: that is fine with me. I was mainly addressing Thinkscape's point that it must require mb
Mar 07 18:32 <MikeA> +1
Mar 07 18:32 <cballou> I also find myself trying to use escape helpers succinctly in views, i.e. statics like "clean::xss()"
Mar 07 18:32 <mwillbanks> +1
Mar 07 18:32 <cballou> as to not clutter the view files anymore than they already are
Mar 07 18:32 <PadraicB> cballou, the defaults are already ahead of most others
Mar 07 18:32 <mwillbanks> Thinkscape: i think i would take an issue with it having to have alternative names to handle different handling
Mar 07 18:33 <PadraicB> cballou, that will be the biggest challenge - proper escaping needs nested calls to escapers. A LOT of people don't get that and never show in examples for their preferred template solution
Mar 07 18:33 <mwillbanks> PadraicB: it might be helpful to state the level of security and what it would cost, by default it could depend on everything then through DI it could make sense to have a flag to allow a lesser security model such as no mb_* being installed so that it is explicitly disabled rather than optional behind the scenes to bring more exposure
Mar 07 18:34 <Thinkscape> mwillbanks: I'm doing graceful degration in Zend\Console. If you have OS that doesn't support something, it will degrate but still work. You can not do this with security ... it cannot silently not secure you aganst attack X.
Mar 07 18:34 <cballou> let me show you an example call to one I use...
Mar 07 18:34 <PadraicB> Do I get to vote for myself? NO?
Mar 07 18:34 <cballou> public static function xss($string, $filterIn = array('Tidy', 'Dom', 'Striptags'), $filterOut = 'none', $drupal = FALSE) {
Mar 07 18:34 <weierophinney> PadraicB: go for it.
Mar 07 18:34 <PadraicB> mwillbanks, will do - docs improvements are part of the RFC too
Mar 07 18:34 <Thinkscape> PadraicB: +1
Mar 07 18:34 <weierophinney> PadraicB: +1 from me on escaper rfc
Mar 07 18:35 <ezimuel> PadraicB: +1
Mar 07 18:35 <Akrabat> With a rename to Zend\Escaper, I'm +1 btw.
Mar 07 18:35 <weierophinney> I'm sure you'll work out kinks/address the mb vs iconv stuff during implementation
Mar 07 18:35 <mwillbanks> +1
Mar 07 18:35 <weierophinney> Akrabat: +1
Mar 07 18:35 <PadraicB> Akrabat, true - anyone object to that?
Mar 07 18:35 <PadraicB> Though, Zend\Escaper\Escaper... Namespaces...it'll do
Mar 07 18:36 <mwillbanks> lol
Mar 07 18:36 <PadraicB> People will get worried about what
Mar 07 18:36 <PadraicB> is escaping
Mar 07 18:36 <mwillbanks> PadraicB: forgot to ask; what about console escaping are you going to add that into it as well?
Mar 07 18:36 <weierophinney> mwillbanks: I think that's Thinkscape's job.
Mar 07 18:37 <mwillbanks> weierophinney: figured that much but thought it might be fun to ask
Mar 07 18:37 <PadraicB> mwillbanks, could be through that'll be up to the Console Guru in the corner I suspect
Mar 07 18:37 <Thinkscape> Argument parsing will provide filtering and validation.
Mar 07 18:37 <Thinkscape> And there will be un-utf8ing
Mar 07 18:37 <Thinkscape> for non-utf8 compatible shells.
Mar 07 18:37 <Thinkscape> mwillbanks: give me a use case...
Mar 07 18:38 <weierophinney> let's move that discussion to the ML or #zftalk.2
Mar 07 18:38 <weierophinney> and move on to the last agenda item, since we appear to have approval of the Escaper RFC
Mar 07 18:38 <weierophinney> (which reminds me, I need to add that story to the board...)
Mar 07 18:38 <weierophinney> Next topic: Service classes
Mar 07 18:38 <PadraicB> weierophinney, I'll do it later
Mar 07 18:39 <weierophinney> This has come up a few times on the list, and I thought we should address it.
Mar 07 18:39 <PadraicB> This is where I run screaming from the room
Mar 07 18:39 <weierophinney> Basically, a number of folks think the various Zend\Service classes should be removed from the main library and pushed into modules
Mar 07 18:39 <weierophinney> you can read the summary here: http://framework.zend.com/wiki/display/ZFDEV2/2012-03-07+Meeting+Agenda
Mar 07 18:39 <Thinkscape> yes, please.
Mar 07 18:40 <weierophinney> I'm personally in favor, but note that there will be some that we have to keep in place – anything consumed elsewhere in the framework, and, particularly, the cloud service apis
Mar 07 18:40 <Akrabat> I'm generally pro this idea too.
Mar 07 18:40 <weierophinney> Anybody have any thoughts outside what's captured in the agenda?
Mar 07 18:40 <PadraicB> What exactly is the rationale behind using Modules for this (I'm assuming the M is capital)
Mar 07 18:40 <mwillbanks> weierophinney: I believe that the service components should be separated; due to the changes that may happen within service components aka API changes that must be changed for the integration to continue to work. this happened quite a few times in ZF1
Mar 07 18:40 <Akrabat> which components do we have that are dependent on service apis?
Mar 07 18:40 <PadraicB> vs - stick it on GH as usual?
Mar 07 18:40 <Thinkscape> This proposal does not affect the fact that individual APIs go unmaintained - that happens anyways, regardless.
Mar 07 18:40 <weierophinney> Akrabat: Zend\Cloud in particular, also zend\Queue, iirc
Mar 07 18:41 <Akrabat> I think there's two types of service apis: those talking to 3rd parties and generic
Mar 07 18:41 <EvanDotPro> weierophinney: why does Zend\Cloud have to be in the framework? marketing reasons?
Mar 07 18:41 <weierophinney> PadraicB: having them in modules makes them easy to drop into applications, basically. But they could just be self-contained component repos, too.
Mar 07 18:41 <weierophinney> EvanDotPro: bingo
Mar 07 18:41 <Kit-10> With Less visibility issue - I would say that if we have more prominence with modules - like modules.zendframework.com and have categorisation for it..
Mar 07 18:41 <Akrabat> EvanDotPro: you could ask that about Zend\Gdata too
Mar 07 18:41 <EvanDotPro> weierophinney: i was afraid that was the case.
Mar 07 18:41 <PadraicB> weierophinney, and when I'm not using ZF2 I...
Mar 07 18:41 <mwillbanks> weierophinney: IMO Zend\Queue integration should be built out using the Zend\Service integration... such that say, Zend\Service\Amazon\Sms would have Zend\Service\Amazon\Sms\QueueAdapter or the like
Mar 07 18:42 <weierophinney> Gdata actually falls under this category for ZF2 as well – Google says they won't maintain it for ZF2.
Mar 07 18:42 <EvanDotPro> weierophinney: the thing i don't like about that is that we start drawing lines
Mar 07 18:42 <weierophinney> mwillbanks: that makes sense to me.
Mar 07 18:42 <weierophinney> EvanDotPro: if we were to go mwillbanks route, we may be able to do it en masse.
Mar 07 18:42 <Akrabat> I would like to weierophinney which Zend\Service components does Zend\Cloud depend on ?
Mar 07 18:43 <weierophinney> and have some of them under the zendframework organization.
Mar 07 18:43 <Thinkscape> One more (pro), not mentioned: it can invite service providers (i.e. community integration teams at companies developing various SAAS) to contribute or author those extensions. That was difficult in zf1 an could still be with those classes living inside monster's belly.
Mar 07 18:43 <Akrabat> add an ask in there
Mar 07 18:43 <PadraicB> I'll be honest guys, I have no idea why we're reinventing PEAR, Pyrus, git and Composer in some weird framework specific "module" just for general purpose classes. It's hideous.
Mar 07 18:43 <weierophinney> Akrabat: amazon cloud services, azure, nirvanix, strikeiron
Mar 07 18:43 <weierophinney> Thinkscape: good points!
Mar 07 18:43 <Akrabat> right
Mar 07 18:43 <matuszemi> +1 for module implementations.. but I believe we should provide them as 1. standalone modules (so anybody can just take them and use outside of ZF2 — or with minimum ZF2 libraries...) and 2. module would be the one supporting additional functionality build on full ZF2 stack with MVC etc..?
Mar 07 18:43 <ezimuel> Zend\Cloud is an abstraction of specific cloud service components
Mar 07 18:43 <ralphschindler> PadraicB: in most cases, they won't be general purpose, they might need routes and controllers
Mar 07 18:43 <MikeA> Thinkscape: +1 – and a major marketing boost for ZF2 as each one comes along
Mar 07 18:43 <ralphschindler> for example, the Facebook stuff with oauth
Mar 07 18:44 <ralphschindler> or anything that uses openid
Mar 07 18:44 <weierophinney> PadraicB: like I said, wouldn't need to be modules.
Mar 07 18:44 <PadraicB> weierophinney, that seems to be the prevailing idea though
Mar 07 18:44 <Thinkscape> PadraicB: think less "Module", more "taking it outside of the core, where crazy people tinker around"
Mar 07 18:44 <mwillbanks> what we could do is call them component extensions and then make them available through a pear repo?
Mar 07 18:44 <weierophinney> ralphschindler: um, no, actually. No Zend\Service components require MVC linking
Mar 07 18:44 <mwillbanks> or pyrus repo
Mar 07 18:44 <Akrabat> Adding a Module.php simply gives free Zend\Loader\Autoloader integration
Mar 07 18:44 <ralphschindler> PadraicB: if its just a set of classes, it really could live on its own as its own non-zf-related repository
Mar 07 18:44 <PadraicB> ralphschindler, for ZF2 yes - for S2, Lithium, the crap I wrote 5 years ago...no.
Mar 07 18:45 <ralphschindler> weierophinney: not currently, but in the future, some might
Mar 07 18:45 <Spabby> I have absolutely no wish to build a Module that doesn't rely on ZF2 components, and would vigorously argue against it
Mar 07 18:45 <PadraicB> Akrabat, they are all PSR-0 already aren;t they?
Mar 07 18:45 <Thinkscape> Spabby: well, if we used something like that Packager, then it can depend on zf2 components and require them
Mar 07 18:45 <weierophinney> Here's what I'm hearing:
Mar 07 18:46 <mwillbanks> Thinkscape: pretty much my thoughts exactly...
Mar 07 18:46 <weierophinney> a) people support moving the service APIs – all of them – outside the main ZF library
Mar 07 18:46 <Spabby> exactly, the whole purpose of building a facebook implimentation is because Zend\Http\Client exists
Mar 07 18:46 <weierophinney> b) how that is done – i.e., simply as library code, or as a ZF2 module – is debatable.
Mar 07 18:46 <PadraicB> Thinkscape - exactly! We don't need to merge libraries and modules. Let the damn package manager worry about grabbing them.
Mar 07 18:47 <weierophinney> I'd argue that we can do them as library code very easily, exposing them as pear/pyrus packages and/or composer packages quite simply.
Mar 07 18:47 <Thinkscape> Realistically — those Service* components will require ZF2 (at least some parts of it), so we're not talking here about phpclasses.org - but a new, warm and fuzzy home for Service* classes.
Mar 07 18:47 <weierophinney> and optionally exposing them as modules
Mar 07 18:47 <Kit-10> weierophinney: agreed
Mar 07 18:47 <weierophinney> The questions I have from the above are:
Mar 07 18:47 <mwillbanks> weierophinney: as well as library code that we may not want to introduce to the core
Mar 07 18:48 <weierophinney> * Do they get a separate namespace?
Mar 07 18:48 <weierophinney> * How/when do we package releases for them?
Mar 07 18:48 <Thinkscape> * what level of "official endorsement" are we talking about ?
Mar 07 18:48 <weierophinney> (the latter is a moot point with composer; we just drop in the composer.json... for pear/pyrus, we'd need a way to make this happen)
Mar 07 18:48 <mwillbanks> weierophinney: package releases; i would say should be automatic based on tags within the GH repo
Mar 07 18:48 <PadraicB> weierophinney 1. Possibly, 2. Independently version them
Mar 07 18:49 <Thinkscape> i.e. Zend\Service\Gdata - becomes github/ZendServiceGdata ?? still living in Zend\Service\Gdata ?
Mar 07 18:49 <matuszemi> namespace: ZendService, releases: as soon as it's needed.. e.g. FB API changes..,
Mar 07 18:49 <mwillbanks> i think these should work much like PEAR/PECL and are independent of the main framework
Mar 07 18:49 <weierophinney> PadraicB: right – but does that mean we offer them via packages.zendframework.com, or no?
Mar 07 18:49 <Kit-10> I'd recommend a separate namespace to differenciate between service code and ZF2 code
Mar 07 18:49 <Kit-10> something that is simple
Mar 07 18:50 <PadraicB> weierophinney, I'd be worried if we didn't - what sort of support is ZF is offering these?
Mar 07 18:50 <Thinkscape> ^^ just said that
Mar 07 18:50 <PadraicB> If we're segregating them, not packaging them, and switching their namespaces - why are we even keeping them loosely associated with ZF at all?
Mar 07 18:50 <Spabby> sorry guys, I know I was late (kid trouble), but can I just make a few points that may or may not have been covered?
Mar 07 18:50 <weierophinney> PadraicB:
Mar 07 18:50 <mwillbanks> Endorsement: The model that PEAR/PECL use to approve packages for development should be used; lets use a model that is basically already working
Mar 07 18:51 <weierophinney> Spabby: go for it.
Mar 07 18:51 <mwillbanks> that way we don't have duplicates that are doing the exact same thing
Mar 07 18:51 <matuszemi> PadraicB: let's say they will be officially supported by ZF team.. I think they should be promoted alongside with ZF2...
Mar 07 18:52 <weierophinney> so, if they're supported via the project, that implies a Zend* namespace.
Mar 07 18:52 <weierophinney> and under the zendframework organization
Mar 07 18:52 <PadraicB> mwillbanks, if we endorse them, we own them - I'm considering the angle of what happens when something hits a big problem or sec issue. Implies Zend namespace.
Mar 07 18:52 <Spabby> I am specifically looking at this from my proposed Facebook integration package, I'm willing to do the lions share of the work, however, I was hoping it would be under the ZF2 umbrella, either as part of a Zend\Service or as an "accredited" module. Getting the support and help I require will be much, much easier if it's "part" of the framework in some way, and it automatically becomes something people will trust and use,
Mar 07 18:53 <weierophinney> We can likely have hooks/processes in place such that a new tag on the repo triggers packaging for packages.zendframework.com
Mar 07 18:53 <PadraicB> Let's not copy PEAR's half in/half out practices (they have borked insecure crap in PEAR that has sat there for years)
Mar 07 18:53 <Thinkscape> weierophinney: PadraicB: well said. The way I see it is that these become modules, similar to ZfcUser. They might be in any namespace their authors want them to be. That is because – let's assume we move current Gdata to ZendServiceGdata repo — this stalls, but in the meantime, someone does WootGdata modules that' 300% better. It's not up to us to decide which should end-user use anyways.... that means end of official endorsement of
Mar 07 18:53 <weierophinney> Spabby: I think that's what most here are arguing for – just outside the zf2 repo, and in a separate repo dedicated to that particular service API component.
Mar 07 18:54 <weierophinney> Thinkscape: your client cut you off after "that means end of official endorsement of"
Mar 07 18:54 <Thinkscape> .. that means end of official endorsement of the Service* space.
Mar 07 18:55 <Thinkscape> It is plausible, we'll have 4 Gdata modules before the end of 2012 on modules.zendframework.com
Mar 07 18:55 <mwillbanks> Thinkscape: I'd argue in that case that the component should be moved to a new maintainer
Mar 07 18:55 <Akrabat> This is also a good place to learn how to do multiple repositories/namespaces
Mar 07 18:55 <Thinkscape> mwillbanks: not everyone wants to pick up old components...
Mar 07 18:55 <mwillbanks> no duplications can be accepted but can be rewritten
Mar 07 18:55 <PadraicB> Spabby, it should be supported - we're just sounding out how this will work with sep. repos.
Mar 07 18:55 <Spabby> I have to be brutally honest, I would be less inclined to code and maintain a facebook integration if it was not, at the very least, endorsed by the Zend Framework team, for selfish reasons.
Mar 07 18:56 <Thinkscape> Spabby: what happens when you drop it ?
Mar 07 18:56 <PadraicB> mwillbanks, there is no anti-dup rule I thought - I dup'd Zend\Feed pretty easily
Mar 07 18:56 <weierophinney> Spabby: you're re-iterating a point that we've already told you we're agreeing with.
Mar 07 18:56 <Thinkscape> Spabby: I don't see everyone dropping ZF2 (core), but see what happens to other Service* components (since zf1)
Mar 07 18:56 <Spabby> because it's part of the framework in some way, someone else will be able to run with it, in the same way as they can with the core
Mar 07 18:57 <Spabby> apologies for repeating then
Mar 07 18:57 <PadraicB> mwillbanks, it's more of a discouraging glare from weierophinney
Mar 07 18:57 * Thinkscape hides behind a pillar
Mar 07 18:57 <weierophinney> Spabby: we're simply saying the service APIs would sit outside the core framework, but we'd likely distribute them with the standard or "kitchen sink" distribution.
Mar 07 18:57 <mwillbanks> PadraicB: yes, i just would think that having 3 components that are essentially targeting the same issue have the epidemic issue of "not built here" in which case people should learn to work together and if there is apposing opinions maybe it should go to the CR team to state the best approach for moving forward in that case
Mar 07 18:58 * mwillbanks remembers a discussion on internals like that on GeoIP extension
Mar 07 18:58 <weierophinney> Spabby: it also would allow easier consumption by end users if they can just grab that API and use it, without the whole framework coming along in tow.
Mar 07 18:58 <Thinkscape> well, because currently it's stalled anyways, I'd propose we move Service* outside ---- everyone and anyone who wants to pick up selected compoennts is free to do so. Then we'll se what happens - case-by-case......
Mar 07 18:58 <Spabby> Thinkscape: +1
Mar 07 18:58 <weierophinney> Question: do we create a repo per-API under the zendframework org?
Mar 07 18:58 <PadraicB> Spabby, if it makes sense - most of ZF2 should be separate repos anyway (in my opinion) so being separate doesn't mean excluded - it's just a repo URI
Mar 07 18:58 <mwillbanks> my main point and case on "Service" components; waiting for a ZF release in order to have the service upgraded is IMO the worst possible problem
Mar 07 18:59 <Thinkscape> weierophinney: that means trying to keep life-support for some components...
Mar 07 18:59 <Thinkscape> weierophinney: it means - there has to be someone (you?) who keeps respective components and their maintainers in check.
Mar 07 18:59 <mwillbanks> additionally the second issue is; how many times do you use ALL of the service components; there are simply a million possibilities here and it doesn't make sense in the core
Mar 07 18:59 <Spabby> it makes it much easier for people who want to contribute to a service implementation to just do it, then submit the repo for peer review
Mar 07 18:59 <ezimuel> if we support a service we should ship as a Zend\Service component, otherwise we can have modules available from the community
Mar 07 18:59 <PadraicB> weierophinney, I'd say yes - keep them separate, independently versioned, and hooked up for packaging when tagged
Mar 07 19:00 <PadraicB> Then add composer.json to all their master branches...done.
Mar 07 19:00 <weierophinney> PadraicB: kk. All but the last part are easy currently.
Mar 07 19:00 <weierophinney> (the packaging when tagged bit)
Mar 07 19:00 <MikeA> What about "Zend Aprroved" badging? Withdrawn for out of date services
Mar 07 19:00 <PadraicB> weierophinney, you can do it - just sleep less and skip a vacation or three
Mar 07 19:00 <Thinkscape> weierophinney: not sure how your corporate stuff works at Zend, but I'd argue it's not a good idea to keep those under that org.
Mar 07 19:00 <weierophinney> I'd argue we should have a "VERSION" constant in each of the services as well
Mar 07 19:01 <Spabby> I presume that these implementations will be subject to the same rules as core contributions with regards to coding convention, unit tests etc
Mar 07 19:01 <weierophinney> Thinkscape: keep which under the org?
Mar 07 19:01 <Thinkscape> weierophinney: that implies, it's the same-class citizen as ZendFramework (the core). which it's not.
Mar 07 19:01 <PadraicB> Spabby, yes - presumably
Mar 07 19:01 <weierophinney> Thinkscape: and the org is not Zend's, it's the project's...
Mar 07 19:01 <Thinkscape> (under github/zend organization)
Mar 07 19:01 <mwillbanks> Spabby: agreed; including code review and having to issue pull requests
Mar 07 19:01 <PadraicB> Spabby, also visitations from the CR-Team
Mar 07 19:01 <Thinkscape> weierophinney: sorry, but that's even worse
Mar 07 19:01 <weierophinney> Thinkscape: why isn't it the same class as the ZF repo?
Mar 07 19:01 <weierophinney> I thought we were areguing it is
Mar 07 19:02 <weierophinney> Thinkscape: you're confusing me, frankly.
Mar 07 19:02 <Thinkscape> hmm... it implies "supported by" ... or "part of", which we discussed should change.
Mar 07 19:02 <PadraicB> Thinkscape, they are same citizens - just special ones with special needs.
Mar 07 19:02 <Thinkscape> well, then is the history of ^^ 19:59 < Thinkscape> weierophinney: it means - there has to be someone (you?) who keeps respective components and their maintainers in check.
Mar 07 19:02 <weierophinney> Thinkscape: we were actually saying they are supported by the project, just on a different timeline than the framework itself..
Mar 07 19:02 <mwillbanks> weierophinney: +1
Mar 07 19:02 <PadraicB> Thinkscape, then we're back to why bother including them anywhere at all? We're either in or out.
Mar 07 19:02 <weierophinney> Thinkscape: and the idea is that my team and CR-Team help with the oversight.
Mar 07 19:03 <MikeA> need to go: +1 for separation of service APIs from the core
Mar 07 19:03 <Thinkscape> weierophinney: which ones? all of them? what if there's a better module, can it deprecate current one? is bc kept ?
Mar 07 19:03 <ocra|afk> re
Mar 07 19:04 <weierophinney> Thinkscape: those questions we still have to answer, but my initial stab: better module/offering? replace the one under the org.
Mar 07 19:04 <Thinkscape> weierophinney: that also means - there's got to be someone at the door — letting people in. That's against the idea of: "anyone can build a good gdata module"
Mar 07 19:05 <ocramius> where are we? services?
Mar 07 19:05 <PadraicB> Thinkscape, that should happen anyway - but it needs to be discussed separately. We have deprecated components in the past.
Mar 07 19:05 <Spabby> if there is oversight from the Zend and CR teams, then we should try and keep duplication from occurring, if someone shows interest in writing a new/better implementation of an existing Module, they should be encouraged to fork and submit PR instead
Mar 07 19:05 <mwillbanks> I think we should write an RFC for this and start to incorporate comments to get a tactical alignment on how this will work
Mar 07 19:05 <weierophinney> Spabby: +1
Mar 07 19:05 <weierophinney> mwillbanks: +1
Mar 07 19:05 <PadraicB> mwillbanks +100
Mar 07 19:05 <weierophinney> Who wants to spear-head the RFC?
Mar 07 19:06 <mwillbanks> I can do it; it will likely be later on this week
Mar 07 19:06 <PadraicB> mwillbanks will, he's tactical \
Mar 07 19:06 <mwillbanks> lmfao
Mar 07 19:06 <PadraicB> Plus he has all the party hats
Mar 07 19:06 <Kit-10> there are too many caveats to state a carte blanche response ... so +1 to mwillbanks & spabby
Mar 07 19:06 <ezimuel> mwillbanks: +1, thi is a big topic and cannot be discussed only in a meeting
Mar 07 19:06 <Maks3w> If you wan't maintance the modules just forgive them. Let the people fork the old code and submit his proposals to packagist
Mar 07 19:06 <weierophinney> mwillbanks: kk, so get a draft written, post to the ML.
Mar 07 19:07 <mwillbanks> will do
Mar 07 19:07 <weierophinney> cool
Mar 07 19:07 <weierophinney> So, last topic I'm nixing, because most voted against it, likely because I influenced the vote.
Mar 07 19:07 <weierophinney> (forms... basically, I need to incorporate feedback and bring it back to the list)
Mar 07 19:08 <weierophinney> To summarize the meeting....
Mar 07 19:08 <cballou> does that imply a close relationship with composor/packagist?
Mar 07 19:08 <weierophinney> * WIP system seems interesting, but there are some technical issues. Some alternative options were raised; ocramius will bring them to the list.
Mar 07 19:08 <Maks3w> There are a website for SF2 to the people can submit his own bundles (knpbundles)
Mar 07 19:08 <matuszemi> weierophinney: yep.. please do.. is there a way how I can help on Zend\Form component to speed up a development?
Mar 07 19:09 <cballou> because there was some discussion on hacker news yesterday in that ballpark
Mar 07 19:09 <weierophinney> * Escapeer RFC was approved, with a request that the name change to Zend\Escaper
Mar 07 19:09 <mwillbanks> cballou: might be good to push that to the ML
Mar 07 19:09 <PadraicB> cballou, composer is a tool - we'd like to support it, of course. Link the HN discussion?
Mar 07 19:09 <weierophinney> * General consensus to move the Zend\Service components out of the main framework, but still as part of the project. mwillbanks will create an RFC this week.
</pre>
]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.