commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject Re: [lang] Java 6 now
Date Sat, 25 Feb 2012 20:17:06 GMT
On Sat, Feb 25, 2012 at 8:00 AM, Gary Gregory <> wrote:
> On Sat, Feb 25, 2012 at 10:00 AM, James Carman
> <>wrote:
>> Gary,
>> In this case, we're dealing with a veto to a code modification, which
>> is allowed.  Here's the information with respect to code modification
>> vetoes (
>> "A code-modification proposal may be stopped dead in its tracks by a
>> -1 vote by a qualified voter. This constitutes a veto, and it cannot
>> be overruled nor overridden by anyone. Vetos stand until and unless
>> withdrawn by their casters.
>> To prevent vetos from being used capriciously, they must be
>> accompanied by a technical justification showing why the change is bad
>> (opens a security exposure, negatively affects performance, etc. ). A
>> veto without a justification is invalid and has no weight."
>> Since there is a technical justification ("it's not necessary")
>> provided with this veto, it stands until "sebb" withdraws it.
>> That isn't to say that I agree with sebb's assessment, necessarily.  I
>> think we should drop Java 5 like a bad habit.  We already have a bad
>> reputation for living in the past.  We need to be more
>> forward-leaning.  We can always support older versions on older JDKs
>> if necessary (could be a YAGNI situation).  If we do jump JDK
>> versions, I'd say we should jump major version numbers (which others
>> have disagreed with in the past).  To me, version numbers are cheap
>> (look at Firefox!).
> James,
> Thank you for your kind reply and refreshing my memory to our processes.
> At the risk of being pedantic, let me get the details right and on 'paper'
> here so that we can all be on the same page.
> Sebb's -1 was not a veto to a code change but to my opinion that we should
> update our platform requirement to Java 6 from 5, so there is here nothing
> to 'veto'. I guess you could call it a pre-commit-veto to avoid a sequence
> of commitJava6-veto-commitJava5.
> (Now let's say I change the POM to require Java 6 so changes can now be
> Java 6 changes. Is changing the POM a code change that can be vetoed?
> Angles dancing on the head of pin, bleh. Forget I just said that :) Can you
> only veto code? What about other kinds of artifacts like images,
> documentation, and so on. Perhaps our process should be more precise.)
> So:
> Is a VOTE required to change our platform requirement to Java 6 from 5?
> Because subsequence code changes can be vetoed, it seems like the simplest
> thing to do.
> So my key question is: if/when a VOTE is called to change our platform
> requirement to Java 6 from 5, is that vote veto-able or is all that is
> needed is the usual three +1 binding votes?
> As we all know, strictly speaking, a release is not vetoable, all you need
> are three +1s (but there can be -1s to code changes before the release).
> If such a VOTE gets a -1 and the veto's "technical justification" is that
> the change is "unnecessary", then IMO that does not qualify as a "technical
> justification".

Dunno, but I'm not touching Lang 'til we're on Java 6.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message