Skip to end of metadata
Go to start of metadata

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


<li>Date: 20 June 2012, 20:00-21:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-06-20 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 27 June 2012</li>


<h3>Adopting PSR-1 / PSR-2 coding standards</h3>

<p>(Search for "20:02:25" in the log.)</p>

<p>PSR-1 and PSR-2 have recently been accepted, and they provide the kernel for a coding standards recommendation:</p>

<li><a href="">PSR-1</a></li>
<li><a href="">PSR-2</a></li>

<p>Currently, the only change this would require in the current ZF2 coding standards is to have a "use" statement <em>per</em> import (vs. a single "use" statement, with each import separated by commas). </p>

<p>There was no debate about whether or not we should comply; consensus was immediate, and in favor.</p>

<p><strong>tl;dr</strong>: There will be some slight changes to the ZF2 coding standards soon so we can be PSR-1 and PSR-2 compliant.</p>

<h3>Replacing the Plugin Broker + PluginClassLocator with ServiceManager</h3>

<p>(Search for "20:06:51" in the log.)</p>

<p>Matthew <a href="">raised a discussion on the ML</a> suggesting replacing plugin broker usage with context-specific service managers, and also posted a prototype. Since the plugin broker solution is a subset of the service manager, and currently allows injecting a service manager anyways, it seems reasonable to reduce the number of APIs in the framework and provide a more flexible solution.</p>

<p>As Rob Allen (Akrabat) noted, "that's the one where we rip out code that noone uses and use the stuff we all have to use" – less code, and an API everyone will be familiar with (as it's the core of the MVC).</p>

<p>Just as in the PSR-1/PSR-2 discussion, there was immediate consensus in favor of taking this approach. (Update: Matthew already has a <a href="">pull request</a> for this in place.)</p>

<p><strong>tl;dr</strong>: plugin broker usage will be replaced with context-specific service managers in time for beta5.</p>


<p>(Search for "20:11:54" in the log.)</p>

<p>Gary Hockin (Spabby) raised a discussion via the agenda suggesting we need to clean up documentation.</p>

<p>Matthew noted that Jonas Marien has volunteered to refactor existing documentation not currently published to follow the new namespaces and class/interface/etc. renamings so that we at least have <em>some</em> documentation in place. Additionally, his <ac:link><ri:page ri:content-title="Proposal for Documentation in ZF2" /><ac:link-body>RFC</ac:link-body></ac:link> appears to have widespread agreement... but we don't have a plan for implementation.</p>

<p>Rob Allen (Akrabat) reiterated that we need to do something radical with the documentation. Evan Coury (EvanDotPro) raised a concern that docbook may be a barrier to entry for many potential contributors.</p>

<p>In the end, we realized we need a solid proposal for action. We agreed that Gary, Matthew, and Rob would collaborate to come up with such a proposal and present it to the community soon so we can start work.</p>

<p><strong>tl;dr</strong>: In the short term, please help Jonas get current docs updated and in line with current code. If you have concrete ideas on how to improve documentation moving forward, including arguments for other documentation formats, please bring them up on the list.</p>

<h3>Which components to ship?</h3>

<p>(Search for "20:21:15" in the log.)</p>

<p>This topic was chaotic. Rob Allen (Akrabat) had posted to the mailing list last week a <a href="">list of components and current testing, packaging, and documentation status for each</a>, and has asked that we decide what will be in the stable version.</p>

<p>Unfortunately, there are a number of questions:</p>

<li>What do we do with any components we choose not to ship in the stable release? (i.e., do they all go in a separate repo? or a separate repo per component? or perhaps a separate branch on the zf2 repo? or simply delete and let folks pull from the history?</li>
<li>What constitutes a stable component? Number of maintainers? Passing tests? Refactorization during Zf2 lifecycle?</li>

<p>Basically, we couldn't come to a consensus on any of these points.</p>

<p>We decided that Rob and Matthew will create a Google form with the list of components, current testing/documentation/packaging status, and known maintainers, and ask the community to vote on each. Additionally, we'll create a Google form or wiki poll presenting the various options for splitting out unstable components.</p>

<p><strong>tl;dr</strong>: lots of polls in the community's future.</p>


<ac:macro ac:name="html"><ac:parameter ac:name="output">html</ac:parameter><ac:plain-text-body><![CDATA[
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) */
word-wrap: break-word; /* IE 5.5+ */
border: 1px solid darkgray;
padding: 0.5em;
<pre class="log">
20:01:46 <weierophinney> So, we have 4 agenda items.
20:02:06 <weierophinney> I'm going through them in the order of least resistance ... as in, doing the ones that require least discussion first.
20:02:16 < DASPRiD> so, the voting one first?
20:02:22 < DASPRiD> (PSR-2)
20:02:25 <weierophinney> First up: Adopting PSR-1 / PSR-2 coding standards.
20:02:29 <weierophinney> DASPRiD: you guessed it. :0
20:02:38 <weierophinney> Anybody have any reservations at all about doing this?
20:02:40 < ocramius> well, what has to be discussed?
20:02:46 < SpiffyJr> Eh, I haven't read the specs so 0
20:02:49 <weierophinney> ocramius: that's what I'm getting at.
20:02:54 < Freeaqingme> my opinion: Since we're actively taking part on drawing up the psr stuff, I think we'd be fools not to adhere to them ourselves
20:02:56 < DASPRiD> i just got one point: extend it, add e.g. array definitions
20:03:05 < DASPRiD> Freeaqingme, idd
20:03:13 <weierophinney> In a nutshell, the only thing that they have in them that would require a change on our part is declaration of imports.
20:03:16 < ocramius> Freeaqingme: exactly
20:03:16 < Akrabat> what's idd?
20:03:22 < Freeaqingme> *indeed
20:03:27 < DASPRiD> weierophinney, well, we got my shell script for that
20:03:27 < Akrabat> ah
20:03:39 < DASPRiD> Akrabat, you already asked that a couple of times
20:03:43 <weierophinney> one "use" statement per import. I've been doing it in all new code already.
20:03:57 < SocalNick> weierophinney: i've seen that lately and like it
20:04:09 < Akrabat> I like that too
20:04:14 < ocramius> weierophinney: I also started using using those conventions for in-house stuff and like them totally, so yeah =)
20:04:15 < SpiffyJr> webik, good, I like that change
20:04:18 <weierophinney> We'd need to modify our CS to simply base off those two standards, and then add whatever else we have specific to our needs.
20:04:19 < SpiffyJr> err, weierophinney ^^
20:04:25 < Maks3w> I don't have any reservation about PSR-1/2 only we need complete the parts without specification like split conditional statements in if/else
20:04:35 < jurians> DASPRiD: what you mean with extend with array definitions?
20:04:45 < DASPRiD> jurians, it's missing array stuff
20:04:49 <weierophinney> Maks3w: which is precisetly what I said above.
20:04:53 < DASPRiD> (formatting)
20:05:02 < prolic> i guess everybody will be fine with PSR-1/2, so let's vote
20:05:10 <weierophinney> DASPRiD: right – that's where we would be "psr-1/2 + these additional rules"
20:05:17 < Maks3w> for me it's good have the same split rules than with arguments in functions
20:05:26 < DASPRiD> Maks3w, right
20:05:29 <weierophinney> !vote-start Adopt PSR-1 and 2?
20:05:34 < WalterTamboer> +1
20:05:35 < Freeaqingme> +1
20:05:35 < prolic> +1
20:05:36 <weierophinney> is that the right notation, DASPRiD?
20:05:36 < Maks3w> +1
20:05:37 < SocalNick> +1
20:05:37 < DeNixPort> +1
20:05:37 < Akrabat> +1
20:05:37 < Left_brained> +1
20:05:38 < DASPRiD> Maks3w, although we had one additional thing: aligning "=>"
20:05:38 < mattcockayne> +1
20:05:38 < DASPRiD> +1
20:05:39 < PadraicB> +1
20:05:40 < jurians> DASPRiD: you mean this part:
20:05:40 < sigriffiths> +1
20:05:41 < mabe_> +1
20:05:44 < cgmartin> +1
20:05:44 < ocramius> +1
20:05:48 < DASPRiD> weierophinney, no
20:05:51 < webik> +1
20:05:52 < DASPRiD> weierophinney, it's start-vote
20:05:56 < SpiffyJr> Well, holy hell.
20:05:59 < SpiffyJr> I guess I should +1
20:05:59 < jurians> hehe
20:06:01 < SpiffyJr> +1
20:06:04 < Freeaqingme> weierophinney, not sure we need a bot to count the -1's
20:06:10 < ocramius> DASPRiD: do we really need that? visual impact is enough right now
20:06:11 < PadraicB> ROFL
20:06:16 < Maks3w> DASPRiD, Really we need it's how split docblock lines
20:06:16 < DASPRiD> ocramius,
20:06:17 * SpiffyJr folds under peer pressure
20:06:25 <weierophinney> okay, that vote is done.
20:06:30 < Maks3w> like @param xxx|xxxx|xxxx|xxx dfasf daf dsfads fds afds
20:06:30 < DASPRiD> hehe
20:06:45 < DASPRiD> Maks3w, that's doc block definitions, which we should have as well
20:06:51 <weierophinney> Next topic: Plugin Broker + PluginClassLocator replacement with ServiceManager
20:07:07 < DASPRiD> +1
20:07:08 < DASPRiD>
20:07:09 <weierophinney> I raised the discussion on the ML:
20:07:15 < SpiffyJr> +1
20:07:27 < mpinkston> +1
20:07:28 < Akrabat> that's the one where we rip out code that noone uses and use the stuff we all have to use ...
20:07:34 < Maks3w> IMO we could add a special note. If you don't see the full line in GitHub without move the scrollbar, then you need split the line
20:07:38 <weierophinney> I've made some improvements today, and it's seriously slimmer than the Plugin Broker solution.
20:07:56 < WalterTamboer> less code to worry about, +1 for me as well
20:07:59 <weierophinney> Akrabat: exactly.
20:08:00 < DASPRiD> Maks3w, i think any sane guy tries to go with 80 characters
20:08:09 < SpiffyJr> one of the pr's Akrabat likes so much (-200000 lines, +2 lines)
20:08:10 < PadraicB> +1
20:08:18 <weierophinney> Maks3w, DASPRiD we're on a new topic now... take it elsewhere.
20:08:23 < Akrabat> SpiffyJr: exactly
20:08:26 <weierophinney> SpiffyJr: LOL
20:08:26 < DASPRiD> weierophinney, sure
20:08:27 < ocramius> I think no-one would even use the broker itself directly with so much awesomeness on the other side
20:08:29 < Maks3w> !vote-end?
20:08:30 < DASPRiD> brb, rebooting
20:08:30 < prolic> when i saw the plugin broker the first time, i couldn't even understand why not di or sm here? so +1
20:08:45 < SocalNick> I believe one of the original goals of ZF2 was to standardize plugin loading across modules, this goes a step further +1
20:09:05 < Freeaqingme> I'm always for standardization
20:09:06 < Freeaqingme> +1
20:09:08 <weierophinney> SocalNick: that was my thought – since Broker was a subset of SM, it seemed silly to have two implementations.
20:09:09 < mattcockayne> +1
20:09:13 <weierophinney> Anybody with reservations?
20:09:16 < Akrabat> obviously +1 here
20:09:17 < cgmartin> +1
20:09:19 <weierophinney> I can have this done in the next day or two.
20:09:21 < DeNixPort> +1
20:09:31 * EvanDotPro catches up
20:09:34 < Akrabat> I want to review it
20:09:34 < PadraicB> -1 is apparently an endangered species today...
20:09:35 < mpinkston> Though it may be useful to think about how to organize service locator alias names (or give tips on how to do it)
20:09:40 <weierophinney> PadraicB: LOL
20:09:43 < mpinkston> it can get hard to track
20:09:43 * SpiffyJr shoots PadraicB
20:09:48 < PadraicB>
20:09:49 * SpiffyJr realizes PadraicB wasn't actually -1'ing anything
20:09:55 <weierophinney> mpinkston: actually, I ended up being able to rip all aliases out in the latest revision
20:10:09 < mpinkston> oh, nice
20:10:11 <weierophinney> mpinkston: the way that the SM canonicalizes names, they weren't necessary – they all resolved the same.
20:10:20 < Akrabat> I wondered about that
20:10:24 < SpiffyJr> weierophinney, I ran into that a few times and had a wtf moment until I realized what was going on.
20:10:25 < mpinkston> great
20:10:30 < SpiffyJr> (something working when I didn't think it should)
20:10:33 < Akrabat> cos the error messages you get with SM are the normalised ones
20:10:37 <weierophinney> Akrabat: yep
20:10:42 < SpiffyJr> For a moment I thought ServiceManager was a higher power...
20:10:47 < EvanDotPro> is the vote still psr1/2?
20:10:49 <weierophinney> Akrabat: which will help you find them easier.
20:10:54 < SpiffyJr> EvanDotPro, SM PluginBroker
20:10:56 < jurians> EvanDotPro: nope, SM for plugin brokek
20:10:59 <weierophinney> EvanDotPro: no, we're on to the PluginBroker -> SM bit now.
20:11:04 * EvanDotPro continues catching up then
20:11:34 <weierophinney> I'm not seeing any body against it now... time to move on?
20:11:40 < Akrabat> yes
20:11:41 < WalterTamboer> yup
20:11:43 < prolic> yes
20:11:48 < DASPRiD> re
20:11:51 < mpinkston> awesome. I love the way that went
20:11:54 <weierophinney> Next on the "easiest to agree on to hardest" list: Documentation
20:11:55 < DASPRiD> yes
20:11:58 <weierophinney> So, an update...
20:12:07 <weierophinney> Jonas Marien from King Foo approached me at DPC
20:12:24 <weierophinney> and he's started going through and refactoring docs to follow new namespaces, change class names as necessary, etc.
20:12:39 <weierophinney> So, that's one piece of the puzzle. Enrico is helping him as well.
20:12:53 <weierophinney> Where's Spabby? He added this topic...
20:13:02 < Akrabat> and the RFC formatting?
20:13:15 * EvanDotPro points out that he's +1 on PSR1+2, and the pluginbroker -> sm topic.
20:13:17 <weierophinney> Akrabat: they're not doing that on first pass, but I'd like to do so.
20:13:25 < Akrabat> ok
20:13:27 <weierophinney> EvanDotPro: awesome, glad you're caught up.
20:13:41 < Akrabat> I'm very very keen that we do something radiacal with our doc quality and consistency
20:13:46 <weierophinney> Is there anybody who wants to spearhead the documentation effort?
20:13:58 < Akrabat> Spabby does
20:14:01 <weierophinney> crickets
20:14:09 <weierophinney> oh, sure, let's nominate the guy who's not here.
20:14:11 < Akrabat> I said I'd support him
20:14:13 <weierophinney> I'm good with that.
20:14:28 < Akrabat> if he doesn't step up, then I'll hassle people to do the work instead
20:14:41 <weierophinney> My plan is once beta5 is out the door, ralph, myself, and enrico will likely spend the bulk of our time on docs.
20:14:49 < EvanDotPro> i'd really like to see something done, but don't have the spare cycles to do anything myself.
20:14:50 < Akrabat> (as I 've no idea how busy he is)
20:14:52 <weierophinney> so we can support as well.
20:15:19 < Akrabat> I have limited time to do doc work, but can do organisation & management
20:15:28 < EvanDotPro> i think the current docbook format might be a barrier to entry to some who may have otherwise contributed to the docs.
20:15:32 < Maks3w> We should hard with the review of it or any contribution is welcome even if doesn't follow the format?
20:15:38 <weierophinney> I think we need an actual "plan", however – what doc format we want to use (if not docbook5), how we want to tackle examples and options. The RFC I have only goes as far as suggesting format, but now how to get there.
20:15:56 < SpiffyJr> docbook is, erm, confusing... I still haven't managed to compile it on Ubuntu.
20:16:05 < Akrabat> agreed. I can work with Spabby and anyone else interested in sorting that out
20:16:08 < SpiffyJr> it = the zf2 docs
20:16:12 < Freeaqingme> SpiffyJr, it's just one simple command
20:16:22 < SpiffyJr> Now you're just insulting me
20:16:29 < SpiffyJr>
20:16:31 < Freeaqingme> sorry, not my intention
20:16:33 < mpinkston> are we talking about two different issues; writing vs formatting?
20:16:34 < Akrabat> I don't have it working on my mac either...
20:16:42 <weierophinney> Akrabat: let's do an email with Spabby and see if we can come up with a plan for how to move forward.
20:16:44 < Maks3w> I think that at this moment we could do our efforts in fix the actual documentation and for the next major releases do it more professional
20:16:47 <weierophinney> Does that sound reasonable?
20:16:48 < Maks3w> with a structure
20:16:54 < Akrabat> mpinkston: they are intertwined
20:16:59 < Freeaqingme> weierophinney, perhaps part of the plan should be to set up a simple tutorial to get the docs compiling etc?
20:17:04 < Akrabat> loosely we need much better docs than we have with ZF1
20:17:14 < SpiffyJr> Freeaqingme, I think I was using the wrong Docblock format...
20:17:14 <weierophinney> Freeaqingme: I can definitely do that.
20:17:18 < SpiffyJr> Freeaqingme, Never revisited it.
20:17:23 < Akrabat> that's both look and feel along with consistent content
20:17:27 <weierophinney> Freeaqingme: it's mainly a matter of having the write XSLT and DTD at hand.
20:17:35 < Akrabat> weierophinney: re email: works for me
20:17:46 <weierophinney> kk, so decision points:
20:17:46 < cgmartin> Akrabat: agreed
20:17:49 <weierophinney> * We need a plan
20:17:59 < Maks3w> We could add a task in Travis to check the syntax
20:18:05 < SpiffyJr> Too bad there isn't just a Markdown doc format...
20:18:08 <weierophinney> * weierophinney, Akrabat, and Spabby will email and hash out details, and publish said plan
20:18:13 < SpiffyJr> So much easier than messing with XML stuff
20:18:16 < WalterTamboer> weierophinney: Isn't it wise to decide if docbook is the best tool for the job before everyone starts investing time in the docs?
20:18:26 <weierophinney> WalterTamboer: that's part of what we'll be hashing out.
20:18:36 < mpinkston> Akrabat: true, but perhaps there'd be better luck if writers didn't have to worry as much about formatting and that could instead be passed to editors
20:18:37 < Akrabat> * weierophinney, Akrabat & Spabby we hassle people to volunteer to help ou
20:18:44 <weierophinney> WalterTamboer: part of that will be figuring out how hard it will be getting existing content from docbook to another format.
20:18:46 < beberlei> there are some python tools which can easily convert docs between different formats
20:18:50 < beberlei> i always forget the name of that thing
20:18:53 <weierophinney> Akrabat: right, that's the third point.
20:19:01 < beberlei> but we used it to convert markdown based docs to rst
20:19:07 < Akrabat> mpinkston: that crossed my mind too
20:19:09 < mattcockayne> SpiffyJr: theres always RST & sphinx which is not a million miles away from markdown
20:19:12 < WalterTamboer> weierophinney: alrighty, I have nothing against docbook but since some people raised the topic...
20:19:15 < beberlei> pandoc i thinkg
20:19:16 < Akrabat> beberlei: there's also the ezDoc component
20:19:17 <weierophinney> beberlei: pandoc, perhaps?
20:19:19 <weierophinney> jinx
20:19:21 < Akrabat> or pandoc
20:19:23 < Akrabat> bah!
20:19:27 < beberlei> Akrabat, pandoc is much better than ezc docs
20:19:35 < mpinkston> I'd personally write more documentation if I could quickly jot it down and toss it in a repo for later organizing
20:19:35 < Akrabat> thought pandoc was haskell?
20:19:40 <weierophinney> WalterTamboer: right – I wouldn't mind an easier markup format, tbh.
20:19:42 < Akrabat> mpinkston: yes
20:19:49 < Freeaqingme> we would not discuss the format right now. But for large docss rst does have its issues, so does markdown (think of lack of unique consistent url's/identifiers). Still; out of scope
20:20:03 < Maks3w> I'm in favour off any language compatible (at least in part) with GitHub's preview
20:20:04 < beberlei> markdown and rst have the benefit that you can commit broken docs wiothout problem
20:20:04 < PadraicB> weierophinney, should be simple enough from Docbook to convert... Hard part is reformatting the raw data into whatever new format is chosen - if any
20:20:10 < Maks3w> and Fork and Edit methodology
20:20:14 < WalterTamboer> I think Open Office can actually save documents in a docbook format, there you have your editor
20:20:26 <weierophinney> PadraicB: right – that's really the issue.
20:20:32 < Xerkus> was moving docs out of main zf2 repo decided?
20:20:42 < EvanDotPro> WalterTamboer: i doubt that would use like <classname> and stuff properly though
20:20:47 <weierophinney> Xerkus: no, but that goes into hte next topic nicely.
20:21:01 <weierophinney> so... we have action items for the documentation heading.
20:21:08 <weierophinney> NEXT TOPIC, and LAST
20:21:15 <weierophinney> Which Components to Ship
20:21:28 <weierophinney> Akrabat: raised this on the ML:
20:21:31 < SpiffyJr> This one will be fun.
20:21:38 < Akrabat> as few as possible!
20:21:48 < mpinkston> wow, gonna have to take a minute to review that list..
20:21:54 <weierophinney> One point: a lot of components have docs, but need the docs to be udpated before we can build them. That's the update I gave at the beginning of last topic.
20:21:59 < Akrabat> mpinkston: you've had 10 days
20:22:00 < Freeaqingme> Akrabat, why as few as possible?
20:22:08 < mpinkston> lol, you got me
20:22:10 < Akrabat> Freeaqingme: cos we have to support them
20:22:13 < EvanDotPro> weierophinney: Zend\Mvc, Zend\ModuleManager, Zend\EventManager, Zend\Stdlib
20:22:13 <weierophinney> On top of that, I'd mention Xerkus 's point: docs may need to be moved to a separate repo.
20:22:18 < Akrabat> Freeaqingme: and we have to be confident of their quality
20:22:19 < EvanDotPro> weierophinney: oh and Zend\View
20:22:31 < SpiffyJr> EvanDotPro, forms...
20:22:33 < Akrabat> we're much better off shipping a smaller set for 2.0 and then adding 10 new components for 2.1
20:22:40 < Freeaqingme> Akrabat, webik so the question is: are they OK quality-wise, and can we support them?
20:22:44 <weierophinney> Akrabat: +1
20:22:46 < Akrabat> than shipping a few good ones and some less good ones
20:22:49 < PadraicB> Agreed with Akrabat
20:23:05 < Freeaqingme> weierophinney, I'm not sure we should discuss this here and now for each component?
20:23:06 < SpiffyJr> eww Zend\Registry
20:23:07 < Akrabat> someone asked me if Zend\Log was done. I didn't have a clue
20:23:09 < EvanDotPro> Akrabat: +1
20:23:10 < SpiffyJr> ./kill it
20:23:13 <weierophinney> Akrabat: yes, it is.
20:23:17 < mpinkston> I've always felt service-specific modules should be separated out
20:23:19 <weierophinney> was done for beta4
20:23:28 < Maks3w>
20:23:30 < EvanDotPro> SpiffyJr: i was joking about just those couple components – it would be like the minimum for the skeleton to run.
20:23:38 <weierophinney> SpiffyJr: well, registry is used internally in some view helpers, we can't just kill it right now.
20:23:48 < SpiffyJr> With the usage of packages/git we could easily have a slim & trim "Core" package
20:23:49 < DASPRiD> yes we can
20:23:52 < SpiffyJr> And then extensions
20:23:54 < Xerkus> also we might want to reorganize docs to ship relevant parts with components being installed
20:24:03 <weierophinney> So, wait, stop everyone...
20:24:06 <weierophinney> FIRST THINGS FIRST
20:24:15 < Akrabat> some stuff still relies on Zend\translator for instance too
20:24:19 <weierophinney> As we decide which ones to weed out, the question is: where do they go
20:24:30 <weierophinney> Does each component get its own repo at that point?
20:24:37 < DASPRiD> Akrabat, i thought we stripped it out everywhere?
20:24:39 <weierophinney> or do we create one repo for "not shipped" components?
20:24:46 <weierophinney> DASPRiD: not yet we haven't.
20:25:08 < mabe_> weierophinney: one repo for each group of not shipped component
20:25:10 < EvanDotPro> weierophinney: we could just delete them... they'll always be in the history.
20:25:10 < PadraicB> weierophinney, separate repos are cheap - it's git
20:25:16 < SpiffyJr> lol EvanDotPro
20:25:16 < Akrabat> have to admit, that I'd quite like separate repositories for every component
20:25:17 < EvanDotPro> delete them for now*
20:25:18 < PadraicB> LOL
20:25:20 < beberlei> uh ship vs having in the repository is something entirely different
20:25:23 < mpinkston> +1 to that. It'd be easier to find maintainers that way too
20:25:27 <weierophinney> EvanDotPro: makes it harder to find them to improve them, though.
20:25:30 < prolic> a not shipped repo would be good, so things are grouped together, perhabs they even have dependencies on each other
20:25:38 < beberlei> seperate repositories for components is a mess
20:25:42 < EvanDotPro> weierophinney: meh... i'll be around for git help :-p
20:25:49 < WalterTamboer> beberlei: +1
20:25:50 < beberlei> at least for components having lots of dependencies, its really ugly
20:25:51 < Akrabat> beberlei: funnily enough, was gonna ask you about that
20:25:54 < Freeaqingme> I'm with beberlei. -1 for separating each of them
20:25:56 < ocramius> -1 on having different repositories. Many PRs/code changes space over more and more pieces of code
20:26:01 < DASPRiD> i'd say have them all in one repository (a build script can make separate packages out of it)
20:26:03 < ocramius> tracking dependencies become a mess REAL quick
20:26:05 < WalterTamboer> There is a difference between deploying and keeping them in version control..
20:26:14 < mpinkston> if they are too interdependent, then maybe they need to be re-thought
20:26:28 < Akrabat> in that case, two repos: the current one for stable and a new one for zf2-unstable
20:26:30 < bjy> if we separate, it's simple to keep them together – just have a "wrapper" repo with the components as submodules
20:26:30 <weierophinney> ocramius, beberlei – that's the impression I've had from doctrine and symfony – good to get some confirmation on that.
20:26:33 < PadraicB> mpinkston: +1
20:26:47 < SpiffyJr> Since we're using composer I'd just like to be able to add "zendframework/core": "*" to my list and get a slim&trim basic mvc setup going
20:26:53 < beberlei> weierophinney, well the symfony components are autogenerated from the central repository
20:26:56 < Xerkus> -1 for separate repos
20:26:57 < cgmartin> -1 on separate repos
20:27:03 < SpiffyJr> Is that possible with just zip archives? Anyone know?
20:27:05 < ocramius> I think the same of docs. Having docs all together allows contributors enforced to document their stuff by "please do also that"
20:27:06 < beberlei> weierophinney, and the doctrine ones is sometimes problematic
20:27:07 < Freeaqingme> -1 on separate repos / components
20:27:07 < prolic> an unstable branch would be sufficient???
20:27:14 < DASPRiD> beberlei, yeah, sounds like the best solution
20:27:16 < Freeaqingme> for unstable we could simply use a branch, imho
20:27:18 < Maks3w> ocramius, I don't believe that
20:27:31 < ocramius> Maks3w: well, refusing prs takes a click
20:27:39 < Akrabat> Freeaqingme: so have two separate clones ?
20:27:40 < EvanDotPro> -1 on separate repos.. splitting tests and docs would be a pain too...
20:27:41 < beberlei> and we even had the idea to remove the subtree splits which are autogenerated from github, because people do pull requests against them
20:27:45 < beberlei> which is even more annoying
20:27:56 < Akrabat> beberlei: as Linus about that
20:28:00 < Akrabat> ask even
20:28:02 < Maks3w> prolic, I think that an unstable namespaces ZendUnstable\<component>
20:28:02 < Freeaqingme> Akrabat, or just switch branch?
20:28:11 <weierophinney> So, what I'm seeing is:
20:28:12 < Akrabat> Freeaqingme: you can't - you still need Zend\Mvc
20:28:27 <weierophinney> * separate repos seems obvious, except there are issues in practice
20:28:30 < Freeaqingme> Akrabat, you can ocassionally merge back the stable version into unstable?
20:28:38 < SpiffyJr> Freeaqingme, eww
20:28:40 < Akrabat> not whilst developing the unstable
20:28:47 <weierophinney> * A single separate repo makes sense,
20:28:53 <weierophinney> * as does having a separate branch.
20:28:55 < Maks3w> The problem is that in Git you merge commits not files
20:28:58 < SpiffyJr> Separate namespaces makes the most sense to me in a single branch
20:29:03 < SpiffyJr> Then you can still have dependencies
20:29:20 < SpiffyJr> But the "unstable" components are clearly labeled (also makes packaging via script easy)
20:29:20 < Freeaqingme> SpiffyJr, we had that with ZendX_: nobody used it
20:29:21 < Maks3w> you can't say, Git move Zend\<component> to branch XXX
20:29:41 < EvanDotPro> Freeaqingme: i used it!
20:29:52 < Freeaqingme> Maks3w,
20:29:52 < SpiffyJr> Freeaqingme, a few people did, but it wasn't core, so the majority did not (same idea as unstable)
20:30:08 < cgmartin> is a single separate repo only to solve packaging?
20:30:11 < mpinkston> almost like signed vs unsigned modules..
20:30:15 < Freeaqingme> I was exaggerating, but hardly anybody was (I have used it too, some times)
20:30:15 < EvanDotPro> Freeaqingme: jquery and the pntl_fork stuff
20:30:21 < Akrabat> the key thing about unstable is that they aren't to be used
20:30:26 < Maks3w> Freeaqingme, do da same with directories and tell me the same
20:30:30 < WalterTamboer> weierophinney: I can't follow this anymore...
20:30:38 < Akrabat> as released & supported ZF components
20:30:40 <weierophinney> Freeaqingme: you lose history if you do that, though (the SO link you did)
20:30:58 <weierophinney> cgmartin: no, it's more to solve identifying what's stable and what is not
20:31:07 < Akrabat> the unstable ones need to be worked on to become released (or deleted)
20:31:30 < SpiffyJr> That's why I like the namespace idea. Keeps history intact. You don't have dependency issues across branches.
20:31:36 < SpiffyJr> And the separation is clearly marked.
20:31:36 < EvanDotPro> i say branch or delete code we're not maintaining.
20:31:39 < Akrabat> if we do the branch thing, then I think we move everything over and then justify each one that moved back to the master
20:31:42 < Maks3w> +1 for namespaces
20:31:53 < Akrabat> definitely -1 for namespaces
20:32:07 < EvanDotPro> -1 for separate namespaces... if an unstable component goes stable, you have a bunch of references/imports to update.
20:32:10 < Akrabat> right old pain to promote
20:32:11 <weierophinney> having changed namespaces within the repo a few times, it's a definite PITA, I'm -1 there.
20:32:30 <weierophinney> So, what's the consensus? Do we have one?
20:32:34 < Freeaqingme> wait
20:32:37 < WalterTamboer> I still don't understand why the code needs to be seperated in the repo.. What does that have to do with deployment?
20:32:43 < Akrabat> I think the branch should be called unsupported
20:32:46 < Freeaqingme> with the DI stuff, can we alias stuff when switching namespaces?
20:32:54 < Maks3w> EvanDotPro, Seriously? s#Zend\Unstable\Component#Zend\Component
20:32:59 <weierophinney> WalterTamboer has a good point folks
20:33:10 < cgmartin> what issues are there for having a "unstable" branch and master (stable/deleted components)
20:33:10 < mattcockayne> just wanna clarify something i may have missed.. .are we suggesting 1 branch with all "unstable" components or on branch for each "unstable" component
20:33:12 < Akrabat> WalterTamboer: cos it's nearly impossible to work out what which components are which and what state they are in
20:33:15 < EvanDotPro> imo having unsupported code in master is confusing – it doesn't imply at all that it's not unmaintained or out of date.
20:33:24 < Akrabat> I'm +1 with EvanDotPro
20:33:36 < bjy> EvanDotPro: +1
20:33:38 < SpiffyJr> If you're not cahnging the namespace then +1 EvanDotPro
20:33:39 < WalterTamboer> Akrabat: That why you normally have scripts to handle deployment
20:33:40 < Akrabat> master should contain what we support
20:33:42 < Maks3w> WalterTamboer, because beta things are not shipped in final releases
20:33:48 < Freeaqingme> I'm losing it now. Feels there are 3 discussions being voted for at once
20:33:51 < WalterTamboer> Maks3w: Still don't get it
20:33:52 < Akrabat> WalterTamboer: Composer consfuses things...
20:33:53 < mpinkston> isn't this why modules are now 1st class citizens? perhaps if it's not critical in every mvc app, it should be a module
20:33:57 < SpiffyJr> You need some sort of discrete separation.
20:34:11 < WalterTamboer> Akrabat: Ok... that's a valid point
20:34:12 < mpinkston> and modules could have 'vendor signatures'
20:34:14 < Freeaqingme> before doing any voting, can anyone clearly state what's voted for?
20:34:28 < Akrabat> mpinkston: I'm generally +1 on having ZF stable as small as we can reasonably make it
20:34:37 < SpiffyJr> Akrabat, mpinkston +1
20:34:44 <weierophinney> I'm going to pull back a moment. Several months ago, we discussed moving the various Zend\Service components into their own repos. But now it's sounding like we don't want that. I'm getting very confused.
20:34:51 < Maks3w> In resume what options are on the table?
20:35:10 < DASPRiD> weierophinney, i'm definetly for moving zend\service into their own repository
20:35:16 < DASPRiD> since they are unsupported
20:35:22 <weierophinney> options on the table:
20:35:25 < beberlei> zend service is something different imho
20:35:30 <weierophinney> * Move each unsupported into its own repo
20:35:40 < SpiffyJr> core + modules is sounding nice too mpinkston
20:35:42 <weierophinney> * Have a single repo for all unsupported components
20:35:44 < Maks3w> DASPRiD, +1 if the component will not have support don't have sense still having the code
20:35:49 <weierophinney> Folks, stop please
20:35:55 <weierophinney> I'm trying to summarize options.
20:36:01 <weierophinney> * Move each unsupported into its own repo
20:36:06 <weierophinney> * Have a single repo for all unsupported components
20:36:16 <weierophinney> * Have a separate branch for unsupported components
20:36:25 <weierophinney> * Have a separate branch per unsupported component
20:36:32 <weierophinney> * Delete unsupported components entirely
20:36:42 < Maks3w> * Do nothing
20:36:47 <weierophinney> * Do nothing, and leave it to the build script
20:36:58 <weierophinney> Is that all the options currently floating?
20:37:05 < SpiffyJr> You forgot mpinkston's
20:37:07 < DASPRiD> looks complete
20:37:07 < mpinkston> my 2cents = core is all MVC critical components. everything else is a module with an official "zend" signature stable or not
20:37:17 < mpinkston> other vendors can have their own sigs
20:37:22 < saschaH> who decide what "unsoported" means?
20:37:26 < SpiffyJr> <mpinkston> isn't this why modules are now 1st class citizens? perhaps if it's not critical in every mvc app, it should be a module
20:37:27 < beberlei> this is a deployment problem
20:37:27 < Akrabat> saschaH: me
20:37:30 < Freeaqingme> weierophinney, I also read 'have a separate namespace for unsupported components'
20:37:33 < saschaH> Akrabat: lol
20:37:34 < EvanDotPro> * Delete unsupported code, and bring it back if/when it becomes supported
20:37:45 < DASPRiD> saschaH, things like services are unsuported, since they need their own release cycle due to exterrnal api changes
20:37:49 < Akrabat> deleted code is lost code
20:37:57 < EvanDotPro> Akrabat: +1
20:38:01 <weierophinney> Freeaqingme: I took that one off the table as I've had to deal with it already.
20:38:05 < saschaH> DASPRiD: thx.
20:38:14 < Akrabat> that's a good point. Anything that isn't on the same release cycle as ZF-core should not be in the repo
20:38:18 < Freeaqingme> weierophinney, heh, right
20:38:22 < Maks3w> WalterTamboer, one reason more that is stable components have backward compatibility but unstable components don't, so you need to know what is the real status before start to develop an App for your client
20:38:27 < prolic> +1 for EvanDotPro, the code is not lost, at least we all know about them and will recover as soon as possible
20:38:28 < WalterTamboer> Akrabat: EvanDotPro: Create a branch of the current code base, delete unused code in the master. THan you would have a backup right?
20:38:30 < DASPRiD> EvanDotPro, i think you confuse "supported" and "maintained"
20:38:39 < cgmartin> I like #3 branch, and #5 delete
20:38:43 < mattcockayne> weierophinney: Might I suggest we put a vote on the Wiki for all the options voice and re-address at the next meeting
20:38:53 < Akrabat> prolic: we know about them now... we won't remember in 4 years
20:38:54 < Xerkus> +1 for separate branch per unsupported component, then it can be worked on, rebased on master and merged
20:39:02 < EvanDotPro> WalterTamboer: i'm fine with a branch, but it's not a "backup" you're not losing anything.
20:39:16 < WalterTamboer> EvanDotPro: Ok than I misunderstood
20:39:19 < prolic> Akrabat: so we make a wiki entry: our lost components, please help
20:39:26 < Akrabat> I'm much more interested in polishing what we are shipping for 2.0
20:39:33 < Akrabat> i want that list and that list only in master
20:39:38 < Maks3w> I think that we can find a trick to maintain the history of the file like the subtrees
20:39:41 < Akrabat> the rest is a bikeshed to me
20:39:41 < WalterTamboer> Maks3w: I see. I would say, master is always in development so you can never say that it is stable. You pick a moment where you make it stable, tag it and start the process over again.
20:39:45 < Maks3w> when is moving between branches
20:39:47 < beberlei> a branch is messy
20:39:55 < EvanDotPro> having a branch would help us not to forget..
20:39:58 < beberlei> how to keep the code compatible with the core?
20:40:01 <weierophinney> I like Xerkus's suggestion – it's relatively easy to fork a branch, rebase off of master, and work from there. You also then have the rest of the framework available, making testing easy.
20:40:10 < Maks3w> also you need rebase the branch all the time
20:40:20 < Akrabat> Maks3w: is that hard?
20:40:21 < beberlei> yeah, rebasing the master onto the "trash" branch
20:40:30 < Freeaqingme> If a component has been unmaintained for a while, we could move it to a branch called graveyard. However, the moment we stop maintaining it I'd opt for simply not packaging it. That allows for people to easily catch up developing it once they discover it's missing
20:40:36 < SpiffyJr> Akrabat, in theory no.
20:40:41 < EvanDotPro> Maks3w: no, we'd probably have to contend with merge commits and not rebase.
20:40:46 < Maks3w> Akrabat, no, if nothing touch something from the stable components
20:41:13 < DASPRiD> the problem with service components was, is that they need their own release cycle, thus imho they don't belong into the core repository
20:41:18 < Akrabat> so , we're still no closer to actually deciding what we want to ship
20:41:20 < Freeaqingme> weierophinney, agreed. But then I would put those branches in a separate repo, just to keep oversight over time
20:41:20 < Xerkus> and if component dropped completely - just delete its branch
20:41:34 < Akrabat> DASPRiD: +1 service to separate repositories
20:41:38 < Akrabat> that's agreed I thought?
20:41:42 < DASPRiD> i thought so
20:41:45 <weierophinney> kk, obviously this arena needs more discussion.
20:41:59 < DASPRiD> discussion is the reason why we are here
20:42:01 <weierophinney> Let's move to the core question here, which Akrabat keeps asking: what do we ship?
20:42:02 < WalterTamboer> weierophinney: This is such a big change which in my opinion needs more thinking before a decision can be made... Is it an idea if someone creates a page on the wiki where all cons and pros are listed?
20:42:12 < Xerkus> weierophinney: we decided we move services out into it's own repo to keep it's own release cycle iirc
20:42:16 <weierophinney> WalterTamboer: yes, that's my suggestion.
20:42:17 < Freeaqingme> weierophinney, mind providing a little more context?
20:42:30 <weierophinney> Freeaqingme:
20:42:32 < Akrabat> My general idea for choose what to ship was that it should have two committed maintainers
20:42:50 < mpinkston> what ships for zf2 shouldn't be that tough a question.. how it ships seems to be the problem
20:43:00 < Akrabat> if we cant' find two people willing to patch and merge PRs then we shouldn't commit to it
20:43:07 < SpiffyJr> Akrabat, my vote is for whatever makes the skeleton app run + a few others (forms, db, and maybe navigation).
20:43:12 <weierophinney> mpinkston: there's a lot of cruft in that list, tbh
20:43:30 < cgmartin> SpiffyJr: +1
20:43:30 < mpinkston> weierophinney: 'tis true that
20:43:32 < Akrabat> SpiffyJr: -navigation, +i18n maybe
20:43:48 < Maks3w> Akrabat, weierophinney -1 to have a minium of maintainers
20:43:57 < Akrabat> shrug it's much easier to start the list by finding out what we can actually maintain going forward
20:44:02 < Freeaqingme> webik, there's 50+ components in there. I'd rather have someone write a specific proposal, of which we can then discuss details
20:44:12 < Xerkus> SpiffyJr: remove zend\db it is not used in skeleton)
20:44:14 < Freeaqingme> * weierophinney ^^
20:44:21 < Maks3w> you can't quarantee volunteers that for the live cycle of the framework
20:44:33 < SpiffyJr> Xerkus, yes, but I think providing a db implementation out of the box is probably warranted?
20:44:34 < DASPRiD> Xerkus, lol
20:44:40 < Akrabat> Maks3w: no - but if we can't find anyone now...
20:44:48 < Akrabat> why do you think we'll suddenly find people later?
20:44:52 < EvanDotPro> Xerkus is right, i think we've already decided and voted on what to do with the service components, this should only be about the other unmaintained stuff.
20:44:53 < Maks3w> Now and the next week?
20:45:07 <weierophinney> Akrabat: well, the argument against that is that with git, we're getting a lot more folks coming in and providing fixes.
20:45:21 < DASPRiD> EvanDotPro, i think we already voted on unmaintained stuff as well earlier (removal)
20:45:21 <weierophinney> people outside the subset of developers in this room
20:45:23 < Akrabat> weierophinney: may be, but someone needs to check them
20:45:32 < SpiffyJr> Has anyone sat down and figured out what is needed to run the skeleton app?
20:45:33 <weierophinney> Akrabat: fair enough
20:45:45 < Akrabat> I won't merge a i18n PR for instance
20:45:51 < DASPRiD> Akrabat, heh
20:45:56 < Maks3w> Anyway could be usefull have a list of how many components are unstable
20:46:01 < Freeaqingme> this discussion is pointless, sorry
20:46:06 < Maks3w> Maybe we are talking of two or five
20:46:07 < Akrabat> Maks3w: most of them
20:46:10 < Maks3w> and its not a big deal
20:47:06 < Xerkus> Akrabat: then i think they must have at least one person per component who can review PRs
20:47:13 <weierophinney> Akrabat: I wouldn't say most components are unstable at this point. As you note, 61 are currently tested on travis out of 86 – we simply need to identify those other 25 and determine if they're needed or can be tossed.
20:47:18 < saschaH> again me, who and how decide what parts are unstable
20:47:21 < Akrabat> Xerkus: that's what I said
20:47:44 < Maks3w> weierophinney, How many of that are Services?
20:47:45 <weierophinney> Akrabat: and a number of those not tested can't be tested on travis, due to needing API credentials (a vote for moving those into separate repos, really)
20:47:54 < Akrabat> weierophinney: exactly
20:48:01 <weierophinney> Maks3w: bulk of those are services.
20:48:01 < Xerkus> Akrabat: vs you 2 dedicated maintainers
20:48:12 < Maks3w> weierophinney, I only have 7 components in the blacklist
20:48:16 < Maks3w> so the rest are tested
20:48:23 < Akrabat> saschaH: My view is that stable == able to be maintained and documented
20:48:34 < Maks3w> Amf, Date, Dojo, Queue, Test, Wildfire
20:48:45 < mpinkston> looks like this needs one of those voting pages broken down by component
20:48:49 <weierophinney> The ones I know are unstable and likely should be removed/marked unstable/whatever are Queue, GData, Wildfire, and possibly Debug.
20:49:02 < Akrabat> Maks3w: Search, Pdf, Registry, Progressbar, Debug, queue, openid...
20:49:11 <weierophinney> AMF belongs on that list, too. Dojo is a harder one – either needs to be dropped or pushed to 2.1
20:49:17 < WalterTamboer> mpinkston: I was just typing that
20:49:38 < mpinkston>
20:49:48 <weierophinney> So, Akrabat – I suggest we create a google form with a yea/nay vote for each, noting testing status for each, and post that to the list?
20:49:54 < Xerkus> i'm for moving dojo to ZfcDojo
20:49:54 < mpinkston> personally, I'm going to try to make paginator obsolete with something else, but for now it seems a little behind
20:49:59 < saschaH> Akrabat: so with the last topic we have no stable component?
20:50:03 < Xerkus> as module
20:50:07 < prolic> dojo in zf wouldn't be sufficient for nicer dojo integration, imho we need a module and a dojo module is already there i guess, don't know how good it is
20:50:08 < mpinkston> Xerkus: +1!
20:50:15 < Akrabat> weierophinney: I agree. I would also list who's willing to maintain
20:50:23 < Freeaqingme> weierophinney, agreed
20:50:26 < Akrabat> though we can do other way around
20:50:36 <weierophinney> Xerkus, mpinkston, prolic – that makes sense
20:50:38 < Akrabat> if community want a component, then someone should be willing to step up
20:50:53 < Maks3w> I think that any component with external dependencies should be in a different repository with differente live cycles
20:51:01 <weierophinney> So, last bit then: still move services to independent repos?
20:51:03 < Akrabat> if not, I don't care what the communit wants
20:51:08 < Akrabat> weierophinney: yes
20:51:13 < Freeaqingme> pros/cons?
20:51:21 <weierophinney> that makes the list shorter, definitely
20:51:30 < Freeaqingme> repos != distribution imho
20:51:32 < prolic> i could probably help refactoring zend\queue in 1-2 months
20:51:34 < Akrabat> Freeaqingme: As DASPRiD service are on different release cycles
20:51:41 <weierophinney> prolic: we'll target it for 2.1 then.
20:51:42 < Maks3w> +1 for move Services and other similar components, GData, Cloud, etc
20:51:43 < mpinkston> services thing +1
20:51:43 < prolic> i mean to start with it
20:51:47 < Freeaqingme> so even if we ship them separately, I dont see why they have to be in a separate repo
20:51:56 < SpiffyJr> My vote is for:
20:51:56 < Akrabat> so service\Amazon may need an update between 2.0 and 2.1 due to changes at their end
20:52:08 <weierophinney> Freeaqingme: so that they don't get tagged with the same version.
20:52:09 < SpiffyJr>
20:52:19 < mpinkston> I guess the only issue with repos is merge privileges right?
20:52:32 <weierophinney> Freeaqingme: we can have each of those repos indicate what versions of ZF they work with, but they'd have their own versioning.
20:52:33 < Akrabat> far far better that the service components follow their own release cycles
20:52:36 < Maks3w> mpinkston, no, its the PR sync
20:52:40 < cgmartin> identify for each? 1) which are core/required, 2) which to be moved, 3) which to be removed altogether
20:52:45 <weierophinney> mpinkston: we can define additional teams for those.
20:52:47 < mpinkston> ahyes
20:52:54 < mpinkston> ok got it
20:53:08 <weierophinney> kk, so, action items (please don't interrupt)
20:53:19 <weierophinney> * Akrabat and myself to create a google form for voting on each individual component
20:53:19 < Maks3w> Here was a classification
20:53:40 <weierophinney> * Move services (including Gdata, likely Cloud) into separate repos, to version separately
20:54:01 <weierophinney> * Open a wiki page identifying options for dealing with unstable components, and discuss (and later vote)
20:54:11 <weierophinney> does that sound right?
20:54:15 < prolic> agree
20:54:15 < Freeaqingme> #2 is all services in 1 repo right?
20:54:16 < DASPRiD> +
20:54:21 < saschaH> yep
20:54:24 <weierophinney> Freeaqingme: no, repo per service.
20:54:45 < Maks3w> Move any component that use external apis
20:54:48 < Akrabat> that maches my action list
20:54:49 < Freeaqingme> I see a maintenance hell coming up
20:54:50 <weierophinney> Freeaqingme: as each service has its own timeline
20:55:11 <weierophinney> Freeaqingme: we have one already. Our service components often get out of date with official apis
20:55:13 < Akrabat> I'd love to see separate teams per service component
20:55:14 < Freeaqingme> weierophinney, what's wrong with releasing all service components alltogether on a biweekly schedule?
20:55:34 < prolic> agree with Freeaqingme
20:55:35 < Akrabat> it'd be great to have people who actually use the service be responsible for it and drive it forward
20:55:39 < Maks3w> Freeaqingme, each compony has his own livecycles
20:55:55 < Maks3w> Freeaqingme, for example GitHub v2 will dissapear
20:55:55 < SpiffyJr> Freeaqingme, if the work is done the day after an API change why force everyone for that service to wait two weeks?
20:55:57 < Akrabat> Freeaqingme: realistically, most people only use one or two service components
20:55:58 <weierophinney> Freeaqingme: it makes more sense for the team working on the service component to issue a release when it's ready.
20:56:00 < Freeaqingme> Maks3w, so? When it's stable they merge it to the release branch, and then it will be released in the next release?
20:56:02 < Maks3w> and you cannot wait for a SF release
20:56:02 < prolic> it doesn't matter if my Zend\Cloud 12.0 has no difference to 4.0
20:56:08 < Akrabat> so why distribute together ?
20:56:10 < Maks3w> ZF release to do that
20:56:18 <weierophinney> Freeaqingme: plus, with composer, we wouldn't even need to package – just tag and it's ready
20:56:19 < Maks3w> because the release are each 6 months
20:56:35 < Maks3w> (for example)
20:56:37 < Akrabat> weierophinney: +1
20:57:06 < mpinkston> composer not my fav, but it certainly works (I just need to learn it better). so +1
20:57:10 < cgmartin> weierophinney: +1 on your action items
20:57:12 < Freeaqingme> still, you loose oversight. You loose the 'zf standard'. Different teams will pick up different tactics fairly soon
20:57:24 < Freeaqingme> so I'm -1
20:57:29 < Akrabat> we have that now anyway
20:57:37 < Xerkus> yeah, i somewhat agree on single services repo
20:57:47 < Maks3w> ZF should be only core and separated components and this components with different live cycles
20:57:54 < Freeaqingme> Akrabat, but yet now everybody get to see 1 pull request backlog and just ocassionally look what's going on, and that will be lost
20:57:56 < Akrabat> noone who works on Zend_Service_Amazon compares their work to Zend_Service_Simpy
20:58:13 <weierophinney> kk, let's call it a day, folks. Lots of action items. I'll get the SM stuff done by end of week so it can be in beta5

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