incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <ant.el...@gmail.com>
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.

   ...ant

On Mon, Sep 16, 2013 at 12:56 AM, sebb <sebbaz@gmail.com> wrote:
> On 15 September 2013 14:16, Tim Williams <williamstw@gmail.com> wrote:
>> 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.
>
> 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 <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
>>
>
> ---------------------------------------------------------------------
> 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