[Dextrose] Defining Dextrose 4 code workflow

[Rafael Ortiz]

On Thu, Oct 11, 2012 at 4:03 AM, Ajay Garg <ajay at activitycentral.com> wrote:

>
>
> 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.
>
>
>
+1

>
>>
>>
>>
>>
>> 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/63b606d8/attachment-0001.html>