Andy

Quick question based on mnemonic's VOTE (
http://mail-archives.apache.org/mod_mbox/incubator-general/201605.mbox/%3C573CE75B.5030404%40apache.org%3E
)
It looks like both the commit hash and tag need to be committed in
git-wip-us.apache.org. IMO this seems to be a bit of the chicken vs egg
conundrum.
Committing a tag and hash before VOTE means these may need to be reapplied
if the VOTE fails.
I assume this is ok (someone not knowing a VOTE was in progress could
checkout by TAG which could change later if the VOTE fails).

Kam


On Thu, Jun 30, 2016 at 2:47 PM, Andrew Purtell <[email protected]> wrote:

> Sounds like great progress. Let's start a candidate release vote!
>
> I'll give it a good looking over before casting my vote.
>
> We have a long holiday weekend coming up in the US. You might want to
> extend the vote beyond the customary 72 hours into next week.
>
>
> On Thu, Jun 30, 2016 at 2:44 PM, Kam Kasravi <[email protected]> wrote:
>
>> Hi Andy
>>
>> I've update KEYS and files in RC0 with updates as suggested (see
>> https://dist.apache.org/repos/dist/dev/incubator/gearpump/)
>> Updates include:
>>
>> KEYS file now includes code signing key
>>
>> LICENSE file now includes SIL Font license
>>
>> NOTICE file looks to be complete for source only release
>>
>> Rat tool is run as part of a bash script in dev-tools (assumes RAT has
>> been built in a peer directory). It has been run and noted files have had
>> the apache 2.0 license added (mostly .js, .html files)
>>
>> Shaded libraries are now included as part of the build and not included
>> from elsewhere
>>
>> Repos providing commercial derivatives of apache projects (eg cloudera)
>> have been replaced with the apache repo:
>> https://repository.apache.org/content/repositories
>>
>> For later releases which include binary artifacts, it's clear that we'll
>> need separate LICENSE, NOTICE files for each artifact. For this source
>> release I think we're getting fairly close. If the updates checkout by you
>> I can start a candidate release vote.
>>
>> Thanks
>> Kam
>>
>> On Tue, Jun 28, 2016 at 11:06 AM, Kam Kasravi <[email protected]>
>> wrote:
>>
>>> We'll add the rat tool as part of prepping the release.
>>>
>>> On Mon, Jun 27, 2016 at 5:43 PM, Andrew Purtell <[email protected]>
>>> wrote:
>>>
>>>> > You can run 'sbt dumpLicenseReport', which runs the equivalent of
>>>> the RAT tool.
>>>>
>>>> I don't think so. Apache RAT does more than just report on licenses, it
>>>> checks for Apache specific release policy compliance. Or did you mean that
>>>> sbt's dumpLicenseReport is actually set up in your project to run Apache
>>>> RAT?
>>>>
>>>> On Mon, Jun 27, 2016 at 5:23 PM, Kam Kasravi <[email protected]>
>>>> wrote:
>>>>
>>>>> Thanks Andy for going through RC0! Comments inline. I'll update and
>>>>> upload back under RC0.
>>>>>
>>>>> > - I imported the KEYS file but then failed to find the signing key.
>>>>> >
>>>>> > gpg --verify gearpump-0.8.1-incubating-src.tgz.asc
>>>>> gearpump-0.8.1-incubating-src.tgz
>>>>> > gpg: Signature made Fri 24 Jun 2016 03:07:40 PM PDT using RSA key ID
>>>>> E7DE27E3
>>>>> > gpg: Can't check signature: public key not found
>>>>> >
>>>>> > - recv-key E7DE27E3 worked
>>>>> >
>>>>> > gpg: key E7DE27E3: public key "Kam Kasravi (CODE SIGNING KEY) <
>>>>> [email protected]>" imported
>>>>> > gpg: Total number processed: 1
>>>>> > gpg:               imported: 1  (RSA: 1)
>>>>> >
>>>>> > - And now the signature check passes
>>>>> >
>>>>> > gpg: Signature made Fri 24 Jun 2016 03:07:40 PM PDT using RSA key ID
>>>>> E7DE27E3
>>>>> > gpg: Good signature from "Kam Kasravi (CODE SIGNING KEY) <
>>>>> [email protected]>"
>>>>> > gpg: WARNING: This key is not certified with a trusted signature!
>>>>> > gpg:          There is no indication that the signature belongs to
>>>>> the owner.
>>>>> > Primary key fingerprint: 4FF1 FDB7 1079 F43F 132D  FBBB 5806 2555
>>>>> E7DE 27E3
>>>>> >
>>>>> > I encourage Kam and everyone to go to an ApacheCon or the meetups of
>>>>> other projects and get your keys signed by other Apache folks. Yes, I
>>>>> should take my own advice... my code signing key has the same issue.
>>>>> > > - MD5 and SHA1 checksum files match file sums
>>>>> >
>>>>>
>>>>> [Kam] I've updated KEYS to include the CODE SIGNING KEY. I also
>>>>> updated our release shell script so it can also verify the signed 
>>>>> artifacts
>>>>> (dev-tools/create_apache_source_release.sh).
>>>>>
>>>>> > - Archive unpacks and layout looks good
>>>>> >
>>>>> > - LICENSE file looks ok, except maybe the text of the SIL Open Font
>>>>> License is missing?
>>>>>
>>>>> [Kam] I'll add this.
>>>>>
>>>>> >
>>>>> > - Is the NOTICE file complete? "If the dependency supplies a NOTICE
>>>>> file, its contents must be analyzed and the relevant portions bubbled up
>>>>> into the top-level NOTICE file." (
>>>>> http://www.apache.org/dev/licensing-howto.html) We don't want to add
>>>>> anything here not legally required, though. I'm assuming you went through
>>>>> all of your dependencies and checked if they have anything in a NOTICE
>>>>> file? If not let's do that.
>>>>>
>>>>> [Kam] For the source release I didn't - but best to do it now so
>>>>> subsequent binary artifacts are correctly handled.
>>>>>
>>>>> > > - I can't find build instructions on the website (eg.
>>>>> http://gearpump.incubator.apache.org/how-to-contribute.html). They
>>>>> are in the README.md, however.  How does one invoke 'sbt' such that it 
>>>>> will
>>>>> also run the Apache RAT tool?
>>>>>
>>>>> [Kam] You can run 'sbt dumpLicenseReport', which runs the equivalent
>>>>> of the RAT tool. The sbt plugin is here
>>>>> https://github.com/sbt/sbt-license-report. I've updated the README.md.
>>>>>
>>>>> > > - What is
>>>>> http://dl.bintray.com/fvunicorn/maven/org/apache/gearpump/gearpump-shaded-gs-collections/6.2.0/gearpump-shaded-gs-collections-6.2.0.jar
>>>>> ? I'm not sure this will be fatal to the release candidate but this is
>>>>> something that needs to be fixed. At the least it should be hosted on
>>>>> Apache infrastructure somewhere. Ideally, the shading and staging of
>>>>> gs-collections can be made part of the build so no need for a custom
>>>>> artifact of gs-collections just for gearpump. Same for
>>>>> gearpump-shaded-akka-kyro and anything like this I may have missed.
>>>>>
>>>>> [Kam] Fink also includes shaded jars. I'll follow their example.
>>>>>
>>>>> > > - Some code builds against a downstream commercial derivative of
>>>>> an Apache project, hosted on a third party repository. You should not be
>>>>> doing this. If you depend on Hadoop, build against an Apache released
>>>>> version of Hadoop.
>>>>>
>>>>> [Kam] Got it. I'll update our Build.scala, rerun
>>>>> 'sbt dumpLicenseReport' and reverify.
>>>>>
>>>>> > > When ready to start a release candidate vote, Mnemonic recently
>>>>> ran a vote, you can use that as an example.
>>>>> >
>>>>> > Vote thread: https://s.apache.org/NqCu
>>>>> >
>>>>> > Result: https://s.apache.org/wERS
>>>>>
>>>>>
>>>>> On Mon, Jun 27, 2016 at 3:52 PM, Andrew Purtell <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Kam posted artifacts for 0.8.1 RC0 and asked me to take a look at
>>>>>> them. Here are my notes:
>>>>>>
>>>>>> - I imported the KEYS file but then failed to find the signing key.
>>>>>>
>>>>>> gpg --verify gearpump-0.8.1-incubating-src.tgz.asc
>>>>>> gearpump-0.8.1-incubating-src.tgz
>>>>>> gpg: Signature made Fri 24 Jun 2016 03:07:40 PM PDT using RSA key ID
>>>>>> E7DE27E3
>>>>>> gpg: Can't check signature: public key not found
>>>>>>
>>>>>>
>>>>>> - recv-key E7DE27E3 worked
>>>>>>
>>>>>> gpg: key E7DE27E3: public key "Kam Kasravi (CODE SIGNING KEY) <
>>>>>> [email protected]>" imported
>>>>>> gpg: Total number processed: 1
>>>>>> gpg:               imported: 1  (RSA: 1)
>>>>>>
>>>>>>
>>>>>> - And now the signature check passes
>>>>>>
>>>>>> gpg: Signature made Fri 24 Jun 2016 03:07:40 PM PDT using RSA key ID
>>>>>> E7DE27E3
>>>>>> gpg: Good signature from "Kam Kasravi (CODE SIGNING KEY) <
>>>>>> [email protected]>"
>>>>>> gpg: WARNING: This key is not certified with a trusted signature!
>>>>>> gpg:          There is no indication that the signature belongs to
>>>>>> the owner.
>>>>>> Primary key fingerprint: 4FF1 FDB7 1079 F43F 132D  FBBB 5806 2555
>>>>>> E7DE 27E3
>>>>>>
>>>>>> I encourage Kam and everyone to go to an ApacheCon or the meetups of
>>>>>> other projects and get your keys signed by other Apache folks. Yes, I
>>>>>> should take my own advice... my code signing key has the same issue.
>>>>>>
>>>>>>
>>>>>> - MD5 and SHA1 checksum files match file sums
>>>>>>
>>>>>> - Archive unpacks and layout looks good
>>>>>>
>>>>>> - LICENSE file looks ok, except maybe the text of the SIL Open Font
>>>>>> License is missing?
>>>>>>
>>>>>> - Is the NOTICE file complete? "If the dependency supplies a NOTICE
>>>>>> file, its contents must be analyzed and the relevant portions bubbled up
>>>>>> into the top-level NOTICE file." (
>>>>>> http://www.apache.org/dev/licensing-howto.html) We don't want to add
>>>>>> anything here not legally required, though. I'm assuming you went through
>>>>>> all of your dependencies and checked if they have anything in a NOTICE
>>>>>> file? If not let's do that.
>>>>>>
>>>>>> - I can't find build instructions on the website (eg.
>>>>>> http://gearpump.incubator.apache.org/how-to-contribute.html). They
>>>>>> are in the README.md, however.  How does one invoke 'sbt' such that it 
>>>>>> will
>>>>>> also run the Apache RAT tool?
>>>>>>
>>>>>> - What is
>>>>>> http://dl.bintray.com/fvunicorn/maven/org/apache/gearpump/gearpump-shaded-gs-collections/6.2.0/gearpump-shaded-gs-collections-6.2.0.jar
>>>>>> ? I'm not sure this will be fatal to the release candidate but this is
>>>>>> something that needs to be fixed. At the least it should be hosted on
>>>>>> Apache infrastructure somewhere. Ideally, the shading and staging of
>>>>>> gs-collections can be made part of the build so no need for a custom
>>>>>> artifact of gs-collections just for gearpump. Same for
>>>>>> gearpump-shaded-akka-kyro and anything like this I may have missed.
>>>>>>
>>>>>> - Some code builds against a downstream commercial derivative of an
>>>>>> Apache project, hosted on a third party repository. You should not be 
>>>>>> doing
>>>>>> this. If you depend on Hadoop, build against an Apache released version 
>>>>>> of
>>>>>> Hadoop.
>>>>>>
>>>>>> When ready to start a release candidate vote, Mnemonic recently ran a
>>>>>> vote, you can use that as an example.
>>>>>>
>>>>>> Vote thread: https://s.apache.org/NqCu
>>>>>>
>>>>>> Result: https://s.apache.org/wERS
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>>
>>>>    - Andy
>>>>
>>>> Problems worthy of attack prove their worth by hitting back. - Piet
>>>> Hein (via Tom White)
>>>>
>>>
>>>
>>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Reply via email to