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

[Didier Roche]

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.
>> Future improvments
>> I will add additional checks soon in the future:
>> - ensure that every branches have at least a bug attached. There will be
>> the possibility to add "NOBUGNEEDED" to bypass it, but we will have a
>> report to avoid abuses (and that will enable us to have the bug
>> automatically set and components added). No more unclosed bugs! Having
>> real metrics of number of bugs closed, and such…
>> - ensure that every branches have tests (with a test directory of file
>> changes). There will be the possibility to add "NOTESTNEEDED", with the
>> same report to avoid abuses.
>> - we can even ensuring that the contributor signed the CLA checking for
>> the right team if the team is put up to date again on launchpad.
>> - we can also imagining that after UIF or FF, if the bug linked to the
>> branch authenticated as a UIFe or FFe is not acked by the release or
>> documentation team, it is rejected automatically.
>> - finally, we can get a "ready to release" time, where no approved
>> branch are merged automatically, when set in this mode, we can directly
>> choose which branch to merge and pick only those that are helping
>> getting closer to the release (a freeze-like mode in some way).
>>
>>
>> For developers, in a nutshell, no more direct merge, think to set the
>> "approved" status in the merge request and all should be smoothed.
>> Of course, as this has been tested on a test project in the infra, we
>> are enabling projects one after another.
> In what order will the projects be enabled?
> How is this going to affect (if at all) unity-2d, which has had a
> partially similar set-up for quite some time now?

Right now, are enabled: all projects listed in the intial email apart from:
unity, unity-2d, bamf, libunity.
Inded, make check doesn't pass under a X-less server for those projects.
Example: https://jenkins.qa.ubuntu.com/job/automerge-unity/lastBuild/console
I asked Tim to designate someone in dx to work on that quickly. dbusmenu 
is using xfvb (and dbus-test-runner) for addressing this case. If not, 
making make check and make "headless" check not requiring X. Not that no 
branch in each of those projects will be merged before this being fixed. 
Other projects continue to have branches automatically landing.
I deactivated automerging of those 4 branches to avoid rejecting every 
branches because of this. But this need to be fixed shortly so that we 
can have new code entering trunks.

Unity-2d team  needs to remove his tarmac landing to follow the new 
testing passing before branch landing to trunk. I've pinged Kaleo about it

Cheers,
Didier