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?
