cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: [VOTE] release 3.0.1
Date Mon, 16 Aug 2010 18:43:14 GMT
Yeah I vaguely remember this discussion - http://markmail.org/thread/njray5dbazwcdcts 
  and I have to agree with Roy's logic, which convinces me better than  
a mention of "policy" :-)

Ok, so say we have a Maven build system that exports buildable source  
with poms... which, considering the reliance on a public Maven repo  
for dependencies may not be that "buildable" 6 months from now :-/  
Even open-source Apache-licensed (but not ASF-managed) packages may  
disappear. How far can we go with that? (a good experiment would be to  
take a year old existing ASF package and trying to build it, say  
Geronimo or something of that level of complexity..)

Andrus


On Aug 16, 2010, at 9:28 PM, Mike Kienenberger wrote:
> It's one thing to state that it may not be a requirement to provide
> buildable source, but it's quite a stretch to claim that we do provide
> buildable source immediately after a message stating "It is
> practically impossible to do that as the build system is ... well,
> complex"  Taken to extremes, you could say that a jar file full of
> classes is buildable source, since, with the right tools, you can
> decompile the class files back to java code.
>
> But if you want to say that we're meeting the source build
> requirement, consider this. It would mean that everyone voting +1 on a
> release has somehow thrown a home-grown build-system on top of the
> source release and successfully built it.   Because that's the only
> way an evaluator can be sure that the release has met the condition
> and the release manager hasn't accidentally left out some required
> piece of source.   We wouldn't say that we know that the release has a
> valid checksum without checking it ourselves or that the release has a
> valid signature without checking it ourselves.   Same goes for
> building it.
>
>
> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik <andrus@objectstyle.org 
> > wrote:
>>
>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
>>
>>> Every ASF release must contain a source package, which must be
>>> sufficient for a user to build and test the release provided they  
>>> have
>>> access to the appropriate platform and tools. The source package  
>>> must
>>> be cryptographically signed by the Release Manager with a detached
>>> signature; and that package together with its signature must be  
>>> tested
>>> prior to voting +1 for release. Folks who vote +1 for release may
>>> offer their own cryptographic signature to be concatenated with the
>>> detached signature file (at the Release Manager's discretion)  
>>> prior to
>>> release.
>>
>> Actually, re-reading the above and it doesn't state a need of a  
>> working
>> pom.xml or build.xml, just the source that is matching the  
>> binaries. In this
>> respect we don't violate this. We do not provide a buildfile, but a  
>> Java
>> developer will be able to build the source regardless (e.g. by  
>> writing
>> build.xml himself, or importing sources in Eclipse).
>>
>> Andrus
>>
>>
>
>
>
> On Mon, Aug 16, 2010 at 2:08 PM, Andrus Adamchik <andrus@objectstyle.org 
> > wrote:
>>
>> On Aug 16, 2010, at 6:32 PM, Mike Kienenberger wrote:
>>
>>> Every ASF release must contain a source package, which must be
>>> sufficient for a user to build and test the release provided they  
>>> have
>>> access to the appropriate platform and tools. The source package  
>>> must
>>> be cryptographically signed by the Release Manager with a detached
>>> signature; and that package together with its signature must be  
>>> tested
>>> prior to voting +1 for release. Folks who vote +1 for release may
>>> offer their own cryptographic signature to be concatenated with the
>>> detached signature file (at the Release Manager's discretion)  
>>> prior to
>>> release.
>>
>> Actually, re-reading the above and it doesn't state a need of a  
>> working
>> pom.xml or build.xml, just the source that is matching the  
>> binaries. In this
>> respect we don't violate this. We do not provide a buildfile, but a  
>> Java
>> developer will be able to build the source regardless (e.g. by  
>> writing
>> build.xml himself, or importing sources in Eclipse).
>>
>> Andrus
>>
>>
>


Mime
View raw message