incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: Convenience Binary Policy
Date Wed, 22 Oct 2014 07:01:55 GMT
Thanks for the clarification!

I’m still not sure I understand. In plain English we seem to have these unresolved questions:

1) (Re)compiling convenience packages with modifications to binary dependencies after the
release vote: Is that kosher or not?
2) If a binary dependency is added to a convenience package (instead of being downloaded at
install time) which results in the need to modify the LICENSE / NOTICE file that’s accompanying
the convenience package, does that require a new VOTE and release or not?
3) In our case, the binary dependency is JBurg which is used as part of the compiler process
on the client’s machine. It’s not byte code that is compiled into the resultant binary.
The literal interpretation of the text would lean towards saying that’s a no-no. I find
it hard to believe that that’s the intent. Is there any way to better clarify this point?

Justin, please correct me if I missed any points or misrepresented any of them.

Thanks,
Harbs

On Oct 21, 2014, at 9:35 PM, Marvin Humphrey <marvin@rectangular.com> wrote:

> On Tue, Oct 21, 2014 at 6:55 AM, Harbs <harbs.lists@gmail.com> wrote:
>> The one thing I see missing from the proposed text is dependencies and
>> installers.
>> 
>> Particularly this section:
>> 
>>  ### Compiled packages ### {#compiled-packages}
>> 
>>  The Apache Software Foundation produces open source software. All releases
>>  are in the form of the source materials needed to make changes to the
>>  software being released.
>> 
>>  As a convenience to users that might not have the appropriate tools to
>>  build a compiled version of the source, binary/bytecode packages MAY be
>>  distributed alongside official Apache releases.  In all such cases, the
>>  binary/bytecode package MUST have the same version number as the source
>>  release and MUST only add binary/bytecode files that are the result of
>>  compiling that version of the source code release.
>> 
>> ---
>> 
>> How do binary dependencies fit in?
> 
> Thanks for the review!
> 
> The sentence in question is taken nearly verbatim from the existing release
> policy document.  The only changes are capitalizing "MUST" and swapping out
> "may only" for "MUST ONLY":
> 
>    http://www.apache.org/dev/release#what
> 
>    In all such cases, the binary/bytecode package must have the same version
>    number as the source release and may only add binary/bytecode files that
>    are the result of compiling that version of the source code release.
> 
> This is in keeping with the goal of the initiative: "to clarify policy,
> NOT TO CHANGE IT."
> 
> My interpretation of that passage is that a liberal view of the word
> "compiling" allows the bundling of binary dependencies.  Sometimes "compiling"
> is taken to mean a compilation/translation phase which is distinct from
> linking, and other times "compiling" encompasses linking (either static or
> dynamic).  The more expansive definition is consistent with how that
> policy has traditionally been applied.
> 
> Marvin Humphrey
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org


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