Perhaps, but AFAICT the existing documentation is either incorrect, lacking, or ambiguous so i've raised LEGAL-178 to clarify.
...ant On Mon, Sep 16, 2013 at 12:56 AM, sebb <seb...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
