[dojo-contributors] Dojo Utilities?
kzyp at dojotoolkit.org
Thu Mar 10 11:30:26 EST 2011
On 3/10/2011 8:29 AM, Chris Mitchell wrote:
> ok with goal of "breaking out pieces of our repository", but there are
> some things that need to be ironed out ahead of time...
> 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).
Then other forks of the project would just continue to thrive. Welcome
to the world of distributed version control ;) One person can't kill a
distributed project in this world.
Joking aside, it certainly can be better organized and more robust to
actually use an organization account in git. Maybe you could setup an
ibm-dojo account for the group of devs over there?
> 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.
This is possible to, but this seems counterproductive in terms of
granularity of control and ownership which is part of the reason for
breaking DojoX up. I think it would be better to have smaller units of
organization that can be more specifically controlled.
> 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.
I think it beyond the scope of our package structure to dictate server
structure (and there are plethora of languages that would have to be
defined), and I think there are already best practices for organizing
> 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.
Here is a template I put together. I am sure it will continue to evolve
as we work through issues and clarify things:
> 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.
I agree, it is important to keep the necessary consistency in projects
to make this continue to be achievable.
More information about the dojo-contributors