Bug #64

Source Control and Issue Tracking for Dojo 2

Added by Dylan Schiemann over 5 years ago. Updated over 5 years ago.

Status:In Progress Start date:05/01/2012
Priority:Normal Due date:05/31/2012
Assignee:Dylan Schiemann % Done:

0%

Category:-
Target version:Late May 2012

Description

Work through the logistics of transitioning to Git.

There's a nice article from Django that can inform some decisions at http://www.holovaty.com/writing/django-github/

Some things we really like today:

  • Each commit updates the related issue it is fixing (and in fact, an issue must be open)
  • Each commit runs through JSLint (we want to change this to JSHint asap)

Both of the above are challenges out of the box with a change to GitHub (in addition to many of the items in the Django article).

Some new challenges:

  • Because we are switching respositories, we will either need a new Trac instance for 2.x work, or it's a great time to switch to ChiliProject
  • Linking user ids on GitHub to Dojo Foundation user ids
  • Each new project that's not part of core will have its open repo somewhere... if we use ChiliProject, we could offer each sanctioned project that wants it an issue tracker subproject.

Please list other challenges and ideas here. For example, it's clear we'll be using GitHub, but would it make sense to use our own Git repo and sync that with GitHub, to force some of these things to happen (I don't know enough about Git/GitHub to know if this is even a validly formed question).

History

Some notes/suggestions from James Burke:

Dojo 2.0 construction ====

I have started to use github's group capability to organize a set of
modules into a larger cohesive whole, but still giving them enough
individual space to have their own identity. I am doing that with the
requirejs plugins that I used to have in the requirejs repo:

https://github.com/requirejs

A similar approach for Dojo may make sense, and for dijit (by grouping
widgets under a "dijit" group name). Have a github.com/dojo/array,
github.com/dojo/Observable, etc... This may help people consume just
parts of Dojo without needing to get the full download today, and help
with the "dojo is too big" perception. It might also help identify
areas where there is too much interdependence.

A couple folks at work are using volo1 to pull down JS
dependencies/manage internal dependencies, and I expect to have
recursive dependency fetching in the 0.2 release. But something like
that kind of tool or cpm that can read dependencies from the
package.json directly from github makes it easy to get just the code
needed for a project.

It would be interesting to just pull down Observable, the pub/sub
stuff and a dijit core to see how that would work for a light mvc
approach.

I know there are lots of forces in play for Dojo, so this may not make
sense. Just mentioning something that seems to be working for some
things.

[1] https://github.com/volojs/volo

Also available in: Atom PDF