<ac:macro ac:name="toc" />
<li>Date: 01 February 2012, 18:00-19:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-02-01 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 08 February 2012</li>
<h3>Weekly meetings? </h3>
<p>(Search for "18:03:13" in the log.)</p>
<p>During <ac:link><ri:page ri:content-title="2012-01-25 Meeting Log" /><ac:link-body>last week's meeting</ac:link-body></ac:link>, a number of folks brought up that they would like more frequent meetings, in part:</p>
<li>To allow for shorter meetings</li>
<li>To get more frequent updates on project status</li>
<li>To space out votes (i.e., fewer votes per meeting)</li>
<p>There was little to no real discussion this week – everybody felt it was a good idea, and thus it got a quick "+1".</p>
<p><strong>tl;dr</strong>: Meetings are now weekly, at 18:00 UTC on Wednesdays.</p>
<h3>Vote on the Zend\View Proposal </h3>
<p>(Search for "18:13:42" in the log.)</p>
<p>Matthew (me) posted the <ac:link><ri:page ri:content-title="RFC - View Layer" /><ac:link-body>View layer RFC</ac:link-body></ac:link> some weeks ago, and has a prototype ready; he has asked for a vote so he can continue in earnest.</p>
<p>There was a little discussion surrounding the following topics:</p>
<li>Terminology. ralphschindler thinks there may be confusion between the terms "Response" (response object), "Result" (result of execution, passed to the MvcEvent), and ViewModels. He did not think it was a deal-breaker in terms of approval however; Matthew asked him to clarify his problems on the list so that he can address them if necessary.</li>
<li>EvanDotPro suggested an "ErrorHandlingViewStrategy" should be included by default.</li>
<li>Where should the strategy be instantiated and attached to the event manager? Matthew suggested we could potentially do this in the Application or Bootstrap objects, but it needs a little thought.</li>
<li>Aldemar wanted to ensure that the component handles disambiguation properly. As an example, as of beta2, two controllers in two modules using the same methods will result in the same view script being invoked – which can lead to the wrong view script being invoked. Matthew indicated that this is resolved via a combination of hinting to the ViewModel returned by the controller which view script to use, and configuring your resolvers correctly.</li>
<p>In the end, there were no dissenting votes, providing approval for the RFC.</p>
<p><strong>tl;dr</strong>: The View Layer RFC was approved.</p>
<h3>Discussion of Coding Standard Ballot Items</h3>
<p>(Search for "18:39:59" in the log.)</p>
<p>Ralph started a discussion last week about naming of interfaces (and abstract classes, and traits), in light of usage patterns and problems encountered so far in ZF2's life-cycle. The discussion is backed by an <ac:link><ri:page ri:content-title="RFC - Revised Naming of Interfaces in ZF2" /><ac:link-body>RFC</ac:link-body></ac:link>, which details some of the issues and rationale behind proposed changes.</p>
<p>Ralph has now created a <ac:link><ri:page ri:content-title="POLL - Coding Standards for Type Names" /><ac:link-body>poll</ac:link-body></ac:link>, and wanted to ensure it accurately listed all options we should vote on. </p>
<p>The only change suggested was by Thinkscape, who suggested adding an option for having traits in their own subnamespaces of components.</p>
<p>With that change, we voted to open the poll for one week, starting today.</p>
<p><strong>tl;dr</strong>: the poll on coding standards for interfaces, abstract, and trait naming conventions is now open.</p>
<p>(Search for "18:50:52" in the log.)</p>
<p>I raised the idea of considering PHP 5.4 as the minimum required version for ZF2. The primary reasons:</p>
<li>PHP 5.4 stable is on the verge of release, which means that once ZF2 is released, if we stick with PHP 5.3, we'd be pinning ourselves to an "old" release immediately.</li>
<li>Traits could greatly simplify some internals of ZF2. As examples: traits for Options, Events, and Brokers would lead to less and more maintainable code.</li>
<li>Additionally, adopting PHP 5.4 and fully using features such as traits will reduce the workload later (no need to refactor to use these features), and allow us to focus on new framework feature instead of language features.</li>
<p>That said, there are some cons to doing this:</p>
<li>Many popular linux/freebsd/etc. distributions will not be shipping PHP 5.4 in a long term support (LTS) edition in the foreseeable future. (Though ubuntu, debian, and fedora have indicated they will do so soon.) Couple this with the fact that many hosting providers are very conservative in updating versions, and we have a potential to lock out many developers due to version incompatibilities.</li>
<li>Many developers and companies have already started putting plans in place for 5.3 + ZF2; this changes the equation and adds additional overhead and time to migrations.</li>
<li>Many view the ".0" release as inherently unstable, and simply will not adopt until a few bugfix releases have dropped.</li>
<p>Another potential route is to stick with 5.3 as our base version, but offer some forwards-compatible features for consumption by end users. As an example, we've already created a "ProvidesEvents" trait in the EventManager; this is not used <em>in</em> the framework itself, but end users may compose this trait into their classes in order to quickly provide eventing capabilties to their own classes. Providing features in this way would provide useful tools for PHP 5.4 users, with little expense to 5.3 users (there would be minimal support requirements for traits).</p>
<p>In the end, we decided to provide a poll in the wiki, allow discussion for a week, and then open the poll to voting. Matthew will create this in the next day or so. <strong>UPDATE:</strong> poll is <ac:link><ri:page ri:content-title="POLL - What version of PHP should ZF2 target?" /><ac:link-body>here</ac:link-body></ac:link>.</p>
<p><strong>tl;dr</strong>: Many, many opinions on PHP 5.4 adoption and what it would mean to the framework, and little consensus. More discussion is needed.</p>
<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
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;
Feb 01 18:03:13 <weierophinney> First topic: do we want to move to weekly meetings for the foreseeable future?
Feb 01 18:04:04 <NickBelhomme_> I cannot comment on that one, because I don't follow the bi-weekly meetings anymore on a regular basis.
Feb 01 18:04:19 <NickBelhomme_> The people who requested that are here?
Feb 01 18:04:25 <weierophinney> I'll admit I only perused the log quickly last week.
Feb 01 18:04:27 <ralphschindler> Thinkscape had issues with weekly meetings IIRC
Feb 01 18:04:28 <NickBelhomme_> if not... then 2 weekly seems logical
Feb 01 18:04:28 <lubs> weierophinney: yes; i would like to see the certain ones of them more status related
Feb 01 18:05:07 <ralphschindler> lugs you're implying that decision making meetings can't happen weekly then, right?
Feb 01 18:05:12 <weierophinney> But I know from using my PM hat that having weekly makes it much easier for me to gauge what stuff is ready, and to coordinate volunteers for initiatives that are having issues (missing contribs, busy contribs, etc)
Feb 01 18:05:13 <ralphschindler> lubs*
Feb 01 18:05:53 <lubs> ralphschindler: well; yes and no... smaller decisions could be made but potentially larger ones could wait for a bi-weekly or monthly meeting?
Feb 01 18:06:27 <EvanDotPro> weierophinney: that's my perspective as a project manager as well
Feb 01 18:06:39 <weierophinney> lubs, or we could have fewer decisions per meeting as well
Feb 01 18:06:45 <weierophinney> which may keep them shorter.
Feb 01 18:06:52 <lubs> weierophinney: that would work; which would be awesome
Feb 01 18:06:59 <ralphschindler> Thinkscape: you had reservations about the weekly meeting (That is what we're discussing)
Feb 01 18:07:01 <weierophinney> Those just joining: what are your thoughts on weekly meetings?
Feb 01 18:07:26 <MikeA> +1
Feb 01 18:07:30 <ralphschindler> i think fewer decisions is a product of going weekly, no?
Feb 01 18:07:30 <Bostjan> +1
Feb 01 18:07:40 <weierophinney> ralphschindler, I'd think so.
Feb 01 18:07:56 <NickBelhomme_> weekly meetings gives more flexibility to people who want to attend, if they skip one, they have the bi-weekly. If they have something important to throw they can do that in the next upcoming week meeting.
Feb 01 18:07:57 <EvanDotPro> i think weekly meetings to better maintain a picture of the progress being made is good – i do think we should put tihngs like voting into more persistent mediums like the wiki
Feb 01 18:08:22 <Thinkscape> Sorry, my alarm clock failed. I'm ok for weekly, unless we don't have any topics to discuss which I doubt.
Feb 01 18:08:25 <Bostjan> i like reading irc logs, it's nice to see progress (from those who are not involved in developing zf2)
Feb 01 18:08:44 <PadraicB> +1 for weekly
Feb 01 18:08:47 <ralphschindler> +1
Feb 01 18:08:47 <weierophinney> EvanDotPro, I think that makes sense as well.
Feb 01 18:08:55 <Slamdunk> +1 for weekly
Feb 01 18:08:56 <EvanDotPro> +1 for weekly from me as well
Feb 01 18:09:29 <NickBelhomme_> +1 weekly: smaller and quicker feedback
Feb 01 18:10:09 <weierophinney> kk, I'm calling it: agreed to weekly meetings.
Feb 01 18:10:12 <lubs> yay +1 for weekly
Feb 01 18:10:15 »» Thinkscape is unable to vote on http://framework.zend.com/wiki/display/ZFDEV2/POLL+-+Coding+Standards+for+Type+Names because there is a small lock there, and there was no info on ML on that
Feb 01 18:10:19 <Bostjan> \o/
Feb 01 18:10:31 <weierophinney> Is the 18:00 UTC do-able, or should we switch things up.
Feb 01 18:10:34 <weierophinney> I'm big on consistency.
Feb 01 18:10:47 <weierophinney> Thinkscape, the discussion today is whether that poll captures all the options.
Feb 01 18:10:55 <weierophinney> Thinkscape, once approved, we'll open it.
Feb 01 18:11:08 <Thinkscape> ah, ok.
Feb 01 18:11:14 <weierophinney> back on topic..
Feb 01 18:11:21 <weierophinney> 18:00 UTC okay, or a different time?
Feb 01 18:11:43 <weierophinney> going once
Feb 01 18:11:43 <NickBelhomme_> In europe (Belgium) 18h is perfect
Feb 01 18:11:49 <MikeA> +1
Feb 01 18:11:52 <NickBelhomme_> +1
Feb 01 18:11:53 <EvanDotPro> 18:00 is good for me.
Feb 01 18:12:13 <Thinkscape> +1
Feb 01 18:13:04 <weierophinney> and there we go.
Feb 01 18:13:14 <weierophinney> Decision: weekly meetings, 18:00 UTC on Wednesdays.
Feb 01 18:13:42 <weierophinney> Next topic: Zend\View RFC
Feb 01 18:13:51 <weierophinney> Can we approve it?
Feb 01 18:14:14 <weierophinney> As a reminder, the RFC is here: http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer
Feb 01 18:15:32 <MikeA> Poll there is unanimous in favour at present
Feb 01 18:15:32 <ralphschindler> i like the general architecture, I'm not fond of some of the terminology
Feb 01 18:16:01 <Thinkscape> I'm +1 for the general architecture - there are a few things to polish and determine (like those events, configuring layouts etc.) but that's up to consequent prototypes.
Feb 01 18:16:04 <weierophinney> MikeA, that poll is for whether to include the topic in the meeting.
Feb 01 18:16:10 <weierophinney> ralphschindler, which terminology?
Feb 01 18:16:29 <ralphschindler> theres a disconnect in this line:
Feb 01 18:16:30 <ralphschindler> $result = new ViewModel();
Feb 01 18:16:36 <weierophinney> Thinkscape, exactly – that's exactly what I've run into as well. RFCs capture the general architecture, but things often need tweaks during development.
Feb 01 18:16:42 <ralphschindler> AFAIK, there is no result infrastructure?
Feb 01 18:16:49 <weierophinney> ralphschindler, actually, there is.
Feb 01 18:16:59 <PadraicB> With Thinkscape, I believe
Feb 01 18:16:59 <weierophinney> ralphschindler, the MvcEvent composes a "result" of dispatch
Feb 01 18:17:14 <weierophinney> ralphschindler, in this case, the result is a ViewModel.
Feb 01 18:17:21 <weierophinney> (vs a Response object)
Feb 01 18:17:41 <ralphschindler> but the result could be something other than related to a view, like a redirect object?
Feb 01 18:18:05 <weierophinney> ralphschindler, correct. (redirect object == response object with a Location header and alternate status code)
Feb 01 18:18:34 <ralphschindler> well, that comes back to my original statement about terminology results and responses might get confusing for folks
Feb 01 18:18:57 <Thinkscape> good question though - if controllers producte ViewModel's that are consumed by strategies that produce redirect Responses ---- how can a controller control a redirect?
Feb 01 18:19:03 <saltybeagle> ralphschindler: you're just talking about the name of the variable there? $result vs $viewModel or some such thing?
Feb 01 18:19:42 <Thinkscape> Unless "redirection" is one of the strategies ..
Feb 01 18:19:44 <weierophinney> Thinkscape, typically, once you hit the View, you won't be creating a redirect.
Feb 01 18:19:47 <ralphschindler> saltybeagle: the concept, and educating users on what a result is (MvcEvent listens for) and a response object (similar in nature to dispatch's second parameter)
Feb 01 18:19:53 <weierophinney> Thinkscape, but yes, it could be a strategy
Feb 01 18:20:21 <ralphschindler> so, no not the variable name, but what ends up handling something returned from an action (the underlying architecture)
Feb 01 18:20:22 <weierophinney> ralphschindler, mvc doesn't "listen" for a result. Controllers set the event's result when done with dispatch.
Feb 01 18:20:40 <Thinkscape> hmm... but that introduces some lazy typing (implicit structures) like, inside a controller: return array('redirect'=>true,'redirectUrl'=>'http://foo') ...
Feb 01 18:20:50 <weierophinney> ralphschindler, if the result is a Response object, the event loop ends, and the response gets kicked out and returned immediately.
Feb 01 18:21:12 <Thinkscape> aaah
Feb 01 18:21:17 <weierophinney> Thinkscape, like I said above, if you're going to redirect, you'll likely simply return a response object.
Feb 01 18:21:40 <Thinkscape> that makes sense... you skip the strategies+rendering part then
Feb 01 18:21:44 <weierophinney> exactly
Feb 01 18:21:46 <Thinkscape> (altogether)
Feb 01 18:22:20 <PadraicB> I don't see it causing confusion muself
Feb 01 18:22:32 <ralphschindler> if you return a result of some kind, does the Application\View\Listener not get an opportunity to do something with it?
Feb 01 18:22:38 <ralphschindler> but if you return a response, it bypasses that?
Feb 01 18:22:42 <EvanDotPro> that's one of the places in zf2 so far where i haven't been confused, tbh
Feb 01 18:22:54 <flavius> Hi
Feb 01 18:23:14 <weierophinney> ralphschindler, if you return a Response object, rendering would not occur. If you return something else, the view will pass it to the rendering strategies to determine what to do with it.
Feb 01 18:23:15 <EvanDotPro> (the returning a response to short circuit the dispatching)
Feb 01 18:23:45 <Thinkscape> actually, similar things will happen with exception during dispatch
Feb 01 18:23:53 <Thinkscape> if a controller throws an exception (i.e. db error)
Feb 01 18:24:08 <Thinkscape> That's something for either app-leve event or a view strategy
Feb 01 18:24:12 <weierophinney> yep
Feb 01 18:24:13 <EvanDotPro> Thinkscape: yes – that's something we seriously need to normalize right now, too.
Feb 01 18:24:39 <weierophinney> the view layer should make this fairly easy to implement, though it will require some minor changes to the workflow within Application::run
Feb 01 18:24:59 <Thinkscape> EvanDotPro: agreed. Imagine a streamlined "ErrorHandlingViewStrategy" that does just that...
Feb 01 18:25:35 <EvanDotPro> Thinkscape: yep, something along those lines would be really nice
Feb 01 18:25:39 <weierophinney>
Feb 01 18:26:24 <Thinkscape> Anyone against the "view rendering RFC" as an architecture ?
Feb 01 18:26:41 <PadraicB> That is confusing though - presumably exceptions are app level concerns (and the view's thereafter should that be configured)
Feb 01 18:26:53 <weierophinney> As noted, in prototyping, I'm seeing a few rough edges, but overall, it feels sound when I implement it in projects
Feb 01 18:27:29 <MikeA> Given that in the skeleton application it begins in Application/Module.php at present, where do you intend the view should "start"?
Feb 01 18:27:58 <weierophinney> MikeA, what do you mean, exactly?
Feb 01 18:28:26 <PadraicB> Where it's first instantiated do you mean, MikeA?
Feb 01 18:28:34 <weierophinney> ah
Feb 01 18:28:42 <MikeA> PadraicB: yes
Feb 01 18:29:21 <weierophinney> So, right now, when Akrabat and I have used it, we've done it in Application\Module in a bootstrap listener. We pull the View from the locator, and then attach it (as an aggregate) to the application events instance.
Feb 01 18:29:40 <weierophinney> We could potentially automate that in either the Application instance and/or Bootstrap, however.
Feb 01 18:29:58 <MikeA> Saw that, but when writing about it ins
Feb 01 18:30:10 <MikeA> ...instantiating view seemed to belong elsewhere
Feb 01 18:30:18 <MikeA> Not that I know where
Feb 01 18:30:51 <DASPRiD> oh meeting!
Feb 01 18:31:00 <ocramius> wb DASPRiD
Feb 01 18:31:08 <Thinkscape> zf1 also used bootstrap (view app resource) for that, but it DID have a "default" implementation if one didn't use the bootstrap.
Feb 01 18:31:49 <weierophinney> Thinkscape, we can actually still do that. The way I prototyped means that it will attach renderers by default.
Feb 01 18:32:05 <weierophinney> the bit it can't do right now is pull those renderers from DI, which would simplify it even more.
Feb 01 18:32:09 <PadraicB> cough, ViewRenderer
Feb 01 18:32:09 <ocramius> well, until it's sealed in Zend\Mvc
Feb 01 18:32:20 <weierophinney> PadraicB, different beast.
Feb 01 18:32:29 <PadraicB> Ugly terrible beast, aye...
Feb 01 18:32:32 <ocramius> weierophinney: what would you pull from the locator? an interface? an alias?
Feb 01 18:32:45 <MikeA> k – I'm +1 for RFC
Feb 01 18:33:10 <weierophinney> ocramius, the DefaultRenderingStrategy attaches three renderers by default – PhpRenderer, JsonRenderer, and FeedRenderer, and has some strategies for selection of each.
Feb 01 18:33:40 <weierophinney> ocramius, so, we'd potentially pull those from the locator within the strategy class, just to make usage simpler.
Feb 01 18:33:50 <EvanDotPro> would it make sense to simply pull a ListenerAggreaget from the locator for this?
Feb 01 18:33:54 <Aldemar> weierophinney: in beta2 you can't have 2 controllers in 2 modules with the same di alias, di gets
confused and always takes either one, I don't know if you addressed that problem in this rfc
Feb 01 18:33:59 <EvanDotPro> then leave everything else up to the implementation
Feb 01 18:33:59 <weierophinney> EvanDotPro, that's what I do, actually.
Feb 01 18:34:02 <DASPRiD> (The PhpRenderer renders PHP?)
Feb 01 18:34:06 <ocramius> weierophinney: I would pull $listener = $locator->get('Zend\Mvc\View\RenderingStrategy');
Feb 01 18:34:09 <EvanDotPro> weierophinney: oh nice! i should actually look at it lol
Feb 01 18:34:10 <ocramius> instead of $listener = $locator->get('Zend\Mvc\View\DefaultRenderingStrategy');
Feb 01 18:34:17 <ocramius> that would allow for preferences
Feb 01 18:34:25 <ocramius> (maybe I'm liking that feature too much)
Feb 01 18:34:36 <weierophinney> Aldemar, this addresses it insofar as you will typically return ViewModel instances specifying the view "script" (just a token, actually) to render.
Feb 01 18:35:06 <Thinkscape> ocramius's got a point
Feb 01 18:35:13 <weierophinney> ocramius, makes sense to me.
Feb 01 18:35:22 <Thinkscape> but it also needs to work without any di alias/def
Feb 01 18:35:35 <ocramius> Thinkscape: that needs Di preference
Feb 01 18:35:40 <ocramius> Thinkscape: no way around it
Feb 01 18:35:45 <weierophinney> Thinkscape, if we do it as a marker interface, then it's pretty easy to use as a DI preference or an alias.
Feb 01 18:35:48 <Thinkscape> ah - and it need to be extendable (as opposed to replacable)
Feb 01 18:35:51 <ocramius> Thinkscape: otherwise definition, choose one of the two
Feb 01 18:35:57 <ocramius>
Feb 01 18:36:05 <weierophinney> Thinkscape, yep.
Feb 01 18:36:07 <Thinkscape> ocramius: ah, so now I dislike it
Feb 01 18:36:19 <flavius> shouldn't aliases be prefixed with the module name, as to avoid confusion?
Feb 01 18:36:26 <Thinkscape> Probably 90% of people will use DefaultRend* because it does the job...
Feb 01 18:36:34 <DASPRiD> wasn't di meant to be completly optional?
Feb 01 18:36:38 <Thinkscape> but there needs to be a simple way to add-on to that behavior
Feb 01 18:36:39 <DASPRiD> or do i misunderstadn that?
Feb 01 18:36:45 <Thinkscape> (instead of replacing the whole)
Feb 01 18:36:46 <weierophinney> flavius, not always. Sometimes you may want to extend a module – in that case, a prefix may actually be counter-intuitive.
Feb 01 18:36:49 <ocramius> DASPRiD: then call it "locator"
Feb 01 18:37:09 <weierophinney> DASPRiD, it's really an implementation detail
Feb 01 18:37:11 <ocramius> DASPRiD: I still confuse them when writing, my fault
Feb 01 18:37:26 <weierophinney> so, any objections to ratifying the RFC and moving forward with development in earnest?
Feb 01 18:37:43 <ocramius> I'm fine with the RFC
Feb 01 18:38:12 <EvanDotPro> +1 let's make this happen
Feb 01 18:38:19 <ralphschindler> +1
Feb 01 18:38:24 <saltybeagle> weierophinney: I say you move forward, in earnest. +1
Feb 01 18:38:55 <weierophinney> there's still room for some changes, and if ralphschindler has some really good objections to terminology, I'll listen.
Feb 01 18:38:55 <Thinkscape> going once... going twice...
Feb 01 18:39:10 <flavius> ralphschindler: has the issue we just discussed on #zftalk.2 been raised here too?
Feb 01 18:39:18 <weierophinney> DONE
Feb 01 18:39:31 <weierophinney> flavius, nope. Save it for after the other topics are complete.
Feb 01 18:39:35 <DASPRiD> Thinkscape, sold for $29
Feb 01 18:39:40 <weierophinney> NEXT ITEM:
Feb 01 18:39:43 <Thinkscape> + S&H
Feb 01 18:39:55 <Aldemar> +1 as far as I can have same aliases in more than 1 module
Feb 01 18:39:59 <weierophinney> ralphschindler has created a poll surrounding CS for type names: http://framework.zend.com/wiki/display/ZFDEV2/POLL+-+Coding+Standards+for+Type+Names
Feb 01 18:40:11 <MikeA> it's locked
Feb 01 18:40:13 <weierophinney> Aldemar, yes – see above. It's more explicitly done now than implicitly.
Feb 01 18:40:17 <weierophinney> MikeA, right, that's the poitn
Feb 01 18:40:19 <weierophinney> SO
Feb 01 18:40:31 <DASPRiD> i like explicitlity
Feb 01 18:40:39 <weierophinney> that page's polls are LOCKED because ralphschindler wants to find out if it accurately captures the various options.
Feb 01 18:40:54 <Thinkscape> chuckles – "Naming for Trait Types"
Feb 01 18:40:56 <ralphschindler> (as we discussed the plan was last week )
Feb 01 18:40:57 <Thinkscape> Traits FTW
Feb 01 18:40:58 <weierophinney> DOES ANYBODY WANT ANY CHANGES TO THAT POLL?
Feb 01 18:41:13 <DASPRiD> Thinkscape, uh
Feb 01 18:41:20 <PadraicB> None here
Feb 01 18:41:24 <DASPRiD> Thinkscape, shouldn't the 5.4 discussion come first?
Feb 01 18:41:29 <Thinkscape> DASPRiD: it's like a little hint on what's coming next
Feb 01 18:41:30 <PadraicB>
Feb 01 18:41:36 <weierophinney> DASPRiD, NO
Feb 01 18:41:53 <MikeA> Poll's fine
Feb 01 18:42:19 <ralphschindler> if no additions, the next question is when to open and close it
Feb 01 18:42:33 <Thinkscape> ralphschindler: how about traits were held in a namespace container ?
Feb 01 18:42:40 <ralphschindler> btw, you can always change your vote once you've cast it, until it closes
Feb 01 18:42:50 <Thinkscape> As it's new for php, how would i.e. java do that ?
Feb 01 18:43:06 <ralphschindler> i don't follow Thinkscape
Feb 01 18:43:15 <Thinkscape> My idea is: Zend\Stdlib\Traits Zend\Http\Client\Traits etc.
Feb 01 18:43:21 <Thinkscape> Group them
Feb 01 18:43:30 <Thinkscape> not thought out
Feb 01 18:43:34 <DASPRiD> Thinkscape, singular Trait plz
Feb 01 18:43:34 <weierophinney> ew
Feb 01 18:43:34 <Thinkscape> just throwing a bone .. etc.
Feb 01 18:43:35 <NickBelhomme_> aren't we discussing poll still? The moderator didn't move on yet
Feb 01 18:43:47 <ralphschindler> Exceptions are the only things we do that for
Feb 01 18:43:47 <weierophinney> thank you, NickBelhomme_
Feb 01 18:43:54 <Thinkscape> I know
Feb 01 18:43:56 <Thinkscape> traits are new
Feb 01 18:43:59 <Thinkscape> so we can discuss it
Feb 01 18:44:05 <ocramius> weierophinney: poll open till next wednesday imo
Feb 01 18:44:07 <weierophinney> Thinkscape, java doesn't have traits, so we're carving new territory here with naming.
Feb 01 18:44:11 <ocramius> from now
Feb 01 18:44:25 <MikeA> ocramius: +1
Feb 01 18:44:30 <Thinkscape> Well, I kinda like the grouping because it allows for:
Feb 01 18:44:41 <Thinkscape> use Zend\Stdlib\Features <--------- this holds all traits
Feb 01 18:44:42 <PadraicB> Poll seems fine unless someone is just about to object... Voting period of 5-7 days should be plenty.
Feb 01 18:44:54 <ralphschindler> Thinkscape is proposing an addition to the provided names, so i think its valid to entertain
Feb 01 18:45:06 <Thinkscape> then later class XYZ
Feb 01 18:45:07 <weierophinney> I'm fine with adding the option – more options is fine.
Feb 01 18:45:10 <ralphschindler> I'm ok with adding it, Thinkscape , although i wouldn't vote for it
Feb 01 18:45:20 <weierophinney> Thinkscape, can you edit that page and add it, please?
Feb 01 18:45:37 »» Thinkscape is editing
Feb 01 18:45:41 <ralphschindler> thanks Thinkscape
Feb 01 18:45:55 <weierophinney> any other changes anybody wants to see?
Feb 01 18:46:06 <ocramius> nope
Feb 01 18:46:06 <DASPRiD> Thinkscape, tho why would you specially namespace traits but not interfaces
Feb 01 18:46:26 <EvanDotPro> ocramius: +1 for leaving polls open for 7 days
Feb 01 18:46:41 <Thinkscape> DASPRiD: because of how traits work
Feb 01 18:46:42 <ralphschindler> we have a full week to vote, so i think discussions on individual items can happen in zftalk.2
Feb 01 18:46:43 <weierophinney> DASPRiD, usage is different.
Feb 01 18:46:47 <Thinkscape> It's like mini-classes
Feb 01 18:46:53 <ralphschindler> and, you can change your vote as many times as you like
Feb 01 18:47:05 <Thinkscape> you compose a big class from smaller ones, that's why you can call it features, or plugins or blocks or som,eting like that
Feb 01 18:47:20 <weierophinney> I can see the point. Not 100% sure I agree, and I think the namings don't have to dictate a subnamespace. But we can discuss on the list and/or #zftalk.2
Feb 01 18:47:26 <ralphschindler> wed following this meeting and closed before next weeks meeting, is that ratified?
Feb 01 18:47:31 <NickBelhomme_> dispatch or setOptions is not really a feature
Feb 01 18:48:12 <weierophinney> NickBelhomme_, it is in a way – you can compose that stuff in via traits in order to reduce the amount of coding. But yes, "feature" as a terminology may not be completely accurate.
Feb 01 18:48:21 <DASPRiD> NickBelhomme_, i thought we were getting rid of setOptions eventually
Feb 01 18:48:30 <ralphschindler> i meant, opening it after this meeting, and closing it before the next.
Feb 01 18:48:42 <weierophinney> any object to ralphschindler?
Feb 01 18:48:56 <DASPRiD> nah, sounds fine mwop
Feb 01 18:48:59 <weierophinney> if you're uncertain about some of the options/ramifications, ask on the ML or #zftalk.2
Feb 01 18:49:03 <NickBelhomme_> DASPRiD, just examples, that feature is a wrong name grouping, but hell, that can be included in the poll, I will not vote for that
Feb 01 18:49:19 <weierophinney> I'm going to call it in 3
Feb 01 18:49:25 <DASPRiD> NickBelhomme_, mh, not working for it, or voting against it?
Feb 01 18:49:27 <weierophinney> 2
Feb 01 18:49:40 <weierophinney> 1
Feb 01 18:49:43 <weierophinney> NEXT TOPIC
Feb 01 18:50:00 <DASPRiD> (get ready to rumble)
Feb 01 18:50:00 <ralphschindler> Thinkscape: by Feature, do you mean Trait ?
Feb 01 18:50:10 <weierophinney> I sprung this yesterday in #zftalk.2 : do we want to consider a minimum version of 5.4 for ZF2.
Feb 01 18:50:10 <ralphschindler> b/c that particular poll is specifically about traits
Feb 01 18:50:19 <weierophinney> ralphschindler, yes
Feb 01 18:50:23 <weierophinney> but we've moved on now.
Feb 01 18:50:30 <ralphschindler> Thinkscape: pm
Feb 01 18:50:31 <DASPRiD> why not just call that namespace "Trait"… or "Mixin"
Feb 01 18:50:31 <weierophinney> So, re: 5.4.
Feb 01 18:50:40 <EvanDotPro> personally i'd be +1 for 5.4 (i probably want it more than most here), but in general, i think it might be jumping the gun.
Feb 01 18:50:41 <weierophinney> DASPRiD, WE'VE MOVED ON
Feb 01 18:50:52 <weierophinney> So, let me summarize a few points real quick.
Feb 01 18:50:52 <DASPRiD> weierophinney, that was just a sidenote
Feb 01 18:51:03 <NickBelhomme_> Personally seeing how ZF2 is evolving
Feb 01 18:51:04 <EvanDotPro> my concern in NOT going with 5.4 is that we now have to also maintain zf2 on 5.3 while we move on to zf3.
Feb 01 18:51:13 <NickBelhomme_> I think we should consider targetting 5.4
Feb 01 18:51:38 <weierophinney> One reason to consider it is (a) mainteance later down the line (less to rewrite), (b) pushing 5.4 adoption, and (c) baseline performance of the framework (5.4 is faster even than 5.3)
Feb 01 18:51:47 <weierophinney> that's actually three reasons. Whatever.
Feb 01 18:52:15 <weierophinney> As a few folks noted, there are a lot of companies already planning for ZF2, and since we've said 5.3 all along, this is a bit of an upset.
Feb 01 18:52:15 <EvanDotPro> let's even ignore (b) as that shouldn't be our primary influence in this decision, just a potential positive side-effect
Feb 01 18:52:29 <DASPRiD> mh, c) is no really valid, current zf2 already makes use of the performance gain in 5.4, no?
Feb 01 18:52:41 <NickBelhomme_> I agree with EvanDotPro , 2.0 took already 1.5 years, if you want to produce zf3.0 it will take again a long time, so why not put it in there already, 1 less major version to maintain
Feb 01 18:52:52 <weierophinney> DASPRiD, I said baseline – we'd be able to depend on that for all ZF2 users.
Feb 01 18:52:56 <ocramius> (c) isn't valid for me too....
Feb 01 18:53:14 <PadraicB> I'm -1 - for personal reasons: I'm invested in PHP 5.3 for at least another 12 months.
Feb 01 18:53:19 <weierophinney> So, on the flip side of things... 5.3 adoption has not been getting a ton of traction, particularly in distros.
Feb 01 18:53:29 <flavius> weierophinney: those companies are ready to make the jump, right? so why not do it to 5.4 then, if they do it anyway?
Feb 01 18:53:40 <MikeA> I thought about this all day: I was definate NO due to limited number of 5.4 hosts. However, what about with VMs whereby developers can load 5.4 if hosts don't want to?
Feb 01 18:53:40 <weierophinney> and for those who have, moving to 5.4 seems to be a "it's a ways in the future yet"
Feb 01 18:54:01 <weierophinney> flavius, see above: distros are not necessarily making the jump, and not everyone wants to maintain their own packages.
Feb 01 18:54:17 <flavius> long live archlinux heh
Feb 01 18:54:23 <weierophinney> MikeA, that was part of my argument as well.
Feb 01 18:54:31 <NickBelhomme_> I gave a talk on php5.4 this weekend, and if the room was packed with 100 people, only 4 had tried php5.4 (1 was including derick)
Feb 01 18:54:31 <DASPRiD> so ubuntu will have php 5.4 in april: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54
Feb 01 18:54:41 <weierophinney> Anyways, that's the summary of the discussion.
Feb 01 18:54:54 <NickBelhomme_> so ... that says something about the frontline of PHP devs (conference people are considered front line)
Feb 01 18:55:02 <ocramius> NickBelhomme_: haven't tried it on my own too if not for travis...
Feb 01 18:55:06 <Aldemar> -1 to 5.4 here
Feb 01 18:55:09 <weierophinney> DASPRiD, it's a blueprint. Discussion on the internals list is they may back out of that due to lack of a few security patches they feel are critical.
Feb 01 18:55:12 <NickBelhomme_> low interest in new techs, features
Feb 01 18:55:13 <EvanDotPro> i think it's at least worth putting up for a community vote
Feb 01 18:55:51 <Slamdunk> +1 for community vote
Feb 01 18:55:53 <weierophinney> One thing I didn't note: we can OFFER traits for end-user consumption, without making ZF2 require 5.4 to operate.
Feb 01 18:55:55 <ralphschindler> EvanDotPro: zf2-meeting vote, or a poll on the wiki?
Feb 01 18:56:05 <weierophinney> poll on the wiki, I think.
Feb 01 18:56:07 <DASPRiD> weierophinney, yeah, it is probably more likely to get 5.4 in ubuntu 12.10 (which is a non LTS release…)
Feb 01 18:56:17 <Thinkscape> -1 for offering traits in PHP 5.3 framework
Feb 01 18:56:19 <MikeA> Turning to the marketing aspect of this bombshell, you put it up for community vote and there comes potential for negative press feedback
Feb 01 18:56:21 <Thinkscape> That's confusng
Feb 01 18:56:21 <weierophinney> DASPRiD, and that highlights the concerns for some.
Feb 01 18:56:22 <ocramius> EvanDotPro: ok for the poll on the meeting
Feb 01 18:56:24 <weierophinney> Thinkscape, why?
Feb 01 18:56:32 <Aldemar> to launch something in a tech that doesn't have at least 1 year (5.4) in the market is not well seen
Feb 01 18:56:39 <EvanDotPro> SpiffyJr metioned that is seems a little late for a change like this, being half way through beta, but i feel like maintaining zf2 on 5.3 and then trying to move on with zf2 on 5.4 will turn into a huge headache and hold things back a lot.
Feb 01 18:56:39 <EvanDotPro> ralphschindler: poll on the wiki, at LEAST 7 days with posts to the mailing list.. it's a rather large decision, everyone should have voice
Feb 01 18:56:42 <weierophinney> Thinkscape, if it makes development easier/faster for those useing 5.4, why not offer them?
Feb 01 18:56:53 <ralphschindler> +1 to EvanDotPro's suggestion
Feb 01 18:57:08 <weierophinney> EvanDotPro, +1
Feb 01 18:57:12 <Slamdunk> +1 to EvanDotPro's suggestion
Feb 01 18:57:16 <ocramius> +1
Feb 01 18:57:17 <Aldemar> zf2.5 should be in 5.4, by now we should stay using 5.3
Feb 01 18:57:20 <DASPRiD> EvanDotPro, i don't really see that zf2->3 transition would take up much time
Feb 01 18:57:26 <ralphschindler> although, and this is directed at weierophinney - how do we resolve the greater good against the needs of a few?
Feb 01 18:57:28 <Thinkscape> weierophinney: the same reason there aren't any 5.3 features used in zf1
Feb 01 18:57:28 <MikeA> EvanDotPro: that's a technologists POV – business people who pay for projects want security
Feb 01 18:57:42 <EvanDotPro> DASPRiD: i mean ongoing maintenance holding us back / slowing us down, mostly.
Feb 01 18:57:50 <EvanDotPro> DASPRiD: think of the constant backports
Feb 01 18:58:00 <EvanDotPro> zf2 users will press for white a long period of support
Feb 01 18:58:00 <ralphschindler> i suspect the larger community wants to target 5.4, but we need to decide what we're sacrificing and if its worth it
Feb 01 18:58:01 <weierophinney> Aldemar, we can't jump to a new minor version of PHP within the same major cycle.
Feb 01 18:58:04 <Aldemar> +1 MikeA
Feb 01 18:58:09 <DASPRiD> EvanDotPro, didn't we want to shorten the release cycles anyway?
Feb 01 18:58:17 <EvanDotPro> s/white/quite
Feb 01 18:58:19 <NickBelhomme_> DASPRiD, zf2->zf3 is not a big transition, but some will not host 5.4 and thus you have to maintain to frameworks
Feb 01 18:58:20 <DASPRiD> and thus, the lifetime cycles?
Feb 01 18:58:28 <NickBelhomme_> s/to/two
Feb 01 18:58:29 <weierophinney> Thinkscape, this is different. We'd be offering code for end-user use, not for internal use.
Feb 01 18:58:35 <DASPRiD> NickBelhomme_, well at least for some time…
Feb 01 18:58:58 <Thinkscape> My opinion: zf2 already requires a lot of commitment in both consumption and extension. It requires a new php ver (as compared to zf1) so the adoption will be abysmal at first. BUT – zf2 is "cutting-edge" so it can use any modern php version.
Feb 01 18:59:16 <DASPRiD> weierophinney, zf2 release was planned around summer/zendcon, right?
Feb 01 18:59:29 <Thinkscape> We can argue 5.4 vs 5.3 the same way we argue 5.1 vs 5.3 — same thing, same problems in some businesses and webhosts ..
Feb 01 18:59:30 <MikeA> I suggest some research of hosts intentions around the world before embarking on this route
Feb 01 18:59:33 <NickBelhomme_> the users who will be using zf2 will already be the bleeding edge of devs
Feb 01 18:59:37 <weierophinney> DASPRiD, no planned date, but currently targetting summer.
Feb 01 18:59:53 <DASPRiD> weierophinney, well, by then, not all of the major distros will have 5.4
Feb 01 18:59:55 <NickBelhomme_> I do not see general devs implement it too be honest, sorry guys
Feb 01 19:00:08 <Aldemar> Thinkscape: there are some hosts that hasn't even upgrade to 5.3 yet
Feb 01 19:00:11 <NickBelhomme_> not at least the first year after release
Feb 01 19:00:16 <flavius> +1 "the users who will be using zf2 will already be the bleeding edge of devs"
Feb 01 19:00:19 <DASPRiD> which basically answers the question to not go for php5.4 dependency
Feb 01 19:01:00 <weierophinney> would anyone here like to volunteer and reach out to some of the major hosting companies, and find out plans for 5.3/5.4 adoption?
Feb 01 19:01:09 <Thinkscape> Aldemar: EXACTLY, but you've proven my point
Feb 01 19:01:16 <Thinkscape> There are probably hosts that haven't upgraded to 5.0
Feb 01 19:01:19 <EvanDotPro> in the first wave of zf2 users, developers without control of thier _AMPP stack are probably going to be a minority, if i had to venture a guess.
Feb 01 19:01:22 <MikeA> What's the possibility of starting ZF3 to run in parallel with ZF2?
Feb 01 19:01:27 <Thinkscape> not in the scope of zf2 which is advanced as it is (code-wise)
Feb 01 19:01:38 <weierophinney> MikeA, we actually already forked with that idea in mind when at ZendCon
Feb 01 19:01:44 <Aldemar> Thinkscape: lol, no php5, that would be the cheapest
Feb 01 19:01:56 <NickBelhomme_> maintaining ZF1, ZF2 and ZF3 => horrible
Feb 01 19:02:01 <MikeA> weierophinney: that's interesting – and?
Feb 01 19:02:03 <EvanDotPro> NickBelhomme_: exactly my concern
Feb 01 19:02:05 <DASPRiD> EvanDotPro, sure, on a root you can install anything you want… but usually sys admins go with the distributions packages
Feb 01 19:02:15 <weierophinney> MikeA, it's possible, but see NickBelhomme_ and EvanDotPro
Feb 01 19:02:34 <ocramius> Ok, now I'm confused...
Feb 01 19:02:36 <Thinkscape> why zf3?? zf3 === zf2+traits ? awful
Feb 01 19:02:52 <Thinkscape> Guys – regarding packages
Feb 01 19:02:52 <EvanDotPro> DASPRiD: sysadmins should be at the mercy of the web developers – the organization you're describing has a flawed setup
Feb 01 19:02:54 <weierophinney> Thinkscape, it would be more than that
Feb 01 19:03:06 <ocramius> I'm thinking about symfony 2 in this exact moment and about doctrine 2, which has no file caching mechanism, and which almost requires the user to provide a VM
Feb 01 19:03:12 <Thinkscape> zf2 launch === distro packages of 5.4 + 1 month (at least)
Feb 01 19:03:15 <EvanDotPro> DASPRiD: let's not get off topic, that's a different argument lol
Feb 01 19:03:22 <ocramius> and this is a case where 5.4 could be addressed by the dev
Feb 01 19:03:35 <EvanDotPro> anyway – i have to take off, but see my earlier suggestion.
Feb 01 19:03:40 <DASPRiD> EvanDotPro, i personally won't upgrade my server as well and wait for the ubuntu dist-upgrade (+1 month for usual patches)
Feb 01 19:03:41 <MikeA> whether it's Zf2, ZF3 or ZF2 & 3 there are going to be maintenance issues – they are technical, not business strategy matters
Feb 01 19:04:07 <EvanDotPro> "poll on the wiki, at LEAST 7 days with posts to the mailing list.. it's a rather large decision, everyone should have voice"
Feb 01 19:04:18 <Bittarman> zf3? thats quite a clanger to turn up and see talked about
Feb 01 19:04:20 <Aldemar_> we haven't released 2.0 and we are talking about 3.0
Feb 01 19:04:21 <ralphschindler> +1, polls can have comments btw
Feb 01 19:04:22 <EvanDotPro> ^^ that's my vote here
Feb 01 19:04:28 <EvanDotPro> ralphschindler: yep
Feb 01 19:04:34 »» Thinkscape_ got disconnected
Feb 01 19:04:44 <EvanDotPro> anyway, i'll be back in ~30 in ztalk.2 at least.
Feb 01 19:05:02 <Thinkscape_> sooo - zf3 should be a huge leap forward, same as zf2 compared to zf1
Feb 01 19:05:10 <ocramius> btw, I guess I'll think about it a bit more, because I just changed my idea to "+1", which means I have no clear ideas
Feb 01 19:05:37 <DASPRiD> Thinkscape_, not neccessarly
Feb 01 19:05:38 <weierophinney> Thinkscape, see, that's where you're in disagreement with a lot of folks. The discussions since August are suggesting devs want shorter intervals between major releases, with fewer big changes.
Feb 01 19:05:55 <DASPRiD> yeah, switchting to a rapid release model
Feb 01 19:05:55 <NickBelhomme_> weierophinney, +1
Feb 01 19:06:02 <NickBelhomme_> DASPRiD, +1
Feb 01 19:06:09 <weierophinney> I'm going to call it at this point, as we're past the hour.
Feb 01 19:06:19 »» Aldemar_ is now known as Aldemar
Feb 01 19:06:26 <weierophinney> Let's open a poll on the wiki, and start a discussion there, on the ML, and in #zftalk.2
Feb 01 19:06:26 <NickBelhomme_> so we follow EvanDotPro his suggestion?
Feb 01 19:06:32 <Bittarman> whats wrong with jsut offering support for 5.4 in zf2, but not making it a minimum, like we already do in zf1 for php 5.3
Feb 01 19:06:34 <weierophinney> we'll leave it open for at least a week.
Feb 01 19:06:43 <Thinkscape_> ugh, that means less consistency, parallel maintenance of several concurrent versions, documentation nightmare, missing features...
Feb 01 19:06:45 <Aldemar> +1 weierophinney
Feb 01 19:06:49 <weierophinney> Bittarman, I suggested that earlier. Most like the idea. Thinkscape hates it.
Feb 01 19:06:56 <Thinkscape_> i.e. in one point in time you could have zf3, zf4, zf5 :\
Feb 01 19:07:12 <weierophinney> Thinkscape, we need to setup a release policy, obviously, so that doesn't happen.
Feb 01 19:07:12 <DASPRiD> Thinkscape_, not different than prior minor releases
Feb 01 19:07:14 <flavius> zfx++
Feb 01 19:07:16 <Thinkscape_> weierophinney: wait, don't stick me out
Feb 01 19:07:22 <Thinkscape_> It's about project management
Feb 01 19:07:24 <Bittarman> weierophinney ah, k. that had me worried, (was scanning up and down the backlog thinking wtf!)
Feb 01 19:07:27 <DASPRiD> weierophinney, Thinkscape_: heh, think: Firefox
Feb 01 19:07:32 <Thinkscape_> show me a good way to do it for "a php framework" and I'm all in
Feb 01 19:07:32 <weierophinney> Thinkscape, the idea is 18-24 months between major releases.
Feb 01 19:07:34 <MikeA> Thinkscape_: that's an area of persuasion for me
Feb 01 19:07:39 <Thinkscape_> Firefox is NOT php framework
Feb 01 19:07:43 <Thinkscape_> same as Google Chrome
Feb 01 19:07:56 <Thinkscape_> ZF will not auto-update itself in the background ...
Feb 01 19:08:04 <DASPRiD> Thinkscape_, heh…
Feb 01 19:08:07 <Thinkscape_> weierophinney: 18-24 mo is ok!
Feb 01 19:08:08 <weierophinney> As such, fewer big bits need rewriting, but newer versions are happening more frequently to allow BC breaks, architectural changes, etc – just more targetted.
Feb 01 19:08:15 <Thinkscape_> So that leaves us zf2 for the next 18 months
Feb 01 19:08:19 <weierophinney> Thinkscape_, right.
Feb 01 19:08:25 <Thinkscape_> back to business - php 5.4 for zf2 or not ?
Feb 01 19:08:28 <MikeA> I'm for letting folk dwell on this for a week or two before polling
Feb 01 19:08:34 <weierophinney> at about which time, ZF1 support ends, leaving us with just ZF2 + ZF3
Feb 01 19:08:39 <DASPRiD> Thinkscape_, well, in 18 months, php 5.4 should be spread enough
Feb 01 19:08:39 <ralphschindler> +1 on MikeA
Feb 01 19:08:43 <Thinkscape_> or wait for zf3 and in 18 months we could have php 6
Feb 01 19:08:44 <weierophinney> MikeA, +1
Feb 01 19:08:46 <Bittarman> Thinkscape_, we already do it for php 5.3 support in zf1... whats so bad about it in zf2??
Feb 01 19:08:47 <ralphschindler> lets do the poll between next meeting and the one following
Feb 01 19:08:52 <ralphschindler> one major poll at at a time
Feb 01 19:08:53 <weierophinney> Thinkscape_, unlikely.
Feb 01 19:08:53 <DASPRiD> Thinkscape_, heh
Feb 01 19:09:09 <weierophinney> kk
Feb 01 19:09:10 <PadraicB> Sry, missed the conversation .
Feb 01 19:09:11 <weierophinney> so...
Feb 01 19:09:13 <Thinkscape_> ... just a general idea... call it php 5.6 or whatever
Feb 01 19:09:28 <ocramius> MikeA: spread the word...
Feb 01 19:09:30 <weierophinney> Summary: we'll do a poll on the wiki, and have continued discussion in the comments there, on the ML, and in IRC.
Feb 01 19:09:31 <Thinkscape_> We are at tipping point now — between 5.3 and 5.4, next major
Feb 01 19:09:38 <PadraicB> Guys, is there some fundamental reason why ZF2 should adopt 5.4? This is a massive course correction right at the end of the process.
Feb 01 19:09:44 <weierophinney> Poll will open officially in 1 week, and stay open in a week.
Feb 01 19:10:13 <weierophinney> PadraicB, the reasons I raised it are because 5.4 is dropping in the next few weeks as stable.
Feb 01 19:10:25 <Bittarman> PadraicB, because in a years time, it would be nice for zf2 users to be able to make use of php 5.4 features, without being held back by their framework.
Feb 01 19:10:26 <weierophinney> And there are a number of features that could make development and maintenance easier.
Feb 01 19:10:27 <DASPRiD> PadraicB, i would +1 it only if php 5.4 would already be in all major distris by now
Feb 01 19:10:29 <Thinkscape_> + traits for de-duplication and add-on functionality for user classes
Feb 01 19:10:38 <NickBelhomme_> If ZF2 would be released as stable within 2 months => NO
Feb 01 19:10:50 <Thinkscape_> DASPRiD: will you +1 for that idea in may ?
Feb 01 19:10:51 <MikeA> DASPRiD: +1
Feb 01 19:11:13 <Thinkscape_> Remember - We are talking future .... not TODAY, because today is not zf2 RC day.
Feb 01 19:11:21 <ralphschindler> All in favor of discussing this in #zftalk.2 for a week, then, if it makes sense and its still valid, polling to the larger community between next wed. and the wed following?
Feb 01 19:11:24 <DASPRiD> exactly Thinkscape_
Feb 01 19:11:29 <MikeA> Dare I say it, how long did it take MS to stabilise?
Feb 01 19:11:30 <Thinkscape_> so – should zf2 be php 5.4 WHEN it shipps mid 2012
Feb 01 19:11:31 <NickBelhomme_> ralphschindler, +1
Feb 01 19:11:32 <Thinkscape_> ?
Feb 01 19:11:36 <weierophinney> PadraicB, but we can have more discussion – I only wanted to raise it for discussion with this meeting.
Feb 01 19:11:56 <weierophinney> MikeA, bad analogy.
Feb 01 19:11:59 <DASPRiD> Thinkscape_, i wouldn't be able to run it on my dev machine, bad idea
Feb 01 19:12:04 <Aldemar> we have here +20 servers running 5.2 that haven't been able to update because of legacy applications, Now I'm trying to make the business understand that the path is zf2+5.3 and you are talking about 5.4!
Feb 01 19:12:10 <MikeA> weierophinney: couldn't resist
Feb 01 19:12:19 <weierophinney> MikeA, LOL
Feb 01 19:12:20 <Thinkscape_> DASPRiD: you lazy a.... dev... compile it
Feb 01 19:12:30 <weierophinney> Aldemar, that's why we're discussing it now, not deciding on it yet.
Feb 01 19:12:34 <Thinkscape_> Aldemar: so skip 5.3
Feb 01 19:12:38 <Thinkscape_> straight to 5.4
Feb 01 19:12:48 <Thinkscape_> (faster, safer, better, more lifetime ahead)
Feb 01 19:12:51 <DASPRiD> Thinkscape_, surely not compiling it
Feb 01 19:12:58 <weierophinney> Aldemar, bring up your concerns and what's driving them in the ML/IRC/etc so we can all understand how this affects users.
Feb 01 19:13:07 <Thinkscape_> DASPRiD: I'll hack your box and compile it for you..
Feb 01 19:13:09 <MikeA> Thinkscape_: then why isn't all the rage now?
Feb 01 19:13:10 <weierophinney> kk
Feb 01 19:13:11 <Aldemar> Thinkscape_, safer? 5.4 is already in rc
Feb 01 19:13:18 <weierophinney> LET'S MOVE DISCUSSION TO #zftalk.2
Feb 01 19:13:22 <DASPRiD> Thinkscape_, and make a deb package?
Feb 01 19:13:24 <weierophinney> thanks all for coming!