Version 4 by Matus Zeman
on Mar 07, 2012 14:54.

compared with
Current by Matus Zeman
on Mar 07, 2012 14:54.

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

Changes (52)

View Page History
<p>This IRC Meeting is planned for 18:00 UTC on Wednesday, 7 March 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-03-07T18:00:00" frameborder="0" width="350" 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-03-07T18:00:00" frameborder="0" width="350" height="64"></iframe>]]></ac:plain-text-body></ac:macro>

Please feel free to add topics, according to the template on the [parent page|IRC Meetings].
<p>Please feel free to add topics, according to the template on the <ac:link><ri:page ri:content-title="IRC Meetings" /><ac:link-body>parent page</ac:link-body></ac:link>.</p>

h2. Work in Progress (WIP) pull request system
<h2>Work in Progress (WIP) pull request system</h2>

[~ocramius] has started discussion about Work in Progress [pull requests|http://help.github.com/send-pull-requests/] (PR) [on the mailing list|http://zend-framework-community.634137.n4.nabble.com/ZF2-Pull-Request-usage-WIP-Pull-Requests-td4405109.html]. Currently, PRs are used only to merge changes that have already been reworked on foreign repositories and discussed on the mailing list or IRC, while changes not ready for merge end up with a PR being closed. That is not using the full potential of the Github website. He suggested that PR could be kept open even on earlier stages of development to allow longer discussion threads also on Github.
<p><ac:link><ri:user ri:username="ocramius" /></ac:link> has started discussion about Work in Progress <a href="http://help.github.com/send-pull-requests/">pull requests</a> (PR) <a href="http://zend-framework-community.634137.n4.nabble.com/ZF2-Pull-Request-usage-WIP-Pull-Requests-td4405109.html">on the mailing list</a>. Currently, PRs are used only to merge changes that have already been reworked on foreign repositories and discussed on the mailing list or IRC, while changes not ready for merge end up with a PR being closed. That is not using the full potential of the Github website. He suggested that PR could be kept open even on earlier stages of development to allow longer discussion threads also on Github.</p>

h5. Pros:
* Increased visibility of WIP on ZF2
* More contributions by occasional visitors
<h5>Pros:</h5>
<ul>
<li>Increased visibility of WIP on ZF2</li>
<li>More contributions by occasional visitors</li>
* More <li>More discussion and code review through Github (notifications/comments on diffs)</li>
</ul>

h5. Cons:
* Increased number of open PRs
* Possible "hanging" of PRs for longer periods of time

Some other very different suggestions popped up, but probably a vote during a meeting will be needed for just this point.
<h5>Cons:</h5>
<ul>
<li>Increased number of open PRs</li>
<li>Possible &quot;hanging&quot; of PRs for longer periods of time</li>
</ul>


<p>Some other very different suggestions popped up, but probably a vote during a meeting will be needed for just this point.</p>

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

h2. Escaper Class RFC
<h2>Escaper Class RFC</h2>

[~padraic] <p><ac:link><ri:user ri:username="padraic" /></ac:link> has proposed a new Escaper class to add contextual escaping support to decrease the variability (or complete lack as is more likely) of [truly <a href="http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Escaper+Class">truly secure anti-XSS escaping methods|http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Escaper+Class]. methods</a>. The RFC does not go into specific design or implementation issues so the discussion is focused on whether such a class is to be developed and what API it should expose. This discussion will focus primarily on sorting out what changes the API might need, what dependencies should be allowed for it's default modes of operation, and whether there are any additional features, escapers, or other functionality to be added.</p>

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

h2. Service classes
<h2>Service classes</h2>

<p>Recent (and ongoing) discussions on the mailing list suggest we may want to move the various Zend\Service components into modules, instead of having them as part of the main project.</p>

<p>Pros:</p>
* Less maintenance required from ZF contributors
<ul>
<li>Less maintenance required from ZF contributors</li>
* Can <li>Can version separately from the main library, allowing updates when APIs are updated vs when the next ZF release happens</li>
* Easier <li>Easier for developers to install separately from the framework (though many depend on Zend\Http, Zend\Rest, and/or Zend\Uri)</li>
</ul>

Cons:
* Potentially less visibility
* Potential for individual APIs to go unmaintained

Matthew notes that a move in this direction would require keeping select service APIs present in the framework, particularly those that are utilized elsewhere in the framework (e.g., the various cloud provider APIs).
<p>Cons:</p>
<ul>
<li>Potentially less visibility</li>
<li>Potential for individual APIs to go unmaintained</li>
</ul>


<p>Matthew notes that a move in this direction would require keeping select service APIs present in the framework, particularly those that are utilized elsewhere in the framework (e.g., the various cloud provider APIs).</p>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[{vote:Service APIs as modules - Should we discuss this?
|visibleVoters=true}
Yes
No
{vote}
{vote}]]></ac:plain-text-body></ac:macro>

h2. RFC - Forms
<h2>RFC - Forms</h2>

Short discussion about [RFC - Forms|http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms].
<p>Short discussion about <a href="http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+Forms">RFC - Forms</a>.<br />
Where are we at, where are we heading, who is behind it?</p>

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