[Dextrose] Defining Dextrose 4 code workflow

[Ruben Rodríguez]

2012/10/11 Bernie Innocenti <bernie at sugarlabs.org>:
>
> The hard problem to solve is how to do rebasing.

To be precise, it is not so much rebasing as it is rebasing while
maintaining the ability to extract patches for upstreaming. If we
didn't want to upstream or if we were developing an isolated feature,
it would be easy to maintain with git.

>  - 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

You could generate the rpms directly from the git branch, but that is
too much of a black box.

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

How come? You can checkout any previous state of the code and make a
patchset or rpms.

> 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 .

That is a very good goal, but at this point we have over 150 patches
already piled up. Of course the pile is not clean and many of those
patches are redundant, but still we need to be able to cope with many
patches and also with different independent features making changes in
the same places of the code.

> 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.

Well, we need to address that as a separate problem. And it is an important one.

> (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).

I agree. We need to centralize all the code so it can be tested and
deployed properly, so we have too paths for the code: for deployment
and for upstreaming. And none should take over the other.


-- 
Rubén Rodríguez
CTO
Activity Central: http://activitycentral.com

Facebook: https://activitycentral.com/facebook
Google+: https://activitycentral.com/googleplus
Twitter: https://activitycentral.com/twitter