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) Cheers, -g -- Greg Stein, http://www.lyra.org/
