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

[Sam Spilsbury <smspillaz@xxxxxxxxx>]

On Wed, Nov 23, 2011 at 5:42 PM, Didier Roche <didrocks@xxxxxxxxxx> 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<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?
>
> 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     : ayatana-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Sam Spilsbury