[Dextrose] Defining Dextrose 4 code workflow

[Ajay Garg]

Having so many branches is an overkill; it is too efforts-intensive,
error-prone and generally daunting.

We should just go for one branch (besides the upstream master branch).
This singular branch should serve everyone's purposes  - developers, QA,
staging, "golden", etc.

As far as extracting patches is concerned, well, hold me responsible for
doing it later.
Right now, let's just focus on getting things completely and efficiently,
IN AS SIMPLE A MANNER as possible, for December-16.

On Thu, Oct 11, 2012 at 9:02 AM, Ruben Rodríguez
<ruben at activitycentral.com>wrote:

> 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
> _______________________________________________
> Dextrose mailing list
> Dextrose at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/dextrose
>



Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/dextrose/attachments/20121011/920d37f8/attachment.html>