www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: Clarification on the release requirements
Date Wed, 29 Apr 2009 00:15:57 GMT

----- Original Message ----

> From: Ralph Goers <ralph.goers@dslextreme.com>
> To: legal-discuss@apache.org
> Sent: Tuesday, April 28, 2009 8:07:53 PM
> Subject: Re: Clarification on the release requirements
> 
> 
> On Apr 28, 2009, at 4:43 PM, Roy T. Fielding wrote:
> 
> > On Apr 28, 2009, at 4:21 PM, Brian Fox wrote:
> >>> 
> >>> 
> >> This level of detail is definately not on the site that I've been able to 
> find.
> > 
> > It has been described many times, documented many times, and
> > periodically watered down by folks who don't know what they
> > are doing.
> 
> You never cease to make me laugh!
> > 
> > 
> >> The current example release process validates certain conditions and then 
> makes a tag. That tag is then checked out and in the same motion, the binaries 
> are produced and the source tar'd up and everything signed. All of these things, 
> the source archives and binaries are then validated and voted upon.
> >> 
> >> The end result is the same, the source archives contain the same code that 
> produced the binaries, which is in agreement with the documented policy on the 
> site:
> >> 
> >> "In all such cases, the binary/bytecode package must have the same version 
> number as the source release and may only add binary/bytecode files that are the 
> result of compiling that version of the source code release."
> >> 
> >> It seems like semantics that source must be tared, signed, untared and then

> rebuilt if it's all being done in the same action. Do we agree or disagree?
> > 
> > No, it is not semantics.  You assume that everything was tar'd correctly
> > and completely, which is not a valid assumption.  Also, voting on binary
> > artifacts is inherently stupid because their quality cannot be verified.
> > That's why we specifically tell people not to vote on binaries, because
> > it just weakens the meaning of voting.
> 
> While I absolutely agree with this process, without board approved documentation 
> it gets left up to each PMC to determine this. I'm sure Brian's goal is to 
> understand the recommendation and then modify the appropriate Maven components 
> so that this process can be followed.  Is there no way to get this posted on the 
> site so that it is crystal clear and won't get changed unless the membership 
> expresses a desire to change it?

Policy documents like this one are delegated to infrastucture, which is supposed
to be overseeing all commits to the /dev section of the website.


      

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message