launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

On Fri, Feb 19, 2010 at 02:19:12PM +1100, Martin Pool wrote:
> 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.

Yes, I was thinking of doing that. I'vd done that now, and I've also
divided it into three columns to hopefully make things a bit clearer.


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

Agreed. I used "devel", since I wanted to re-use the existing branches.
However, renaming it is a good idea to makes things clearer. I renamed
it to "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.

Yes, I've added a section to clarify this.


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

Yes, this is one unresolved issue. What happens if someone merges in
edge into their feature branch? How can we revert this, without doing an
uncommit? I guess it's the same way we undid merges of db into devel in
the past?


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

Yes. They should start from db or stable, actually.


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

Yes, Francis brought this up as well. I think it's ok to have the merge
of the feature branch into edge to be a manualy step. We'll see how it
will work out.


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

Good point :)


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

Yes, I've talked to Brian about this already. I think it's valuable to
clearly show which features on edge that we expect to be QAed by our
users.



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

It's a bit confusing, since the QA step isn't defined yet :)


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

Oops, forgot an arrow there. There are arrows from stable to db now, so
that the revisions in stable are testable on staging through the db
branch. It's not ideal. We might want to have two different staging
systems. One of the db branch, and one of the stable branch, in case the
db changes interfere.


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

Stable (previously devel) and production are basically the same branch.
Things are landed on stable (even small and extremely safe changes).
They stay on stable until someone confirms that they are good to be
pushed to production. Stable gets merged to both db and edge, so the
changes can be QAed both on staging and edge.


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

Right, this is basically how things work in the proposed workflow.


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

Yes, it's probably safer and easier not to try to use cherry picking,
even if bzr supported it.

Thanks for your comments!


-- 
Björn Tillenius | https://launchpad.net/~bjornt