Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Greg Stein]

On Thu, May 10, 2018 at 3:25 PM, Roman Shaposhnik 
wrote:

> On Thu, May 10, 2018 at 9:50 AM, Julian Hyde  wrote:
> > 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.
>
> That's actually a great way to put it.
>

Yeah, it really is. Props to Julian!

Cheers,
-g

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Justin Mclean]

Hi,

Looking at the release candidate just made both the license and notice for the 
source release and the connivance binary are going to be just about identical 
as there's only 2 3rd party jars included and none of the other jars contain 
3rd party code (other than what is mentioned in LICENSE), both the 3rd party 
jars are apache licensed so it’s optional if they are mention in LICENSE. Nice 
if they are but not essential. [1] Neither have NOTICE files so there no effect 
on the Apache Dubbo’s NOTICE.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#alv2-dep
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Justin Mclean]

Hi,

>> 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.
> 
> Big +1 here. This is exactly what I advise my podlings as well.

Which was the advice given here but as most of their users use the binary not 
the source it was decided to do both.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Justin Mclean]

Hi,

> 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.

As per ASF policy a connivance binary can be release as the same time [1] and 
it needs to comply with license and notice policy [2].

It usually very easy to check a binary (and I’ve done it 100’s of time) by 
uncompress the jar or just editing it directly to see what is bundled inside it.

Thanks,
Justin

1. http://www.apache.org/legal/release-policy.html#compiled-packages
2. http://www.apache.org/dev/licensing-howto.html#binary
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Daffodil (incubating) 2.1.0-rc3

[Dave Fisher]

Hi -

+1 (binding) with a couple of areas for improvement.

Source - hashes and signatures are good.

I’m finally reviewing this release and in looking at the NOTICE and LICENSE 
there are many copyrights/required notices that are in the LICENSE instead of 
the NOTICE. Breaking these apart properly is difficult, but needs to be done 
before your next release.

RAT Check:
  ./daffodil-lib/src/main/scala/org/apache/daffodil/util/UniquenessCache.scala
  ./daffodil-lib/src/main/scala/passera/numerics/package.scala
  ./daffodil-lib/src/main/scala/passera/unsigned/package.scala
  ./daffodil-lib/src/main/scala/passera/unsigned/SmallUInt.scala
  ./daffodil-lib/src/main/scala/passera/unsigned/UByte.scala
  ./daffodil-lib/src/main/scala/passera/unsigned/UInt.scala
  ./daffodil-lib/src/main/scala/passera/unsigned/ULong.scala
  ./daffodil-lib/src/main/scala/passera/unsigned/Unsigned.scala
  ./daffodil-lib/src/main/scala/passera/unsigned/UShort.scala
I recognize that all of these have headers that have been copied to the LICENSE.

Binaries - hashes and signatures are good.
LICENSE and NOTICE are more correct in the Binaries than the Source.
Tgz and Zip unpack identical project jars, but for the NPM they are the same 
size but diff reports they are not identical. I’m going to think of this as an 
artifact of how I unpacked rpm2cpio | cpio

TO DO:
(1) Fix Source NOTICE and LICENSE
(2) Handle the 2 test files.
(3) Improve Rat Check. Probably by including sbt-rat in project with 
addSbtPlugin("org.musigma" % "sbt-rat" % "0.5.1”) and updating .rat-excludes.

Regards,
Dave

> On May 10, 2018, at 11:39 AM, John D. Ament  wrote:
> 
> Justin/Steve,
> 
> Apologies as its very confusing looking at this email thread trying to 
> understand what the current state of the vote is.
> 
> From what I understand:
> 
> - Two files were included in the release that are Cat-X
> - These were supposed to be relicensed, but doesn't sound like that happened
> 
> Or was it corrected that these two files are UoI NCSA licensed?  If these 
> files are Cat-X I would also vote a -1 since we cannot release with clear 
> Cat-X contents (we can release with Cat-X dependencies, but the contents 
> can't be Cat-X).
> 
> Thanks,
> 
> John
> 
> On 2018/04/30 11:52:22, Steve Lawrence  wrote:
>> Hi all,
>> 
>> We are still need at least one more +1. We'd really appreciate if if you
>> could take a look.
>> 
>> Thanks,
>> - Steve
>> 
>> On 04/09/2018 07:24 PM, Steve Lawrence wrote:
>>> The Apache Daffodil community has voted and approved the proposed
>>> release of Apache Daffodil (incubating) 2.1.0-rc3.
>>> 
>>> We now kindly request the Incubator PMC members review and vote on this
>>> incubator release.
>>> 
>>> Daffodil is an open source implementation of the DFDL specification that
>>> uses DFDL schemas to parse fixed format data into an infoset, which is
>>> most commonly represented as either XML or JSON. This allows the use of
>>> well-established XML or JSON technologies and libraries to consume,
>>> inspect, and manipulate fixed format data in existing solutions.
>>> Daffodil is also capable of the reverse by serializing or "unparsing" an
>>> XML or JSON infoset back to the original data format.
>>> 
>>> Vote thread:
>>> https://lists.apache.org/thread.html/10811e8f520bf100a9250a3ae0610633e9018e0ae8fc422e2c0f097a@%3Cdev.daffodil.apache.org%3E
>>> 
>>> Result thread:
>>> https://lists.apache.org/thread.html/54a3e681b25f084e0dc46e19764cd19507ff502b927516093a3bd667@%3Cdev.daffodil.apache.org%3E
>>> 
>>> All distribution packages, including signatures, digests, etc. can be
>>> found at:
>>> 
>>> https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.1.0-rc3/
>>> 
>>> Staging artifacts can be found at:
>>> 
>>> https://repository.apache.org/content/repositories/orgapachedaffodil-1002/
>>> 
>>> This release has been signed with PGP key 033AE661, corresponding to
>>> slawre...@apache.org, which is included in the repository's KEYS file.
>>> This key can be found on keyservers, such as:
>>> 
>>> http://pgp.mit.edu/pks/lookup?op=get&search=0x033AE661
>>> 
>>> It is also listed here:
>>> 
>>> https://people.apache.org/keys/committer/slawrence.asc
>>> 
>>> The release candidate has been tagged in git with v2.1.0-rc3.
>>> 
>>> For reference, here is a list of all closed JIRAs tagged with 2.1.0:
>>> 
>>> https://issues.apache.org/jira/browse/DAFFODIL-1897?jql=project%20%3D%20DAFFODIL%20AND%20fixVersion%20%3D%202.1.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>>> 
>>> For a summary of the changes in this release, see:
>>> 
>>> https://daffodil.apache.org/releases/2.1.0/
>>> 
>>> Please review and vote. The vote will be open for at least 72 hours.
>>> 
>>> [ ] +1 approve
>>> [ ] +0 no opinion
>>> [ ] -1 disapprove (and reason why)
>>> 
>>> Thanks,
>>> - Steve
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: genera

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Roman Shaposhnik]

On Thu, May 10, 2018 at 9:50 AM, Julian Hyde  wrote:
> 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.

That's actually a great way to put it.

> 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.

Big +1 here. This is exactly what I advise my podlings as well.

Thanks,
Roman.

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

Re: [VOTE] Apache Crail 1.0-incubating (RC2)

[John D . Ament]

Ok, now I see the difference between them.  Whew.

The Crail PPMC is going to rename Crail's release from 1.0-rc2 to 1.0 I would 
assume.  However, when users extract the files, even if they fix it the way 
you're describing you'll end up with a -rc2 in the path.

John

On 2018/05/10 19:56:11, Julian Hyde  wrote: 
> I’m talking about directories inside the .tar.gz too.
> 
> Currently there is a leading directory. This is good:
> 
> $ tar tvfz apache-crail-1.0-rc2-incubating-source.tar.gz |head -3
> drwxr-xr-x  0 jpfjpf 0 Apr 23 04:32 incubator-crail/
> drwxr-xr-x  0 jpfjpf 0 Apr 23 04:32 incubator-crail/client/
> -rw-r--r--  0 jpfjpf  2625 Apr 23 04:32 incubator-crail/client/pom.xml
> 
> No leading directory would be bad (in my opinion):
> 
> $ tar tvfz apache-crail-1.0-rc2-incubating-source.tar.gz |head -2
> drwxr-xr-x  0 jpfjpf 0 Apr 23 04:32 client/
> -rw-r--r--  0 jpfjpf  2625 Apr 23 04:32 client/pom.xml
> 
> A leading directory named after the release would be better:
> 
> $ tar tvfz apache-crail-1.0-rc2-incubating-source.tar.gz |head -3
> drwxr-xr-x  0 jpfjpf 0 Apr 23 04:32 
> apache-crail-1.0-incubating-src/
> drwxr-xr-x  0 jpfjpf 0 Apr 23 04:32 
> apache-crail-1.0-incubating-src/client/
> -rw-r--r--  0 jpfjpf  2625 Apr 23 04:32 
> apache-crail-1.0-incubating-src/client/pom.xml
> 
> Julian
> 
> > On May 10, 2018, at 12:46 PM, John D. Ament  wrote:
> > 
> > BTW, I just re-read your reply.
> > 
> > I'm not talking about the root of the calcite dist area, it's pretty common 
> > that projects create a /dist/dev/incubator//version# folder.  I'm 
> > talking about the actual inside of the tar/zip file having an extra 
> > directory.
> > 
> > John
> > 
> > On 2018/05/10 19:44:53, John D. Ament  wrote: 
> >> Ok, I suspect we're seeing the same issues then, just me looking at it on 
> >> windows my brain can't even process it any longer :-D
> >> 
> >> Calcite inherits from the ASF parent pom.  This means the standard 
> >> source-release distribution is applied.  I'm not sure how Crail created 
> >> their source release, but I suspect if they switch out to use ASF parent 
> >> and regenerate it (mvn release:prepare release:perform) they'll get the 
> >> right output format in the zip/tar.gz.
> >> 
> >> I saw on list there's some hesitation in using the parent.  If so, you can 
> >> just pull out the distribution logic from the parent pom's repo ( 
> >> https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L336-L417
> >>  ) and merge that into the Crail pom.
> >> 
> >> John
> >> 
> >> On 2018/05/10 19:10:29, Julian Hyde  wrote: 
> >>> Here’s a tar file where every file is in a sub-directory:
> >>> 
> >>> https://dist.apache.org/repos/dist/release/calcite/apache-calcite-1.16.0/apache-calcite-1.16.0-src.tar.gz
> >>>  
> >>> 
> >>> 
> >>> I couldn’t find any examples under dist/release with files in the root 
> >>> directory, so I made a couple, and put them on my web server. In the 
> >>> first, directory names are preceded by “./“ because I created using “tar 
> >>> cvfz /tmp/ament.tar.gz .”. In the second, there are no prefixes.
> >>> 
> >>> http://www.hydromatic.net/ament.tar.gz 
> >>> 
> >>> 
> >>> http://www.hydromatic.net/ament2.tar.gz 
> >>> 
> >>> 
> >>> My personal tool of choice for browsing tar.gz files is emacs. Things 
> >>> look the same on macOS, linux or windows (Cygwin).
> >>> 
> >>> Julian
> >>> 
>  On May 10, 2018, at 11:42 AM, John D. Ament  
>  wrote:
>  
>  
>  Julian,
>  
>  On 2018/05/10 18:40:12, Julian Hyde   > wrote: 
> > I agree about the missing DISCLAIMER file and the missing disclaimer in 
> > README.md. -1 until those are fixed.
> > 
> > Regarding directories, I disagree. Common practice is to have 
> > everything (including NOTICE, README and DISCLAIMER) in a directory 
> > that is named after the release. If you do otherwise, you make it more 
> > difficult for the user to clean up if they accidentally unzip the file 
> > in the wrong place. 
> > 
> > In my opinion Crail should have called that directory 
> > “apache-crail-1.0-incubating”, not “incubator-crail”.
>  
>  Weird.  Again, I've been using mac for a while (hate being back on 
>  windows so much), is this a windows thing?  I've been reviewing mostly 
>  tar.gz files recently and I can't think of any that have a nested 
>  directory.  But it could be my mac was cleaning things up.
>  
>  Do you have some examples I could look at to see the difference?
>  
> > 
> > Julian
> > 
> > 
> >> On May 10, 2018, at 10:26 AM, John D. Ament  
> >> wrote:
> >> 
> >> Also, it could be that I'

Re: [VOTE] Apache Crail 1.0-incubating (RC2)

[Julian Hyde]

I’m talking about directories inside the .tar.gz too.

Currently there is a leading directory. This is good:

$ tar tvfz apache-crail-1.0-rc2-incubating-source.tar.gz |head -3
drwxr-xr-x  0 jpfjpf 0 Apr 23 04:32 incubator-crail/
drwxr-xr-x  0 jpfjpf 0 Apr 23 04:32 incubator-crail/client/
-rw-r--r--  0 jpfjpf  2625 Apr 23 04:32 incubator-crail/client/pom.xml

No leading directory would be bad (in my opinion):

$ tar tvfz apache-crail-1.0-rc2-incubating-source.tar.gz |head -2
drwxr-xr-x  0 jpfjpf 0 Apr 23 04:32 client/
-rw-r--r--  0 jpfjpf  2625 Apr 23 04:32 client/pom.xml

A leading directory named after the release would be better:

$ tar tvfz apache-crail-1.0-rc2-incubating-source.tar.gz |head -3
drwxr-xr-x  0 jpfjpf 0 Apr 23 04:32 apache-crail-1.0-incubating-src/
drwxr-xr-x  0 jpfjpf 0 Apr 23 04:32 
apache-crail-1.0-incubating-src/client/
-rw-r--r--  0 jpfjpf  2625 Apr 23 04:32 
apache-crail-1.0-incubating-src/client/pom.xml

Julian

> On May 10, 2018, at 12:46 PM, John D. Ament  wrote:
> 
> BTW, I just re-read your reply.
> 
> I'm not talking about the root of the calcite dist area, it's pretty common 
> that projects create a /dist/dev/incubator//version# folder.  I'm 
> talking about the actual inside of the tar/zip file having an extra directory.
> 
> John
> 
> On 2018/05/10 19:44:53, John D. Ament  wrote: 
>> Ok, I suspect we're seeing the same issues then, just me looking at it on 
>> windows my brain can't even process it any longer :-D
>> 
>> Calcite inherits from the ASF parent pom.  This means the standard 
>> source-release distribution is applied.  I'm not sure how Crail created 
>> their source release, but I suspect if they switch out to use ASF parent and 
>> regenerate it (mvn release:prepare release:perform) they'll get the right 
>> output format in the zip/tar.gz.
>> 
>> I saw on list there's some hesitation in using the parent.  If so, you can 
>> just pull out the distribution logic from the parent pom's repo ( 
>> https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L336-L417 
>> ) and merge that into the Crail pom.
>> 
>> John
>> 
>> On 2018/05/10 19:10:29, Julian Hyde  wrote: 
>>> Here’s a tar file where every file is in a sub-directory:
>>> 
>>> https://dist.apache.org/repos/dist/release/calcite/apache-calcite-1.16.0/apache-calcite-1.16.0-src.tar.gz
>>>  
>>> 
>>> 
>>> I couldn’t find any examples under dist/release with files in the root 
>>> directory, so I made a couple, and put them on my web server. In the first, 
>>> directory names are preceded by “./“ because I created using “tar cvfz 
>>> /tmp/ament.tar.gz .”. In the second, there are no prefixes.
>>> 
>>> http://www.hydromatic.net/ament.tar.gz 
>>> 
>>> 
>>> http://www.hydromatic.net/ament2.tar.gz 
>>> 
>>> 
>>> My personal tool of choice for browsing tar.gz files is emacs. Things look 
>>> the same on macOS, linux or windows (Cygwin).
>>> 
>>> Julian
>>> 
 On May 10, 2018, at 11:42 AM, John D. Ament  wrote:
 
 
 Julian,
 
 On 2018/05/10 18:40:12, Julian Hyde >>> > wrote: 
> I agree about the missing DISCLAIMER file and the missing disclaimer in 
> README.md. -1 until those are fixed.
> 
> Regarding directories, I disagree. Common practice is to have everything 
> (including NOTICE, README and DISCLAIMER) in a directory that is named 
> after the release. If you do otherwise, you make it more difficult for 
> the user to clean up if they accidentally unzip the file in the wrong 
> place. 
> 
> In my opinion Crail should have called that directory 
> “apache-crail-1.0-incubating”, not “incubator-crail”.
 
 Weird.  Again, I've been using mac for a while (hate being back on windows 
 so much), is this a windows thing?  I've been reviewing mostly tar.gz 
 files recently and I can't think of any that have a nested directory.  But 
 it could be my mac was cleaning things up.
 
 Do you have some examples I could look at to see the difference?
 
> 
> Julian
> 
> 
>> On May 10, 2018, at 10:26 AM, John D. Ament  
>> wrote:
>> 
>> Also, it could be that I'm back to windows and no idea what I'm doing 
>> (I've grown to be a mac user), but there's a root incubator-crail folder 
>> that's in the zip.  We typically expect the LICENSE/NOTICE/DISCLAIMER at 
>> the root.
>> 
>> Speaking of, there is no DISCLAIMER file and the README.md does not 
>> include the incubating disclaimer text.  One of those two needs to exist.
>> 
>> I reviewed other stuff (rat output, notice file entries, headers,etc).  
>> That looks fine.  If you can fix the disclaimer and repack to not t

Re: [VOTE] Apache Crail 1.0-incubating (RC2)

[John D . Ament]

BTW, I just re-read your reply.

I'm not talking about the root of the calcite dist area, it's pretty common 
that projects create a /dist/dev/incubator//version# folder.  I'm 
talking about the actual inside of the tar/zip file having an extra directory.

John

On 2018/05/10 19:44:53, John D. Ament  wrote: 
> Ok, I suspect we're seeing the same issues then, just me looking at it on 
> windows my brain can't even process it any longer :-D
> 
> Calcite inherits from the ASF parent pom.  This means the standard 
> source-release distribution is applied.  I'm not sure how Crail created their 
> source release, but I suspect if they switch out to use ASF parent and 
> regenerate it (mvn release:prepare release:perform) they'll get the right 
> output format in the zip/tar.gz.
> 
> I saw on list there's some hesitation in using the parent.  If so, you can 
> just pull out the distribution logic from the parent pom's repo ( 
> https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L336-L417 ) 
> and merge that into the Crail pom.
> 
> John
> 
> On 2018/05/10 19:10:29, Julian Hyde  wrote: 
> > Here’s a tar file where every file is in a sub-directory:
> > 
> > https://dist.apache.org/repos/dist/release/calcite/apache-calcite-1.16.0/apache-calcite-1.16.0-src.tar.gz
> >  
> > 
> > 
> > I couldn’t find any examples under dist/release with files in the root 
> > directory, so I made a couple, and put them on my web server. In the first, 
> > directory names are preceded by “./“ because I created using “tar cvfz 
> > /tmp/ament.tar.gz .”. In the second, there are no prefixes.
> > 
> > http://www.hydromatic.net/ament.tar.gz 
> > 
> > 
> > http://www.hydromatic.net/ament2.tar.gz 
> > 
> > 
> > My personal tool of choice for browsing tar.gz files is emacs. Things look 
> > the same on macOS, linux or windows (Cygwin).
> > 
> > Julian
> > 
> > > On May 10, 2018, at 11:42 AM, John D. Ament  wrote:
> > > 
> > > 
> > > Julian,
> > > 
> > > On 2018/05/10 18:40:12, Julian Hyde  > > > wrote: 
> > >> I agree about the missing DISCLAIMER file and the missing disclaimer in 
> > >> README.md. -1 until those are fixed.
> > >> 
> > >> Regarding directories, I disagree. Common practice is to have everything 
> > >> (including NOTICE, README and DISCLAIMER) in a directory that is named 
> > >> after the release. If you do otherwise, you make it more difficult for 
> > >> the user to clean up if they accidentally unzip the file in the wrong 
> > >> place. 
> > >> 
> > >> In my opinion Crail should have called that directory 
> > >> “apache-crail-1.0-incubating”, not “incubator-crail”.
> > > 
> > > Weird.  Again, I've been using mac for a while (hate being back on 
> > > windows so much), is this a windows thing?  I've been reviewing mostly 
> > > tar.gz files recently and I can't think of any that have a nested 
> > > directory.  But it could be my mac was cleaning things up.
> > > 
> > > Do you have some examples I could look at to see the difference?
> > > 
> > >> 
> > >> Julian
> > >> 
> > >> 
> > >>> On May 10, 2018, at 10:26 AM, John D. Ament  
> > >>> wrote:
> > >>> 
> > >>> Also, it could be that I'm back to windows and no idea what I'm doing 
> > >>> (I've grown to be a mac user), but there's a root incubator-crail 
> > >>> folder that's in the zip.  We typically expect the 
> > >>> LICENSE/NOTICE/DISCLAIMER at the root.
> > >>> 
> > >>> Speaking of, there is no DISCLAIMER file and the README.md does not 
> > >>> include the incubating disclaimer text.  One of those two needs to 
> > >>> exist.
> > >>> 
> > >>> I reviewed other stuff (rat output, notice file entries, headers,etc).  
> > >>> That looks fine.  If you can fix the disclaimer and repack to not the 
> > >>> extra directory I'll vote +1, but I'm -1 without that.  Disclaimer is 
> > >>> the one thing we mandate, and i cannot budge on that.  I will verify 
> > >>> the sig once you send me the keys file location.
> > >>> 
> > >>> John
> > >>> 
> > >>> On 2018/05/10 17:07:53, John D. Ament  wrote: 
> >  Hi,
> >  
> >  Where can I find the key that was used to sign these files?
> >  
> >  John
> >  
> >  
> >  On 2018/05/07 14:49:29, "Jonas Pfefferle"  wrote: 
> > > Please vote to approve the source release of Apache Crail 
> > > 1.0-incubating 
> > > (RC2).
> > > 
> > > The podling dev vote thread:
> > > https://www.mail-archive.com/dev@crail.apache.org/msg00241.html
> > > 
> > > The result:
> > > https://www.mail-archive.com/dev@crail.apache.org/msg00249.html
> > > 
> > > Commit hash: 749f44206943fcaef0841ed89411013c2dc11d64
> > > 
> > > https://git1-us-west.apache.org/repos/asf?p=incubator-crail.git;a=commit;h=749f44206943fcaef0841ed89411013c2dc11d64
> > > 
> > 

Re: [VOTE] Apache Crail 1.0-incubating (RC2)

[John D . Ament]

Ok, I suspect we're seeing the same issues then, just me looking at it on 
windows my brain can't even process it any longer :-D

Calcite inherits from the ASF parent pom.  This means the standard 
source-release distribution is applied.  I'm not sure how Crail created their 
source release, but I suspect if they switch out to use ASF parent and 
regenerate it (mvn release:prepare release:perform) they'll get the right 
output format in the zip/tar.gz.

I saw on list there's some hesitation in using the parent.  If so, you can just 
pull out the distribution logic from the parent pom's repo ( 
https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L336-L417 ) 
and merge that into the Crail pom.

John

On 2018/05/10 19:10:29, Julian Hyde  wrote: 
> Here’s a tar file where every file is in a sub-directory:
> 
> https://dist.apache.org/repos/dist/release/calcite/apache-calcite-1.16.0/apache-calcite-1.16.0-src.tar.gz
>  
> 
> 
> I couldn’t find any examples under dist/release with files in the root 
> directory, so I made a couple, and put them on my web server. In the first, 
> directory names are preceded by “./“ because I created using “tar cvfz 
> /tmp/ament.tar.gz .”. In the second, there are no prefixes.
> 
> http://www.hydromatic.net/ament.tar.gz 
> 
> 
> http://www.hydromatic.net/ament2.tar.gz 
> 
> 
> My personal tool of choice for browsing tar.gz files is emacs. Things look 
> the same on macOS, linux or windows (Cygwin).
> 
> Julian
> 
> > On May 10, 2018, at 11:42 AM, John D. Ament  wrote:
> > 
> > 
> > Julian,
> > 
> > On 2018/05/10 18:40:12, Julian Hyde  > > wrote: 
> >> I agree about the missing DISCLAIMER file and the missing disclaimer in 
> >> README.md. -1 until those are fixed.
> >> 
> >> Regarding directories, I disagree. Common practice is to have everything 
> >> (including NOTICE, README and DISCLAIMER) in a directory that is named 
> >> after the release. If you do otherwise, you make it more difficult for the 
> >> user to clean up if they accidentally unzip the file in the wrong place. 
> >> 
> >> In my opinion Crail should have called that directory 
> >> “apache-crail-1.0-incubating”, not “incubator-crail”.
> > 
> > Weird.  Again, I've been using mac for a while (hate being back on windows 
> > so much), is this a windows thing?  I've been reviewing mostly tar.gz files 
> > recently and I can't think of any that have a nested directory.  But it 
> > could be my mac was cleaning things up.
> > 
> > Do you have some examples I could look at to see the difference?
> > 
> >> 
> >> Julian
> >> 
> >> 
> >>> On May 10, 2018, at 10:26 AM, John D. Ament  wrote:
> >>> 
> >>> Also, it could be that I'm back to windows and no idea what I'm doing 
> >>> (I've grown to be a mac user), but there's a root incubator-crail folder 
> >>> that's in the zip.  We typically expect the LICENSE/NOTICE/DISCLAIMER at 
> >>> the root.
> >>> 
> >>> Speaking of, there is no DISCLAIMER file and the README.md does not 
> >>> include the incubating disclaimer text.  One of those two needs to exist.
> >>> 
> >>> I reviewed other stuff (rat output, notice file entries, headers,etc).  
> >>> That looks fine.  If you can fix the disclaimer and repack to not the 
> >>> extra directory I'll vote +1, but I'm -1 without that.  Disclaimer is the 
> >>> one thing we mandate, and i cannot budge on that.  I will verify the sig 
> >>> once you send me the keys file location.
> >>> 
> >>> John
> >>> 
> >>> On 2018/05/10 17:07:53, John D. Ament  wrote: 
>  Hi,
>  
>  Where can I find the key that was used to sign these files?
>  
>  John
>  
>  
>  On 2018/05/07 14:49:29, "Jonas Pfefferle"  wrote: 
> > Please vote to approve the source release of Apache Crail 
> > 1.0-incubating 
> > (RC2).
> > 
> > The podling dev vote thread:
> > https://www.mail-archive.com/dev@crail.apache.org/msg00241.html
> > 
> > The result:
> > https://www.mail-archive.com/dev@crail.apache.org/msg00249.html
> > 
> > Commit hash: 749f44206943fcaef0841ed89411013c2dc11d64
> > 
> > https://git1-us-west.apache.org/repos/asf?p=incubator-crail.git;a=commit;h=749f44206943fcaef0841ed89411013c2dc11d64
> > 
> > Release files can be found at:
> > https://dist.apache.org/repos/dist/dev/incubator/crail/1.0-rc2/
> > 
> > The vote is open for at least 72 hours and passes if a majority of at 
> > least
> > 3 +1 PMC votes are cast.
> > 
> > [ ] +1 Release this package as Apache Crail 1.0-incubating
> > [ ] -1 Do not release this package because ...
> > 
> > Thanks,
> > Jonas
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > -
> >>>

Re: [VOTE] Apache Crail 1.0-incubating (RC2)

[Julian Hyde]

Here’s a tar file where every file is in a sub-directory:

https://dist.apache.org/repos/dist/release/calcite/apache-calcite-1.16.0/apache-calcite-1.16.0-src.tar.gz
 


I couldn’t find any examples under dist/release with files in the root 
directory, so I made a couple, and put them on my web server. In the first, 
directory names are preceded by “./“ because I created using “tar cvfz 
/tmp/ament.tar.gz .”. In the second, there are no prefixes.

http://www.hydromatic.net/ament.tar.gz 

http://www.hydromatic.net/ament2.tar.gz 


My personal tool of choice for browsing tar.gz files is emacs. Things look the 
same on macOS, linux or windows (Cygwin).

Julian

> On May 10, 2018, at 11:42 AM, John D. Ament  wrote:
> 
> 
> Julian,
> 
> On 2018/05/10 18:40:12, Julian Hyde  > wrote: 
>> I agree about the missing DISCLAIMER file and the missing disclaimer in 
>> README.md. -1 until those are fixed.
>> 
>> Regarding directories, I disagree. Common practice is to have everything 
>> (including NOTICE, README and DISCLAIMER) in a directory that is named after 
>> the release. If you do otherwise, you make it more difficult for the user to 
>> clean up if they accidentally unzip the file in the wrong place. 
>> 
>> In my opinion Crail should have called that directory 
>> “apache-crail-1.0-incubating”, not “incubator-crail”.
> 
> Weird.  Again, I've been using mac for a while (hate being back on windows so 
> much), is this a windows thing?  I've been reviewing mostly tar.gz files 
> recently and I can't think of any that have a nested directory.  But it could 
> be my mac was cleaning things up.
> 
> Do you have some examples I could look at to see the difference?
> 
>> 
>> Julian
>> 
>> 
>>> On May 10, 2018, at 10:26 AM, John D. Ament  wrote:
>>> 
>>> Also, it could be that I'm back to windows and no idea what I'm doing (I've 
>>> grown to be a mac user), but there's a root incubator-crail folder that's 
>>> in the zip.  We typically expect the LICENSE/NOTICE/DISCLAIMER at the root.
>>> 
>>> Speaking of, there is no DISCLAIMER file and the README.md does not include 
>>> the incubating disclaimer text.  One of those two needs to exist.
>>> 
>>> I reviewed other stuff (rat output, notice file entries, headers,etc).  
>>> That looks fine.  If you can fix the disclaimer and repack to not the extra 
>>> directory I'll vote +1, but I'm -1 without that.  Disclaimer is the one 
>>> thing we mandate, and i cannot budge on that.  I will verify the sig once 
>>> you send me the keys file location.
>>> 
>>> John
>>> 
>>> On 2018/05/10 17:07:53, John D. Ament  wrote: 
 Hi,
 
 Where can I find the key that was used to sign these files?
 
 John
 
 
 On 2018/05/07 14:49:29, "Jonas Pfefferle"  wrote: 
> Please vote to approve the source release of Apache Crail 1.0-incubating 
> (RC2).
> 
> The podling dev vote thread:
> https://www.mail-archive.com/dev@crail.apache.org/msg00241.html
> 
> The result:
> https://www.mail-archive.com/dev@crail.apache.org/msg00249.html
> 
> Commit hash: 749f44206943fcaef0841ed89411013c2dc11d64
> 
> https://git1-us-west.apache.org/repos/asf?p=incubator-crail.git;a=commit;h=749f44206943fcaef0841ed89411013c2dc11d64
> 
> Release files can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/crail/1.0-rc2/
> 
> The vote is open for at least 72 hours and passes if a majority of at 
> least
> 3 +1 PMC votes are cast.
> 
> [ ] +1 Release this package as Apache Crail 1.0-incubating
> [ ] -1 Do not release this package because ...
> 
> Thanks,
> Jonas
> 
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 
 
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org
 
 
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org 
>> 
>> For additional commands, e-mail: general-h...@incubator.apache.org 
>> 
>> 
>> 
> 
> ---

Re: [VOTE] Apache Crail 1.0-incubating (RC2)

[John D . Ament]

Julian,

On 2018/05/10 18:40:12, Julian Hyde  wrote: 
> I agree about the missing DISCLAIMER file and the missing disclaimer in 
> README.md. -1 until those are fixed.
> 
> Regarding directories, I disagree. Common practice is to have everything 
> (including NOTICE, README and DISCLAIMER) in a directory that is named after 
> the release. If you do otherwise, you make it more difficult for the user to 
> clean up if they accidentally unzip the file in the wrong place. 
> 
> In my opinion Crail should have called that directory 
> “apache-crail-1.0-incubating”, not “incubator-crail”.

Weird.  Again, I've been using mac for a while (hate being back on windows so 
much), is this a windows thing?  I've been reviewing mostly tar.gz files 
recently and I can't think of any that have a nested directory.  But it could 
be my mac was cleaning things up.

Do you have some examples I could look at to see the difference?

> 
> Julian
> 
> 
> > On May 10, 2018, at 10:26 AM, John D. Ament  wrote:
> > 
> > Also, it could be that I'm back to windows and no idea what I'm doing (I've 
> > grown to be a mac user), but there's a root incubator-crail folder that's 
> > in the zip.  We typically expect the LICENSE/NOTICE/DISCLAIMER at the root.
> > 
> > Speaking of, there is no DISCLAIMER file and the README.md does not include 
> > the incubating disclaimer text.  One of those two needs to exist.
> > 
> > I reviewed other stuff (rat output, notice file entries, headers,etc).  
> > That looks fine.  If you can fix the disclaimer and repack to not the extra 
> > directory I'll vote +1, but I'm -1 without that.  Disclaimer is the one 
> > thing we mandate, and i cannot budge on that.  I will verify the sig once 
> > you send me the keys file location.
> > 
> > John
> > 
> > On 2018/05/10 17:07:53, John D. Ament  wrote: 
> >> Hi,
> >> 
> >> Where can I find the key that was used to sign these files?
> >> 
> >> John
> >> 
> >> 
> >> On 2018/05/07 14:49:29, "Jonas Pfefferle"  wrote: 
> >>> Please vote to approve the source release of Apache Crail 1.0-incubating 
> >>> (RC2).
> >>> 
> >>> The podling dev vote thread:
> >>> https://www.mail-archive.com/dev@crail.apache.org/msg00241.html
> >>> 
> >>> The result:
> >>> https://www.mail-archive.com/dev@crail.apache.org/msg00249.html
> >>> 
> >>> Commit hash: 749f44206943fcaef0841ed89411013c2dc11d64
> >>> 
> >>> https://git1-us-west.apache.org/repos/asf?p=incubator-crail.git;a=commit;h=749f44206943fcaef0841ed89411013c2dc11d64
> >>> 
> >>> Release files can be found at:
> >>> https://dist.apache.org/repos/dist/dev/incubator/crail/1.0-rc2/
> >>> 
> >>> The vote is open for at least 72 hours and passes if a majority of at 
> >>> least
> >>> 3 +1 PMC votes are cast.
> >>> 
> >>> [ ] +1 Release this package as Apache Crail 1.0-incubating
> >>> [ ] -1 Do not release this package because ...
> >>> 
> >>> Thanks,
> >>> Jonas
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> -
> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>> 
> >>> 
> >> 
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >> 
> >> 
> > 
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

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

Re: [VOTE] Apache Crail 1.0-incubating (RC2)

[Julian Hyde]

I agree about the missing DISCLAIMER file and the missing disclaimer in 
README.md. -1 until those are fixed.

Regarding directories, I disagree. Common practice is to have everything 
(including NOTICE, README and DISCLAIMER) in a directory that is named after 
the release. If you do otherwise, you make it more difficult for the user to 
clean up if they accidentally unzip the file in the wrong place. 

In my opinion Crail should have called that directory 
“apache-crail-1.0-incubating”, not “incubator-crail”.

Julian


> On May 10, 2018, at 10:26 AM, John D. Ament  wrote:
> 
> Also, it could be that I'm back to windows and no idea what I'm doing (I've 
> grown to be a mac user), but there's a root incubator-crail folder that's in 
> the zip.  We typically expect the LICENSE/NOTICE/DISCLAIMER at the root.
> 
> Speaking of, there is no DISCLAIMER file and the README.md does not include 
> the incubating disclaimer text.  One of those two needs to exist.
> 
> I reviewed other stuff (rat output, notice file entries, headers,etc).  That 
> looks fine.  If you can fix the disclaimer and repack to not the extra 
> directory I'll vote +1, but I'm -1 without that.  Disclaimer is the one thing 
> we mandate, and i cannot budge on that.  I will verify the sig once you send 
> me the keys file location.
> 
> John
> 
> On 2018/05/10 17:07:53, John D. Ament  wrote: 
>> Hi,
>> 
>> Where can I find the key that was used to sign these files?
>> 
>> John
>> 
>> 
>> On 2018/05/07 14:49:29, "Jonas Pfefferle"  wrote: 
>>> Please vote to approve the source release of Apache Crail 1.0-incubating 
>>> (RC2).
>>> 
>>> The podling dev vote thread:
>>> https://www.mail-archive.com/dev@crail.apache.org/msg00241.html
>>> 
>>> The result:
>>> https://www.mail-archive.com/dev@crail.apache.org/msg00249.html
>>> 
>>> Commit hash: 749f44206943fcaef0841ed89411013c2dc11d64
>>> 
>>> https://git1-us-west.apache.org/repos/asf?p=incubator-crail.git;a=commit;h=749f44206943fcaef0841ed89411013c2dc11d64
>>> 
>>> Release files can be found at:
>>> https://dist.apache.org/repos/dist/dev/incubator/crail/1.0-rc2/
>>> 
>>> The vote is open for at least 72 hours and passes if a majority of at least
>>> 3 +1 PMC votes are cast.
>>> 
>>> [ ] +1 Release this package as Apache Crail 1.0-incubating
>>> [ ] -1 Do not release this package because ...
>>> 
>>> Thanks,
>>> Jonas
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: [VOTE] Release Apache Daffodil (incubating) 2.1.0-rc3

[John D . Ament]

Justin/Steve,

Apologies as its very confusing looking at this email thread trying to 
understand what the current state of the vote is.

>From what I understand:

- Two files were included in the release that are Cat-X
- These were supposed to be relicensed, but doesn't sound like that happened

Or was it corrected that these two files are UoI NCSA licensed?  If these files 
are Cat-X I would also vote a -1 since we cannot release with clear Cat-X 
contents (we can release with Cat-X dependencies, but the contents can't be 
Cat-X).

Thanks,

John

On 2018/04/30 11:52:22, Steve Lawrence  wrote: 
> Hi all,
> 
> We are still need at least one more +1. We'd really appreciate if if you
> could take a look.
> 
> Thanks,
> - Steve
> 
> On 04/09/2018 07:24 PM, Steve Lawrence wrote:
> > The Apache Daffodil community has voted and approved the proposed
> > release of Apache Daffodil (incubating) 2.1.0-rc3.
> > 
> > We now kindly request the Incubator PMC members review and vote on this
> > incubator release.
> > 
> > Daffodil is an open source implementation of the DFDL specification that
> > uses DFDL schemas to parse fixed format data into an infoset, which is
> > most commonly represented as either XML or JSON. This allows the use of
> > well-established XML or JSON technologies and libraries to consume,
> > inspect, and manipulate fixed format data in existing solutions.
> > Daffodil is also capable of the reverse by serializing or "unparsing" an
> > XML or JSON infoset back to the original data format.
> > 
> > Vote thread:
> > https://lists.apache.org/thread.html/10811e8f520bf100a9250a3ae0610633e9018e0ae8fc422e2c0f097a@%3Cdev.daffodil.apache.org%3E
> > 
> > Result thread:
> > https://lists.apache.org/thread.html/54a3e681b25f084e0dc46e19764cd19507ff502b927516093a3bd667@%3Cdev.daffodil.apache.org%3E
> > 
> > All distribution packages, including signatures, digests, etc. can be
> > found at:
> > 
> > https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.1.0-rc3/
> > 
> > Staging artifacts can be found at:
> > 
> > https://repository.apache.org/content/repositories/orgapachedaffodil-1002/
> > 
> > This release has been signed with PGP key 033AE661, corresponding to
> > slawre...@apache.org, which is included in the repository's KEYS file.
> > This key can be found on keyservers, such as:
> > 
> > http://pgp.mit.edu/pks/lookup?op=get&search=0x033AE661
> > 
> > It is also listed here:
> > 
> > https://people.apache.org/keys/committer/slawrence.asc
> > 
> > The release candidate has been tagged in git with v2.1.0-rc3.
> > 
> > For reference, here is a list of all closed JIRAs tagged with 2.1.0:
> > 
> > https://issues.apache.org/jira/browse/DAFFODIL-1897?jql=project%20%3D%20DAFFODIL%20AND%20fixVersion%20%3D%202.1.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> > 
> > For a summary of the changes in this release, see:
> > 
> > https://daffodil.apache.org/releases/2.1.0/
> > 
> > Please review and vote. The vote will be open for at least 72 hours.
> > 
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and reason why)
> > 
> > Thanks,
> > - Steve
> > 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

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

Apache Daffodil (incubating) in need of mentors

[Steve Lawrence]

All,

The Daffodil project has had a VOTE open for over a month [1], receiving
two votes so far. We would greatly appreciate it if others could review
the release so that can we get our first release out as an Apache incubator.

That said, although our mentors have been incredibly helpful in getting
Daffodil bootstrapped to this point, we think a core issue is that
activity from our mentors has decreased in the past month to a point
where it hinders our progress (we've had minimal response to emails and
neither has voted on this release). Daffodil is already shorthanded with
only 2 mentors, so having and extra mentor or two would provide a great
benefit and help the project move forward.

So, we are asking if anyone would be interested in becoming a mentor to
the Daffodil project. The majority of the bootstrapping work has been
completed, so we think the main focus will be on getting releases
out and building the community. For some background on Daffodil and how
it aligns with Apache, the Daffodil incubation proposal is available here:

  https://wiki.apache.org/incubator/DaffodilProposal

and our website is at:

  https://daffodil.apache.org

Thanks,
- Steve

[1]
https://lists.apache.org/thread.html/bfa624a2eefb1c1c193f0c497f6dcc46172d9fa9a0e3fcd37464f95e@%3Cgeneral.incubator.apache.org%3E

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

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Ted Dunning]

There may be binary convenience artifacts, but let's not dignify them by
the name release. They aren't, after all.



On Thu, May 10, 2018 at 8:56 AM, Matt Sicker  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.
>
> On 10 May 2018 at 10:20, Roman Shaposhnik  wrote:
>
> > On Thu, May 10, 2018 at 4:17 AM, sebb  wrote:
> > > On 10 May 2018 at 11:37, Greg Stein  wrote:
> > >> On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang 
> > wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang <
> willem.ji...@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-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> --
> Matt Sicker 
>

Re: [VOTE] Apache Crail 1.0-incubating (RC2)

[John D . Ament]

Also, it could be that I'm back to windows and no idea what I'm doing (I've 
grown to be a mac user), but there's a root incubator-crail folder that's in 
the zip.  We typically expect the LICENSE/NOTICE/DISCLAIMER at the root.

Speaking of, there is no DISCLAIMER file and the README.md does not include the 
incubating disclaimer text.  One of those two needs to exist.

I reviewed other stuff (rat output, notice file entries, headers,etc).  That 
looks fine.  If you can fix the disclaimer and repack to not the extra 
directory I'll vote +1, but I'm -1 without that.  Disclaimer is the one thing 
we mandate, and i cannot budge on that.  I will verify the sig once you send me 
the keys file location.

John

On 2018/05/10 17:07:53, John D. Ament  wrote: 
> Hi,
> 
> Where can I find the key that was used to sign these files?
> 
> John
> 
> 
> On 2018/05/07 14:49:29, "Jonas Pfefferle"  wrote: 
> > Please vote to approve the source release of Apache Crail 1.0-incubating 
> > (RC2).
> > 
> > The podling dev vote thread:
> > https://www.mail-archive.com/dev@crail.apache.org/msg00241.html
> > 
> > The result:
> > https://www.mail-archive.com/dev@crail.apache.org/msg00249.html
> > 
> > Commit hash: 749f44206943fcaef0841ed89411013c2dc11d64
> > 
> > https://git1-us-west.apache.org/repos/asf?p=incubator-crail.git;a=commit;h=749f44206943fcaef0841ed89411013c2dc11d64
> > 
> > Release files can be found at:
> > https://dist.apache.org/repos/dist/dev/incubator/crail/1.0-rc2/
> > 
> > The vote is open for at least 72 hours and passes if a majority of at least
> > 3 +1 PMC votes are cast.
> > 
> > [ ] +1 Release this package as Apache Crail 1.0-incubating
> > [ ] -1 Do not release this package because ...
> > 
> > Thanks,
> > Jonas
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> > 
> > 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

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

Re: [VOTE] Apache Crail 1.0-incubating (RC2)

[John D . Ament]

Hi,

Where can I find the key that was used to sign these files?

John


On 2018/05/07 14:49:29, "Jonas Pfefferle"  wrote: 
> Please vote to approve the source release of Apache Crail 1.0-incubating 
> (RC2).
> 
> The podling dev vote thread:
> https://www.mail-archive.com/dev@crail.apache.org/msg00241.html
> 
> The result:
> https://www.mail-archive.com/dev@crail.apache.org/msg00249.html
> 
> Commit hash: 749f44206943fcaef0841ed89411013c2dc11d64
> 
> https://git1-us-west.apache.org/repos/asf?p=incubator-crail.git;a=commit;h=749f44206943fcaef0841ed89411013c2dc11d64
> 
> Release files can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/crail/1.0-rc2/
> 
> The vote is open for at least 72 hours and passes if a majority of at least
> 3 +1 PMC votes are cast.
> 
> [ ] +1 Release this package as Apache Crail 1.0-incubating
> [ ] -1 Do not release this package because ...
> 
> Thanks,
> Jonas
> 
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

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

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Julian Hyde]

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  wrote:
> 
> On 10 May 2018 at 16:56, Matt Sicker  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  wrote:
>> 
>>> On Thu, May 10, 2018 at 4:17 AM, sebb  wrote:
 On 10 May 2018 at 11:37, Greg Stein  wrote:
> On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang 
>>> wrote:
> 
>> Hi,
>> 
>> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang 
>> 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-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>>> 
>> 
>> 
>> --
>> Matt Sicker 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: [VOTE] Apache Crail 1.0-incubating (RC2)

[Julian Hyde]

IPMC members,

This vote has been open 72 hours and has two votes so far (Luciano and I are 
mentors).

I’d really appreciate it if someone else could download and vote.

This is Crail’s first release in the incubator but in my opinion they’re in 
pretty good shape.

Julian
 

> On May 7, 2018, at 10:27 PM, Luciano Resende  wrote:
> 
> +1 (binding)
> 
> On Mon, May 7, 2018 at 7:49 AM Jonas Pfefferle  wrote:
> 
>> Please vote to approve the source release of Apache Crail 1.0-incubating
>> (RC2).
>> 
>> The podling dev vote thread:
>> https://www.mail-archive.com/dev@crail.apache.org/msg00241.html
>> 
>> The result:
>> https://www.mail-archive.com/dev@crail.apache.org/msg00249.html
>> 
>> Commit hash: 749f44206943fcaef0841ed89411013c2dc11d64
>> 
>> 
>> https://git1-us-west.apache.org/repos/asf?p=incubator-crail.git;a=commit;h=749f44206943fcaef0841ed89411013c2dc11d64
>> 
>> Release files can be found at:
>> https://dist.apache.org/repos/dist/dev/incubator/crail/1.0-rc2/
>> 
>> The vote is open for at least 72 hours and passes if a majority of at least
>> 3 +1 PMC votes are cast.
>> 
>> [ ] +1 Release this package as Apache Crail 1.0-incubating
>> [ ] -1 Do not release this package because ...
>> 
>> Thanks,
>> Jonas
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> --
> Sent from my Mobile device


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

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[sebb]

On 10 May 2018 at 16:56, Matt Sicker  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  wrote:
>
>> On Thu, May 10, 2018 at 4:17 AM, sebb  wrote:
>> > On 10 May 2018 at 11:37, Greg Stein  wrote:
>> >> On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang 
>> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang 
>> >>> 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-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>
>
> --
> Matt Sicker 

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

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Matt Sicker]

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.

On 10 May 2018 at 10:20, Roman Shaposhnik  wrote:

> On Thu, May 10, 2018 at 4:17 AM, sebb  wrote:
> > On 10 May 2018 at 11:37, Greg Stein  wrote:
> >> On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang 
> >>> 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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Matt Sicker 

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Roman Shaposhnik]

On Thu, May 10, 2018 at 4:17 AM, sebb  wrote:
> On 10 May 2018 at 11:37, Greg Stein  wrote:
>> On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang  wrote:
>>
>>> Hi,
>>>
>>> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang 
>>> 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[sebb]

On 10 May 2018 at 11:37, Greg Stein  wrote:
> On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang  wrote:
>
>> Hi,
>>
>> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang 
>> 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.

> Regards,
> -g
> (Member, skipping my Infra hat)

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

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Greg Stein]

On Thu, May 10, 2018 at 3:31 AM, Huxing Zhang  wrote:

> Hi,
>
> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang 
> 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.

Regards,
-g
(Member, skipping my Infra hat)

Removing Legacy websites

[John D. Ament]

All,

I was reminded of an outstanding issue from the conversion from svn to git
for the website where some of the old podlings are still served from an svn
dir that gets loaded into the same git dir.

All of the podlings at this point that this was working for are either
retired, graduated or converted (ODF was converted a few weeks ago I
believe, but its not up yet).  Therefore I have asked infra to disable the
SVN side of things to avoid a race condition from the two publishing
systems.

https://issues.apache.org/jira/browse/INFRA-16510

We'll likely need to wait for ODF to finish up their work before this can
be implemented.

John

Re: [VOTE] Release Apache Omid 0.9.0.0 (incubating)

[Ohad Shacham]

Thanks Justin.

Could you please review the notice file in OMID-44
 before I'll cook a new
release candidate?

Thanks,
Ohad


On Thu, May 10, 2018 at 2:13 AM, Justin Mclean 
wrote:

> Hi,
>
> > Has the project taken YCSB notice file into account [1] and can you
> confirm YCSB has taken MTBT notice file into account [2]. From a casual
> look (and I could be mistaken) this doesn’t seem to be the case.
>
> BTW I don’t think this is a major issue and it can be fine in a later
> release if needed.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Justin Mclean]

Hi,,
IMO it only the source release that is important and unless we find a
serious issue like GPL licensed software in the binary all is good.
Particularly if you call out that they may be issues with the binary
license and notice files as part of the vote email. This is an incubating
project and it's not expected to get everything right first go.

Thanks,
Justin

On Thu., 10 May 2018, 5:59 pm Willem Jiang,  wrote:

> Is there any plan for going through the vote process of Binary file?
> Normally there are lots of work on the License files of Binary durning the
> first release.
> Maybe we should need to vote the binary file as well.
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, May 9, 2018 at 4:34 PM, Huxing Zhang  wrote:
>
> > On Wed, May 9, 2018 at 3:35 PM, Bertrand Delacretaz
> >  wrote:
> > > On Wed, May 9, 2018 at 3:44 AM, Huxing Zhang 
> wrote:
> > >> ...The maven artifact is the most significant for most of the Dubbo
> > >> users, so we want to include a maven artifact in the release
> > >
> > > Binaries are NOT part of Apache Releases, as mentioned earlier in this
> > thread.
> >
> > Yes, we fully understood that.
> >
> > Here what I mean "release" does not mean an Apache release, it is
> > actually a "hybrid" release, which includes:
> >
> > * source (following Apache release policy)
> > * binary (it is optional but still following Apache release policy)
> > * Maven artifacts under third-party coordinates (Non Apache release)
> >
> > >
> > > Dubbo mentors, I think we need a clear description of how these
> > > "hybrid" releases are done, to avoid any misunderstandings.
> > >
> > > Justin mentioned in this thread that that's been discussed on your dev
> > > list, so you probably just need to summarize that and include the URL
> > > in your next Incubator report.
> > >
> > > -Bertrand
> >
> > --
> > Best Regards！
> > Huxing
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Von Gosling]

Hi,

Dubbo teams are making every endeavor to prepare the first formal release under 
the apache way, I also help teams to sweep away the binary and source liences 
problems :-) 


Best Regards,
Von Gosling

> 在 2018年5月10日，16:31，Huxing Zhang  写道：
> 
> Hi,
> 
> On Thu, May 10, 2018 at 3:59 PM, Willem Jiang  > wrote:
>> Is there any plan for going through the vote process of Binary file?
> 
> Yes, binaries will also go through the vote process.
> 
>> Normally there are lots of work on the License files of Binary durning the
>> first release.
>> Maybe we should need to vote the binary file as well.
>> 
>> 
>> Willem Jiang
>> 
>> Blog: http://willemjiang.blogspot.com (English)
>>  http://jnn.iteye.com  (Chinese)
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>> 
>> On Wed, May 9, 2018 at 4:34 PM, Huxing Zhang  wrote:
>> 
>>> On Wed, May 9, 2018 at 3:35 PM, Bertrand Delacretaz
>>>  wrote:
 On Wed, May 9, 2018 at 3:44 AM, Huxing Zhang  wrote:
> ...The maven artifact is the most significant for most of the Dubbo
> users, so we want to include a maven artifact in the release
 
 Binaries are NOT part of Apache Releases, as mentioned earlier in this
>>> thread.
>>> 
>>> Yes, we fully understood that.
>>> 
>>> Here what I mean "release" does not mean an Apache release, it is
>>> actually a "hybrid" release, which includes:
>>> 
>>> * source (following Apache release policy)
>>> * binary (it is optional but still following Apache release policy)
>>> * Maven artifacts under third-party coordinates (Non Apache release)
>>> 
 
 Dubbo mentors, I think we need a clear description of how these
 "hybrid" releases are done, to avoid any misunderstandings.
 
 Justin mentioned in this thread that that's been discussed on your dev
 list, so you probably just need to summarize that and include the URL
 in your next Incubator report.
 
 -Bertrand
>>> 
>>> --
>>> Best Regards！
>>> Huxing
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>>> 
> 
> -- 
> Best Regards！
> Huxing

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Huxing Zhang]

Hi,

On Thu, May 10, 2018 at 3:59 PM, Willem Jiang  wrote:
> Is there any plan for going through the vote process of Binary file?

Yes, binaries will also go through the vote process.

> Normally there are lots of work on the License files of Binary durning the
> first release.
> Maybe we should need to vote the binary file as well.
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
>   http://jnn.iteye.com  (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Wed, May 9, 2018 at 4:34 PM, Huxing Zhang  wrote:
>
>> On Wed, May 9, 2018 at 3:35 PM, Bertrand Delacretaz
>>  wrote:
>> > On Wed, May 9, 2018 at 3:44 AM, Huxing Zhang  wrote:
>> >> ...The maven artifact is the most significant for most of the Dubbo
>> >> users, so we want to include a maven artifact in the release
>> >
>> > Binaries are NOT part of Apache Releases, as mentioned earlier in this
>> thread.
>>
>> Yes, we fully understood that.
>>
>> Here what I mean "release" does not mean an Apache release, it is
>> actually a "hybrid" release, which includes:
>>
>> * source (following Apache release policy)
>> * binary (it is optional but still following Apache release policy)
>> * Maven artifacts under third-party coordinates (Non Apache release)
>>
>> >
>> > Dubbo mentors, I think we need a clear description of how these
>> > "hybrid" releases are done, to avoid any misunderstandings.
>> >
>> > Justin mentioned in this thread that that's been discussed on your dev
>> > list, so you probably just need to summarize that and include the URL
>> > in your next Incubator report.
>> >
>> > -Bertrand
>>
>> --
>> Best Regards！
>> Huxing
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

-- 
Best Regards！
Huxing

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

Re: Publishing Maven artifacts under third-party coordinates (was: Set up Nexus staging profile for Dubbo ...)

[Willem Jiang]

Is there any plan for going through the vote process of Binary file?
Normally there are lots of work on the License files of Binary durning the
first release.
Maybe we should need to vote the binary file as well.


Willem Jiang

Blog: http://willemjiang.blogspot.com (English)
  http://jnn.iteye.com  (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem

On Wed, May 9, 2018 at 4:34 PM, Huxing Zhang  wrote:

> On Wed, May 9, 2018 at 3:35 PM, Bertrand Delacretaz
>  wrote:
> > On Wed, May 9, 2018 at 3:44 AM, Huxing Zhang  wrote:
> >> ...The maven artifact is the most significant for most of the Dubbo
> >> users, so we want to include a maven artifact in the release
> >
> > Binaries are NOT part of Apache Releases, as mentioned earlier in this
> thread.
>
> Yes, we fully understood that.
>
> Here what I mean "release" does not mean an Apache release, it is
> actually a "hybrid" release, which includes:
>
> * source (following Apache release policy)
> * binary (it is optional but still following Apache release policy)
> * Maven artifacts under third-party coordinates (Non Apache release)
>
> >
> > Dubbo mentors, I think we need a clear description of how these
> > "hybrid" releases are done, to avoid any misunderstandings.
> >
> > Justin mentioned in this thread that that's been discussed on your dev
> > list, so you probably just need to summarize that and include the URL
> > in your next Incubator report.
> >
> > -Bertrand
>
> --
> Best Regards！
> Huxing
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>