[dojo-contributors] Dojo Utilities?

Adam L. Peller adam at peller.org
Thu Mar 10 11:36:55 EST 2011

All good questions.  ttrenka can correct me if I'm wrong, but I don't think
the package structure applies to webapps like this so much, so perhaps
James' project is an opportunity to explore the github infrastructure/access
control issues and ease our way into this, without worrying about other
issues of drag and dependencies just yet.

2011/3/10 Chris Mitchell <ccmitchellusa at gmail.com>

> ok with goal of "breaking out pieces of our repository", but there are some
> things that need to be ironed out ahead of time...
> -Chris
> 1) Is this new GitHub project going on James' personal github account?  If
> so, this will be a problem...if James were to go away for whatever reason
> (not that  that will happen any time soon).   I hear there is a Dojo
> Foundation account that can be used... Where are the details for how we can
> establish GitHub projects maintained under this account.
> 2) The Web Builder is new code that hasn't existed in dojo before, so it's
> easy  easier to break out as it's own thing now.  It has client side parts
> that can follow the package metadata spec from Ttrenka, but what are
> considerations for package structure of the server pieces (Java-based) in
> this case.
> 3) For existing project's already part of Dojo distro's, for example gfx
> that we want to split out to github, I believe we need to address (1) above,
> and mandate that the separating packages follow ttrenka's package metadata
> format.  We really need an exemplar project here, that illustrates how
> developers should structure docs, tests, licenses, etc. so that Dojo.next
> can be aggregated back together--not just from a JS module perspective.
> Until an exemplar project is put together and an example of how the
> extracted git projects can be re-aggregated to form Dojo.next, we should be
> very careful...other wise Dojo WILL fragment, losing the value it's built up
> to companies in the past.
>    a) Docs need to be structured (phiggins' work should help here, but
> guidelines still need to be written) so that they can be pulled together
> into a reference guide. I don't think James' project is the one to use for
> this because of (2)).
>    b) We need to be able to run tests across sanctioned projects as a
> whole, to ensure the separated modules continue work properly together.
> 4) If we don't have the ability to pull separated projects back together
> (3), it will be untenable for companies (like IBM) to do the legal work
> necessary to make Dojo's pedigree the quality it needs to be for enterprise
> customers.  This is not a small amount of work, but is something the OSS
> community needs to be aware of in terms of downstream consumption in large
> companies...it is important to continue to maintain our quality around
> pedigree when things split out, and doing this on an aggregate distro is the
> only feasible way right now.
> -Chris
> 2011/3/10 Adam L. Peller <adam at peller.org>
> So I've always been +1 on breaking out pieces of our repository, and utils
>> seems to be a great place to start.  Not only would it enable a separate
>> development and release cycle, but it would help bring down the size and
>> complexity of our distribution.  There are many web developers who would
>> feel overwhelmed by other languages and technologies besides html/css, and
>> this particular app can ultimately be provided "in the cloud", in which case
>> many developers would not require the source at all, so I think this is a
>> great candidate.
>> -Adam
>> On Tue, Mar 8, 2011 at 6:34 AM, James Thomas <jthomas.uk at gmail.com>wrote:
>>> I'm very close to reaching a stage where the Web Builder can be
>>> released externally, both a hosted version and the entire source code.
>>> The source code lives in a private github repository and the release
>>> plan was going to be making the repo public, rather than committing it
>>> to the actual Dojo SVN "utils" directory. Do people have any
>>> objections to this?
>>> I very much see this project as being a member of our awesome Dojo
>>> Utilities but given we want to break away DojoX from being under
>>> centralised source control in the future, I didn't think adding
>>> another large project to SVN seemed appropriate.
>>> Do we think that other tools might be broken out like this in the
>>> future, like the new doc tools?
>>> I don't have many definite answers I'm afraid but wanted to bring it
>>> up anyway.....
>>> --
>>> Regards,
>>> James Thomas
>>> _______________________________________________
>>> dojo-contributors mailing list
>>> dojo-contributors at mail.dojotoolkit.org
>>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>> _______________________________________________
>> dojo-contributors mailing list
>> dojo-contributors at mail.dojotoolkit.org
>> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110310/b7344c72/attachment.htm 

More information about the dojo-contributors mailing list