Version 3 by Evan Coury
on Jan 11, 2012 17:34.

compared with
Current by Evan Coury
on Jan 11, 2012 17:34.

(show comment)
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (33)

View Page History
h3. NOTE: <h3>NOTE: The meeting has been moved from 17:00 UTC to 18:00 UTC due to community demand (DST).</h3>

<p>This IRC Meeting is planned for 18:00 UTC on Wednesday, 11 January 2012.</p>

{html}<iframe src="http://free.timeanddate.com/countdown/i2vpvyb9/cf12/cm0/cu4/ct0/cs0/ca0/cr0/ss0/cac000/cpc000/pcfff/tcfff/fs100/szw320/szh135/tatTime%20left%20to%20Event%20in/tac000/tptTime%20since%20Event%20started%20in/tpc000/mac000/mpc000/iso2012-01-11T18:00:00" frameborder="0" width="149" height="64"></iframe>{html}
<ac:macro ac:name="html"><ac:plain-text-body><![CDATA[<iframe src="http://free.timeanddate.com/countdown/i2vpvyb9/cf12/cm0/cu4/ct0/cs0/ca0/cr0/ss0/cac000/cpc000/pcfff/tcfff/fs100/szw320/szh135/tatTime%20left%20to%20Event%20in/tac000/tptTime%20since%20Event%20started%20in/tpc000/mac000/mpc000/iso2012-01-11T18:00:00" frameborder="0" width="149" height="64"></iframe>]]></ac:plain-text-body></ac:macro>

h2. Finalize Beta3 Components
<h2>Finalize Beta3 Components</h2>

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

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


<p>High priority items include Views, Forms, and DB; lower priority items include Log, Config, Console, and a few others (see the post for more details). We need to decide exactly what we will accomplish for ZF2beta3 and agree on a schedule.</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Finalize Beta3 Components - Should we discuss and vote on this?
|visibleVoters=true}
Yes
No
{vote}
{vote}]]></ac:plain-text-body></ac:macro>


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

<p>We're seeing a lot of questions from folks asking how long we'll be supporting ZF 1.X. At this point, Matthew and his team feel that once 1.12 drops, we should only work on critical bugfixes and security fixes. The open questions, however, are:</p>

<ul>
* How <li>How long should the ZF community provide such fixes? Matthew has discussed this with Zend as well as with several community members, and the sweet spot seems to be 18 months, but we should discuss and come to consensus.</li>
* Who <li>Who will be responsible for coordinating fixes and releases? While this could potentially fall on Matthew and team, it could also be the CR Team, or a nominated Release Manager from the community. These latter two options would free the Zend team up to work primarily on 2.X.</li>
</ul>


<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Discuss ZF 1.X EOL?
|visibleVoters=true}
Yes
No
{vote}
{vote}]]></ac:plain-text-body></ac:macro>

h2. Brainstorm ZF2 Module Options
<h2>Brainstorm ZF2 Module Options</h2>

<p>One common pattern we're going to see with modules is a set of simple, scalar options to be set for a given module. One example is [ZfcUser|https://github.com/ZF-Commons/ZfcUser] <a href="https://github.com/ZF-Commons/ZfcUser">ZfcUser</a> (formerly EdpUser), where we have [options|https://github.com/ZF-Commons/ZfcUser/blob/master/config/module.zfcuser.config.php.dist] <a href="https://github.com/ZF-Commons/ZfcUser/blob/master/config/module.zfcuser.config.php.dist">options</a> such as 'login_after_registration', 'password_hash_algorithm', and more. Currently, a place-holder has been implemented in the absence of a better solution: Module::getOption('login_after_registration');. This makes use of a static property and method, which does not cater to multiple instances, and is generally not a good practice for something like this. The idea is that access to these scalar options will likely need to be available all over the place (in controllers, forms, views, services, adapters, etc), so trying to come up with a way to pass/inject the options all over the place will quickly become messy and unmanageable. At this point, what we need are suggestions for cleaner solutions to this problem.</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Discuss ZF2 Module Options
|visibleVoters=true}
Yes
No
{vote}
{vote}]]></ac:plain-text-body></ac:macro>