[Dextrose] Defining Dextrose 4 code workflow

[Rafael Ortiz]

On Wed, Oct 10, 2012 at 11:37 PM, Ajay Garg <ajay at activitycentral.com>wrote:

> 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.
>
>
Too many are overkill but too few are also error prone and become critical
to maintain. an alternative scheme could be:

1 Upstream - Master
2 DX - Master
3 DX - Devel





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
>
>
> _______________________________________________
> Dextrose mailing list
> Dextrose at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/dextrose
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/dextrose/attachments/20121011/6f657016/attachment-0001.html>