On 18 February 2010 19:11, Bjorn Tillenius <[email protected]> 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/> _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
