Moving this[1] to general@ On Sat, Sep 14, 2013 at 2:55 AM, ant elder <ant.el...@gmail.com> wrote: > On Saturday, September 14, 2013, Tim Williams <william...@gmail.com> wrote: >> Hi Eric, >> I've included references inline for your convenience. I'll once again >> [strongly] suggest you guys remove that artifact. >> >> Thanks, >> --tim >> >> On Fri, Sep 13, 2013 at 6:53 PM, Eric Yang <eric...@gmail.com> wrote: >>> Hi Tim, >>> >>> There is LICENSE.txt and NOTICES.txt in both source and binary package. > In >>> the binary package, the files are located in $PREFIX/share/doc/chukwa to >>> match what standard Linux file system layout. We voted for source > release >>> and there is no Apache restriction that a source release, can not > procedure >>> a binary package. >> >> "Votes on whether a package is ready to be released use majority >> approval -- i.e., at least three PMC members must vote affirmatively >> for release, and there must be more positive than negative votes." >> >> Each vote is on signed, hashed artifacts, so yes, if you say it's a >> "source vote" then no binary should accompany it. >> >> http://www.apache.org/dev/release.html#approving-a-release >> >>> There is also no restriction that binary release must >>> have LICENSE.txt and NOTICES.txt in the top level directory. >> >> How do you reach that understanding from the sentence below? >> >> "Every Apache distribution should include a NOTICE file in the top >> directory, along with the standard LICENSE file." >> > > Plenty of other release artifacts from other projects have these files > somewhere other than the top directory, eg most jar releases have them in > the meta-inf directory. > > There is also ambiguity around convenience binary releases in the ASF docs > and the historical mailing list discussions around those, so a little > flexibility is warranted. I recall there was once a some bugs in the maven > plugin for building jars which meant several projects distributing jar > artifacts with missing or completely incorrect license/notice files, and > those artifacts weren't pulled . I also recall on one project where an > artifact was discovered distributed without a release vote and the solution > was just to have a posthumous vote. The important thing here in my opinion > is to get a common understanding of how convenience binary artifacts will > be handled in the future that everyone is happy with.
No offense, but this is ridiculous. If our job as mentors is to help podlings rationalize violations of most basic policies (e.g. release artifacts require a vote, NOTICE/LICENSE files), to play the well-they-got-away-with-it game, then this process is really a joke and we should close up shop. If such basic things as this are really up for debate by seemingly clueful folk, then the incubator isn't serving a useful purpose and should be dissolved as it means we're actively graduating podlings that are somewhere between just not getting it and putting the foundation at risk. (alarmingly, discussion of Chukwa's graduation was recently had!). I dunno, that podlings are defending the idea of releasing unvoted on artifacts only to have their mentor follow suit is frustrating - I really assumed this was as simply case of "oh, we didn't understand that"... Thanks, --tim [1] - http://mail-archives.apache.org/mod_mbox/incubator-chukwa-dev/201309.mbox/browser --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
