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

[Olivier Tilloy <olivier.tilloy@xxxxxxxxxxxxx>]

Hey Didier,

That was a long e-mail, thanks for setting this up!

On 2011-11-22, Didier Roche <didrocks@xxxxxxxxxx> 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?

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

Thanks,

Olivier