incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: binary release artifacts
Date Sun, 15 Sep 2013 13:16:16 GMT
On Sun, Sep 15, 2013 at 5:19 AM, ant elder <ant.elder@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.

--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 <williamstw@gmail.com> wrote:
>> Moving this[1] to general@
>>
>> On Sat, Sep 14, 2013 at 2:55 AM, ant elder <ant.elder@gmail.com> wrote:
>>> On Saturday, September 14, 2013, Tim Williams <williamstw@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 <eric818@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message