Skip to end of metadata
Go to start of metadata

<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, 07 November 2011.</p>

<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/iso2011-12-07T18:00:00" frameborder="0" width="149" height="64"></iframe>]]></ac:plain-text-body></ac:macro>

<p>Please read the <ac:link><ri:page ri:content-title="IRC Meetings" /></ac:link> page for details on adding items to the agenda.</p>

<h2>Discuss usage of application environment variable in config files merged by glob()</h2>

<p>See <a href="http://zend-framework-community.634137.n4.nabble.com/Glob-path-config-merging-td4116586.html">this thread</a> on the ML. The tl;dr is that right now, any config file loaded in ./config/autoload/* must have a top level array key matching the specified application environment, otherwise an exception is thrown. Most people agree this is not a great behavior, and statically putting the environment names as keys isn't the best practice, however a consensus has not been reached on what the best solution is moving forward. A decision should be made and implemented prior to beta2 being tagged.</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Application Environment in Configs - Should we discuss and vote on this? (Log In to vote.)
Choices Your Vote

Yes

No

]]></ac:plain-text-body></ac:macro>

<h2>Discuss deprecation of mandatory/recommended <code>PHP_CONSTANTS</code> in config files and documentation</h2>
<p>Related to previous one. </p>
<ul>
<li><code>APPLICATION_PATH</code> is not needed nor used any more in <a href="https://github.com/zendframework/ZendSkeletonApplication">ZF2 skeleton app</a> (there is no application/ dir and there is new <code>Zend\MVC</code>)</li>
<li><code>APPLICATION_ENV</code> should not be a requirement and must not be used in any ZF2 component or class</li>
<li><a href="https://github.com/zendframework/ZendSkeletonApplication">Skeleton app </a> does not support application environments out of the box</li>
<li>Application environments can be easily enabled by the user, by checking $_ENV (or otherwise) and loading a separate config file (that is merged later)</li>
<li>hence: <code>APPLICATION_ENV</code> is not useful any more and should not be endorsed</li>
<li><code>DATA_DIR</code>, <code>DATA_PATH</code>, <code>LIBRARY_DIR</code> and other constants were always proprietary, not used consistently in ZF1 docs and should not be endorsed.</li>
<li>Above constants must not exist and be a dependency in any ZF2 component or class.</li>
<li>Token parsing (including CONSTANT parsing) inside config files should be optional.</li>
</ul>

<p>See <a href="http://zend-framework-community.634137.n4.nabble.com/ZF2-usage-of-constants-in-configs-tp4127848p4127848.html">this thread</a> for thorough explanation. </p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Discuss deprecation of CONSTANTS in config files? (Log In to vote.)
Choices Your Vote

Yes

No

]]></ac:plain-text-body></ac:macro>

<h2>Discuss endorsement of root (main) application path</h2>
<p>Related to previous one. </p>
<ul>
<li>assuming <code>APPLICATION_PATH</code> and <code>APPLICATION_ENV</code> are deprecated.</li>
<li><strong>root application path</strong> is the upmost dir holding all other files related to that application (including dirs like <code>public/</code> <code>config/</code> <code>vendor/</code> etc.)</li>
<li>each entry point for zf2 application (i.e. <code>public/index.php</code> <code>console.php</code> etc.) does a chdir(<em>DIR</em><em>) or chdir(</em><em>DIR</em>.'/../) into the root application path</li>
<li>all config files that have path-related entries can use one of these two types of path
<ol>
<li>relative path (to the root app path) i.e.: <span style="color: gray;">module.config.data_file = "data/module/something.dat"</span></li>
<li>absolute path (on filesystem) i.e.: <span style="color: gray;">module.config.data_file = "/var/usr/webapp/data/module/something.dat"</span></li>
</ol>
</li>
<li>because there is only a single (main) path, there is no need for constants or path sniffing/walking (i.e. with <em>DIR</em>."/../../../")</li>
<li>paths in config file are explicitly defined, which means changes in folder structures need to be manually updated</li>
<li>the above is actually not bad. It's transparent and obvious.</li>
<li>special cases are handled by components in PHP calls, not config files (i.e. scanning paths and looking for view scripts)</li>
<li>users are educated accordingly</li>
</ul>

<p>See <a href="http://zend-framework-community.634137.n4.nabble.com/ZF2-usage-of-constants-in-configs-tp4127848p4127848.html">this thread</a> for thorough explanation. </p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Discuss usage of root (main) application path? (Log In to vote.)
Choices Your Vote

Yes

No

]]></ac:plain-text-body></ac:macro>

<h2>Schedule Beta 2 Release</h2>

<p>We are (past) due for our beta2 release. We should discuss setting a firm date for tagging beta2.</p>

<ul>
<li>Is Zend\Mail ready?</li>
<li>Is Zend\Cache ready?</li>
<li>Is Zend\Log ready?</li>
</ul>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Schedule Beta 2 Release - Should we discuss and vote on this? (Log In to vote.)
Choices Your Vote

Yes

No

]]></ac:plain-text-body></ac:macro>

<h2>Pull Request Queue Management</h2>

<p>What process should we use to manage our pull request queue? Dolf suggested this workflow:</p>

<blockquote><p>Our workflow is simple; whenever someone who's allowed to push the pull request reviews it, he either merges it, or comments & closes it. If the contributor then updates his pull request the pull requester can just reopen it. That way the queue of open pull requests always resembles the list of pull requests that can potentially be merged.</p></blockquote>

<p>This seems sane to me (Rob Allen) as it's easy to understand and remember.</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Pull Request Queue Management - Should we discuss and vote on this? (Log In to vote.)
Choices Your Vote

Yes

No

]]></ac:plain-text-body></ac:macro>

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