On Sat, Feb 25, 2012 at 8:00 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > On Sat, Feb 25, 2012 at 10:00 AM, James Carman > <ja...@carmanconsulting.com>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 (http://www.apache.org/foundation/voting.html#Veto): >> >> "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. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
