Jacek Laskowski wrote:
2006/1/16, Rodent of Unusual Size <[EMAIL PROTECTED]>:
Under CTR, any change can get committed at any time, although
major ones are supposed to follow the RTC model. Committers
need to ask themselves whether the commit will spark controversy;
if so, they should follow RTC and get support first.
...
The advantage of CTR is prototyping speed. Its disadvantages
are less-assured quality and community divisiveness. Its
enemy is ego. Since criticism occurs after code has been
committed, personal investment is greater and defensiveness
higher. Developers are typically less aware of each others'
work.
I believe it is safe to say that Geronimo has been operating
in CTR mode, but I think the specifics and ground rules may
not have been spelt out, or need to be again. Is this the
way in which the majority wants to continue to proceed?
Hi Ken,
Am I reading it correctly that in CTR when a committer vetoed a
commit, it *ought to* be backed out *as soon as it's happened* and
discussed afterwards before being committed again?
I think we're operating this way and dispate the recent issue it works well.
Jacek,
I think that this strategy is in place for seriously disasterous
checkins. If after backing out someone else's change, you can clearly
demonstrate that it introduced a show-stopping bug and that your only
reasonable option was to back it out immediately, before it prevented
everyone else from getting on with their work, then I think you would be
justified.
If on the other hand, after the event, it is clear that the change was
to a rarely used area of the code, that would only impact the developers
working directly upon it, that it did not introduce any show-stopper and
that, when invited to, you failed to demonstrate that the change broke
anything, then I think you would have a very hard time justifying your
actions. In this case, I think the sensible course of action is to
explain to the owner of the code, what your issues with it are, discuss
them in an open forum with your peers, reach consensus and then make
further changes on top of the original to take you to the place where
you have all decided to go.
So, I don't think it is so much whether you adhere to a particular
methodology, but that you apply it sensibly.
Jules
#ken P-)}
--
Jacek Laskowski
http://www.laskowski.org.pl
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
