geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <ju...@coredevelopers.net>
Subject Re: -1 on checkin of 368344 was Re: [wadi-dev] Clustering: WADI/Geronimo integrations.
Date Tue, 17 Jan 2006 11:33:54 GMT
Jacek Laskowski wrote:

>2006/1/16, Rodent of Unusual Size <Ken.Coar@golux.com>:
>
>  
>
>>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.
 **********************************/


Mime
View raw message