harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [general] aiming no regression
Date Mon, 18 Dec 2006 12:34:28 GMT


Mikhail Loenko wrote:
> 2006/12/1, Geir Magnusson Jr. <geir@pobox.com>:
>>
>>
>> Mikhail Loenko wrote:
>> > 4) We have cruise controls running classlibrary tests on DRLVM. We
>> > need to decide what will we do when DRLVM+Classlib cruise control
>> > reports failure.
>>
>> Stop and fix the problem.  Is there really a question here?  I agree
> 
> Yes, there is a question here. "Stop and fix" includes "discuss". But
> as we now know discussion may take several days. And while some people
> discuss what the problem is other people can't proceed with
> development and patch
> intagration.
> 
> To have better pace and better CC up-time we need something else but not
> just "stop and fix". I suggest "revert and continue"

What's the difference, other than debating the semantics of "fix" and 
"revert"?

We all agree - but I still don't think you're clearly stating the 
problem.  I think that the core problem is that we don't immediately 
react to CC failure.

Immediately reacting to CC failure should be the first order of the day 
here.  Reacting to me is making the decision, quickly, about either 
rolling back the change ("reverting") or doing something else.  The key 
is being responsive.

It seems that what happens is that we wait, and then sets of changes 
pile up, and I think that doing mass rollbacks at that point will solve 
it, but make a mess.

The example of what I envision is when I broke the build in DRLVM, 
Gregory told me immediately, and I fixed immediately - w/o a rollback.


All I'm saying is :

1) We need to be far better with reaction time

2) We have intelligent people - we can be agile in this by making 
decisions (quickly!) on a case by case basis what to do.

I'll also suggest that we ask each committer to check the CC event 
stream before committing, so you don't commit into a bad state of things.

One of my problems is that I don't trust the CC stream, and don't 
clearly see it because it's mixed in the other drek of the commits@ list.

I'm going to focus on these problems this week and see if we can make 
some progress on it.

First, I'll create a new list for this.  I'll use "buildalerts@" unless 
someone can propose a better name :)

geir


Mime
View raw message