View Source

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

<h2>Information</h2>

<ul>
<li>Date: 20 September 2012, 18:00-19:00 UTC</li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 26 September 2012</li>
</ul>


<h2>Summary</h2>

<h3>RFC: Move to GitHub Issues (and possibly Wiki)</h3>

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

<p>Ralph Schindler (nick: ralphschindler) created an RFC for moving to GitHub issues and potentially wiki:</p>

<ul>
<li><a class="external-link" href="https://github.com/zendframework/zf2/wiki/RFC-Move-To-Github-Issues-And-Wiki">https://github.com/zendframework/zf2/wiki/RFC-Move-To-Github-Issues-And-Wiki</a></li>
</ul>


<p>The idea is basically to keep development information in one place. It will simplify the ability to create issues and link them to the pull requests that resolve them, and to search through both issues and pull requests for duplication.</p>

<p>The main drawbacks to moving to GitHub issues are around getting at information that JIRA exposes readily: priority, voting, affected versions, component affected, and automatic assignment being the primary ones. Most of these may be emulated with issue tags (in particular, priority, affected versions, and component affected). Some of them may be emulated via the GitHub API &ndash; and much automation could be accomplished that way as well. </p>

<p>A migration to GitHub issues would occur only for the ZF2 issues; ZF1 would remain on JIRA. As such, we may be able to migrate JIRA to a hosted solution.</p>

<p>Regarding the wiki, the majority of the wiki is read-only (or should be) at this point, due to the feature-freeze status of ZF1. As such, the only part of the wiki that is actively growing is the ZFDEV2 namespace. The main issues with moving to the GitHub wiki are:</p>

<ul>
<li>lack of namespaces (but at this time, we're not really using them anyways)</li>
<li>voting (this could and likely should be accomplished via another service/app anyways).</li>
<li>comments</li>
</ul>


<p>The plan for migration would be to migrate only pages under the ZFDEV2 namespace. Other pages would either be scraped in order to be served statically, or moved to a hosted Confluence instance.</p>

<p>Comments were the main sticking point. One suggestion was that these could be emulated by creating an issue per wiki page and cross-linking the two (ZF-Commons does this). Alternately, we could simply open a dedicated thread on the mailing list, and link to that. Some even suggested that comments in the wiki may not be a great idea, anyways, as they fragment the conversations.</p>

<p>Alternately, we could host something like dokuwiki via the ZF website, and migrate pages to that solution. This would allow us to fairly easily keep the wiki up-to-date (we are PHP developers, after all), and keep the wiki as part of the website. However, it would mean a disconnect with the other developer tools.</p>

<p>The general agreement during the meeting was that it makes sense to move issues over as soon as possible, and to continue investigating and exploring options for the wiki.</p>

<p><strong>tl;dr</strong>: The ZF2 issues will move to GitHub issues soon; expect a different solution for the wiki not long after.</p>

<h3>Frequency of maintenance releases</h3>

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

<p>Matthew (nick: weierophinney) announced the plan for minor releases will be the same as for the beta release cycle: every 8-12 weeks. The question he had was: how often should maintenance releases be made. The suggestions made were:</p>

<ul>
<li>Every two weeks</li>
<li>Every month</li>
</ul>


<p>with the latter, every month, getting the vote. The decision was then made to do releases every third Wednesday of the month (well, technically Tuesday, but Matthew made a case for Wednesday, and this was agreed upon).</p>

<p><strong>tl;dr</strong>: Maintenance releases will be done on the third Wednesday of each month, with minor releases every 8-12 weeks (2-3 months).</p>

<h3>RBAC RFC</h3>

<p>Kyle Spraggs (nick: spiffyjr) created a proposal for a new Role Based Access Control (RBAC) component for the Zend\Permissions component:</p>

<p> <a class="external-link" href="http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Zend_Permission_Rbac">http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Zend_Permission_Rbac</a></p>

<p>It differs from ACL as it's purely role-based, and does not include resources; as such, it's a simpler solution to permissions.</p>

<p>There was no disagreement with the approach, and everybody gave it a thumbs up.</p>

<p><strong>tl;dr</strong>: We'll have an RBAC solution in ZF 2.1.</p>

<h3>ZendSkeletonApplication tests</h3>

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

<p>Gabriel Baker (nick: Gabriel403) proposed adding tests to the ZendSkeletonApplication for two reasons:</p>

<ul>
<li>To ensure that the functionality it provides stays stable</li>
<li>To provide an example of how to test a ZF2 application and/or module</li>
</ul>


<p>Matthew (weierophinney) noted that the ZendSkeletonModule has a testing infrastructure in place that could be used to get started. Evan Coury (EvanDotPro) indicated that the scaffolding in ZSM is out-dated, and that they'd developed a simpler one in ZfcBase in the ZF-Commons project. Gabriel agreed to look them over and start working on tests.</p>

<p><strong>tl;dr</strong>: look for tests in an upcoming release of the ZendSkeletonApplication!</p>

<h3>OAuth Server</h3>

<p>(Search for 19:00:31 in the log.)</p>

<p>Gary Hockin (nick: Spabby1) is looking for volunteers for working on the oauth2 server. If you have ideas or want to help, please contact him.</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">
18:02:21 &lt;weierophinney&gt; So, let's begin
18:02:40 &lt;weierophinney&gt; Sorry for not getting a formal agenda in place -- been interesting mopping up after the release!
18:02:54 &lt;weierophinney&gt; And, first, CONGRATS everyone, on a successful release!
18:03:07 &lt;weierophinney&gt; Second, get ready for another one -- 2.0.1 will likely drop today.
18:03:33 &lt;weierophinney&gt; As for other things, the big one for the agenda is Ralph's RFC on moving to Github issues.
18:03:41 &lt;weierophinney&gt; Let's see if I can get him in here...
18:03:52 &lt; ralphschindler&gt; already in here
18:04:00 &lt;weierophinney&gt; oh, missed you in the joins!
18:04:10 &lt;weierophinney&gt; ralphschindler: so, share a link, and take the floor. :)
18:04:31 &lt; ralphschindler&gt; well
18:04:40 &lt; ralphschindler&gt; hopefully everyone has already seen:
18:04:41 &lt; ralphschindler&gt; https://github.com/zendframework/zf2/wiki/RFC-Move-To-Github-Issues-And-Wiki
18:04:56 &lt; ralphschindler&gt; it was posted to the wiki last week, and to the mailing list yesterday (after being 'completed")
18:05:05 &lt; ralphschindler&gt; does anyone disagree with the move?
18:05:31 &lt; ralphschindler&gt; b/c I'm getting the sense no one cares, or everyone agrees, in general, with the move
18:05:34 &lt;weierophinney&gt; or does anyone have reservatoins...
18:06:06 &lt; Spabby1&gt; all-in-one-place +1
18:06:10 &lt;weierophinney&gt; For the record, I originally opposed the idea, but over the last couple months, in working with github issues in other projects, and then seeing what the API exposes, my reservations are gone.
18:06:23 &lt; cgmartin&gt; do all essential features exist in the GitHub system? any feature that will be missed?
18:06:29 &lt; Gabriel403&gt; I'm a little worried about the lack of a component option
18:06:40 &lt;weierophinney&gt; Gabriel403: we'd use tagging for that.
18:06:54 &lt;weierophinney&gt; Gabriel403: interestingly, jira actually creates a tag when you specify a component already.
18:06:58 &lt; Gabriel403&gt; Oh, hmm, then awesome :)
18:07:01 &lt;weierophinney&gt; So in many ways, it's equivalent already.
18:07:05 &lt; Bakura&gt; Really agree too with this one !
18:07:06 &lt;weierophinney&gt; and you can search by tag easily
18:07:36 &lt;weierophinney&gt; Gabriel403: also, if a tag already exists, github will autocomplete for you, so it's really, really easy.
18:07:52 &lt; cgmartin&gt; agree with Spabby about benefits of having in one place
18:07:54 &lt;weierophinney&gt; cgmartin: the only one that really comes to mind is the auto-assign on creation. But we can automate that via the API.
18:08:14 &lt; cgmartin&gt; cool, just wanted to ask that
18:08:57 &lt;weierophinney&gt; cgmartin: likely, this will be a better solution anyways, as if you want to change who is on that list, you'd be able to do a PR against the repo that contains the automation.
18:09:29 &lt;weierophinney&gt; For the wiki bit, we've got some ideas, but nothing concrete at this time.
18:09:35 &lt;weierophinney&gt; Most of the use in the wiki is in 2 areas.
18:09:52 &lt; EvanDotPro&gt; the few features that aren't there by default are still avaialble via other means (api, etc), but even without that, i don't think they introduce any absolute barriers.
18:09:54 &lt;weierophinney&gt; ZFPROP, which is basically dead at this time, as 1.12 is the last minor release.
18:10:07 &lt; Gabriel403&gt; Would this be a quick move? Like by next week all issues are on github? Or something a little longer to go through?
18:10:17 &lt; Xerkus_needsWork&gt; possible issue is that users might not know or care how to use it properly. that is really minor though
18:10:17 &lt;weierophinney&gt; ZFDEV2 is useful -- but that we can likely port easily to github wiki, due to the fact that it's mostly flat pages.
18:10:22 &lt; EvanDotPro&gt; i think the advantage of making the issue tracker more accessible on a site where everyone already has an account far outweighs anything esle.
18:10:35 &lt; PadraicB&gt; EvanDotPro +1
18:10:37 &lt; cgmartin&gt; aye
18:10:42 &lt;weierophinney&gt; Gabriel403: next few weeks -- have to work it into our schedule (we have a bit of work for 2.1, as well as on the migration guide)
18:11:06 &lt; Gabriel403&gt; weierophinney: ok so < 1month
18:11:36 &lt;weierophinney&gt; Gabriel403: also, we'd need somebody to step up and write a conversion from confluence wiki markup to something github recognizes (I think there's 8 or so markup styles it can work with)
18:11:50 &lt; EvanDotPro&gt; one feature i see used a lot on the confluence wiki is per-page comments.. it would be nice if we could embed disqus comments on github wiki pages, but currently it's not possible :(
18:11:54 &lt; ralphschindler&gt; i'll likely run my test scripts on another test repository/issue api before actually pushing the jira stuff to zendframework/zf2
18:12:02 &lt; ralphschindler&gt; so we can see what it will ultimately end up looking like
18:12:07 &lt;weierophinney&gt; EvanDotPro: yeah, that's one issue, definitely
18:12:23 &lt; ralphschindler&gt; I actually dislike the use of comments in wiki to some degree
18:12:24 &lt; EvanDotPro&gt; weierophinney: on ZF-Commons i worked around that by creating a GH issue per wiki page.
18:12:27 &lt; ralphschindler&gt; it fragments conversations
18:12:29 &lt;weierophinney&gt; I'm thinking the first step is moving ZF2 issues to github, and second step would be wiki
18:12:37 &lt; Gabriel403&gt; EvanDotPro: per page?
18:12:47 &lt;weierophinney&gt; EvanDotPro: I saw that when I voted yesterday.
18:12:51 &lt; cgmartin&gt; weierophinney: +1
18:13:24 &lt; EvanDotPro&gt; weierophinney: hmm, yeah... i agree about the fragmented conversation... and that was one of the main complaints we've received (and one that's pretty hard to disagree with)
18:13:48 &lt; EvanDotPro&gt; Gabriel403: For example we have https://github.com/ZF-Commons/RFC/wiki/RFC:-ZfcAcl with comments here: https://github.com/ZF-Commons/RFC/issues/1
18:14:24 &lt; ralphschindler&gt; we've already got 2 places conversations happen: IRC and mailing list
18:14:41 &lt; ralphschindler&gt; i view the wiki as a place to memorialize those conversations in something more concise
18:14:47 &lt; Gabriel403&gt; EvanDotPro: oh so you mean more of a discussion board than a wiki?
18:15:09 &lt; Gabriel403&gt; like a discuss page for a wiki page
18:15:10 &lt; EvanDotPro&gt; Gabriel403: correct, discussion related to the content on the wiki page, precisely.
18:15:15 &lt; EvanDotPro&gt; Gabriel403: right.
18:15:16 &lt; Gabriel403&gt; nods
18:15:17 &lt; Spabby1&gt; less of a discussion board, more of a documentation repository based on discussions elsewhere
18:15:41 &lt;weierophinney&gt; EvanDotPro: actually, I think ralphschindler is saying that comments on a wiki in GENERAL lead to fragmentation.
18:15:53 &lt; Gabriel403&gt; Do we have any idea what github have planned?
18:16:02 &lt; ralphschindler&gt; Gabriel403: nope
18:16:05 &lt;weierophinney&gt; EvanDotPro: I think the appropriate thing would be to link to a ML thread and/or the #zftalk.dev channel, actually.
18:16:14 &lt; ralphschindler&gt; Gabriel403: you'd have to check the gollum repo for that
18:17:00 &lt; EvanDotPro&gt; weierophinney: yeah, i'm totally okay with that too... i would have done so with ZF-Commons had we had an official mailing list yet.
18:17:15 &lt; Gabriel403&gt; weierophinney: EvanDotPro ,I think if github wiki had talk pages like other wikis that might work
18:17:43 &lt; EvanDotPro&gt; though, the github issues approach does te discussion more accessible to a larger base of users... that could be a positive and a negative, heh.
18:18:12 &lt;weierophinney&gt; Here's my thoughts based on discussion:
18:18:24 &lt;weierophinney&gt; * Looks like everyone agrees with moving issues over. We'll do this ASAP.
18:18:33 &lt; EvanDotPro&gt; Gabriel403: i think we can manage for now with simply linking to mailing list threads.
18:18:49 &lt;weierophinney&gt; * Wiki is more problematic due to legacy of old information, as well as comments. We should likely discuss this further on-list.
18:18:55 &lt; Gabriel403&gt; EvanDotPro: yeh, I can never remember my account for the mailing list :)
18:19:01 &lt; Spabby1&gt; even though it isn't, the mailing list/irc and current wiki approach does feel a little... cliquey to people who aren't involved, it actually isn't once you've joined but anything we can do to be more inclusive feels right to me
18:19:58 &lt;weierophinney&gt; I have to admit, I kind of like the idea of an issue per page; as Spabby1 says, it keeps it in one place, and doesn't require necessarily knowing where in the ZF site to go.
18:20:35 &lt; EvanDotPro&gt; yeah, i can agree with that.
18:20:36 &lt; ralphschindler&gt; what kind of page?
18:20:53 &lt; EvanDotPro&gt; ralphschindler: any wiki page requring context-specific discussion about the content on that page.
18:21:03 &lt; Gabriel403&gt; such as rfcs
18:21:05 &lt; ralphschindler&gt; why can't that happen on the mailing list?
18:21:07 &lt; EvanDotPro&gt; as Gabriel403 said, similar to a mediawiki talk page.
18:21:14 &lt; ralphschindler&gt; seems to work for php.net internals
18:21:16 &lt; EvanDotPro&gt; ralphschindler: see Spabby1's comment.
18:21:37 &lt; ralphschindler&gt; exactly, do we really want drive-by commentary?
18:21:58 &lt; ralphschindler&gt; its hard enough managing drive-by pull requests ;)
18:22:05 &lt;weierophinney&gt; We also tossed around the idea of a PHP-based wiki such as dokuwiki that would be on the ZF website. However, I think that might lead to fragmentation -- tools aren't all in one place.
18:22:34 &lt; Gabriel403&gt; Should we consider moving issues as a seperate vote from moving wiki? since the wiki seems to need more discussion?
18:23:02 &lt; ralphschindler&gt; we've really reduced the overhead in committing back to this project drastically, asking someone to partake in IRC meetings or mailing list conversation doesn't seem like "too much" to me
18:24:09 &lt;weierophinney&gt; Gabriel403: yes -- that's what I proposed above.
18:24:21 &lt; PadraicB&gt; Personally, I don't see the mailing list as that huge a barrier to anyone...
18:24:35 &lt; ralphschindler&gt; esp. with nabble
18:24:37 &lt; PadraicB&gt; Drive by meeting commentary...
18:24:40 &lt; PadraicB&gt; ;)
18:24:47 &lt; ralphschindler&gt; haha
18:24:48 &lt;weierophinney&gt; PadraicB: I agree. And yet, there are folks who loathe mailing lists mightily.
18:25:11 &lt; spiffyjr&gt; I dislike it but that doesn't prevent me from usin git.
18:25:22 &lt; PadraicB&gt; weierophinney, you can't please everyone - I despise private IRC discussions on important topics. Should we close down the channels?
18:25:25 &lt; EvanDotPro&gt; PadraicB: the only issues i see with the mailing list are A) confusion about nabble and not being able to register and post via nabble. B) some people have issues with their mail not being authenticated with the mailing list occasionally (user error or not, it happens)
18:25:51 &lt; Gabriel403&gt; PadraicB: private?
18:25:59 &lt; EvanDotPro&gt; Gabriel403: private as in no logged
18:26:01 &lt; EvanDotPro&gt; s/no/not
18:26:04 &lt; Gabriel403&gt; oh
18:26:08 &lt; spiffyjr&gt; I still favor forums ;)
18:26:12 &lt; EvanDotPro&gt; so those who are not here don't get to see the conversation.
18:26:19 &lt; PadraicB&gt; Gabriel403, IRC is not logged - I am clueless as to what happens here most of the day ;)
18:26:36 &lt;weierophinney&gt; PadraicB: LOL -- touche!
18:26:37 &lt; Gabriel403&gt; ztalk.dev is isn't it?
18:26:40 &lt; Spabby1&gt; we talk about security while your not around
18:26:46 &lt; EvanDotPro&gt; it wouldn't be so bad if posting via nabble worked properly... does anyone know if we can make that work? whitelist nabble smtp servers or something?
18:26:51 &lt;weierophinney&gt; EvanDotPro: YOU *CAN* register and post via nabble.
18:27:06 &lt;weierophinney&gt; I've done it myself to test. I've never understood those who claim you can't.
18:27:42 &lt; EvanDotPro&gt; weierophinney: really? it always shows "This message has not been approved by the mailing list." and you can only see it on nabble, it never comes through to the ML recipients.
18:27:55 &lt; spiffyjr&gt; While you *can* use Nabble it a poor-man's substitute for a real forum. Mailing lists don't bother me enough to push the subject but I definitely prefer forums.
18:28:07 &lt; Spabby1&gt; weierophinney: I couldn't, I tried several times, got the problem EvanDotPro outlined
18:28:12 &lt; PadraicB&gt; weierophinney, that does happen - on nabble, but never reaches ML. Rare but possible.
18:28:13 &lt;weierophinney&gt; EvanDotPro: when that happens, the poster IGNORED THE BIG HONKING DIALOG that pops up that even gives them a form for registering.
18:28:34 &lt; Xerkus_needsWork&gt; weierophinney: i tried posting via nabble couple of years ago, half of my mails never reached list
18:28:35 &lt; PadraicB&gt; Possibly, I don't use it enough ;)
18:28:53 &lt;weierophinney&gt; (I just tried now, because list emails are not coming to my zend.com addy)
18:29:07 &lt; EvanDotPro&gt; weierophinney: well, in that case i suppose it's just an intelligence filter, which i'm fine with. ;)
18:29:16 &lt; PadraicB&gt; lol
18:29:29 &lt; Spabby1&gt; EvanDotPro: I would have failed
18:29:32 &lt; Gabriel403&gt; brb, I vote +1 if we get round to it before i'm back
18:29:34 &lt; Spabby1&gt; oh... wait...
18:29:40 &lt;weierophinney&gt; Of course, mine is now marked "not yet approved". We'll see. I may take back what I said. :)
18:30:07 &lt;weierophinney&gt; Okay, so that was the first big order of business.
18:30:20 &lt;weierophinney&gt; Next: how frequently should we do maintenance releases?
18:30:34 &lt;weierophinney&gt; For background, the plan is to do minor releases on a similar schedule to the betas -- every 8-12 weeks.
18:30:47 &lt;weierophinney&gt; The question I have is: how frequently should we push out maintenance releases?
18:30:51 &lt; Spabby1&gt; I have to put daughter to bed
18:31:05 &lt;weierophinney&gt; It's really easy for us to turn those around at this point -- I think ~30m from start to finish.
18:31:30 &lt;weierophinney&gt; So we can do them frequently if desired. But I recall some feeling that monthly releases were "too frequent" in the past.
18:31:31 &lt;weierophinney&gt; Thoughts?
18:31:36 &lt;weierophinney&gt; (bye, Spabby1)
18:32:14 &lt; PadraicB&gt; weierophinney, not sure - but a regular schedule would probably be nice and per-month is easy to recall
18:32:32 &lt; PadraicB&gt; Why did folk think that was too regular?
18:32:33 &lt; Xerkus_needsWork&gt; with git & github i don't think month is too frequent
18:32:54 &lt; EvanDotPro&gt; i think our release process is getting streamlined enough that we can manage it.
18:33:01 &lt; PadraicB&gt; It's not like leaving it for TWO months made the bugs go away ;)
18:33:05 &lt; cgmartin&gt; what issues arose from them being too frequent? was it more difficult to do releases before? or were people upset that they couldn't "keep up"
18:33:06 &lt; spiffyjr&gt; Fast maintenance releases is the way things are moving (chrome, firefox, etc)
18:33:17 &lt; spiffyjr&gt; Hell, chrome puts out a "major" version once a month.
18:33:27 &lt; spiffyjr&gt; Once a month for maintenance is a good thing, imo.
18:33:41 &lt; cgmartin&gt; would opt for more frequent the better
18:34:03 &lt; EvanDotPro&gt; we have a strict BC policy for minor releases so it shouldn't really be an issue.
18:34:39 &lt;weierophinney&gt; Honestly, the impression I had was that in some companies, changes required a lot of bureaucracy, and thus updating was problematic.
18:34:52 &lt; dsop&gt; also I don't have anything to say, but from my experience (php.net) monthly releases makes it easier for everyone (except occasional haters that dont understnad the concept)
18:34:58 &lt;weierophinney&gt; As EvanDotPro mentions, having strict BC should make this a no-brainer.
18:35:10 &lt; Gabriel403&gt; weierophinney: wen't you having problems getting the prs into the right release branch ?
18:35:15 &lt;weierophinney&gt; So, it looks like once per month for maintenance is the vote -- sound about right?
18:35:31 &lt;weierophinney&gt; Gabriel403: I was, but we solved that with the branch rename last week.
18:35:33 &lt; Xerkus_needsWork&gt; +1 on that
18:35:34 &lt; spiffyjr&gt; weierophinney, nothing prevents companies from doing quarterly updates instead of monthly
18:35:40 &lt; spiffyjr&gt; weierophinney, i don't see how that's relevent to our release schedule
18:35:48 &lt; cgmartin&gt; +1
18:35:49 &lt;weierophinney&gt; spiffyjr: that's my feeling as well.
18:35:52 &lt; spiffyjr&gt; if it takes them 3 months to update, or 3 months for us to release, it's the same thing
18:36:09 &lt; spiffyjr&gt; so, +1
18:36:21 &lt; Gabriel403&gt; it's more helpful for those who are trying to be cutting edge to have the release more often
18:36:29 &lt; Gabriel403&gt; +1
18:36:29 &lt; PadraicB&gt; weierophinney, I think those people were expressing company reluctance poorly. It can take a while to get approval but fixing more often gets bug fixes out quicker, versus very slowly. Either way - the bugs don't mysteriously vanish.
18:36:36 &lt;weierophinney&gt; so, I'm doing a release today, and it's the third Thursday -- shall we call 3rd Thursday the monthly release date?
18:36:49 &lt;weierophinney&gt; PadraicB: agreed.
18:36:51 &lt; spiffyjr&gt; better than Friday or Monday :-D
18:36:59 &lt; spiffyjr&gt; only leaves 3 days take your pick!
18:37:15 &lt; PadraicB&gt; Roll dice? ;)
18:37:16 &lt; Gabriel403&gt; weierophinney: personal preference is earlier in the week
18:37:31 &lt; spiffyjr&gt; weierophinney, tuesday would give companies more time to test changes before the weekend
18:37:39 &lt; Gabriel403&gt; yeh
18:37:40 &lt; cgmartin&gt; aye, would prefer tuesday
18:37:41 &lt; spiffyjr&gt; i've always preferred large updates/version updates earlier in the week
18:37:52 &lt;weierophinney&gt; Gabriel403: for me, having it wednesday or thursday is easier, as it allows me to bug folks early in the week to ensure we get fixes in
18:38:01 &lt; Gabriel403&gt; weierophinney: wednesday then
18:38:11 &lt; spiffyjr&gt; wednesday sounds like good middle ground
18:38:14 &lt; spiffyjr&gt; +1 for wed!
18:38:14 &lt; cgmartin&gt; I'd settle for wednesday :)
18:38:18 &lt;weierophinney&gt; kk, third wednesday
18:38:21 &lt; ralphschindler&gt; so, monthly is for "minor" releases? and "mini" release would be weekly?
18:38:22 &lt; Xerkus_needsWork&gt; i'm for wednesday
18:38:25 &lt;weierophinney&gt; and this month we're a day late. ;-)
18:38:34 &lt;weierophinney&gt; ralphschindler: no, monthly is for maintenance releases
18:38:35 &lt; Gabriel403&gt; slacker
18:38:43 &lt;weierophinney&gt; ralphschindler: and 8-12 weeks between minor releases
18:38:50 &lt; Xerkus_needsWork&gt; as thursday is freeday here :)
18:38:55 &lt; PadraicB&gt; weierophinney, you need a blue police box ;)
18:38:57 &lt;weierophinney&gt; which means we'll typically only get to a .2 or .3 maintenance release.
18:39:09 &lt;weierophinney&gt; Is Akrabat here?
18:39:23 &lt;weierophinney&gt; because the next question I have is how frequently we shoudl do ZF1 maintenance releases.
18:39:27 &lt; PadraicB&gt; weierophinney, I think Akrabat is away - see dev channel
18:39:42 &lt; Gabriel403&gt; so 2._.* monthly 2.*.0 2-3 months?
18:39:51 &lt;weierophinney&gt; Gabriel403: yes.
18:39:56 &lt;weierophinney&gt; PadraicB: ah, right
18:39:57 &lt; Gabriel403&gt; Right
18:40:03 &lt;weierophinney&gt; so, we'll talk 1.12.X another time.
18:40:37 &lt;weierophinney&gt; oh, 3rd wednesday is lovely -- right before ZendCon, not during!
18:40:39 &lt;weierophinney&gt; :)
18:40:44 &lt; Gabriel403&gt; heh
18:40:46 &lt;weierophinney&gt; Speaking of, who will I see there?
18:41:05 &lt; Gabriel403&gt; it's just you DASPRiD an EvanDotPro
18:41:11 &lt; cgmartin&gt; I'll be there with some others from our company
18:41:44 &lt; spiffyjr&gt; EvanDotPro has to buy me a ticket and I'll be there
18:41:46 &lt; spiffyjr&gt; EvanDotPro, thanks, in advance!
18:42:41 &lt;weierophinney&gt; Gabriel403: I think there's more than that going -- heck, I'm not even speaking on ZF or ZF2 at all, and we have a full ZF2 track!
18:42:58 &lt; Gabriel403&gt; hehe
18:43:16 &lt;weierophinney&gt; So, any other business folks want to bring up? Those were the topics I needed to put forward.
18:43:17 &lt; cgmartin&gt; looking forward to the zf2 talks :)
18:43:30 &lt; Xerkus_needsWork&gt; matthew is not too god to get speak on zf2? :D
18:43:33 &lt;weierophinney&gt; spiffyjr: did you have something? you've been bugging me to get an IRC meeting. Something about RBAC, maybe? ;-)
18:43:41 &lt; spiffyjr&gt; RBAC RFC
18:43:49 &lt; spiffyjr&gt; 17 minutes till my work meeting, let's do it!
18:43:54 &lt; spiffyjr&gt; One second while I grab link.
18:43:56 &lt; Gabriel403&gt; I'd like a minute or 2 to bring up something about the skeleton, if I can
18:43:58 &lt;weierophinney&gt; Xerkus_needsWork: I actually didn't submit, on the assumption I'd fill in gaps in the schedule. And there were no gaps. :)
18:44:04 &lt; spiffyjr&gt; http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Zend_Permission_Rbac
18:44:12 &lt; spiffyjr&gt; I'd like a vote on whether or not to include that as a ZF2 component
18:44:18 &lt; spiffyjr&gt; So I can refactor the namespace of my current work
18:44:24 &lt; spiffyjr&gt; And add unit tests/docs.
18:44:48 &lt; spiffyjr&gt; The code is done already and at https://github.com/SpiffyJr/SpiffySecurity/tree/master/src/SpiffySecurity/Rbac
18:44:59 &lt;weierophinney&gt; spiffyjr: After seeing the updated examples I asked for, I'm all over that.
18:45:23 &lt;weierophinney&gt; spiffyjr: my only question at this point: will there be a way to configure the roles and permissions en masse? That's one thing missing from Acl that we need to add.
18:45:43 &lt; spiffyjr&gt; Well, I assumed that would be userland (module) code.
18:45:54 &lt; spiffyjr&gt; The security module there has several adapters you can use to load permissions
18:46:05 &lt; spiffyjr&gt; NestedSet, AdjancencyList, Memory, etc
18:46:06 &lt;weierophinney&gt; kk, that's fine with me.
18:46:12 &lt; spiffyjr&gt; And LazyLoading as well
18:46:14 &lt; PadraicB&gt; spiffyjr, I have no objections. +1
18:46:26 &lt; EvanDotPro&gt; i'm +1 on this, it looks like a solid RBAC implementation
18:46:35 &lt; spiffyjr&gt; My goal is to turn SpiffySecurity into ZfcRbac after the component is (hopefully) voted in
18:47:02 &lt; cgmartin&gt; I'll be using it for my projects, regardless. seemed easier to manage than acl. would be nice to see it included
18:47:07 &lt; Spabby1&gt; I am back
18:47:09 &lt; Spabby1&gt; she is sleeping
18:47:28 &lt;weierophinney&gt; +1 from me.
18:47:38 &lt;weierophinney&gt; Spabby1: discussing spiffyjr's RBAC RFC.
18:47:40 &lt; spiffyjr&gt; Any questions/comments/votes from others?
18:48:27 &lt; ralphschindler&gt; +1
18:49:05 &lt; spiffyjr&gt; Well, that was easier than I thought.
18:49:08 &lt; spiffyjr&gt; weierophinney, good nuff?
18:49:35 &lt;weierophinney&gt; spiffyjr: I'll call that an "approved" vote at this point, as there are no -1's, and no concerns raised.
18:49:43 &lt;weierophinney&gt; Anything else for this meeting?
18:49:54 &lt;weierophinney&gt; Gabriel403: what did you want to discuss about ZFC?
18:50:13 &lt; Gabriel403&gt; Er it was about the skeleton actually, not zfc
18:51:16 &lt; Gabriel403&gt; I was wondering if we could move the present code in a source directory and add a tests directory so we can start piling tests against what we've got in the skeleton, to show how we think tests should be done as a guide to people comgin to zf2 and unit testing
18:52:26 &lt;weierophinney&gt; Gabriel403: well, we'd likely simply add a "test" directory to the Application module, right?
18:52:52 &lt;weierophinney&gt; Gabriel403: also, IIRC, I think the skeleton module has a test infrastructure in place -- ralphschindler and/or EvanDotPro -- didn't you merge something for that?
18:53:17 &lt; ralphschindler&gt; EvanDotPro: what is the status of the module skeleton?
18:53:26 &lt; ralphschindler&gt; is it completely up to date with the application skeleton?
18:54:29 &lt; EvanDotPro&gt; weierophinney: there's one in the SkeletonModule
18:55:09 &lt;weierophinney&gt; Gabriel403: yeah, just looked through it -- looks like SocalNick gave us a patch that provides tests. We could pull that into the Application module.
18:55:19 &lt; Gabriel403&gt; Fair enough
18:55:20 &lt;weierophinney&gt; Gabriel403: does that mean you're volunteering, by chance? :)
18:55:51 &lt; EvanDotPro&gt; but there's a better one i created to be a nice, general purpose, drop-in zf2 module phpunit bootstrapper.. it's in ZfcBase
18:56:17 &lt; EvanDotPro&gt; SocalNick said he'd like to replace his with what i did in ZfcBase, too.
18:56:22 &lt; EvanDotPro&gt; just haven't gotten there.
18:56:32 &lt;weierophinney&gt; ah, okay.
18:56:37 &lt; EvanDotPro&gt; https://github.com/ZF-Commons/ZfcBase/blob/master/test/Bootstrap.php
18:56:54 &lt;weierophinney&gt; let's put that on the schedule for 2.1; if it gets done earlier, great, but otherwise, we know we have a deadline.
18:56:56 &lt; cgmartin&gt; i was using zfcbase's example yesterday actually, was nice
18:57:01 &lt; EvanDotPro&gt; though, ocramius had one additional suggestion that we reset the service manager each time it's fetched, which makes a lot of sense.
18:57:10 &lt; Gabriel403&gt; I was hoping to learn by others examples, but I'd be willing to have a bash at the tests. the phpunit in zsm seems to assume zend installed via git thought?
18:57:52 &lt;weierophinney&gt; Gabriel403: take a look at the example in ZfcBase instead, and maybe ask in #zftalk.dev if you have further questions.
18:58:05 &lt; EvanDotPro&gt; Gabriel403: the one in ZfcBase should work if it's installed via git, tar.gz/zip/etc, composer/packagist, or even if the module is standalone and you have an env variable poining to a zf2 installation path.
18:58:24 &lt; EvanDotPro&gt; Gabriel403: it kinda does various checks to figure out what's going on and how it should bootstrap itself.
18:58:26 &lt; Xerkus_needsWork&gt; can we possible add selenium tests for skeleton? i haven't looked into it and don't know if they fit it
18:58:36 &lt; Gabriel403&gt; ok, so if a pr in a basic setup and then work ont he actual tests later is that ok?
18:59:26 &lt;weierophinney&gt; Xerkus_needsWork: work something up, and do a PR. :)
18:59:33 &lt;weierophinney&gt; Gabriel403: yes, perfect.
18:59:34 &lt; Gabriel403&gt; That way if we get the basic setup in any bugger can chuck the tests in
18:59:46 &lt;weierophinney&gt; cool
18:59:51 &lt; Gabriel403&gt; pro
18:59:54 &lt;weierophinney&gt; okay, we're coming up at the top of the hour.
19:00:05 &lt;weierophinney&gt; Spabby1: you said you had something to raise -- do it quickly!
19:00:31 &lt; Spabby1&gt; I only want volunteers to help with oauth2 server, I need it for a project so willing to do most of donkey work, but no idea how to start
19:00:55 &lt; Spabby1&gt; I really need someone to bounce gists etc off to check I'm doing it vaguely right
19:01:24 &lt; Spabby1&gt; please, don't all volunteer at once I can't write the names down quickly enough :D
19:01:47 &lt;weierophinney&gt; Spabby1: maybe ask on the ML as well.
19:02:02 &lt; mwillbanks&gt; i would love to but right now i just wont have time at least for a month :(
19:02:07 &lt; Spabby1&gt; no problem, I'll make a start on my own module and pester people in dev
19:02:18 &lt; Spabby1&gt; mwillbanks: I'll just annoy you on twitter to review what I do
19:02:25 &lt; mwillbanks&gt; ok ok
19:02:34 &lt;weierophinney&gt; cool
19:02:34 &lt; Spabby1&gt; done
19:02:37 &lt; Spabby1&gt; thanks
19:02:38 &lt;weierophinney&gt; Let's call it a week, then!
19:02:38 &lt; PadraicB&gt; Spabby1, check on ML and maybe pester me...a little. ;)
19:02:44 &lt; spiffyjr&gt; ty everyone
19:03:10 &lt;weierophinney&gt; I'll drop an email on the ML when I have the transcript, and also ask folks what time of day and week works best for meetings in the future -- I'd forgotten we'd moved to 20:00 UTC during the summer.
19:03:47 &lt;weierophinney&gt; Laters, all!
</pre>
]]></ac:plain-text-body></ac:macro>