launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On February 12, 2010, Bjorn Tillenius wrote:
> Hi,
> 
> at the team lead sprint we discussed how we could solve the problem of
> unfinished features being pushed out to launchpad.net every time we do a
> release.
> 
> I have a proposal how we can keep the development cycle separate from
> our montly "push out db changes" cycle. I think using branches to handle
> this would work well, so I'm proposing how we could change our merge
> worfklow to make things better. There are still a few unknowns, but
> let's start a discussion of what I have so far, before I try to refine
> it.
> 
> I've created a LPE, to see how that works, which describes why we're
> doing this:
> 
>     https://dev.launchpad.net/LEP/ReleaseFeaturesWhenTheyAreDone

That link doesn't work for me.

> 
> To summarize, branches that contain db changes always get landed to the
> `db` branch. Other changes get landed to the `edge` branch, although
> branches that are part of a larger features (consisting of multiple
> branches) get landed to edge through an integration branch for that
> feature.
> 
> The landed revision stays in the `edge` branch until it has been marked
> as being QAed. When the revision is marked as good, it automatically
> gets merged into the `production` branch, which is rolled out to
> `launchpad.net` daily.
> 

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.

> {{attachment:merge-workflow.png}}
> 
> == The QA step ==
> 
> A revision gets merged from `edge` to `production` only after it has
> been marked as good in the QA step. This helps ensure that we don't
> rollout feature to `launchpad.net` that haven't been QAed.
> 
> XXX: How the QA step works regarding to marking the revision as good/bad
> is still undefined.

A revision property?

> 
> 
> == Feature branches ==
> 
> Features that will involve multiple branches should have an integration
> branch for that feature. Instead of landing branches related to the
> feature to `edge`, they land their branches to the integration branch.
> New revisions in the integration branch will automatically be merge into
> the `edge` branch.
> 
> The reason for having an integration branch branch is to keep track of
> all the revisions that belong to the feature, so that when the feature
> has been marked as good in the QA process, the whole feature can be
> rolled out at once. Parts of the feature can still be rolled out by
> QAing specific revisions.
> 
> XXX: How to register new feature branches, and how to merge to them, is
> still undefined. Maybe a better way would be to use revision properties
> to tag revisions as being part of a bigger feature, or use bug links?

Again, since bazaar doesn't support revision cherry-picking, we probably need 
separate branch. I heard that bzr-builder could be use to merge a set of 
branches automatically.

> 
> == What about `staging.launchpad.net` ==
> 
> Staging takes the `edge` branch and merges in the `db` branch.
> 

I don't think this works because edge contains feature branches that are not 
ready for roll-out. I think we want staging to be exactly what will be rolled-
out next month. So it should be the db branch + all the QA changes.



-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.