[Dextrose] Defining Dextrose 4 code workflow

[Ajay Garg]

On Thu, Oct 11, 2012 at 11:05 AM, Rafael Ortiz
<rafael at activitycentral.com>wrote:

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


Hmm.. We could have a DX-Devel branch, once we are almost finished
rebasing, and not before 2 weeks of the final release.
So, for now, only "Upstream - Master", and "DX - Master" should suffice.



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


-- 
Regards,

Ajay Garg
Dextrose Developer
Activity Central: http://activitycentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/dextrose/attachments/20121011/673ba906/attachment.html>