geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: [RTC] Vote on GERONIMO-2161 - restart 1
Date Fri, 07 Jul 2006 13:13:07 GMT

On Jul 7, 2006, at 8:40 AM, Jeff Genender wrote:

> Hey Jacek,
> BTW, I apologize about the blessing of the final 3 +1s within the 18
> hours period.  I did not mean to go against your statement.  I just
> recalled an email about 3 +1s allowed it to happen and there was no  
> need
> to wait...that a -1 could be waged at anytime in the future.  If I
> stepped over the line here, then my complete apologies.  I think I may
> be trying to feel my way through this as well...and I may bump into a
> wall every now and then.

I'd rather not troll back through the postings, but I certainly  
recall that the same guidelines -- there wasn't a minimum time period  
for an RTC vote. Once you have 3 +1's you would be able to commit and  
there can still be a -1 at any time (hopefully with some statute of  
limitation) that will force the commit to be reverted. I think this  
process works. I'd also expect that a -1 would be preceded by a  
healthy discussion berore the -1...


> Jeff
> Jacek Laskowski wrote:
>> On 7/7/06, Jason Dillon <> wrote:
>>> This is applied.
>>> :-)
>>> Took longer than expected because I happened to switch to a terminal
>>> that was set to use JDK 1.5 and I did not realize it... until a few
>>> hours later after I was pulling my hair out wondering why the patch
>>> god hates me so much.
>> It's because it needs a solution as I think you won't be alone in  
>> your
>> pain of applying patches/changes that are incompatible with the unix
>> patch command.
>> I think it would be much better if the person who makes a change is
>> not the one who commits it to trunk, but the last PMCer who voted for
>> it. And a branch the change is built from is established. The  
>> solution
>> has such a good effect that the person who works on changes don't  
>> have
>> to worry about the commit date until it's rejected when (s)he or
>> anyone else will fix it and a vote starts over (with 24-hour time
>> period). Another good effect is that knowing the revisions a change
>> that's being voted, one can continue his/her work without worrying
>> about disrupting the vote process as the revisions are still in the
>> branch. Phew, I do like the idea! ;-)
>> WDYT?
>>> --jason
>> Jacek

View raw message