launchpad-dev team mailing list archive

[Michael Hudson <michael.hudson@xxxxxxxxxxxxx>]

Bjorn Tillenius wrote:
> 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.

Hmm.  Have you thought about having feature branches that are merged to
staging?  In the current diagram, there's still no way to get anything
onto staging that doesn't also put it on the treadmill to being released
onto production.

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

This could get pretty messy I think.. what if two feature branches conflict?

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

I guess we can a known revision id that's in the edge branch, and have
PQM reject merges to devel that include it (and for feature branches, if
feature branches are managed through PQM) -- though this might be a bit
unforgiving...

Thanks for working on this, I definitely still like the general thrust!

Cheers,
mwh