On Wed, Nov 23, 2011 at 5:42 PM, Didier Roche <[email protected]> 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<[email protected]> 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.
For this is might be more useful to look at getting xig[1] and a dummy libGL up and running [1] launchpad.net/xig > > 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 > > _______________________________________________ > Mailing list: https://launchpad.net/~ayatana-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ayatana-dev > More help : https://help.launchpad.net/ListHelp > -- Sam Spilsbury _______________________________________________ Mailing list: https://launchpad.net/~ayatana-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~ayatana-dev More help : https://help.launchpad.net/ListHelp
