FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Desktop

 
 
LinkBack Thread Tools
 
Old 11-23-2011, 07:40 AM
Olivier Tilloy
 
Default autolanding of unity and linked components branches ready and activated!

Hey Didier,

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

On 2011-11-22, Didier Roche <didrocks@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
 
Old 11-23-2011, 08:42 AM
Didier Roche
 
Default autolanding of unity and linked components branches ready and activated!

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


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.


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

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 
Old 11-23-2011, 10:28 PM
Tim Penhey
 
Default autolanding of unity and linked components branches ready and activated!

On 23/11/11 22:42, Didier Roche 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@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?


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.


Prerequisite branches are not used for this case.

I use the prerequisite branches as I often developed using bzr-pipelines.

The way the prerequisite branch is used is primarily for diff
generation. The prereq branch is merged into trunk, then the proposed
branch is merged into the result, and the diff of that second merge is
what is connected to the merge proposal.


However, there is still an important check needed here.

It is entire feasible to have a chain of dependent branches (I once had
13), where earlier branches are not approved, but later ones are.


We shouldn't be able to land an approved branch if any of the
prerequisite branches in the chain are not approved. We do need to make
sure that we allow merged ones though, as the prereq stays even if it is
merged. All that happens there is the merging of the prereq into trunk
becomes a no-op for the diff generation.


Tim

--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
 

Thread Tools




All times are GMT. The time now is 09:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org