[Ayatana-dev] autolanding of unity and linked components branches ready and activated!

[Tim Penhey]

On 23/11/11 22:42, Didier Roche wrote:
> Le 23/11/2011 09:40, Olivier Tilloy a écrit :
>> Hey Didier,
>>
>> That was a long e-mail, thanks for setting this up!
>>
>> On 2011-11-22, Didier Roche<didrocks at ubuntu.com> wrote:
>>> […]
>>> Limitations
>>> As we are running all projects in parallels to avoid having to wait too
>>> much before a branch from a project is merged, we need to have in mind
>>> that there is no dependency automagic check, like:
>>> 1. you add a new API to nux
>>> 2. you use this API in unity.
>>> 1. needs to be merged (and so built) successfully. Please, do not
>>> approve 2. until 1. status is "merged". Then, the local repository in
>>> the pbuilder will automatically take the right Nux version with the
>>> additional API. If you set it to "approved" before the nux branch is
>>> merged, you can have great changes seeing your branch rejected because
>>> it will fail to build. Be patient before approving the second branch, as
>>> the merger is running every 15 minutes, you should get a merge soon. :-)
>> Launchpad knows of a notion of "Prerequisite Branch" when creating a
>> merge request, that is a branch that should be merged before the one
>> under review for everything to work as expected. As far as I know this
>> is not limited to branches targeting the same trunk, so you could very
>> well make a branch of e.g. nux be a prerequisite to a branch of unity.
>>
>> Maybe there’s a way of instructing tarmac to respect those dependencies?
>
> Indeed, if people are setting those dependencies (which wasn't the case
> in the past), we can use that. I need to make some tests to ensure that
> we can set pre-requisite on branches that have no common revisions on
> different projects though.

Prerequisite branches are not used for this case.

I use the prerequisite branches as I often developed using bzr-pipelines.

The way the prerequisite branch is used is primarily for diff 
generation.  The prereq branch is merged into trunk, then the proposed 
branch is merged into the result, and the diff of that second merge is 
what is connected to the merge proposal.

However, there is still an important check needed here.

It is entire feasible to have a chain of dependent branches (I once had 
13), where earlier branches are not approved, but later ones are.

We shouldn't be able to land an approved branch if any of the 
prerequisite branches in the chain are not approved.  We do need to make 
sure that we allow merged ones though, as the prereq stays even if it is 
merged.  All that happens there is the merging of the prereq into trunk 
becomes a no-op for the diff generation.

Tim