chukwa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <>
Subject Re: binary release artifacts
Date Sat, 14 Sep 2013 06:55:08 GMT
On Saturday, September 14, 2013, Tim Williams <> 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 <> wrote:
>> Hi Tim,
>> There is LICENSE.txt and NOTICES.txt in both source and binary package.
>> the binary package, the files are located in $PREFIX/share/doc/chukwa to
>> match what standard Linux file system layout.  We voted for source
>> and there is no Apache restriction that a source release, can not
>> 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message