www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <ndbe...@apache.org>
Subject Re: Clarification on the release requirements
Date Wed, 29 Apr 2009 00:54:09 GMT
On Tue, Apr 28, 2009 at 7:26 PM, David Jencks <david_jencks@yahoo.com> wrote:
>
> On Apr 28, 2009, at 4:43 PM, Roy T. Fielding wrote:
>
>> On Apr 28, 2009, at 4:21 PM, Brian Fox wrote:
>>>
>>> Roy T. Fielding wrote:
>>>>
>>>> On Apr 28, 2009, at 1:45 PM, Brian Fox wrote:
>>>>>
>>>>> I'm attempting to get answer to existing legal question marks. Like
>>>>> David Jenks said:
>>>>> "
>>>>> In my opinion this is unnecessary and the source jars produced by maven
>>>>> for instance by the release profile in the proposed apache pom v 6 are
>>>>> adequate.  I'd like this principle to be clearly established and stated
or
>>>>> clearly refuted."
>>>>>
>>>>> Can we start there?
>>>>
>>>> <snip>
>>>> If you can do that with Maven, great.  If you can't, then you can't
>>>> call a Maven build a release -- it is just another form of binary
>>>> packaging that cannot be distributed until after the release is
>>>> cut and approved in source form.  Binary packages MUST be built from
>>>> the SIGNED and RELEASED source package, NOT FROM SUBVERSION TAGS.
>>>>
>>> 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.
>
> Could be.  I am not aware of any projects anywhere, at apache or elsewhere,
> that follow this to release anything.  (I only know about java projects).
>  Without exception every project I know about builds the "source" release
> artifact at the same time as the binary artifacts.  Are there any java
> projects here at apache that follow the procedure Roy describes?
>
>>
>>
>>> 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.
>
> Well, I could argue that you can't tell the quality of source code without
> compiling it and seeing if it works by testing.  Quality can mean many
> things.
>
> Anyway... lets assume the process you describe is both apache policy and
> desirable.   Clearly all the ant scripts and maven release profiles I've
> seen don't follow the policy.  Let's try to think of some maven proecesses
> that would.  I'm going to assume that any release process for java software
> needs to produce both source and binary artifacts that can be voted on at
> once, since I'm pretty sure not voting on binary artifacts would be rejected
> as impractical by most or all java projects.

I disagree with this generalization. The Java projects I've
participated in vote on source, not binary artifacts. However, I must
admit that votes tend to be based on a particular revision in
Subversion, rather than a source archive.

-Nathan

>
> 1.  release process creates a scm tag, svn exports out the entire project at
> once (including possibly hundreds of maven projects), archives the whole
> thing, unpacks the archive, and performs the existing (e.g. maven) build.
>
> 2. release process creates an scm tag, checks it out, and builds source jars
> for each maven module that include all the java source, other main
> resources, and a (possibly modified to avoid trying to run tests) pom that
> will build the jar from the included source.  These source jars are unpacked
> one by one to build the binary artifacts.  No overall archive of the entire
> tag is needed.  In particular no test code is included.
>
> Irrespective of how practical or advisable these processes are, is there any
> doubt they follow the policy Roy enunciated?
>
> thanks
> david jencks
>
>>
>>
>> ....Roy
>>
>> ---------------------------------------------------------------------
>> 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
>
>

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


Mime
View raw message