Reopening the trunk: planning

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Reopening the trunk: planning

Mark Banner
L. David Baron wrote:
> I think the big problem is that we need to be quicker to:
>  * close the tree for bustage or regressions
>  * back people out of they break the rules, such as:
>    * checking in on orange or red
>    * checking in on branch before trunk.

I'd just like to point something out - as far as I know there has never
been a rule to not allow checking in on orange, and I have even been
explicitly told in the past that checking in on orange is ok. Its only
the recent problems that seem to have brought up the fact that we should
extend the rule to not allowing checking in on orange as well. The
SeaMonkey Checkin requirements on the tinderbox page (that the other
pages point to as well) only states:

"Do not check in when the tree is broken (red)."

I'm not against a rule to not allow checking in on orange, but please
can we update that text if we are going to adopt it permanently.

Standard8
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Reopening the trunk: planning

Boris Zbarsky
Mark Banner wrote:
> I'd just like to point something out - as far as I know there has never
> been a rule to not allow checking in on orange

Part of the thing with orange is you have to use your discretion a little.  If
some random box someone added to the tree is orange because it currently can't
find an X server, that might be a non-issue in terms of checkins if everything
else is green.  On the other hand, if the only box running a particular test is
orange, then you should not be checking in.  Just like you should not be
checking in if one of the performance tests is showing an obvious regression.
Or if everything is being orange across the board.  Or if all, say, Mac
tinderboxen are orange while Windows and Linux is green and you're touching
anything other than Windows/Linux-specific code.

Of course the sheriff should close the tree in such cases, imo.  But if sheriff
is #developers, a little bit of self-policing and common sense is in order.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Reopening the trunk: planning

L. David Baron
On Thursday 2006-05-11 17:47 -0500, Boris Zbarsky wrote:

> Mark Banner wrote:
> >I'd just like to point something out - as far as I know there has never
> >been a rule to not allow checking in on orange
>
> Part of the thing with orange is you have to use your discretion a little.  
> If some random box someone added to the tree is orange because it currently
> can't find an X server, that might be a non-issue in terms of checkins if
> everything else is green.  On the other hand, if the only box running a
> particular test is orange, then you should not be checking in.  Just like
> you should not be checking in if one of the performance tests is showing an
> obvious regression. Or if everything is being orange across the board.  Or
> if all, say, Mac tinderboxen are orange while Windows and Linux is green
> and you're touching anything other than Windows/Linux-specific code.
>
> Of course the sheriff should close the tree in such cases, imo.  But if
> sheriff is #developers, a little bit of self-policing and common sense is
> in order.
Probably we should just make the rueles say:

  Do not check in on red or orange.

and then people can ignore the rule if they understand things well
enough to know that a particular orange build is bogus -- just like
people already do for bogus or already-fixed red builds.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

attachment0 (196 bytes) Download Attachment
12