unity-dev team mailing list archive

[Didier Roche <didrocks@xxxxxxxxxx>]

Le 07/01/2013 15:32, Ted Gould a écrit :
> On Mon, 2013-01-07 at 07:40 +0100, Didier Roche wrote:
> > 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.
>
> Perhaps speed is the wrong term to be using here.  Faster build times 
> aren't the problem, the problem is feedback loops and communication 
> patterns.  I'm quite convinced every developer is committed to getting 
> things landed to a quality trunk, but that's not the only place that 
> problems can happen.
>
> I think I'm going to have to switch to a quick diagram :-)
>
> http://ubuntuone.com/1bTq20mlpAvPwwjYLjrv7x
>
> The first part of that I see as the developers responsibility. There's 
> a feedback loop that they get directly notified of and get e-mailed as 
> part of the merge process.  The area outside of the dotted box I think 
> the feedback loop is through LP bugs.  So if anything "after trunk" 
> there breaks, a bug should be filled and prioritized appropriately.  
> But, to be clear, that shouldn't be a "revert from trunk" action, it 
> should be another merge request to fix the problem.  What ever that 
> merge request may contain. Partially this is a matter of language, if 
> caught further down the line it is "we found a bug" not a "you broke 
> the build."

I think you misread my first email or I didn't express properly, but I 
didn't put any blame on anyone or pointed that the feedback loop was 
inadequate, I just raised the issue that trunk was known (so it's not a 
question of awareness here) to be broken for quite some time and this 
wasn't addressed in a timely fashion (even a revert is a good answer in 
my opinion if we can't figure out within a day a good fix).

Your diagram about the feedback loop matches exactly what I presented at 
UDS so we are in agreement here. :)
I'm pretty sure that once we have the unity stack with autopilot running 
automatically every day (which is just few days ahead, needs more UTAH 
stability right now) we will get this speed feedback within 24 hours.

So the email was about to raise the awareness that quality is a daily 
vigilance and we shouldn't start letting that slip by, or we will pay 
the cost later on, as the more you want on, the more complicated it will 
be to investigate the cause and find a proper fix.