On Tue, Jun 22, 2010 at 10:20 PM, Todd Lipcon wrote:
...
Is that wording clear and walk the right line between "you should help test
this release" and "this release may not work great"?
...
Is that wording clear and walk the right line between "you should help test
this release" and "this release may not work great"?
OK. I'll continue to do cluster testing and see if I can reproduce this one.
I'd love to fix it before release, but if we have to release with the bug I
think it's worth doing rather than delaying. Agreed? We'll call it out in
known bugs.
I'd love to fix it before release, but if we have to release with the bug I
think it's worth doing rather than delaying. Agreed? We'll call it out in
known bugs.
This is fine by me. We spin crazy for some short period then the
problem "dissolves". We can fix for the next release (my loading goes
on to complete after this spike).
The avro project had this discussion a bit recently, and what basically came
out of it is that Apache releases are source, not binary. It happens that in
the past our releases have had both source and binary in one tar, but it's
important that the actual *release* artifact contain the source.
assembly:assembly adds in a src jar alongside the bin jar.out of it is that Apache releases are source, not binary. It happens that in
the past our releases have had both source and binary in one tar, but it's
important that the actual *release* artifact contain the source.
This allows
people to rebuild from the signed release tarball if they like, etc.
You can't do this w/ our bundle. We can sign the tgz, it'll includesrc, but you can't build it in-situ once you undo the tgz. We could
try make it so you could build in-situ but IIRC, in that avro
discussion was suggested that we might all want to move away from this
style of deliverable?
Since
the mvn assembly tar isn't re-buildable, I think the release artifact has to
be a tarred svn export, and then we have a second release artifact which is
binary+site+docs like you say above. People can choose whether to download
the source release or the binary.
OK. I'd say do the svn export for now. For next time, we'll have mvnbe a tarred svn export, and then we have a second release artifact which is
binary+site+docs like you say above. People can choose whether to download
the source release or the binary.
generate a -src bundle to sit beside the -bin bundle it currently
creates.
St.Ack
