Fixing Bugs and adding features in USR.

[David Farning]

There seems to be confusion about fixing bugs and adding features in
Ubuntu Sugar Remix.  I think this is caused by a incomplete
understanding of the notion of up and down stream in open source
projects.  http://fossarchy.blogspot.com/2009/07/upstream-downstream.html

In general Ubuntu Sugar Remix has the following upsteams -> downstream
relationships.

{Sugar Labs | OLPC} -> Debian -> Ubuntu

We have seen this is package flow as tarballs and git repos from Sugar
Labs are turned into debian packages which are then synced into
Ubuntu.  Even though we are primarily interested in Sugar on Ubuntu,
we build, and depend, on the work of upstream projects.

When thinking of fixing bugs and adding features we just reverse the flow.

Ubuntu -> Debian -> {Sugar Labs | OLPC}

At this point we are primarily interested in fixing bug and adding
features to Ubuntu 10.10 (Maverick) but we need to respect and
participate in pushing our work upstream.

A refresher into why the open source development methodology works.
Open source works because someone initially creates and shares
something.  If the original something is useful others start to use
it.  If and only if the new users start modifying and improving -- and
pushing their improvements back upstream does the project gain
critical mass and start to grow.  The best example of this is the
linux kernel.  Please see http://lwn.net/Articles/222773/ Many kernel
developers work for a company/organization that uses the kernel.

Seeta and Activity Central are to Sugar like Redhat and Intel are to
the kernel.  (At a slightly smaller scale).  Over the next couple of
months I expect a large percentage of USR developers will be
contributing most of their code upstream to Sugar Labs.

So, when fixing bug and and add features to USR, we have two
overlaping goals.  Make USR awesome and push things as far upstream as
possible.

The basic work flow is to:
1. Test for bugs and missing features in Ubuntu 10.10 (our target)
2. Think about the bug/feature to determine if it would be useful to
other projects that use Sugar.
  a. Is the issue ubuntu specific?
Create Ubuntu specific fix
  b. Does the issue apply to Debian?
Create Debian fix (anything fixed in debian will flow down to ubuntu)
  c. Does the issue apply to all Sugar users?
Create Sugar Labs fix (anything fixed in Sugar Labs with flow down to
Debian and then to Ubuntu)

In general the way to fix things is similar between projects:
1.  In Sugar Labs -- Create patch against sugar-jhbuild and submit to
Sugar developers.  In the next months several Seeta developers will
earn the authority to commit directly to the upstream sugar tree.
2. In Debian -- Create patch against sugar-jhbuild and commit to
collab-maint at debian and request approval.  Currently Luke can
approve requests.  In the next months several seeta developers will
earn the authority to approve patches.
3. In Ubuntu -  Create patch against sugar-jhbuild, create debdiff
against existing package in Maverick, submit debdiff to LP for
approval. Currently Luke can approve debdiff requests.  In the next
months several seeta developers will earn the authority to approve
debdiffs.

Caveat.  The farther upstream you push a patch the more users it
affects.... as a result the process for reviewing patches tend to be
more through and take longer the farther upstream you go.  As a result
it will be common to have a patch in Ubuntu/Debian (fixing our problem
temporarily) while it is pending review or being reworked upsteam.
Then when the next upstream version is release the problem will have a
premenant fix and we can remove our local (temporary) patch.

david