Hey Didier, That was a long e-mail, thanks for setting this up!
On 2011-11-22, Didier Roche <didro...@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? > 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 -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop