[dojo-contributors] Dojo Utilities?

Dustin Machi dmachi at dojotoolkit.org
Sat Mar 12 11:59:41 EST 2011


I generally agree, a few comments inline.

> I see the following as what has been discussed so far:
> 
> * Simplicity and cohesion, filtering, marketing
> * Flexibility/modularity
> * Ownership/official versions
> * Ease of contributing and growing community, while under CLA and IP safe
> * Version compatibility (don't turn into jar hell or linux dependency
> management hell)

Much, but not all of this, reflects the external view of these pieces, which is why I suggested that for any projects we decide to officially take one we can either officially add them as a sub project or fork/clone their project to avoid related issues.

> * Testing releases

We have to test of course, and I would expect that 'officially' accepted projects will have to adhere to some standard for testability.  When these projects are pulled in as a submodule (or forked), they can be tested uniformly and as a whole.

> * Documentation (accuracy, completeness, aggregation by release)

The new wiki can actually help with this as well because of its ability to, under the hood, aggregate multiple repositories.

> * Risk management (relying on a single commercial service)

I think there is very little risk on this one, it is mainly convenient.  It is trivial to have a cloned  repo for backup/safety purposes.  

> * Module owner gets bored/abandons, what becomes official next

If it is an important module, we can use our own fork (or create one).  If there is little active community around it, it can be deprecated and dropped at the next opportunity for backwards compat breakage.  

> * Structure of projects (foundation, within dtk)

The choices are to have all projects within one organizational account (currently we have one called 'dojo' whose name is Dojo Foundation) and grant privileges per project as needed.  It is non-trivial to change that 'dojo' name (without screwing up others), though the other is easy to change.  However, there isn't really the ability to have a tree of projects within github, it is more or less a flat list of projects per organization.  In this respect, it seems to me that it would be better to have a dojotoolkit organizational account, and similar for each of the foundation projects.  If we do that, then i'm not sure the foundation as a whole needs something up there at all (what code would be in it), instead it may be better for the foundation to create an organizational github account for each foundation project.

> * Management of the official Dojo Foundation github projects, managing
> patches, etc.

Not sure what you mean on this one aside from account management.  I don't see this as being a different process from what we do now.  When you are a committer you get granted privs to commit on your project.  Of course someone has to do the actual addition.  Im not sure what you mean by managing patches in this case.

> 
> on 3/12/11 8:55 AM (GMT-07:00) Tom Trenka said the following:
>> Not sure who can do it, but would it be possible to talk about changes
>> to that account (like the overall name) so that it is the actual Dojo
>> Foundation, along with gravatar?  Or is the something that should be
>> discussed by the foundation officers first?

The overall name is "Dojo Foundation" currently, though I assume you are referring to the 'dojo'  portion of that.  It is not easy to change the 'dojo' portion of that.  Would be easier to just create a new account.  Gravatar and all that is trivial to change of course too. 

Dustin





More information about the dojo-contributors mailing list