[Dextrose] Defining Dextrose 4 code workflow

[Ruben Rodríguez]

2012/10/5 Anish Mangal <anish at sugarlabs.org>:
> 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.

I don't see this as much of a problem if we can extract patches
cleanly. Other than that issue, almost any git based workflow would be
an improvement.

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

I think we can either think of Dextrose as a product that the
deployments can adapt to some extent, or as the base upon we build a
different thing for every client. Those are diferent ideas both from a
technical and a business perspective. I vote for the first one in any
case, I think having an unified codebase would benefit both the
deployments and us as maintainers.

Adding Ajay's comment for thread unification:

> Pros ::
> * No need to "rebase" a change upon the patch.
> * All that is needed is make-a-change; test; commit.
>
> Cons ::
> * Difficult to isolate patches feature-wise, which is kinda necessary for upstreaming.
> * But, I (at least) would want to make life easier "in the moment", rather than worry for later.
>
> It should not be too tedious to "extract" feature-patches, whenever upstream wishes that they are ok to accept new features.

Making patches is one of my biggest concerns, and I want to have some
tests done (with our patches and some fake commits on git) to see how
cleanly we can get our patches out of git. But I agree it shouldn't be
hard, as git was designed with that (among many other features) in
mind.

I got into several meetings and discussions with Santiago in the last
days regarding the git workflow, and we have come up with the
following proposal:

We start by cloning every upstream package separately into git repos

* Sugar > Sugar-dextrose
* Sugar-toolkit > Sugar-toolkit-dextrose
* Sugar-artwork > Sugar-artwork-dextrose
and so on. The clones will live in git.sugarlabs.org[1] and will grant
commit permissions to the release manager (RM).

Each of this repos will have the following branches, that define the workflow:

1 Master
2 Devel
3 QA
4 Staging
5 Production

Additionally each developer will have a personal clone of the Devel
branch, upon where to commit his code.

1 MASTER: it is a direct clone of an upstream tag, (e.g. sugar
v0.98.1). Optionally it will receive as commits only bugfixes that are
directly approved for upstreaming. This simplifies the commit merges.
2 DEVEL: it receives the latest code from the developers' repos, via
fast-forward merges that the RM would do by request of the developers.
It is the developer duty to make sure the commit applies cleanly
(fast-forward) to the devel branch, by having their own local repos
properly updated.
3 QA: groups of commits forming a new feature or a bugfix are then
committed into the QA branch. Grouping them this way should simplify
extracting patches to send upstream. Automated from this branch we
will generate a set of rpm's in a repository that the QA team will
have set in their machines, so they can test that the new code fixes
the issue. If the fix is approved (or after new commits if it needs a
modification), the commits are merged into the Staging branch.
4 STAGING: This is an optional step. As with QA, it would be used to
generate a (at this time already tested) rpm repository that a
"classroom 0" would use. This extra testing can be done in an
environment closer to production, like a particular school, and with
the help of the teachers, and would prevent a bad update to be pushed
to the whole deployment.
5 PRODUCTION: At this point the code is golden, and is automatically
packaged into a rpm repo for general use.

The passing of code between one branch to the other should be handled
by the appropriate acting of the different teams and the RM using
redmine metadata changes to the related issues.

1: Why not basing the git repos directly in sugardextrose.org?

* Visibility: We wont to be as close to the community as possible, and
the Sugar code lives at git.sugarlabs.org
* Redmine's support for git is incomplete, and is mostly limited to
browsing the code and it's commits, and to connect certain commits to
issues and their changes in status. But it lacks support for multiple
repositories per project, or for personal repositories per developer.
It also lacks support for ssh-key management and other
developer-centric features.
* We would still set redmine to keep a direct clone of the repos at
git.SL.org so the code and commits will still browseable at sdxo,
keeping all the git integration features redmine provides.

NOTES:
* It is the devel responsibility to make sure the commits apply
cleanly, and that they are signed and commented, with the appropriate
headers pointing to the redmine issues.
* It is the RM duty to make sure those rules are followed.
* Commits should be grouped by feature or bugfix as much as possible,
to simplify extracting them for upstreaming. This process will need to
be thoroughly documented with commands and tips for code refactoring.
* Initiating a release on a new upstream Sugar version would start by
tagging the current version (thus freezing the code for the previous
release) and merging down the changes from upstream into master, then
rebasing the Production branch on that master and renaming it to
Devel. New QA, Staging and Production branches would be spawned from
this new Devel branch.
* OOB is somewhat different and needs its own workflow, much simpler.
* We should also review our workflow for activities as a separate project.

My 200 cents.
--

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