launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #02641
Re: New merge workflow to keep features on edge until they have been QAed
Bjorn Tillenius wrote:
> On Fri, Feb 12, 2010 at 11:57:12AM -0500, Francis J. Lacoste wrote:
>> I don't understand how you can land changes both bug fixes and feature
>> integration on the edge branch and how to deploy the QA revisions to
>> production. Bazaar doesn't support cherry-picking.
>>
>> I think we need an intermediate branch (devel) on which we land simple bug
>> fixes, and any stretch of QA revisions on that branch can be merged to
>> production.
>>
>> Edge would be the result of devel + features integration branches.
>
> https://dev.launchpad.net/MergeWorkflowDraft is now updated to keep the
> current devel branch, and add an edge branch. The graph is now a bit
> more complicated, but I think it's still doable.
>
> Everyone that cares about how this should work, please review the
> document once again. If I don't get any complaints before Monday, I will
> start defining what needs be done to implement this, and start moving
> towards this workflow.
It's complicated, but I think it all makes sense, and will improve our
development process and the experience of our users. Some unordered
comments follow.
I'm not sure how this will interact with our continuous integration
approach. I guess some of the branch blobs need to be split into -devel
and -stable blobs, and it's the stable ones that will get automatically
deployed to the various servers. I guess the db->stable separation is
already an instance of this, really?
When does 'devel' get merged into 'db'? That particular line is missing
a label.
It's clear that we need some way to track the 'qa-ed-ness' of a revision
as it moves between the branches.
Because we can't cherry pick, it will be possible for some bugfix that's
hard to QA to block other bugfixes from getting to production. I guess
this will lend some more social pressure to getting your QA done
quickly, which is probably no bad thing.
Given that most of my work these days doesn't touch the app servers, I'd
certainly like to talk about getting improvements to other services
rolled out more quickly (particularly code imports, and these should be
easy). But I guess this can wait until after the branches are all set
up, etc.
Cheers,
mwh
Follow ups
References