On Tue, Jun 22, 2010 at 10:20 PM, Todd Lipcon <t...@cloudera.com> wrote: >... > Is that wording clear and walk the right line between "you should help test > this release" and "this release may not work great"? >
Its excellent. Ship it. > 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. 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. 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 include src, 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 mvn generate a -src bundle to sit beside the -bin bundle it currently creates. St.Ack
