[Dextrose] Defining Dextrose 4 code workflow

[Anish Mangal]

Hi,

I think shifting to a code-repo based workflow has been long overdue.

Advantages:
* Easier to collaborate with upstream. They can actually view the code
in it's intelligible form, rather than discrete patches.
* Easier for deployments to see the code.
* Perhaps better integration with automated build workflow
* The pros that Ajay mentioned.

Challenges:
* Cost of switching. Something that the project managers need to analyze.
* The question of different features for customers remains unanswered
to an extent.
*a. Do we start to maintain different branches for codebases? Are we
maintaining different branches for OOB build envs. right now?
*b. Everything can't be gconfable?

There has to be some level of agreement between uy and au on features
otherwise dextrose starts to lose it's identity.

If we can address these challenges, then it's a +1 for me. The commit
access policies should be reviewed once the switch is made.

Cheers,
Anish

On Thu, Oct 4, 2012 at 8:33 PM, Ruben Rodríguez
<ruben at activitycentral.com> wrote:
> With this new release we have an opportunity to improve how the
> dextrose code is managed.
>
> From a code point of view Dextrose is composed of a set of
> modifications on OOB and a group of patches to the sugar,
> sugar-toolkit and sugar-artwork packages. At this point all those
> changes live together in the same git repository:
> http://git.sugarlabs.org/dextrose/mainline The patches to the sugar
> packages are in the rpms directory.
>
> 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.
>
> Apart from having a clean way to be able to produce patch files to
> send upstream as needed, we should take into account the deployment's
> need to select which set of features they want to have in their
> packages. To simplify that, features like 1-to-n or multiselect could
> have an "enable" switch in a config file or gconf key, so they can
> share the same codebase.
>
> In any case that is just a suggestion, and I'd like to hear yours!
>
> --
> 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
> _______________________________________________
> Dextrose mailing list
> Dextrose at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/dextrose



-- 
Anish | anish at sugarlabs.org