launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 18 February 2010 19:11, Bjorn Tillenius <bjorn@xxxxxxxxxxxxx> 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.

That's pretty good, thanks for driving this forward.  I think it will
really help lp developers and users.

Some things about presentation:

Visually it would help if you pull the "DB change" box over to the
left so it's clearer there are three paths by which some work enters
the system.   Also it may make the results clearer if you had boxes
coming out the right to show which branch is deployed onto which
server, and how often.

I think "devel" is a poor name; the whole thing is development.  This
could be a good chance to change it to eg "fixes" or "stable".

I think your document is open to this, but it may be worth emphasizing
that there is no actual need to have an intermediate feature branch.
If an independently-releasable feature can be done on a single branch,
that's good.

People will have to be careful to to resolve merge conflicts by
merging from edge back into their feature branch, because then when
the changes are landed to "devel" (or "stable") then inadvertent
changes will also be brought in.

It's probably worth documenting that new feature branches should start
out from probably db or production.

I'm not convinced about the auto-merges from feature branches to edge:
it could be good, but it may be better to get to this process in small
steps and automatic merges seem like a potential source of problems,
and at the very least you will need to write and debug the
auto-merger.  If the feature branch is where most of the work takes
place then merging it edge should not be a burden for developers to do
individually.

I think "you're not done until" LOSAs have said, not under duress ;-),
that they understand how it will work and that this will make their
life at least no harder.

Given the tools available I think the best way to track work in
progress is through bugs, which may mean filing more bugs for features
than is done at present.  Then you can either tag the bug as being
ready to go into devel, or you can make a separate series bugtask.

As far as the actual QA step, I think there is a great deal of scope
for Launchpad developers to both save themselves time and get better
results by asking other people to qa their work.  If the bug is
clearly marked as "now live on edge, please test" then I think users
really will test it and tell you.  Obviously a little script could be
written to send that message and manipulate tags.  See
https://wiki.ubuntu.com/StableReleaseUpdates and the general Ubuntu QA
thing.

This page is a bit confusing about just when QA happens: it says the
features are going to be QAd on staging yet the QA arrows go out of
the 'devel' branch, and perhaps it is better to expand the term "QA"
into something more specific.

Is there meant to be some kind of arrow from devel to staging, so that
everything merged to devel can soon be tested on staging?

To me it seems like the QA possibilities, leaving aside stuff on local
machines during development, are

* on staging: can use database changes; can be relatively dangerous
because it's not real data or a real system; serious drawback is that
very few users will actually test it
* on edge: can get real user testing; should not toss its cookies

I would like to dig into what difference, if any, there should be
between devel and production.  Perhaps everything except genuinely
tiny and extremely safe changes should land only onto edge, and then
from there when they are known to be safe, land directly onto
production.

Or alternatively devel could run just slightly ahead of production, so
production is "what's running now" and devel (please rename it) is
"what will be on production next time it's rolled out", but you would
keep the idea that rollouts happen as fast as you like.

You could conceptually eventually add another layer of servers there,
so there is

 "everything under development integrated together"
 "current should-be-stable tip, updated nightly"
 "really stable, less frequently updated"

but I'm not sure that's totally needed, and db divergence may make the
third too hard to support over a long time.

I think cherrypicking or tagging individual revisions would be a big
distraction here.  Since everything eventually has to work together on
the servers, it's very desirable that you have consistent branches
joining up together as they converge on production, and things should
not be chopped-and-changed after they're tested.

-- 
Martin <http://launchpad.net/~mbp/>