[Dextrose] Defining Dextrose 4 code workflow

[Bernie Innocenti]

On Fri, 2012-10-05 at 02:33 +0200, Ruben Rodríguez wrote:

> I think that the first thing to do is separating both things, as the
> changes to OOB are not directly related to the patches, and should
> live in separate repos.
> The next step would be more complicated, and would be moving from the
> patch set to a git workflow that allows us to separate the different
> features so we can upstream them individually, and build rpm's with
> all the changes applied. This was tried before, but since we
> developers are stubborn sometimes, it didn't catch on. We need to make
> a bigger effort this time.

The hard problem to solve is how to do rebasing.

Since you cannot rebase a public repository that other people are
cloning, you can't really use a straight-forward git workflow to manage
a set of patches on top of an upstream project.

Several complicated tools were invented to help with patch queues, but:

 - they make you loose the advantages of better patch visibility because
   they're unfamiliar to most developers

 - the learning curve is pretty steep

 - managing patches tends to become more laborious

 - at some point you need to generate a directory with patches anyway
   so you can apply them to rpms and send them out for review

 - unless you also commit the patches in the OOB repo, you loose the
   ability to reconstruct an old build from source

If you're managing very few off-tree patches, these tools are not worth
all the trouble... and you *SHOULD* be managing very few patches if
you're upstreaming your code immediately after writing it.

You could fix the root issue by not letting patches pile up in the first
place. Tell all developers that you're not accepting a patch in Dextrose
unless they've had at least a public review on sugar-devel at .

You can save time by including a really urgent patch while the review is
still in progress. Years ago Sugar had a really slow and dysfunctional
review process, but things seem to have improved a lot these days.

(NOTE: i think that centralizing patch submission is a really bad idea.
Each developer should submit their own patches individually, like it's
customary in all FLOSS projects).

-- 
Bernie Innocenti
Sugar Labs Infrastructure Team
http://wiki.sugarlabs.org/go/Infrastructure_Team