unity-dev team mailing list archive

[Didier Roche <didier.roche@xxxxxxxxxxxxx>]

Le 04/01/2013 20:33, Ted Gould a écrit :
> On Fri, 2013-01-04 at 09:05 +0100, Didier Roche wrote:
> > Just back from vacations, I have the unpleasant surprise to notice 
> > that unity fails to build in the staging ppa since 2012-12-19 and 
> > that more than 7 merges were done in between without fixing it first 
> > (or reverting the faulty merge): 
> > https://launchpad.net/~unity-team/+archive/staging/+packages?field.name_filter=unity&field.status_filter=superseded&field.series_filter=raring 
> > <https://launchpad.net/%7Eunity-team/+archive/staging/+packages?field.name_filter=unity&field.status_filter=superseded&field.series_filter=raring>
> > I guess it's failing due to the precompiled header: 
> > http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3002 
> > <http://bazaar.launchpad.net/%7Eunity-team/unity/trunk/revision/3002>. Unity 
> > is built in parallel in the ppa, that's maybe why it passed the 
> > merger step.
> >
> > Mirv is now looking and is taking action to get that under control 
> > again, but please please, when you do merge something, track the 
> > builds and install your branch locally to check for side-effects. For 
> > this one, if we couldn't get that fixed easily, the quickest path at 
> > the time would have been to revert ASAP the branch until we find a 
> > good fix and not having an unreleasable unity state as we have right now.
>
> Uhm, no.  Stop blaming people when the tools are broken.
>
> The simple fact here is that nothing should land unless it's 
> buildable.  If the staging PPA is doing something different than the 
> autolander we need to fix that.  There shouldn't ever be a reason to 
> revert because that branch shouldn't land in the first place.  There 
> is no way developers can track all the different ways things are being 
> built.
>
> Additionally the builds take too long to expect developers to track 
> them and respond to them.  If you want people to make sure that they 
> build before they push a merge we can't have autolanders.  If you want 
> people to believe in the tools, the tools need to protect them.
>
> We've now had this problem on several projects where we can't land 
> branches because the tools aren't working properly.  We either need to 
> fix them or back them out.

I agree with you here. Don't blame me for tools I'm not responsible for 
as well please, and rather, work with the PS QA team responsible for 
them to fix those.

So, after investigation last Friday (because I didn't have to wait for 
you to start gathering some info why the first merge happen and why then 
it was failing in the staging ppa), it seems that Francis hacked around 
the builder to disable some flags to have it passed the merger. I talked 
to him and ask to stop doing that as it leaded to more problems like the 
one we saw here. I hope this won't happen again.

I second as well on the speed issue, please again, check within your 
team with the responsible of those tools to see what they can do so that 
the merge answer is way faster. I know that Jibel started to have a look 
as well and it seems the machines on which they are merging are swapping 
a lot, he will adjust in the coming days the infra to help your team.

Cheers,
Didieri