On Sep 6, 2007, at 1:22 PM, Remy Maucherat wrote:
Most of the comments were that it was too annoying to do for casual
bugfixing, and it's true it's not justified for all patches. Maybe
a finer rule could be devised, something like using a RtisTC (tis =
the important stuff) model.
To give an idea, "tis" could mean:
- API changing patches (any protected or above signature change)
- code changes in the critical path (for example, code which gets
executed on each HTTP request)
- any other commit for which a committer asks for the RTC procedure
should be rollbacked if it hinders concurrent work, and go through
the RTC procedure
Jean-Frédéric didn't like it much though, and it's true that people
need to play fair for it to work.
If people felt that people were "playing fair" then the whole
above business wouldn't be needed.
The whole voting thing was developed to basically force coop work
when it would fail on its own. TC is hardly unique in having these
sort of head-butting problems. And in all cases that I know
of, the current voting rules were sufficient to handle it.
Yeah, RTC is annoying for casual bugfixing, but, IMO, that's the
breaks when people can't come to a consensus.
I'm guessing mostly everyone knows about:
http://www.apache.org/foundation/voting.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
