www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Fox <bri...@infinity.nu>
Subject Re: Clarification on the release requirements
Date Thu, 30 Apr 2009 17:17:10 GMT


Joe Schaefer wrote:
> ----- Original Message ----
>
>   
>> From: David Jencks <david_jencks@yahoo.com>
>> To: legal-discuss@apache.org
>> Sent: Thursday, April 30, 2009 12:54:10 PM
>> Subject: Re: Clarification on the release requirements
>>
>>
>> On Apr 30, 2009, at 9:18 AM, John Casey wrote:
>>
>>     
>>> On Thu, Apr 30, 2009 at 9:50 AM, sebb wrote:
>>>       
>>>> Even ignoring SVN deletions, an SVN tag+revision is still not
>>>> constant, as different OSes represent EOLs in different ways. These
>>>> differences can (and do) have an effect on the build output.
>>>>
>>>>         
>>> If this is true, then simply checking out the sources on one machine
>>> and archiving them may mean that the sources will produce different
>>> (flawed?) results when unpacked and built on another machine. So in
>>> the case you mention, the signed source archive is no guarantee that
>>> the build would be reproducible. With a verified tag in SCM, at least
>>> we know that we have the opportunity to research the history on any
>>> particular piece of code, in the event we did uncover a flaw in the
>>> release after the fact. This isn't just theoretical, either; I use
>>> this history, along with the debug information in the binaries we
>>> produce, to trace through Maven all the time in search of bugs.
>>> Without a definite, direct link between SCM and binaries, this would
>>> be a _lot_ less dependable.
>>>       
>> I completely agree.
>>
>> To go out on a limb...
>>
>> I wasn't aware until the last couple of days that the C based projects don't 
>> produce a copy of what's in svn as their source archive.  I've been thinking 
>> about this situation and can't see any fundamental difference between a C 
>> project including a generated configure script (not from svn) and a java project

>> converting all the java source to jasmin (basically "java assembly language") 
>> and releasing that instead of the java files.  In both situations the resulting 
>> archive includes stuff derived from svn that can be used to build working 
>> binaries.  While I don't think anyone would call a bunch of jasmin files a 
>> "source release" I don't see how something with a generated script can be 
>> either.
>>     
>
> Yeah, that's a fairly rediculous stretch IMO.  Having build *scripts* that are
> Apache-release-compatible but generated by other non-Apache open-source projects,
> and dorking with the Apache project's actual source code, are two entirely
> different things.  Yes, I've personally witnessed release duds being created by
> an RM who used outdated auto-tools, but going the extra mile and having the RM actually
> check-in all the generated files that are included in the releasable tarball is a
> fairly pointless exercise IMO.  The *tarball* is the signed, authoritative object,
> not the tag.  If the tarball wasn't generated by the RM from a tag using a
> well-documented and repeatable process, something's wrong with the project's
> release documentation.
>   

It may be a ridiculous stretch, but the point I get from it is that each 
build has slightly different requirements for what should and shouldn't 
be required to be released. We should leave it up to the PMCs to decide 
based on some underlying fundamental rules. Noone disagrees here that a 
source archive is desirable and required. Clearly there is a 
disagreement about the exact steps required to produce this archive, AND 
if a tag should exist and what it should contain. I don't think those 
will ever be solved by a universal set of rules.
> FWIW you don't have these issues in scripting languages like Perl, since the 
> language provides its own support for building and testing the software.  There
> you can just tar up an svn export and put it to a vote.
>
>
>   
And?
>       
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>   

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


Mime
View raw message