incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: binary release artifacts
Date Sun, 15 Sep 2013 23:56:43 GMT
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 again
>>>>> [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 package.
>>>>  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 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.
>>>>>> 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] -
>>> ---------------------------------------------------------------------
>>> 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