Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of tcurdt@gmail.com designates
 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=nYxNhUTNgPFdXxXLpoBvyVnlSkllyMwJI9frN6Mc/dO+1rQJR+i5ppWfwCd+jadp8KvZRn+i4s4JtjXHchyFyFE70iV8ARghrBVG+Nd3croYHaP7OyoYkiHlNCX/r5jjT3+Kfr4Jk2aPpbXHut+v5LRHfHjr5Abt02BJYAKaZx0=
Message-ID: <98e4f1cd0608160016w387a07b0ue78e491081598e7c@mail.gmail.com>
Date: Wed, 16 Aug 2006 17:16:26 +1000
From: "Torsten Curdt" <tcurdt@apache.org>
Sender: tcurdt@gmail.com
To: dev@cocoon.apache.org
Subject: Re: Re: [Vote] Java 5 as minimum JDK requirement
In-Reply-To: <44E2BE04.9000405@dslextreme.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44E0DAD0.6070509@nada.kth.se>
	 <BAY104-F2188C8E0A7CC3974DE7EF2AD4F0@phx.gbl>
	 <cc159a4a0608150650t13d30912x174856048c43d26c@mail.gmail.com>
	 <44E1DF1D.80709@dslextreme.com>
	 <cc159a4a0608150843r56cf80fbtd463eea48921e180@mail.gmail.com>
	 <44E2BE04.9000405@dslextreme.com>

> > If one does not view a veto as valid then one has to challenge it.  To
> > do otherwise would not be taking your position as a committer
> > seriously.
> His veto was challenged.  A reason was stated.  Now if the reason for
> the veto was "the moon is not in alignment with the stars" it would be
> reasonable to state that the reason isn't valid.  But the reason given
> was nothing of the kind.  That doesn't mean you can't try to convince
> him to change his mind using the two paragraphs that followed.  But the
> implication of the statement is that you don't recognize his -1 as being
> valid, when in fact it is.  You simply don't agree with it.

I think you are simplifying this situation a bit...

Let's say I am working for company "A". Company "A" has a policy to only
use reaaaaally stable and proven software. "Don't change if you don't
have to". Basically they are still using JDK 1.3. I am a PMC member of
an OS project the company is using. Now is the non-upgrade policy of
that company "A" a valid reason for the individual PMC member to veto
the upgrade of the JDK requirement for the OS project?

...now I am curious

cheers
--
Torsten