fixing for both 3.0 and 3.1 is the same amount of work as just fixing
it for 3.1...
2.0... I hope we won't be having any more releases of that (and that's
Ant based!!)
Andrus
On Aug 16, 2010, at 10:14 PM, Mike Kienenberger wrote:
So what do we need to do?
Fix it for this point release? Make an exception for old point
releases, and only fix it for 3.1?
Fix our latest point releases for each currently maintained branch?
My opinion is that we should fix all of the latest point releases, but
I personally won't be able to do the work -- as I mentioned a couple
months back, I'm in the middle of a go-live deployment of a three-year
project for the next month or two, and I'm maven-ignorant.
Second best would be to fix the 3.x branches.
Third best would be to fix only 3.1.
On Mon, Aug 16, 2010 at 3:04 PM, Andrus Adamchik <and...@objectstyle.org
> wrote:
So again, I am convinced by your argument and the history trail of
reasoning
behind it. Just feels that the solution that we might use (and that
others
are using) and the desired ideal are pretty far apart from each
other.
Andrus
On Aug 16, 2010, at 9:43 PM, Andrus Adamchik wrote:
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 <and...@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 <and...@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
