Morning all--

At last night's Dojo meeting, the topic of "what should included within a
distribution/distributions of the Dojo Toolkit" 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 "dojo-release-2.0.tar.gz" et al actually contains.

A summary of ideas:

1) Distribution(s) of 2.0+ are essentially marketing tools for the Dojo
Toolkit, in that what they contain should tell a clear "story" of what the
Dojo Toolkit is and why someone would want to choose it over other options.

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
https://github.com/cjolif/dojo-treemap/wiki ) 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).

3) Since everything in 2.0+ will be package-based, the following ideas were
floated as "releases":

3a) Several distributions containing different packages that are
"pluggable", based on the separations/features at
http://dojotoolkit.org/features . This would mean that there is one main
distribution (the Dojo Core essentially), and then several "add-on"
distributions such as (names are arbitrary):

- desktop (aka Dijit + some version of a Grid)
- mobile
- visualization (charting, gauges, geo)
- mvc/app
- tools (essentially our current /util but probably just DOH and the
build system, maybe doc assembly tools)

...the general idea being that a developer would grab the core distribution
and then whatever add-ons they were looking to develop with.

3b) In addition to the above, an "assemble your own distribution" tool
would be a very nice-to-have feature; this would probably do something
similar to http://packages.dojofoundation.org where one can find a list of
packages available, and have the server assemble a tarball/gzip on the fly.

3c) ...and/or there could be our typical kitchen sink release.

NEXT STEPS
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)
2) Decide on what exactly will be in said distributions
3) Begin developing the methods/tools needed

If we have a very good idea of how we'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 "add-on" 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).

Also, we'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:
1) collect all packages
2) unit-test all packages
3) assemble documentation from packages into one
4) create release notes (one would hope this would be part of the previous
step)
5) give it a stamp of approval

...before saying "add-on X" is ready for release. As usual, there can
always be a beta/RC period during which some of these steps may happen.

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'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 https://www.chiliproject.org/ (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.

As always, thoughts...suggestions...other ideas...are more than welcome!

Cheers--
Tom

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120209/64c110df/attachment-0001.htm

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 8 | next ›
Discussion Overview
groupdojo-contributors @
categoriesdojo
postedFeb 9, '12 at 10:25a
activeFeb 9, '12 at 2:13p
posts8
users3
websitedojotoolkit.org

People

Translate

site design / logo © 2021 Grokbase