incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <>
Subject Re: binary release artifacts
Date Mon, 16 Sep 2013 08:44:16 GMT
Perhaps, but AFAICT the existing documentation is either incorrect,
lacking, or ambiguous so i've raised LEGAL-178 to clarify.


On Mon, Sep 16, 2013 at 12:56 AM, sebb <> wrote:
> On 15 September 2013 14:16, Tim Williams <> wrote:
>> On Sun, Sep 15, 2013 at 5:19 AM, ant elder <> 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] -
>>> 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 <> wrote:
>>>> Moving this[1] to general@
>>>> On Sat, Sep 14, 2013 at 2:55 AM, ant elder <> wrote:
>>>>> On Saturday, September 14, 2013, Tim Williams <>
>>>>>> Hi Eric,
>>>>>> I've included references inline for your convenience.  I'll once
>>>>>> [strongly] suggest you guys remove that artifact.
>>>>>> Thanks,
>>>>>> --tim
>>>>>> On Fri, Sep 13, 2013 at 6:53 PM, Eric Yang <>
>>>>>>> Hi Tim,
>>>>>>> There is LICENSE.txt and NOTICES.txt in both source and binary
>>>>>  In
>>>>>>> the binary package, the files are located in $PREFIX/share/doc/chukwa
>>>>>>> match what standard Linux file system layout.  We voted for source
>>>>> release
>>>>>>> and there is no Apache restriction that a source release, can
>>>>> 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
>>>>>> "source vote" then no binary should accompany it.
>>>>>>> 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
>>>>> the meta-inf directory.
>>>>> There is also ambiguity around convenience binary releases in the ASF
>>>>> and the historical mailing list discussions around those, so a little
>>>>> flexibility is warranted. I recall there was once a some bugs in the
>>>>> plugin for building jars which meant several projects distributing jar
>>>>> artifacts with missing or completely incorrect license/notice files,
>>>>> 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
>>>>> 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] -
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message