incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)
Date Thu, 10 May 2018 16:50:06 GMT
In other words, there are several ways to prove that a binary release is WRONG but (to Greg’s
point) there is no way to prove it RIGHT.

As a mentor, I strongly advise against podlings making binary releases, especially for the
first release. It’s difficult enough to get L&N correct for source releases, and when
a binary release is being make at the same time with necessarily different L&N, the PPMC
tend to get hopelessly confused.

Bundling artifacts is very common in the Java world, where shading is a best practice and
is made very easy by maven.

Julian


> On May 10, 2018, at 9:06 AM, sebb <sebbaz@gmail.com> wrote:
> 
> On 10 May 2018 at 16:56, Matt Sicker <boards@gmail.com> wrote:
>> I still minimally require proper gpg signatures on binary artifacts. The
>> source artifacts are what get far more scrutiny, but the binaries are
>> released on apache.org after all.
> 
> +1
> 
> It may also be possible to verify that the binary package works.
> This obviously depends very much on the project.
> 
> In the case of Java code, it's possible to verify that the jars
> contain the expected package names.
> Also that the META-INF directory contains NOTICE and LICENSE files, etc.
> 
>> On 10 May 2018 at 10:20, Roman Shaposhnik <roman@shaposhnik.org> wrote:
>> 
>>> On Thu, May 10, 2018 at 4:17 AM, sebb <sebbaz@gmail.com> wrote:
>>>> On 10 May 2018 at 11:37, Greg Stein <gstein@gmail.com> wrote:
>>>>> On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang <huxing@apache.org>
>>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang <willem.jiang@gmail.com>
>>>>>> wrote:
>>>>>>> Is there any plan for going through the vote process of Binary
file?
>>>>>> 
>>>>>> Yes, binaries will also go through the vote process.
>>>>> 
>>>>> 
>>>>> No. It makes no sense.
>>>>> 
>>>>> There is NO WAY to verify a binary. Even compiling from source to
>>> binary on
>>>>> your machine, and trying to compare against a target binary will
>>> generally
>>>>> fail since timestamps are embedded. Or maybe there are different
>>> compilers
>>>>> being used.
>>>>> 
>>>>> The Foundation *never* votes on binaries, because the Foundation DOES
>>> NOT
>>>>> RELEASE BINARIES. The Foundation only votes/authorizes/releases source
>>>>> code. REPEAT: only source code.
>>>>> 
>>>>> Only source. Which is verifiable. Which has provenance.
>>>> 
>>>> The LICENCE and NOTICE files that accompany the binary artifact are
>>>> text, and IMO should be checked against the contents of the binary
>>>> artifact.
>>>> For example, if the binary bundles jars from other projects, the L&N
>>>> need to agree with the bundled contents.
>>> 
>>> +1000! That has been a well established practice in the Incubator and
>>> as such I see no reason not to keep following it.
>>> 
>>> In addition to that, a reasonable effort should be put into making sure
>>> that the binary bundle doesn't drag in bits with incompatible licenses
>>> (such as GPL). That's why verifying LICENSE in the binary bundle
>>> is NOT a simple exersize of comparing it to the source bundle.
>>> 
>>> Thanks,
>>> Roman.
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>> 
>>> 
>> 
>> 
>> --
>> Matt Sicker <boards@gmail.com>
> 
> ---------------------------------------------------------------------
> 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