Morning all--<div><br></div><div>At last night&#39;s Dojo meeting, the topic of &quot;what should included within a distribution/distributions of the Dojo Toolkit&quot; was discussed.  Unlike previous discussions (which focused primarily on what tools are needed/what absolutely is required within a distribution), this discussion was intended to begin deciding what &quot;dojo-release-2.0.tar.gz&quot; et al actually contains.</div>
<div><br></div><div>A summary of ideas:</div><div><br></div><div>1) Distribution(s) of 2.0+ are essentially marketing tools for the Dojo Toolkit, in that what they contain should tell a clear &quot;story&quot; of what the Dojo Toolkit is and why someone would want to choose it over other options.</div>
<div><br></div><div>2) Unit testing and documentation is a MUST; this means that before we can create a 2.0 distribution,we MUST have ways of aggregating documentation out of individual packages, including assembling content for reference guides and API documentation.  Christophe Jolif has begun experimenting with ways of accomplishing this using his treemap package (at <a href="https://github.com/cjolif/dojo-treemap/wiki">https://github.com/cjolif/dojo-treemap/wiki</a> ) as a test bed.  I am looking into the various unit testing systems that are out there before coming back to DOH and seeing how we can make that a first-class product (i.e. standalone).</div>
<div><br></div><div>3) Since everything in 2.0+ will be package-based, the following ideas were floated as &quot;releases&quot;:</div><div><br></div><div>3a) Several distributions containing different packages that are &quot;pluggable&quot;, based on the separations/features at <a href="http://dojotoolkit.org/features">http://dojotoolkit.org/features</a> . This would mean that there is one main distribution (the Dojo Core essentially), and then several &quot;add-on&quot; distributions such as (names are arbitrary):</div>
<div><ul><li>desktop (aka Dijit + some version of a Grid)</li><li>mobile</li><li>visualization (charting, gauges, geo)</li><li>mvc/app</li><li>tools (essentially our current /util but probably just DOH and the build system, maybe doc assembly tools)</li>
</ul></div><div>...the general idea being that a developer would grab the core distribution and then whatever add-ons they were looking to develop with.</div><div><br></div><div>3b) In addition to the above, an &quot;assemble your own distribution&quot; tool would be a very nice-to-have feature; this would probably do something similar to <a href="http://packages.dojofoundation.org">http://packages.dojofoundation.org</a> where one can find a list of packages available, and have the server assemble a tarball/gzip on the fly.</div>
<div><br></div><div>3c) ...and/or there could be our typical kitchen sink release.</div><div><br></div><div>NEXT STEPS</div><div>1) Decide on what kind of distribution(s) should be taking place (i.e. take the add-on approach or continue with kitchen-sink approach)</div>
<div>2) Decide on what exactly will be in said distributions</div><div>3) Begin developing the methods/tools needed</div><div><br></div><div>If we have a very good idea of how we&#39;re going to be distributing the toolkit at 2.0, we can begin to restructure ourselves so that we can better meet those goals.  For instance, if we decide on the &quot;add-on&quot; approach, we can break ourselves up into smaller teams (each with a lead of some sort) based on the particular add-on (just a thought).</div>
<div><br></div><div>Also, we&#39;re going to definitely need a release team (not just a release manager); when these distros are to be assembled, the release team will need to:</div><div>1) collect all packages</div><div>
2) unit-test all packages</div><div>3) assemble documentation from packages into one</div><div>4) create release notes (one would hope this would be part of the previous step)</div><div>5) give it a stamp of approval</div>
<div><br></div><div>...before saying &quot;add-on X&quot; is ready for release.  As usual, there can always be a beta/RC period during which some of these steps may happen.</div><div><br></div><div>Lastly, Dylan brought up once again the need for a unified bug tracking system; based on experiences so far with dgrid (another major project that is intended to be a test bed for the packages concept), the github tracker is confusing people because they don&#39;t know whether something is a dgrid bug or a DTK one.  If we are going to have a unified bug tracker, we should really take a look at systems like <a href="https://www.chiliproject.org/">https://www.chiliproject.org/</a> (the current fork of Redmine)--because it allows people to set up multiple projects within it.  Obviously other suggestions are welcome, but I think that having everything as a single project (a la Trac) is killing us.</div>
<div><br></div><div>As always, thoughts...suggestions...other ideas...are more than welcome!</div><div><br></div><div>Cheers--</div><div>Tom</div><div><br></div><div>PS As a personal opinion, one thing that I *do* thing should happen sooner than later is the promotion of dojox.gfx to the Dojo core.  Having a way of doing cross-browser graphics should really be a core feature and not something sort of hidden within DojoX...</div>