[Dextrose] Scaling Dextrose.

[David Farning]

Over the past couple of weeks we have been bringing together some new
groups who are interested in developing and deploying dextrose.  As
such, we need to modify work flows and Project Management to support
this growth and encourage additional growth.  The key point will be
determining methods for having several organizations work effectively
together.

Currently we there are at least seven different organizations that are
participating, either activily or passively, in the Dextrose code
base.  Each of these organizations has their own culture, goal, and
decision making process.

Upstreams
1. Fedora - Upstream operating system.
2. OLPC - Upsream for XO specif packages.
3. Sugar Labs -- Upstream Sugar user interface

Deployments/Developers
4. ParaguayEduca
5. Plan Ceibal

Service and Support providers
6. Seeta
7. Activity Central

This creates an interesting working environment.  All of the initial
Dextrose developers are employed by someone to work on Dextrose.  But
no one is directly employed by the Dextrose project.  The participants
are not bound together by legal obligation, instead we are bound
together because Dextrose represents the most efficient way for us as
individual organizations to meet our individual needs.  As developers,
distributed version control systems, such as git make this possible.
We could all maintain our own forks, but unifying our forks _can_
bring economies of scale to the development process.  The key metric
that each participant must assess is, "Is the cost of working with
Dextrose worth the benefit?"

The initial change that we made was to create a patch review process.
Patch review brings two benefits: 1) Peer code review improves the
quality of code and 2) a central place for code reviews help
participants easily stay up to date with changes in the code.  But as
we have seen code review comes at a cost.  It is quicker and easier to
git push then create a correct patch.

The second change is to make a central git repository of patches at
http://git.sugarlabs.org/projects/dextrose/repos/mainline/trees/master/rpms
. From there, it is trivial for a deployment to create a custom
release of dextrose based on which patches they chose to include or
remove.  If we do our jobs right as a project, the individual
deployment releases should be slight variations on the common Dextrose
release.

The third change is hiring a patch manager to push patches from
dextrose into Fedora, OLPC, Sugar Labs, and other upstream projects.
We do this for two reasons: 1) Every local dextrose patch represents a
future maintainer burden. and 2) As good community citizens we want to
share our local improvements as widely as possible.  Over time, I hope
that we can reduce impedance mismatches between Dextrose and upstream
projects thereby eliminating the need for a patch manager.

My biggest concern going forward is how do I, as the persons setting
the tasks for Activity Central, ensure that Activity Central is
working on what is important.  While living in Paraguay it is pretty
easy, I just look at the issues which cause people frustration and
figure out how to reduce those frustrations.  While Bernie was in PY,
we counted on him to set priorities.  But, in a couple of weeks we
will need to come up with a different/better process for setting AC's
priorities.

david