Version 1 by Matthew Weier O'Phinney
on Sep 24, 2012 19:34.

compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (80)

View Page History
{toc}
<ac:macro ac:name="toc" />

h2. Information
<h2>Information</h2>

* Date: 20 September 2012, 18:00-19:00 UTC
* Moderator: Matthew Weier O'Phinney (nickname weierophinney)
* Next meeting: 26 September 2012
<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

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

(Search for 18:03:33 in the log.)
<h3>RFC: Move to GitHub Issues (and possibly Wiki)</h3>

Ralph Schindler (nick: ralphschindler) created an RFC for moving to GitHub issues and potentially wiki:
<p>(Search for 18:03:33 in the log.)</p>

* https://github.com/zendframework/zf2/wiki/RFC-Move-To-Github-Issues-And-Wiki
<p>Ralph Schindler (nick: ralphschindler) created an RFC for moving to GitHub issues and potentially wiki:</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.
<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>

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 -- and much automation could be accomplished that way as well.

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>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>

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>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>

* lack of namespaces (but at this time, we're not really using them anyways)
* voting (this could and likely should be accomplished via another service/app anyways).
* comments
<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>

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>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>

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.
<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>

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.

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>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>

*tl;dr*: The ZF2 issues will move to GitHub issues soon; expect a different solution for the wiki not long after.
<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>

h3. Frequency of maintenance releases
<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>

(Search for 18:30:20 in the log.)
<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>

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

* Every two weeks
* Every month
<h3>Frequency of maintenance releases</h3>

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>(Search for 18:30:20 in the log.)</p>

*tl;dr*: Maintenance releases will be done on the third Wednesday of each month, with minor releases every 8-12 weeks (2-3 months).
<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>

h3. RBAC RFC
<ul>
<li>Every two weeks</li>
<li>Every month</li>
</ul>

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

http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Zend_Permission_Rbac
<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>

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><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>

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

*tl;dr*: We'll have an RBAC solution in ZF 2.1.
<p>Kyle Spraggs (nick: spiffyjr) created a proposal for a new Role Based Access Control (RBAC) component for the Zend\Permissions component:</p>

h3. ZendSkeletonApplication tests
<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>

(Search for 18:51:16 in the log.)
<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>

Gabriel Baker (nick: Gabriel403) proposed adding tests to the ZendSkeletonApplication for two reasons:
<p>There was no disagreement with the approach, and everybody gave it a thumbs up.</p>

* To ensure that the functionality it provides stays stable
* To provide an example of how to test a ZF2 application and/or module
<p><strong>tl;dr</strong>: We'll have an RBAC solution in ZF 2.1.</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.
<h3>ZendSkeletonApplication tests</h3>

*tl;dr*: look for tests in an upcoming release of the ZendSkeletonApplication!
<p>(Search for 18:51:16 in the log.)</p>

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

(Search for 19:00:31 in the log.)
<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>

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.

h2. Log
<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>
{html:output=html}
<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 {
19:03:47 &lt;weierophinney&gt; Laters, all!
</pre>
{html}
]]></ac:plain-text-body></ac:macro>