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
--
Mailing list: https://launchpad.net/~unity-dev
Post to : [email protected]
Unsubscribe : https://launchpad.net/~unity-dev
More help : https://help.launchpad.net/ListHelp
