On 15 September 2013 14:16, Tim Williams <william...@gmail.com> wrote: > On Sun, Sep 15, 2013 at 5:19 AM, ant elder <ant.el...@gmail.com> wrote: >> 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. > > My mail on their list wasn't intended to be 'demanding' or rude - my > apologies if it came across that way. I honestly went in thinking it > was a mistake - a simple misunderstanding. > >> 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. > > I agree, Eric was prompt and polite. I "escalated" this for two reasons: > > 1) It became apparent that it wasn't a misunderstanding - it's a > question of policy and it doesn't seem fair to hash that out on their > dev list. It wasn't so much "escalation" as taking policy discussions > to the right audience - if there were a mentor@ list, I would have > aimed there. > > 2) This PMC has a release artifact published that was never voted > upon. That was news to me and, I felt, worthy of sunlight - > especially after the [prompt/polite] defensive reaction received. > > Sorry for the negativity, it was borne of frustration. It's > frustrating to ask podlings to work hard dotting I's and crossing T's > only to look around and see other podling's lackadaisical approach. > >> 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 guess I viewed that as a frustrating rationalization. Their distro > is a standard tarball - where those files are well expected to be in > the standard place by both policy and social norm - not some other > artifact type where an difference is obvious. Anyway, moving it here > was less about that and more about the fact that they released an > artifact without voting. > > Though, since you bring it up I'd appreciate that if there's going to > be no accountability for podlings to locate those source files in the > right place[1], then yeah, I think we should change the policy to > state that anywhere in the artifact is acceptable.
I think the only proper places are at the top level for tarballs with the option of the META-INF directory for jars. > --tim > > [1] - http://apache.org/legal/src-headers.html#notice > >> 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 >> > > --------------------------------------------------------------------- > 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
