geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Change to commit model for Apache Geronimo
Date Wed, 24 May 2006 19:47:25 GMT
I didn't see a response to this yet, so here ya go...

On Tue, May 23, 2006 at 04:40:57PM -0700, David Jencks wrote:
> This might be fine for simple uncontroversial patches such as this  
> one, but there's a danger that this won't allow much time for review,  
> especially for complicated changes such as occurred during the  
> configid/1.1 development.  Is there an apache standard minimum wait  
> time or is this something we have to decide for ourselves?  I think  
> it will be hard to balance proceeding with further work with giving  
> adequate review time.

When calling for votes/opinions/consensus, the typical wait time is 72
hours. That is the generally-accepted value for "people in all time zones
have had a chance to see it, potentially working around travel and other
real life issues."

But code patches don't follow that model. See below:

> Personally I'm ok with committing immediately after 3 +1 votes and  
> rolling back if there is a later -1.

This is correct. Note that *your* +1 does not count, per Ken's
instructions. Once you have those other +1 votes, then you can assume
there is support for the change and go ahead and commit it.

Note that a -1 can come in at *any* time. Whether 5 minutes later, 5 days,
5 weeks, or 5 months. Roy would even say 5 years, but I tend to disagree
with that :-)  The point is, that at any time, somebody should be able to
say "woah. that wasn't right, for <these> reasons. we shouldn't ship that
change until we talk about this to figure out the right answer." It may
take a while for somebody to realize the full ramifications of a change,
which is why there is no "statute of limitations" on vetoes.

That said: it is also polite to at least raise a concern before pulling
out the veto card. A veto can be considered rather anti-social, so it is
good to try and avoid them whenever possible. One of the best ways to do
that is to avoid creating the situation in the first place. "hmm. I think
this code might not agree with everybody. let me post the patch to the
list for discussion first."  (of course, in RTC, that is always the case,
so the idea is most important under the CTR model)


Greg Stein,

View raw message