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 <andru..bjectstyle.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 <andru..bjectstyle.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
>>
>>
>
This archive was generated by hypermail 2.0.0 : Mon Aug 16 2010 - 18:43:48 UTC