Version 1 by Matthew Weier O'Phinney
on Jun 28, 2012 15:18.

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

Changes (57)

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

h2. Information
<h2>Information</h2>

* Date: 27 June 2012, 20:00-21:00 UTC
* [Agenda|2012-06-27 Meeting Agenda]
* Moderator: Matthew Weier O'Phinney (nickname weierophinney)
* Next meeting: 11 July 2012
<ul>
<li>Date: 27 June 2012, 20:00-21:00 UTC</li>
<li><ac:link><ri:page ri:content-title="2012-06-27 Meeting Agenda" /><ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: 11 July 2012</li>
</ul>

h2. Summary

h3. Annotations: Doctrine Common / Own Implementation
<h2>Summary</h2>

(Search for "20:04:16" in the log.)
<h3>Annotations: Doctrine Common / Own Implementation</h3>

Marco Pivetta (ocramius) asked if we should use our own annotation implementation, or use the one from Doctrine\Common instead.
<p>(Search for &quot;20:04:16&quot; in the log.)</p>

Matthew (weierophinney) indicated that he had made the following conclusions:
<p>Marco Pivetta (ocramius) asked if we should use our own annotation implementation, or use the one from Doctrine\Common instead.</p>

* It does not make sense for ZF to have its own annotation syntax, particularly since we're already inconsistent about it (some take raw strings, others JSON-encoded text). Using a standard already used in multiple projects makes sense.
* However, ZF should be flexible enough to allow annotations using alternate syntaxes. Doctrine\Common currently only allows ignoring such annotations.
<p>Matthew (weierophinney) indicated that he had made the following conclusions:</p>

His suggestion is to use the Doctrine\Common lexer/parser as a default, but allow developers to plug in to the annotation manager to handle alternate annotation styles on a per-annotation basis.
<ul>
<li>It does not make sense for ZF to have its own annotation syntax, particularly since we're already inconsistent about it (some take raw strings, others JSON-encoded text). Using a standard already used in multiple projects makes sense.</li>
<li>However, ZF should be flexible enough to allow annotations using alternate syntaxes. Doctrine\Common currently only allows ignoring such annotations.</li>
</ul>

The main questions from those present at this point was how ZF will package. Composer and Pyrus are simple, and require trivial changes to packaging. For the tarball/zipball packages, we will include Doctrine\Common in the vendor directory, and include instructions for how to configure autoloading.

*tl;dr*: ZF2's Zend\Code\Annotation component will have a dependency on Doctrine\Common for its annotation lexer/parser.
<p>His suggestion is to use the Doctrine\Common lexer/parser as a default, but allow developers to plug in to the annotation manager to handle alternate annotation styles on a per-annotation basis.</p>

h3. Documentation RFC
<p>The main questions from those present at this point was how ZF will package. Composer and Pyrus are simple, and require trivial changes to packaging. For the tarball/zipball packages, we will include Doctrine\Common in the vendor directory, and include instructions for how to configure autoloading.</p>

(Search for "20:23:31" in the log.)
<p><strong>tl;dr</strong>: ZF2's Zend\Code\Annotation component will have a dependency on Doctrine\Common for its annotation lexer/parser.</p>

During the previous IRC meeting, we decided that Gary Hockin (Spabby), Rob Allen (Akrabat), and Matthew (weierophiney) would create an RFC with specific recommendations on how to improve the documentation. Matthew posted it shortly before the meeting, and summarized the main points:
<h3>Documentation RFC</h3>

* Create a cohesive user guide/tutorial, separate from the reference documents
* Have a common structure for reference documents
* Use reST + Sphinx + readthedocs.org instead of DocBook + PhD + Lucene
<p>(Search for &quot;20:23:31&quot; in the log.)</p>

The benefits include: easier to write and translate documentation, easier to render (and automated rendering via readthedocs.org), predictable structure within individual documents, and cohesive and consistent examples (we'd use a reference project for the user guide, and by extension for all examples).
<p>During the previous IRC meeting, we decided that Gary Hockin (Spabby), Rob Allen (Akrabat), and Matthew (weierophiney) would create an RFC with specific recommendations on how to improve the documentation. Matthew posted it shortly before the meeting, and summarized the main points:</p>

Consensus was immediate and in favor of the recommendations. We will be working on a timeline for changes, but hope to have something in place for the stable release.
<ul>
<li>Create a cohesive user guide/tutorial, separate from the reference documents</li>
<li>Have a common structure for reference documents</li>
<li>Use reST + Sphinx + readthedocs.org instead of DocBook + PhD + Lucene</li>
</ul>

*tl;dr*: Documentation will get a huge overhaul, and be easier to create!

h3. OAuth
<p>The benefits include: easier to write and translate documentation, easier to render (and automated rendering via readthedocs.org), predictable structure within individual documents, and cohesive and consistent examples (we'd use a reference project for the user guide, and by extension for all examples).</p>

(Search for "20:39:24" in the log.)
<p>Consensus was immediate and in favor of the recommendations. We will be working on a timeline for changes, but hope to have something in place for the stable release.</p>

Gary Hockin (Spabby) has pointed out that OAuth is largely unmaintained, and OAuth2 development is still in progress. He wanted to discuss where these should live, and the fate of Zend\OAuth.
<p><strong>tl;dr</strong>: Documentation will get a huge overhaul, and be easier to create!</p>

As several people noted, Twitter still utilizes OAuth v1, which means we can't make it go away. Also noted was that a number of people have provided contributions to the component over the last few months, bringing it to a stable status -- Zend\Service\Twitter is working correctly with it at this time.
<h3>OAuth</h3>

After much discussion, we decided:
<p>(Search for &quot;20:39:24&quot; in the log.)</p>

* OAuth will move to a separate repository, under the name "ZendService\OAuth"
* OAuth2 will also be in a separate repository, under the name "ZendService\OAuth2"
<p>Gary Hockin (Spabby) has pointed out that OAuth is largely unmaintained, and OAuth2 development is still in progress. He wanted to discuss where these should live, and the fate of Zend\OAuth.</p>

Both will be developed as _libraries_ (not modules).
<p>As several people noted, Twitter still utilizes OAuth v1, which means we can't make it go away. Also noted was that a number of people have provided contributions to the component over the last few months, bringing it to a stable status &ndash; Zend\Service\Twitter is working correctly with it at this time.</p>

*tl;dr*: We'll continue to ship OAuth, but under a different namespace. OAuth2 support is forthcoming.
<p>After much discussion, we decided:</p>

h2. Log
<ul>
<li>OAuth will move to a separate repository, under the name &quot;ZendService\OAuth&quot;</li>
<li>OAuth2 will also be in a separate repository, under the name &quot;ZendService\OAuth2&quot;</li>
</ul>

{html:output=html}
<p>Both will be developed as <em>libraries</em> (not modules).</p>

<p><strong>tl;dr</strong>: We'll continue to ship OAuth, but under a different namespace. OAuth2 support is forthcoming.</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 {
21:00:01 &lt;weierophinney&gt; kk, I'm calling it a day -- we're right at an hour, and we got a lot discussed, voted on, and agreed upon. Much better than last week. :)
</pre>
{html}
]]></ac:plain-text-body></ac:macro>