Tim, one of the things we're trying to teach podlings is how to handle disputes and resolve problems in a happy respectful manner. You've out of the blue come on to their dev list without introducing yourself demanding that something that happened nearly two years ago be undone. Its a testament to Chukwa that they've engaged in discussing the matter with you promptly and politely, never the less in under 48 hours of starting the discussion you've escalated this to general@ with a fairly negative email.
Lets take your LICENSE/NOTICE file issue, you initially said the binary artifact didn't have any, it was then pointed out that in fact it did have them just not where you were looking, you then asserted that is not acceptable and they must only be right at the top directory, it was then pointed out other types of binary distributions like jars also don't have them at the top either, but you have ignored that and instead come here to general@. I have no doubt that Chukwa will be happy to help resolve this in whatever way is necessary to satisfy all the ASF policy's, but we don't need a big general@ flame thread to do that. ...ant On Sun, Sep 15, 2013 at 3:46 AM, Tim Williams <william...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
