Skip to end of metadata
Go to start of metadata

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

<h2>Information</h2>

<ul>
<li>Date: 11 January 2012, 18:00-19:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-01-11 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Evan Coury (nickname EvanDotPro)</li>
<li>Next meeting: 25 January 2012</li>
</ul>

<h2>Summary</h2>

<h3>Finalize Beta3 Components</h3>

<p>Matthew raised a thread on the mailing list to start the ball rolling on finalizing the list of components for Beta3:</p>

<ul>
<li><a class="external-link" href="http://zend-framework-community.634137.n4.nabble.com/Planning-2-0-0beta3-tp4262342p4262342.html">http://zend-framework-community.634137.n4.nabble.com/Planning-2-0-0beta3-tp4262342p4262342.html</a></li>
</ul>

<p>Discussion ranged for some time, but the following was agreed upon:</p>

<ul>
<li>Beta3 will drop last week of February; components to be included should be code complete the previous week to allow for review.</li>
<li>Components slated for beta3:
<ul>
<li>Cloud (should be done Thursday, 12 Jan 2012)</li>
<li>Config (almost complete)</li>
<li>Log (almost complete)</li>
<li>DB (in process, and limited scope; see <a href="http://zend-framework-community.634137.n4.nabble.com/Zend-Db-For-Beta3-Timeline-td4269624.html">Ralph's post</a>)</li>
<li>View (<ac:link><ri:page ri:content-title="RFC - View Layer" /><ac:link-body>RFC now available</ac:link-body></ac:link>)</li>
<li>Console (Artur Bodera, aka Thinkscape, will spearhead, and piggy-back off of View)</li>
</ul>
</li>
<li>Components slated for beta4:
<ul>
<li>Forms</li>
<li>i18n/l10n <ac:emoticon ac:name="question" /></li>
</ul>
</li>
</ul>

<h3>ZF 1.X EOL</h3>

<p>Matthew indicated he's had a lot of inquiries surrounding community plans for the ZF 1.X end-of-life – how long we'll be supporting it, and to what extent.</p>

<p>Opinions ranged a ton, but the following was agreed upon:</p>

<ul>
<li>1.12 will be the last minor release of the 1.X series</li>
<li>Once 2.0 is marked stable, 1.12 will receive support for 18 months; such support will include only critical and security bugfixes.</li>
<li>Most agreed that the community should spearhead the EOL support. The consensus is to ask members of the existing CR Team who rely on ZF 1.X sites to assist, and to solicit additional volunteers via the mailing list (Mike Willbanks, aka lubs, volunteered during the meeting).</li>
</ul>

<h3>Brainstorm ZF2 Module Options</h3>

<p>Evan Coury indicated he's run into a number of situations where he needs direct access to module-specific configuration options. His examples included cases where he needed authentication adapters to hint whether or not a redirect was needed, whether or not an authentication adapter should select by username, and more (URLs are in the log, below). Right now, he's using static members on his module class that he sets during bootstrapping; the question is how we want to handle this as a framework.</p>

<p>Matthew indicated he's accomplished similar goals typically via direct injection via event listeners registered within a scope that has access to the application configuration. Several others voiced approval for this method, but also indicated it comes at a cost of complexity and education.</p>

<p>In the end, we decided there was not sufficient use cases or discussion prior to the meeting to warrant further discussion at this time; Evan promised to follow up on the list and in IRC.</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">
Jan 11 18:01:20 <EvanDotPro> alright.. let's get right into it... item #1, finalizing beta3 components
Jan 11 18:01:31 <EvanDotPro> agenda is here: http://framework.zend.com/wiki/display/ZFDEV2/2012-01-11+Meeting+Agenda
Jan 11 18:02:03 <DASPRiD> Beta 3 date was when?
Jan 11 18:02:27 <EvanDotPro> the priorities for Beta3 are currently View, Forms, and Db... with the other scheduled components being lower priority in favor of finishing the key componenets.
Jan 11 18:02:53 <weierophinney> DASPRiD, 4-6 weeks.
Jan 11 18:02:58 <Thinkscape> I'd propose we start with defining a desirable deadline
Jan 11 18:03:08 <DASPRiD> Opening links here is damn slow
Jan 11 18:03:27 <weierophinney> For those who haven't seen, I posted the View RFC today: http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+View+Layer
Jan 11 18:03:37 <Thinkscape> ralphschindler: do you see Db coming to an early working prototype in 4 weeks time ?
Jan 11 18:03:42 <DASPRiD> Config should be good for B3 then
Jan 11 18:03:54 <Thinkscape> DASPRiD: remember me ?
Jan 11 18:03:55 <weierophinney> Thinkscape, ralphschindler posted a list of targets for beta3 AND beta4
Jan 11 18:04:12 <weierophinney> with the assumption of 4-6 weeks for each beta
Jan 11 18:04:13 <ralphschindler> yep
Jan 11 18:04:36 <ocra|afk> Saw. Mwop, is there alreasy some sode or just rfc?
Jan 11 18:04:52 <ocra|afk> S/sode/code
Jan 11 18:04:53 <weierophinney> I think View is do-able, now that the RFC is ready, though we'll need to vote on it soonish.
Jan 11 18:05:05 <weierophinney> ocra|afk, no, but it's actually pretty minimal in terms of code.
Jan 11 18:05:49 <weierophinney> ocra|afk, runs an event to get a renderer, passes to a renderer, and then triggers another event for response munging.
Jan 11 18:06:17 <weierophinney> The one bit I'm unsure on is Forms, as I'm still in early processes of creating an RFC.
Jan 11 18:06:42 <EvanDotPro> do we want to set any sort of target date to give people a psychological deadline?
Jan 11 18:07:16 <weierophinney> EvanDotPro, how about last week of February? That's actually around six weeks.
Jan 11 18:07:31 <DASPRiD> Re
Jan 11 18:07:33 <DASPRiD> Bah, I don't even notice when I'm disconnected
Jan 11 18:07:33 <weierophinney> with the idea that code should be complete the week prior.
Jan 11 18:07:43 <lsmith> weierophinney: while event driven view rendering seems very flexible .. it should also be noted that events tend to be a bitch to debug and basically require a step by step debugger to grasp .. so i would be quite cautious with events
Jan 11 18:07:59 <EvanDotPro> that sounds fair to me.. ralphschindler does that seem realistic with Db?
Jan 11 18:08:24 <weierophinney> lsmith, please read the RFC before making a judgment like that.
Jan 11 18:08:46 <weierophinney> lsmith, the events are for strategy selection and response munging specifically – they're more like filter chains in this regard.
Jan 11 18:08:50 <EvanDotPro> lsmith: the RFC is still very much an RFC.. feel free to read it and comment
Jan 11 18:09:03 <lsmith> weierophinney: i have .. well skimmed it just now
Jan 11 18:09:14 <EvanDotPro> right now we're just talking about what components will be scheduled for b3.
Jan 11 18:09:43 <ralphschindler> EvanDotPro: it is reasonable
Jan 11 18:09:45 <weierophinney> EvanDotPro, besides View, DB, and possibly Forms, it looks like Config and Log are about complete.
Jan 11 18:09:52 <ralphschindler> thats what my email was assuming
Jan 11 18:10:00 <lsmith> but i think its very smart that you guys are considering shipping a "view layer" out of the box .. thats missing in Symfony2 core
Jan 11 18:10:06 <DASPRiD> Evan: count config in.
Jan 11 18:10:23 <weierophinney> EvanDotPro, and ezimuel is almost done getting Cloud migrated and refactored to ZF2 – should be done by tomorrow.
Jan 11 18:10:29 <EvanDotPro> weierophinney: possibly forms? should we make a decision on that now?
Jan 11 18:10:36 <weierophinney> EvanDotPro, good point.
Jan 11 18:10:50 <EvanDotPro> k – counting Config and Cloud in for b3.
Jan 11 18:10:57 <weierophinney> lsmith, thanks – it's been a common request, and we felt it necessary to add.
Jan 11 18:11:01 <DASPRiD> Yay forms
Jan 11 18:11:01 <Thinkscape> I'd set up forms discussion in 2 weeks time, with an RFC and possibly a prototype to bash
Jan 11 18:11:36 <weierophinney> Thinkscape, with that, though, would we have time to get it in beta3? Also, in 2 weeks time, I won't be able to attend the meeting, as I'll be travelling to phpbnl. :-/
Jan 11 18:11:37 <skiller> +1 for view layer
Jan 11 18:11:43 <lsmith> for content type negotiation i have been meaning to sit down and implement mod_negotiation in php
Jan 11 18:11:57 <lsmith> maybe something we can collaborate on ..
Jan 11 18:12:00 <Thinkscape> that's 2 weeks out of 6 available..
Jan 11 18:12:06 <weierophinney> lsmith, that would be awesome – it could be consumed as a strategy easily.
Jan 11 18:12:18 <Thinkscape> weierophinney: "DefaultStrategy"
Jan 11 18:12:19 <weierophinney> lsmith, let's discuss elsewhere, though – off topic for this meeting.
Jan 11 18:12:27 <lsmith> k
Jan 11 18:12:30 <EvanDotPro> yeah let's stay on topic
Jan 11 18:12:40 <weierophinney> Thinkscape, damn, I meant to add that to the RFC, too. I'll update with that after the meeting.
Jan 11 18:12:47 <Thinkscape> Who's the Forms leader?
Jan 11 18:12:49 <DASPRiD> Neop: maybe we meet there
Jan 11 18:12:57 <DASPRiD> Mwop
Jan 11 18:12:58 <SpiffyJr> weierophinney, he is
Jan 11 18:13:12 <weierophinney> Thinkscape, right now, me, but if I get a reasonable RFC in place, there are a number of folks who have expressed interest in helping code it.
Jan 11 18:13:15 »» SpiffyJr is sad he's missed most the meeting already
Jan 11 18:13:15 <EvanDotPro> so to recap, we have View, Db, Config, and Cloud slated for release with Beta3 at the end of Feb.
Jan 11 18:13:19 <Thinkscape> ok, so it's up to you man, to say if 2 weeks is enough for an RFC to talk about on irc...
Jan 11 18:13:25 <Thinkscape> and then 4 weeks to implement fully...
Jan 11 18:13:29 <weierophinney> EvanDotPro, and Log
Jan 11 18:13:41 »» EvanDotPro adds Log to that list
Jan 11 18:13:47 <skiller> I understand that Console is out of scope for b3… do you think there is a chance it will make it to b4? Not sure how to read the statement about the availability.
Jan 11 18:13:51 <weierophinney> Thinkscape, well, 3. And don't forget there's work on View, too.
Jan 11 18:14:07 <weierophinney> Thinkscape, want to address skiller here – that's also on-topic.
Jan 11 18:14:16 <Thinkscape> weierophinney: in any case - it's your time you're allocating
Jan 11 18:14:27 <weierophinney> Thinkscape, it sounds a bit like you need View to be ready for Console...
Jan 11 18:14:35 <Thinkscape> yep
Jan 11 18:14:44 <DASPRiD> Really?
Jan 11 18:14:49 <EvanDotPro> so would it be safe to say Forms might be pushed to beta4
Jan 11 18:14:54 <MikeA> Is it essential that the view layer is well on before forms, or can development be run in conjunction?
Jan 11 18:15:00 <weierophinney> Thinkscape, though could you work on the application and routing layers before it's ready?
Jan 11 18:15:09 <Thinkscape> I feel it'd be great to have a "pure" MVC which allows for interactive input (CLI) requests and responses (console output).
Jan 11 18:15:17 <Thinkscape> weierophinney: yes
Jan 11 18:15:20 <weierophinney> EvanDotPro, let's target beta4 for forms. If we get it done for beta3, great, but if not, we've set the expectation.
Jan 11 18:15:44 <Kit-10> i second that weierophinney
Jan 11 18:15:52 <iH8> weierophinney, what happens to View\Helpers?
Jan 11 18:15:53 <weierophinney> MikeA, they could be in conjunction. The only view-related part of forms would be view helpers, and those can be done anytime.
Jan 11 18:15:55 <DASPRiD> +1
Jan 11 18:16:07 <Thinkscape> That said, console prototype can follow view. Routing too. I think 6 wks is enough for me to prepare a working prototype
Jan 11 18:16:11 <MikeA> weierophinney: +1
Jan 11 18:16:13 <weierophinney> iH8, they're already in place. the view layer is actually above the renderer, which is pretty stable right now.
Jan 11 18:16:16 <Thinkscape> (so people can play in console at last)
Jan 11 18:16:40 <weierophinney> Thinkscape, working prototype as in "include in beta3"?
Jan 11 18:16:42 <EvanDotPro> I18N? we had it slated for B2 originally..
Jan 11 18:16:53 <Thinkscape> yes, thought with no api freeze.
Jan 11 18:17:09 <weierophinney> EvanDotPro, I'm going to say beta4 on that, and I need to push thomas a bit harder to be more inclusive in his process.
Jan 11 18:17:15 <Thinkscape> i18n's kinda stalled
Jan 11 18:17:16 <weierophinney> so that it can actually happen
Jan 11 18:17:30 <weierophinney> Thinkscape, our betas do not imply an api freeze, so that'd be okay.
Jan 11 18:17:37 <Thinkscape> weierophinney: is there any exit strategy ? anyone who can take over from Thomas?
Jan 11 18:17:48 <weierophinney> Thinkscape, that's what I'm unsure of.
Jan 11 18:18:05 <weierophinney> Thinkscape, he's done a CLDR-based l10n layer, which requires a fair bit of knowledge.
Jan 11 18:18:16 <DASPRiD> I cohld...
Jan 11 18:18:23 <weierophinney> Thinkscape, if we were to downgrade to just using ext/intl, sure, we could do it, but we'd lose capabilities.
Jan 11 18:18:35 <Thinkscape> DASPRiD: hahhahha
Jan 11 18:18:42 <DASPRiD> I'm familiar with cldr
Jan 11 18:18:46 <Thinkscape> weierophinney: I've noticed there are already some missing features from zf1
Jan 11 18:18:56 <DASPRiD> Thanks to iCal rfc
Jan 11 18:19:14 <weierophinney> So, recap:
Jan 11 18:19:27 <EvanDotPro> Acl and Auth was also scheduled for beta3 in a past meeting...
Jan 11 18:19:31 <weierophinney> beta2: View, DB, Log, Console, Cloud,
Jan 11 18:19:46 <weierophinney> beta3: Form, i18n/l10n
Jan 11 18:19:55 <weierophinney> sorry, that should be beta3 and beta4, respectively.
Jan 11 18:19:56 <Thinkscape> wait, beta2 ?
Jan 11 18:19:59 <Thinkscape> :0
Jan 11 18:20:02 <weierophinney> Thinkscape, ^^
Jan 11 18:20:05 <DASPRiD> Lol
Jan 11 18:20:10 <Thinkscape> EvanDotPro: you should do the recap
Jan 11 18:20:11 <DASPRiD> Typo
Jan 11 18:20:22 <skiller> Yay for Console in b3, terrific!
Jan 11 18:20:24 <EvanDotPro> to paste from my notes...
Jan 11 18:20:25 <weierophinney> EvanDotPro, no RFCs as yet for refactoring on either, so no way to schedule at this time.
Jan 11 18:20:26 <EvanDotPro> * Beta3 target for last week of February. Components slated to be ready: Config, Cloud, Db Log, View
Jan 11 18:20:27 <ocra|afk> How's ezimuel on cloud?
Jan 11 18:20:30 <EvanDotPro> * Components re-scheduled for Beta4: i18n/l10n, Form (with remote possibility to be in B3)
Jan 11 18:20:37 <DASPRiD> Mwop: back to the future
Jan 11 18:20:45 <ezimuel> ocra|afk: i will finish the cloud stuff tomorrow
Jan 11 18:20:47 <weierophinney> ocra|afk, ezimuel is hours away from completing migration
Jan 11 18:21:02 <weierophinney> ocra|afk, but hours away means tomorrow, as it's end of day for him now.
Jan 11 18:21:04 <MikeA> So what about ACL and Auth?
Jan 11 18:21:15 <ocra|afk> +1 for console pushed into priorities...
Jan 11 18:21:16 <EvanDotPro> weierophinney: for Authentication, I haven't heard anyone be vocally in favor of my proposed refactoring, so I'll likely drop that.
Jan 11 18:21:35 <weierophinney> MikeA, see above – nobody has indicated they're working on RFCs, other than EvanDotPro for Authentication at this time – which has been.. contentious...in #zftalk.2
Jan 11 18:21:38 <ocra|afk> Mwop: awesome!
Jan 11 18:21:58 <weierophinney> EvanDotPro, does this mean we can move on to the next topic?
Jan 11 18:22:05 <DASPRiD> Do for i18n l10n: I could take over if required
Jan 11 18:22:09 <skiller> EvanDotPro: umm... Re Auth: got a link?
Jan 11 18:22:14 <weierophinney> DASPRiD, noted.
Jan 11 18:22:16 <MikeA> weierophinney: that's a shame because I though EvanDotPro was on the right path
Jan 11 18:22:27 »» Aldemar wasn't it going to be Zend/Access by the way?
Jan 11 18:22:41 <Thinkscape> mmm...
Jan 11 18:22:41 <EvanDotPro> skiller: it's on the mailing list, bug me for a link after the meeting in #zftalk.2
Jan 11 18:22:46 <Thinkscape> we could try to push it a little bit
Jan 11 18:22:46 <DASPRiD> Sounds like ms access
Jan 11 18:22:49 <weierophinney> MikeA, the problem is the path is app-specific. I'll dig up the discussions for you later if desired.
Jan 11 18:22:59 <weierophinney> Aldemar, no, Acl, to describe the approach.
Jan 11 18:23:04 <skiller> EvanDotPro: thx
Jan 11 18:23:06 <EvanDotPro> Okay... NEXT TOPIC: ZF 1.X EOL
Jan 11 18:23:10 »» EvanDotPro puts fist down
Jan 11 18:23:16 <ocra|afk> Edp: like your auth but would limit it to an adapter for now...
Jan 11 18:23:58 <weierophinney> So, lots of folks are asking about ZF1 EOL with ZF2 on the horizon.
Jan 11 18:24:14 <Thinkscape> weierophinney: how are they asking?
Jan 11 18:24:17 <EvanDotPro> so i'd say this next topic is mostly on the shoulders of the Zend team.. but it would be nice to get feedback from the community... probably most of us ZF2 early adopters have zf2 apps in production that we'd like to have a clear picture of support for.
Jan 11 18:24:17 <weierophinney> The big questions are: how long will it be supported? and who will do the supporting.
Jan 11 18:24:20 <Thinkscape> Like in a positive way ?
Jan 11 18:24:31 <weierophinney> Thinkscape, clients, twitter, IRC, email, lots of places.
Jan 11 18:24:38 <Thinkscape> no, not the places, but the tone...
Jan 11 18:24:49 <Thinkscape> Is it like: "Please please keep zf1 alive"
Jan 11 18:24:54 <Thinkscape> or "get over it" ?
Jan 11 18:24:57 <weierophinney> Thinkscape, many are worried, as they've developed large ZF1 infrastructures.
Jan 11 18:25:01 <EvanDotPro> there's also the possibility of utilizing the CR team or establishing a new team to manage the zf1.x maintenance to keep the Zend team resources freed up for ZF2.
Jan 11 18:25:28 <weierophinney> Thinkscape, that said, I'd also characterize those asking as primarily corporate users (or freelancers developing for corporate clients)
Jan 11 18:25:29 <ocra|afk> I'd freeze it and keep only updates
Jan 11 18:25:38 <StephanFX> weierophinney: i am one of those, have 2 major projects on ZF1
Jan 11 18:25:39 <MikeA> Bad marketing to make any decision now – ZF2 need to be much further on
Jan 11 18:25:45 <leedavis81_> As a bit of an outsider, and a dev who's used ZF1.x on several projects, I'd rather the EOL be as near as practically possible. It gives me ammo to entice the business(es) to invest my time on the next evolution.
Jan 11 18:25:47 <weierophinney> EvanDotPro, that's my main question at thsi time: how we assign responsibility.
Jan 11 18:25:51 <ocra|afk> It is clear there's not many people with time to contribute...
Jan 11 18:26:13 <iH8> i would decide on what components are considered "core" in ZF1
Jan 11 18:26:18 <EvanDotPro> so let's establish two things... a timeline for zf1.x support, and delegation of the responsibility of said support.
Jan 11 18:26:21 <iH8> and focus on them
Jan 11 18:26:22 <Thinkscape> EvanDotPro: it sounds like a good idea. People who depend on and are avid zf1 users should hold the maintenance responsibility.
Jan 11 18:26:32 <weierophinney> I've discussed it with Zeev a fair bit, and 18 months seems reasonable – a lot of people need that long to come up with a migration plan and implement it.
Jan 11 18:26:43 <weierophinney> (corporate/enterprise development is often very, very slow)
Jan 11 18:26:58 <DASPRiD> Re
Jan 11 18:27:00 <DASPRiD> Stupid connection
Jan 11 18:27:15 <skiller> It sounds like 1.12 will be the last dot release of ZF1, and I'd like to make that clear (even now), but offer extended bug/security patch support
Jan 11 18:27:21 <Aldemar> I think that support should go until a major release of zf2 is alive (I mean ZF2.1)
Jan 11 18:27:34 <jowoz> As a corporate user I could handle a freeze but I'd like to see a couple of years worth of security updates. Some of the apps I deal with are far too big to port to ZF2. I'd never be given the funds to do it.
Jan 11 18:27:37 <DASPRiD> At least two of mine
Jan 11 18:27:38 <weierophinney> skiller, that's the idea – 1.12 becomes last minor release branch, and gets only critical and/or security fixes.
Jan 11 18:27:39 <MikeA> Aldemar: +1
Jan 11 18:27:47 <skiller> 18mo sound good, but 3ys would be better
Jan 11 18:28:02 <Jigal> would it be an idea to make the last release of 1.X a migration script of ZF1 to ZF2? Or will that be impossible?
Jan 11 18:28:04 <EvanDotPro> i think we could have two support timelines
Jan 11 18:28:07 <Thinkscape> I'd say it all lies in details - the "infrastructure" you mentioned, I understand it as dozens of controllers, helpers, plugins and such. They won't break from day-to-day, or even one year from now. They possibly will live until the end of PHP 5.x branch. So it's rather a question of security updates...
Jan 11 18:28:21 <EvanDotPro> maybe one date that is backed up by Zend, and a second date beyond that which falls on the community to support.
Jan 11 18:28:23 <Thinkscape> i.e. do we consider Zend_Service_* upgrades as APIs change ?
Jan 11 18:28:39 <weierophinney> Jigal, probably impossible. We'll likely build tools after zf2 is out to assist with migration. But they'd be a separate project.
Jan 11 18:28:40 <leedavis81_> EvanDotPro +1
Jan 11 18:28:46 <Thinkscape> Jigal: i'd say more of a migration FAQ, not script.
Jan 11 18:28:46 <ocra|afk> What would still be maintained in 18 months?
Jan 11 18:29:16 <weierophinney> Thinkscape, if they need upgrades to Service components, we can direct them to the ZF2 equivalents.
Jan 11 18:29:25 <ocra|afk> Also I'd NOT support 5.4
Jan 11 18:29:45 <DASPRiD> Idd, its not full stack after all
Jan 11 18:29:46 <Thinkscape> weierophinney: we could always direct them to zf2, but ^^ what you said before
Jan 11 18:29:47 <weierophinney> ocra|afk, well, we'll likely still work in 5.4 regardless; I've already tested on it.
Jan 11 18:29:51 <skiller> I, personally, wouldn't tie the EOL of 1.x to the "birth" of 2.0 . There are plenty of projects that remain pretty much unchanged for years.
Jan 11 18:29:57 <Jigal> Ok. But maybe it will be good to write down somewhere in a prominent place in the 1.x manual that EOL will be within an x period so new people will have a clear knowledge of that b4 starting new projects with 1.X
Jan 11 18:30:14 <weierophinney> Jigal, +1
Jan 11 18:30:21 <ocra|afk> Mwop: better, but without warranties...
Jan 11 18:30:31 <skiller> EvanDotPro: +1 Re: 2 support timelines
Jan 11 18:30:42 <DASPRiD> Skiller, by support, we probably mean security and critical bugs
Jan 11 18:30:55 <StephanFX> will this be 18 months on the release of zf1.12 or release of zf2?
Jan 11 18:31:00 <weierophinney> EvanDotPro, skiller – not sure I agree. Infrastructure for building releases and pushing them is on my team.
Jan 11 18:31:09 <Thinkscape> I'd rather focus on defining what does the x-month period mean? Security? Features? General bugs? Enhancements? Which packages?
Jan 11 18:31:10 <Aldemar> Support should not stop until a mature version of zf2 is on production
Jan 11 18:31:11 <weierophinney> StephanFX, that's one of the questions.
Jan 11 18:31:25 <weierophinney> Thinkscape, critical bugfixes and security fixes ONLY
Jan 11 18:31:26 <Jigal> aldemar: I agree!
Jan 11 18:31:54 <lubs> ok finally caught up after a team lunch
Jan 11 18:31:54 <weierophinney> Aldemar, we'll have a stable ZF2 version this year, likely w/in first half of year.
Jan 11 18:31:57 <Jigal> StephanFX, weierophinney i prefer after stable zf2 release
Jan 11 18:32:07 <Thinkscape> weierophinney: so basically that means that current release is the last one. is it ?
Jan 11 18:32:16 <weierophinney> Thinkscape, 1.12 will be.
Jan 11 18:32:17 <StephanFX> i would say zf2, to give dev a decent chance to catch up
Jan 11 18:32:24 <Aldemar> weierophinney: ppl is afraid of 0.0 versions
Jan 11 18:32:29 <lubs> with ZF 1.x I think it might be fair to also say there may be a 1.13 release as a backporting release for components in ZF 2?
Jan 11 18:32:38 <weierophinney> lubs, no
Jan 11 18:32:41 <lubs> k
Jan 11 18:32:41 <Thinkscape> how about: zf2 release date + 12 mo ?
Jan 11 18:32:55 <ocra|afk> Lubs -1
Jan 11 18:32:59 <weierophinney> lubs, we'll be adding things like EM and autoloaders to 1.12 – but any sort of forward compats will be via a separate project.
Jan 11 18:33:03 <Aldemar> lubs, not agreed, it wouldn't be longer zf1
Jan 11 18:33:03 <skiller> If 18mo means 1.12 receives bug and security fixes until 18mo after 2.0 is out, all is well.
Jan 11 18:33:06 <iH8> Thinkscape +1
Jan 11 18:33:09 <Jigal> Thinkscape, if 18 months have been proven to be the right timespan why not sticking to that?
Jan 11 18:33:22 <leedavis81_> I think skiller was right, and we should tie the EOL of 1.x to the birth of 2.0
Jan 11 18:33:23 <weierophinney> skiller, that was my original suggestion.
Jan 11 18:33:23 <Thinkscape> MS broadcasts EOL timelines the moment they officially comercially release new version of MS Windows package.
Jan 11 18:33:23 <ezimuel> Thinkscape: I think 18 months is better after the zf2 release date
Jan 11 18:33:28 <leedavis81_> * shoudn't
Jan 11 18:33:35 <lubs> i'm fine with whatever in terms of the EOL; i know that internally it will take us about a year to restructure our application for zf2 (which we've started already)
Jan 11 18:33:49 <skiller> And I wouldn't provide migration scripts. Sounds like a recipe for headache.
Jan 11 18:34:12 <weierophinney> skiller, more like FAQ, but potentially some scripts to automate things like conversion to namespaces, mapping old classes to new, etc.
Jan 11 18:34:28 <skiller> weierophinney: thought so. Thanks for clarifying!
Jan 11 18:34:31 <Thinkscape> ok, so ZF2 Final (2.0.0) date + 18 mo ?
Jan 11 18:34:36 <MikeA> The more I think about this: any announcement before ZF2 release could cause fear for anyone contemplating a new ZF project
Jan 11 18:34:38 <weierophinney> Thinkscape, yes.
Jan 11 18:34:48 <EvanDotPro> so is anyone against zf2 final + 18 months?
Jan 11 18:34:53 <StephanFX> Thinkscape, agreed
Jan 11 18:34:57 <weierophinney> MikeA, yes, we'd announce when ZF2 stable is released.
Jan 11 18:34:58 <EvanDotPro> or have any concerns about it?
Jan 11 18:34:59 <Aldemar> MikeA: I agree
Jan 11 18:35:00 <ocra|afk> Some articles about zf1-2 comparison on zf.com maybe
Jan 11 18:35:05 <weierophinney> ocra|afk, yep
Jan 11 18:35:06 <iH8> It al depends on critical issues per month, i don't think there's too many.
Jan 11 18:35:15 <Thinkscape> ok, so we decided on WHEN? now let's decide on WHO?
Jan 11 18:35:17 <weierophinney> iH8, that's the next point I want to bring up...
Jan 11 18:35:22 <weierophinney> Thinkscape, EXACTLY
Jan 11 18:35:48 <weierophinney> Part of this will require somebody examining incoming issues and determing if they are (a) critical, (b) security related, or (c) neither.
Jan 11 18:35:57 <skiller> MikeA: I think quite the contrary. "Hey people, we'll support 1.12 until way after 2.x is out" will probably soothe a lot of people who are developing ZF1 projects right now.
Jan 11 18:35:57 <weierophinney> In the case of (c), they can be marked "won't fix".
Jan 11 18:36:02 <weierophinney> The question is, who does that part?
Jan 11 18:36:15 <weierophinney> I'd like to nominate a release manager, ideally outside my team.
Jan 11 18:36:17 <EvanDotPro> i'm for establishing a community team
Jan 11 18:36:26 <Thinkscape> How about: which members of CR team use/depend on zf1 in their (corpo?) environments ?
Jan 11 18:36:32 <skiller> +1 for 2.0 + 18mo
Jan 11 18:36:33 <StephanFX> community team +1
Jan 11 18:36:38 <EvanDotPro> i'd like to keep our resources from Zend freed up for ZF2, and also those of the CR team if possible.
Jan 11 18:36:44 <weierophinney> Thinkscape, or adding folks to the CR Team who want to take that on.
Jan 11 18:37:07 <EvanDotPro> personally i'd like to see the CR team focused on zf2 as well... so maybe a specific ZF1 LTS team.
Jan 11 18:37:08 <Thinkscape> weierophinney: if we have such volunteers
Jan 11 18:37:11 <weierophinney> Maybe I should send out a request to the ML, and we can see who is interested?
Jan 11 18:37:28 <Aldemar> weierophinney: when is it scheduled to release zf 2.0.0 ?
Jan 11 18:37:32 <Thinkscape> are you pro a single person responsible for that ? (leader)
Jan 11 18:37:53 <EvanDotPro> weierophinney: +1 for ml post.
Jan 11 18:38:11 <StephanFX> weierophinney: +1 for ml post
Jan 11 18:38:20 <weierophinney> Thinkscape, we'll likely need a pool of folks – 18 months may be longer than an individual volunteer is willing.
Jan 11 18:38:24 <EvanDotPro> if no one steps up, maybe that's in indication of the importance of such support to the community (that may be a harsh assumption though)
Jan 11 18:38:33 <Thinkscape> EvanDotPro: too harsh
Jan 11 18:38:35 <lubs> weierophinney: i could assist in ZF 1.x; we're going to be stuck on it over the next year easily
Jan 11 18:38:50 <Thinkscape> it's 8pm here most devs are resting after their corpo work...
Jan 11 18:38:53 <weierophinney> Aldemar, hopefully no later than June – depends on how fast these betas get out there and we zero in on stable MVC.
Jan 11 18:38:58 <DASPRiD> Re
Jan 11 18:39:10 <DASPRiD> So am I thibkscape
Jan 11 18:39:15 <weierophinney> lubs, cool.
Jan 11 18:39:19 <weierophinney> So, summary:
Jan 11 18:39:52 <weierophinney> * ZF 1.12 becomes last 1.X release, and continues to receive critical bugfix/security fix support ONLY starting from 2.0 stable release until 18 months following.
Jan 11 18:40:21 <weierophinney> * Matthew to send ML post to list asking for volunteers to act as RMs for 1.12.X once we hit that time.
Jan 11 18:40:34 »» Aldemar thinks 2.0+18months is too much I would say 12 months, in a year I think we might be already on zf2.1
Jan 11 18:40:59 <lubs> Aldemar: i think it is almost fair... however, porting over a complex architecture on ZF 1.x is not trivial
Jan 11 18:41:01 <EvanDotPro> Aldemar: unfortunately corporate development timelines are not very fast
Jan 11 18:41:09 <Evil_Otto> I'd suggest that the life expectancy of a zf1 application is more than 12 months
Jan 11 18:41:12 <jowoz> Would removing the CLA from ZF1 and moving it to github not help with the community helping out with security fixes?
Jan 11 18:41:13 <DASPRiD> True
Jan 11 18:41:18 <skiller> EvanDotPro: agreed 100%
Jan 11 18:41:31 <iH8> jowoz, great point
Jan 11 18:41:48 <weierophinney> jowoz, won't happen for ZF1 – we need to keep the licensing and contribution guidelines the same for a given branch
Jan 11 18:42:11 <weierophinney> Otherwise 1.11 becomes the last version some folks can use due to legal issues.
Jan 11 18:42:29 <skiller> weierophinney: makes sense
Jan 11 18:42:49 <EvanDotPro> yeah, it's an unfortunate reality.
Jan 11 18:42:52 <iH8> there is no option to do so, move on
Jan 11 18:42:53 <weierophinney> kk... next topic?
Jan 11 18:43:05 <EvanDotPro> yeah next topic
Jan 11 18:43:09 <EvanDotPro> Brainstorm ZF2 Module Options
Jan 11 18:43:17 <DASPRiD> Note to myself: umts sucks at 300kmh
Jan 11 18:43:22 <weierophinney> EvanDotPro, we could do accessors for the config in the MvcEvent...
Jan 11 18:43:39 <weierophinney> EvanDotPro, that would solve like 90% or more of your use cases, I'd think...
Jan 11 18:43:41 <skiller> DASPriD What a fast car you have ;_)
Jan 11 18:43:50 <EvanDotPro> Bittarman: ping
Jan 11 18:44:25 <DASPRiD> Skiller: train
Jan 11 18:44:31 <EvanDotPro> weierophinney: possibly, but that starts playing the game of how do we make sure every object that is going to have any "options" logic be aware of the mvcevent or get the options injected into it.
Jan 11 18:44:40 <skiller> DASPRiD: thought so
Jan 11 18:44:58 <weierophinney> EvanDotPro, true.
Jan 11 18:45:04 <skiller> What's the approach that best matches DI?
Jan 11 18:45:13 <weierophinney> EvanDotPro, so far, I've gotten around it via DI.
Jan 11 18:45:13 <Thinkscape> One idea was config injection from application or mod.manager into a module, then SomeModule::getOption() and ::getConfig().
Jan 11 18:46:05 <DASPRiD> I should just do DNS tunneling with the train WiFi
Jan 11 18:46:06 <weierophinney> EvanDotPro, Thinkscape: also, if you're in the Module class, you can grab the config from the event passed to the bootstrap event, and use it to pass to objects and/or closures.
Jan 11 18:46:27 <EvanDotPro> weierophinney: that's how i'm setting the static property now
Jan 11 18:46:28 <weierophinney> I've done that for things like my listeners, view helpers, etc.
Jan 11 18:46:46 <DASPRiD> Static...
Jan 11 18:46:48 <Thinkscape> Where I didn't like it was when view helpers and form elements started to query a module. Querying config settings from UI widgets seemed a bad architecture to me, because it should be the other way around - controller or view configures a UI widget, and UI widgets complies accordingly.
Jan 11 18:46:49 <EvanDotPro> weierophinney: https://github.com/ZF-Commons/ZfcUser/blob/master/Module.php#L41
Jan 11 18:47:13 <Aldemar> Thinkscape: I agree
Jan 11 18:47:21 <Thinkscape> Additionally, if you reuse those components ---- which module do I query ?
Jan 11 18:47:26 <DASPRiD> Thibkscape ack
Jan 11 18:47:34 <EvanDotPro> here's a use-case: https://github.com/ZF-Commons/ZfcUser/blob/master/src/ZfcUser/Controller/UserController.php#L108 ... that happens to be in a controller where passing the config in the MbvEvent would work, but that's not always the case.
Jan 11 18:48:11 <Thinkscape> Also, if module A extends module B functionality but uses module A Form... then this form will have module A hard-coded as source of config options.
Jan 11 18:48:50 <weierophinney> EvanDotPro, see, I'd register with the dispatch() event, and inject the configuration from there (using high priority).
Jan 11 18:48:56 <DASPRiD> Indeed, please no registry like stuff again
Jan 11 18:49:07 <weierophinney> EvanDotPro, that can then be done from the module, and you have the configuration readily at hand at that point.
Jan 11 18:49:31 <Thinkscape> On the other hand, Bittarman or Akrabat (sorry) suggested that: if I import module A from vendor, I don't care about how it's form work - I just want to USE it and it is expected to work.
Jan 11 18:49:33 <skiller> weierophinney: +1 Re: register/dispatch/inject
Jan 11 18:49:33 <lubs> i also can see the value in statics within the actual module itself for options although...
Jan 11 18:50:16 <Thinkscape> weierophinney: this requires for each and every component to be injected ...
Jan 11 18:50:24 <DASPRiD> Lubs, statics are bad for re usability
Jan 11 18:50:30 <EvanDotPro> lubs: right.. that's the thing, you can't quantify where you'll need to access the options
Jan 11 18:50:37 <lubs> DASPRiD: the Module.php class itself is not really reusable
Jan 11 18:51:01 <EvanDotPro> https://github.com/ZF-Commons/ZfcUser/blob/master/src/ZfcUser/Form/Register.php#L14
Jan 11 18:51:06 <skiller> Thinkscape, weierophinney: I'd favor the approach that alleviates mocking
Jan 11 18:51:07 <weierophinney> Thinkscape, it looks to me like a case of opting-in to specific configuration – and if so, you can do that in your own logic.
Jan 11 18:51:15 <DASPRiD> No, but the components relying on those statics
Jan 11 18:51:16 <Thinkscape> link ^^ that's the example that I'm referring to
Jan 11 18:51:16 <EvanDotPro> (the inverse of that can be done too, add the element if the preference is enabled)
Jan 11 18:52:10 <EvanDotPro> and you may need access to the same setting in multiple places
Jan 11 18:52:18 <EvanDotPro> for example in the authentication adapter, you may have something like this: https://github.com/ZF-Commons/ZfcUser/blob/master/src/ZfcUser/Authentication/Adapter/Db.php#L40
Jan 11 18:52:24 <weierophinney> EvanDotPro, again, I'd argue in that case I'd want it injected early. But I'm seeing the issues.
Jan 11 18:52:26 <lubs> EvanDotPro: exactly... i can see the reasoning for having statics for say and administration panel where you need access to see enabled vs. disabled to provide a correct interface; also say you need to check to see if a module (from another module) has a certain configuration that may be shared but you need to check for it first... I mean there are ways around it but DI is only good if you don't let it get in your way and this seems like we are creati
Jan 11 18:52:50 <weierophinney> lubs, got cut off after "like we are creati"
Jan 11 18:53:11 <lubs> ...sometimes you might need the options outside of the module itself... for instance; say you have an administration panel where you take the options and provide an a
Jan 11 18:53:17 <lubs> grrr
Jan 11 18:53:22 <lubs> now my client is getting all fubared
Jan 11 18:53:25 <Thinkscape> skiller: good point, mocking. That negates the use of hard-coded calls to statics
Jan 11 18:53:33 <DASPRiD> Get a better client
Jan 11 18:53:40 <EvanDotPro> well, this sounds like this is something that needs a bit more collaborative thought and planning of use-cases at this point.
Jan 11 18:54:04 <lubs> basically all i am saying is that we can make it complex but all in all it's getting more complex for something that should be simple
Jan 11 18:54:09 <DASPRiD> Evan, let's talk about it when I'm home again
Jan 11 18:54:26 <weierophinney> EvanDotPro, agreed – I think we need to come up with a list of use cases where you're noticing issues, and discuss on the ML/IRC – not enough info here to really discuss thoroughly.
Jan 11 18:54:33 <Thinkscape> lubs: it's not that simple. If you make it easy to use (in this case), you make it hard to test... and vice versa.
Jan 11 18:54:43 <weierophinney> Thinkscape, +1
Jan 11 18:54:57 <skiller> Thinkscape: True, those are a real pain to mock. We have terrific PHPUnit support, so let's not forget the busy testers.
Jan 11 18:54:58 <ocra|afk> Not getting it, missed cause of 3g. Discussing over staticness?
Jan 11 18:55:08 <Thinkscape> global $config is easiest I use it even today with zf1 apps
Jan 11 18:55:10 <Aldemar> wouldn't ->getModule() ->setModule() and DI use, make the work?
Jan 11 18:55:11 <DASPRiD> +1
Jan 11 18:55:12 <DASPRiD> Mostly
Jan 11 18:55:14 <lubs> Thinkscape: i agree with that as well - just needs more thought
Jan 11 18:55:27 <weierophinney> I'll note that I've run into a few cases where using statics would simplify things, but I've always managed to find another way to accomplish it, either via bootstrapping and/or events, in combination with direct injection.
Jan 11 18:55:45 <Thinkscape> Aldemar: yes, but that is a double-edged sword. It requires to inject EVERY component with the module :\
Jan 11 18:55:56 <EvanDotPro> weierophinney: i'll slate some time this week to walk through some use cases with you then.
Jan 11 18:56:07 <Thinkscape> and it is possibly a hard dep on di
Jan 11 18:56:10 <weierophinney> Aldemar, and I think one thing EvanDotPro is pointing out is that you may be using values from a module other than the one you're in.
Jan 11 18:56:26 <EvanDotPro> yes
Jan 11 18:56:26 <Thinkscape> EvanDotPro: why "with you"?
Jan 11 18:56:28 <DASPRiD> Tginkdcape stab youself
Jan 11 18:56:45 <weierophinney> EvanDotPro, s/with you/on the ML and\/or IRC/
Jan 11 18:56:51 <EvanDotPro> Thinkscape: i mean i want to discuss some of the solutions that weierophinney said he's come up with to alleviate the statics
Jan 11 18:56:56 <weierophinney> aha
Jan 11 18:57:12 <EvanDotPro> sorry, should have been more explicit there
Jan 11 18:57:23 <DASPRiD> Nah
Jan 11 18:57:59 <EvanDotPro> alright everyone... we're coming up on that time... i think we covered everything we could have hoped to cover today.
Jan 11 18:58:14 <weierophinney> So, summary of the last topic: Needs more discussion and use cases.
Jan 11 18:58:21 <Aldemar>
Jan 11 18:58:22 <EvanDotPro> yep
Jan 11 18:58:26 <skiller> +1
Jan 11 18:58:35 <weierophinney> I'll get the summary page up later today, and post a link to the ML and on twitter.
Jan 11 18:58:38 <DASPRiD> Hehe
Jan 11 18:58:50 <Thinkscape> thx
Jan 11 18:59:04 <EvanDotPro> alright everyone – meeting adjourned! discussions can continue on #zftalk.2 if anyone has lingering thoughts.
</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.