Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Christofer Dutz]

It was reported in the general incubator list that the sha files should be 
named sha1 or sha512 … a quick check of the man page of the sha-tool names 512 
as algorithm version. So, I renamed the files to the sha512 dale suggested 
earlier.

Chris

Am 09.12.17, 22:43 schrieb "Christofer Dutz" :

Hi Dale,

the reason for this is that the changelog plugin scans the git commit 
history to create a changelog. 
The zip however doesn’t contain this history. Therefore, the changelog 
plugin is failing.

Regarding the artifacts in Nexus … in maven, if I run “mvn compile” the 
java classes are compiled and available in the target/classes directory.
If you run “mvn package” this content is packaged in a jar. If you run “mvn 
install” this jar is then copied to the maven local repo. If you run “mvn 
deploy” then this jar is also uploaded to what’s defined in the apache poms 
(the parent of the Edgent parent):

  

  apache.releases.https
  Apache Release Distribution Repository
  
https://repository.apache.org/service/local/staging/deploy/maven2


  apache.snapshots.https
  ${distMgmtSnapshotsName}
  ${distMgmtSnapshotsUrl}

  

The “apache-release” profile additionally ensures the jars are signed and 
the signature, source, Javadoc and pom are uploaded to nexus.

So, the jars in Nexus should be equal to the ones in our maven local repo, 
just with the version 1.2.0 instead of 1.2.0-SNAPSHOT.

Chris


Am 09.12.17, 20:39 schrieb "Dale LaBossiere" :

I was able to successfully perform almost all of the validation on the 
source bundle that I wanted to:
- basically followed the non-RM, non-binary items in [6]
downloaded, checked signatures/sums, checked identical tar.gz / zip 
contents
verified LICENSE, NOTICE, DISCLAIMER, RELEASE_NOTES, README
build/tested via README

I will run the manual kafka tests to verify those look good.

But there are a couple of things...

- I wanted to review more detailed test result status from my manual 
release build/test validation
 (e.g., what was run / what was skipped as noted in [6]) but  “./mvnw 
clean install site:site site:stage”
 failed, complaining that the source tree wasn’t a git repo.

- It’s unclear to me if the *exact jar/war bits* staged in nexus have 
been tested or not.
  I suspect they have been tested, hence there’s nothing missing or 
broken, but want to verify.  Chris, can you elaborate on that please?
  If they have been tested as part the release process so far, is there 
a test results and code coverage reports
  that one can review?

[6] 
https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation 


— Dale

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Dale LaBossiere]

Thanks for the clarifications.

Is there any way to disable the changelog stuff - or some way to run the tests 
with code coverage and get aggregated html reports when building from a source 
release bundle?

Re Nexus, restating just to be sure I understand:  the release process’s “mvn 
deploy” (or at least a prior "mvn install”) built and successfully ran the 
tests on the built jars… and “deploy” uploads those exact jars to nexus.

I filed JIRA EDGENT-440 for the followup work related to our nexus artifacts.

— Dale

> On Dec 9, 2017, at 4:42 PM, Christofer Dutz  wrote:
> 
> Hi Dale,
> 
> the reason for this is that the changelog plugin scans the git commit history 
> to create a changelog. 
> The zip however doesn’t contain this history. Therefore, the changelog plugin 
> is failing.
> 
> Regarding the artifacts in Nexus … in maven, if I run “mvn compile” the java 
> classes are compiled and available in the target/classes directory.
> If you run “mvn package” this content is packaged in a jar. If you run “mvn 
> install” this jar is then copied to the maven local repo. If you run “mvn 
> deploy” then this jar is also uploaded to what’s defined in the apache poms 
> (the parent of the Edgent parent):
> 
>  
>
>  apache.releases.https
>  Apache Release Distribution Repository
>  
> https://repository.apache.org/service/local/staging/deploy/maven2
>
>
>  apache.snapshots.https
>  ${distMgmtSnapshotsName}
>  ${distMgmtSnapshotsUrl}
>
>  
> 
> The “apache-release” profile additionally ensures the jars are signed and the 
> signature, source, Javadoc and pom are uploaded to nexus.
> 
> So, the jars in Nexus should be equal to the ones in our maven local repo, 
> just with the version 1.2.0 instead of 1.2.0-SNAPSHOT.
> 
> Chris
> 
> 
> Am 09.12.17, 20:39 schrieb "Dale LaBossiere" :
> 
>I was able to successfully perform almost all of the validation on the 
> source bundle that I wanted to:
>- basically followed the non-RM, non-binary items in [6]
>downloaded, checked signatures/sums, checked identical tar.gz / zip 
> contents
>verified LICENSE, NOTICE, DISCLAIMER, RELEASE_NOTES, README
>build/tested via README
> 
>I will run the manual kafka tests to verify those look good.
> 
>But there are a couple of things...
> 
>- I wanted to review more detailed test result status from my manual 
> release build/test validation
> (e.g., what was run / what was skipped as noted in [6]) but  “./mvnw 
> clean install site:site site:stage”
> failed, complaining that the source tree wasn’t a git repo.
> 
>- It’s unclear to me if the *exact jar/war bits* staged in nexus have been 
> tested or not.
>  I suspect they have been tested, hence there’s nothing missing or 
> broken, but want to verify.  Chris, can you elaborate on that please?
>  If they have been tested as part the release process so far, is there a 
> test results and code coverage reports
>  that one can review?
> 
>[6] 
> https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation 
> 
> 
>— Dale
> 

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Dale LaBossiere]

I was able to successfully perform almost all of the validation on the source 
bundle that I wanted to:
- basically followed the non-RM, non-binary items in [6]
downloaded, checked signatures/sums, checked identical tar.gz / zip contents
verified LICENSE, NOTICE, DISCLAIMER, RELEASE_NOTES, README
build/tested via README

I will run the manual kafka tests to verify those look good.

But there are a couple of things...

- I wanted to review more detailed test result status from my manual release 
build/test validation
 (e.g., what was run / what was skipped as noted in [6]) but  “./mvnw clean 
install site:site site:stage”
 failed, complaining that the source tree wasn’t a git repo.

- It’s unclear to me if the *exact jar/war bits* staged in nexus have been 
tested or not.
  I suspect they have been tested, hence there’s nothing missing or broken, but 
want to verify.  Chris, can you elaborate on that please?
  If they have been tested as part the release process so far, is there a test 
results and code coverage reports
  that one can review?

[6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation 


— Dale

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Dale LaBossiere]

Interesting re the sha.  The updates regarding sha naming are pretty recent - 
last 6months or so.

So, they’re just wrong / not compatible with the real world and/or nexus 
generated info?
Actually, I suspect it’s OK to just ignore nexus with respect to this - i.e., 
it has it’s own naming
scheme and this ASF scheme is just for the source release repo.
“sha” is compatible with this directive so we can leave it as.

 http://www.apache.org/dev/release-distribution#sigs-and-sums 


Thanks
— Dale

> On Dec 7, 2017, at 4:00 AM, Christofer Dutz  wrote:
> 
> Hi Dale,
> 
> I added the zip and then noticed that the tag.gz did have some “next” and 
> “current” pom copies inside. So, I had a look at my original and they didn’t 
> have them, so I updated the tar.gz and its hashes.
> 
> Also, I did rename the sha512 back to sha as SHA is the algorithm … you 
> usually encounter SHA, SHA1 or SHA2, but never SHA512 in the wild. 
> 
> Regarding the hashes in Nexus: We shouldn’t change this, as these are the 
> hashes Maven works with. If we change this, it could be that the artifacts 
> are no longer accessible. The build isn’t generating them anyway but Nexus 
> generates them automatically. So I guess even if we wanted to change things, 
> we couldn’t.
> 
> Chris
> 
> 
> 
> Am 06.12.17, 23:55 schrieb "Dale LaBossiere" :
> 
>Agreed on all points regarding the zip.  
> 
>Since you offered, I updated the scripts to require it and the sha512 
> noted below :-)
>The verification includes verifying the tar.gz and zip contents are the 
> same.
> 
>On another topic, [1] says the suffix MUST be sha512 for a SHA 512 sum 
> (which in fact is what the file contains)
>apache-edgent-1.2.0-incubating-source-release.tar.gz.sha1
> 
>So that needs be changed in the staging area in addition to staging the 
> zip and its sums/sig.
> 
>Thanks!
>— Dale
> 
>[1] http://www.apache.org/dev/release-distribution#sigs-and-sums
> 
>> On Dec 6, 2017, at 2:35 PM, Christofer Dutz  
>> wrote:
>> ...
>> I just had a look at what the script was looking for. If releasing tar and 
>> zip i think we would have to do the checking for both types. I can add the 
>> other zip easily. But in that Case i would suggest adding that to the script 
>> and add one check to make sure the content is identical. Would be good If we 
>> could be sure we need to detail-check only one.
>> ...
>> From: Dale LaBossiere 
>> ...
>> -Papache-release also generates a zip.  I had expected we’d be releasing 
>> that too but it isn’t staged.
>> At this time I’m fine if we just continue 1.2.0 with only the tar.gz but if 
>> you also want to stage the zip that's fine too.
>> 
>> I just need to know which way we’re going because I need to adjust the 
>> “downloads” website page accordingly.
> 
> 
> 

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Christofer Dutz]

Ok … so I removed all the distribution and the „tests“-modules from the staging 
repo.

Chris


Am 07.12.17, 10:00 schrieb "Christofer Dutz" :

Hi Dale,

I added the zip and then noticed that the tag.gz did have some “next” and 
“current” pom copies inside. So, I had a look at my original and they didn’t 
have them, so I updated the tar.gz and its hashes.

Also, I did rename the sha512 back to sha as SHA is the algorithm … you 
usually encounter SHA, SHA1 or SHA2, but never SHA512 in the wild. 

Regarding the hashes in Nexus: We shouldn’t change this, as these are the 
hashes Maven works with. If we change this, it could be that the artifacts are 
no longer accessible. The build isn’t generating them anyway but Nexus 
generates them automatically. So I guess even if we wanted to change things, we 
couldn’t.

Chris



Am 06.12.17, 23:55 schrieb "Dale LaBossiere" :

Agreed on all points regarding the zip.  

Since you offered, I updated the scripts to require it and the sha512 
noted below :-)
The verification includes verifying the tar.gz and zip contents are the 
same.

On another topic, [1] says the suffix MUST be sha512 for a SHA 512 sum 
(which in fact is what the file contains)
apache-edgent-1.2.0-incubating-source-release.tar.gz.sha1

So that needs be changed in the staging area in addition to staging the 
zip and its sums/sig.

Thanks!
— Dale

[1] http://www.apache.org/dev/release-distribution#sigs-and-sums

> On Dec 6, 2017, at 2:35 PM, Christofer Dutz 
 wrote:
> ...
> I just had a look at what the script was looking for. If releasing 
tar and zip i think we would have to do the checking for both types. I can add 
the other zip easily. But in that Case i would suggest adding that to the 
script and add one check to make sure the content is identical. Would be good 
If we could be sure we need to detail-check only one.
> ...
> From: Dale LaBossiere 
> ...
> -Papache-release also generates a zip.  I had expected we’d be 
releasing that too but it isn’t staged.
> At this time I’m fine if we just continue 1.2.0 with only the tar.gz 
but if you also want to stage the zip that's fine too.
> 
> I just need to know which way we’re going because I need to adjust 
the “downloads” website page accordingly.

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Christofer Dutz]

Hi Dale,

I added the zip and then noticed that the tag.gz did have some “next” and 
“current” pom copies inside. So, I had a look at my original and they didn’t 
have them, so I updated the tar.gz and its hashes.

Also, I did rename the sha512 back to sha as SHA is the algorithm … you usually 
encounter SHA, SHA1 or SHA2, but never SHA512 in the wild. 

Regarding the hashes in Nexus: We shouldn’t change this, as these are the 
hashes Maven works with. If we change this, it could be that the artifacts are 
no longer accessible. The build isn’t generating them anyway but Nexus 
generates them automatically. So I guess even if we wanted to change things, we 
couldn’t.

Chris



Am 06.12.17, 23:55 schrieb "Dale LaBossiere" :

Agreed on all points regarding the zip.  

Since you offered, I updated the scripts to require it and the sha512 noted 
below :-)
The verification includes verifying the tar.gz and zip contents are the 
same.

On another topic, [1] says the suffix MUST be sha512 for a SHA 512 sum 
(which in fact is what the file contains)
apache-edgent-1.2.0-incubating-source-release.tar.gz.sha1

So that needs be changed in the staging area in addition to staging the zip 
and its sums/sig.

Thanks!
— Dale

[1] http://www.apache.org/dev/release-distribution#sigs-and-sums

> On Dec 6, 2017, at 2:35 PM, Christofer Dutz  
wrote:
> ...
> I just had a look at what the script was looking for. If releasing tar 
and zip i think we would have to do the checking for both types. I can add the 
other zip easily. But in that Case i would suggest adding that to the script 
and add one check to make sure the content is identical. Would be good If we 
could be sure we need to detail-check only one.
> ...
> From: Dale LaBossiere 
> ...
> -Papache-release also generates a zip.  I had expected we’d be releasing 
that too but it isn’t staged.
> At this time I’m fine if we just continue 1.2.0 with only the tar.gz but 
if you also want to stage the zip that's fine too.
> 
> I just need to know which way we’re going because I need to adjust the 
“downloads” website page accordingly.

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Dale LaBossiere]

Agreed on all points regarding the zip.  

Since you offered, I updated the scripts to require it and the sha512 noted 
below :-)
The verification includes verifying the tar.gz and zip contents are the same.

On another topic, [1] says the suffix MUST be sha512 for a SHA 512 sum (which 
in fact is what the file contains)
apache-edgent-1.2.0-incubating-source-release.tar.gz.sha1

So that needs be changed in the staging area in addition to staging the zip and 
its sums/sig.

Thanks!
— Dale

[1] http://www.apache.org/dev/release-distribution#sigs-and-sums

> On Dec 6, 2017, at 2:35 PM, Christofer Dutz  wrote:
> ...
> I just had a look at what the script was looking for. If releasing tar and 
> zip i think we would have to do the checking for both types. I can add the 
> other zip easily. But in that Case i would suggest adding that to the script 
> and add one check to make sure the content is identical. Would be good If we 
> could be sure we need to detail-check only one.
> ...
> From: Dale LaBossiere 
> ...
> -Papache-release also generates a zip.  I had expected we’d be releasing that 
> too but it isn’t staged.
> At this time I’m fine if we just continue 1.2.0 with only the tar.gz but if 
> you also want to stage the zip that's fine too.
> 
> I just need to know which way we’re going because I need to adjust the 
> “downloads” website page accordingly.

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Justin Mclean]

Hi,

> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm No 
> expert on that. My key should be valid judging from the number of Apaches 
> that signed it. Eventually there is no path of trust and you need to import 
> it manually.

The warning is fine - it just means that Chis is not in Dale’s web of trust. 
I’d assume Dale has not gone to an ASF key signing party.

The important part is that it is a good signature and it’s signed by an 
apache.org email.

Thanks,
Justin

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Christofer Dutz]

Hi Dale,

I just had a look at what the script was looking for. If releasing tar and zip 
i think we would have to do the checking for both types. I can add the other 
zip easily. But in that Case i would suggest adding that to the script and add 
one check to make sure the content is identical. Would be good If we could be 
sure we need to detail-check only one.

Chris

Outlook for Android<https://aka.ms/ghei36> herunterladen


From: Dale LaBossiere <dml.apa...@gmail.com>
Sent: Wednesday, December 6, 2017 7:28:11 PM
To: dev@edgent.apache.org
Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

I’ll pull of that trust thread, thx.

Another question re RC1:

-Papache-release also generates a zip.  I had expected we’d be releasing that 
too but it isn’t staged.
At this time I’m fine if we just continue 1.2.0 with only the tar.gz but if you 
also want to stage the zip that's fine too.

I just need to know which way we’re going because I need to adjust the 
“downloads” website page accordingly.

— Dale

> On Dec 6, 2017, at 11:46 AM, Christofer Dutz <christofer.d...@c-ware.de> 
> wrote:
>
> I think in the gpg GUI Tool you also have to explicitly "trust" a Key. 
> Otherwise its Just a Key.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
> 
> From: Dale LaBossiere <dml.apa...@gmail.com>
> Sent: Wednesday, December 6, 2017 5:31:03 PM
> To: dev@edgent.apache.org
> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
>
> I hear your pain :-)
>
> FWIW, I did import your key using the (possibly incomplete?) directions 
> reported by the script.
> That’s why I was wondering if you saw the same thing for 1.2.0 and 1.1.0.
>
> I did what it told me to below when it failed the 1st time I ran it.
> buildTools/download_edgent_asf.sh —validate 1.2.0 1
> ...
> If the following bundle gpg signature checks fail, you may need to
> import the project's list of signing keys to your keyring
>$ gpg downloaded-edgent-1.2.0rc1/KEYS# show the included keys
>$ gpg --import downloaded-edgent-1.2.0rc1/KEYS
> …
>
>
>> On Dec 6, 2017, at 11:24 AM, Christofer Dutz <christofer.d...@c-ware.de> 
>> wrote:
>>
>> Hi Dale,
>>
>> I'm still on the task of manually deleting Things. Will continue tomorrow. 
>> Have to manually delete at least 4 Files for every artifact one at a time :-(
>>
>> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm 
>> No expert on that. My key should be valid judging from the number of Apaches 
>> that signed it. Eventually there is no path of trust and you need to import 
>> it manually.
>>
>> Chris
>>
>> Outlook for Android<https://aka.ms/ghei36> herunterladen
>>
>> 
>> From: Dale LaBossiere <dml.apa...@gmail.com>
>> Sent: Wednesday, December 6, 2017 5:08:27 PM
>> To: dev@edgent.apache.org
>> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
>>
>> Thx re the nexus content.
>>
>> I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I 
>> don’t
>> get when downloading/validating 1.1.0.
>> Might your KEY changes have an issue or you didn’t “published” your key or 
>> such?
>> Or maybe it’s just that with 1.1.0 I’m just validating something that I 
>> signed
>> to it doesn’t complain for me?
>>
>> Do you get the WARNING below when you
>> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
>>
>> Do you get the WARNING if for 1.1.0?
>> Using the *master* branch for the script:
>> buildTools/download_edgent_asf.sh  —validate 1.1.0
>>
>> When I run
>> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
>> ...
>> Verifying the source bundle signatures...
>> + /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
>> 1.2.0-incubating/rc1
>>
>> Checking 
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz 
>> MD5 OK
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz 
>> SHA OK
>> gpg: assuming signed data in 
>> '1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
>> gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
>> gpg: Good signature from "Christofer Dutz (Apache Comitter) 
>> <cd...@apache.org>" [unknown]
>> gpg: aka "[jpeg image of size 272202]&qu

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Dale LaBossiere]

I’ll pull of that trust thread, thx.

Another question re RC1:

-Papache-release also generates a zip.  I had expected we’d be releasing that 
too but it isn’t staged.
At this time I’m fine if we just continue 1.2.0 with only the tar.gz but if you 
also want to stage the zip that's fine too.

I just need to know which way we’re going because I need to adjust the 
“downloads” website page accordingly.

— Dale

> On Dec 6, 2017, at 11:46 AM, Christofer Dutz <christofer.d...@c-ware.de> 
> wrote:
> 
> I think in the gpg GUI Tool you also have to explicitly "trust" a Key. 
> Otherwise its Just a Key.
> 
> Chris
> 
> Outlook for Android<https://aka.ms/ghei36> herunterladen
> 
> 
> From: Dale LaBossiere <dml.apa...@gmail.com>
> Sent: Wednesday, December 6, 2017 5:31:03 PM
> To: dev@edgent.apache.org
> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
> 
> I hear your pain :-)
> 
> FWIW, I did import your key using the (possibly incomplete?) directions 
> reported by the script.
> That’s why I was wondering if you saw the same thing for 1.2.0 and 1.1.0.
> 
> I did what it told me to below when it failed the 1st time I ran it.
> buildTools/download_edgent_asf.sh —validate 1.2.0 1
> ...
> If the following bundle gpg signature checks fail, you may need to
> import the project's list of signing keys to your keyring
>$ gpg downloaded-edgent-1.2.0rc1/KEYS# show the included keys
>$ gpg --import downloaded-edgent-1.2.0rc1/KEYS
> …
> 
> 
>> On Dec 6, 2017, at 11:24 AM, Christofer Dutz <christofer.d...@c-ware.de> 
>> wrote:
>> 
>> Hi Dale,
>> 
>> I'm still on the task of manually deleting Things. Will continue tomorrow. 
>> Have to manually delete at least 4 Files for every artifact one at a time :-(
>> 
>> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm 
>> No expert on that. My key should be valid judging from the number of Apaches 
>> that signed it. Eventually there is no path of trust and you need to import 
>> it manually.
>> 
>> Chris
>> 
>> Outlook for Android<https://aka.ms/ghei36> herunterladen
>> 
>> 
>> From: Dale LaBossiere <dml.apa...@gmail.com>
>> Sent: Wednesday, December 6, 2017 5:08:27 PM
>> To: dev@edgent.apache.org
>> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
>> 
>> Thx re the nexus content.
>> 
>> I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I 
>> don’t
>> get when downloading/validating 1.1.0.
>> Might your KEY changes have an issue or you didn’t “published” your key or 
>> such?
>> Or maybe it’s just that with 1.1.0 I’m just validating something that I 
>> signed
>> to it doesn’t complain for me?
>> 
>> Do you get the WARNING below when you
>> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
>> 
>> Do you get the WARNING if for 1.1.0?
>> Using the *master* branch for the script:
>> buildTools/download_edgent_asf.sh  —validate 1.1.0
>> 
>> When I run
>> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
>> ...
>> Verifying the source bundle signatures...
>> + /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
>> 1.2.0-incubating/rc1
>> 
>> Checking 
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz 
>> MD5 OK
>> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz 
>> SHA OK
>> gpg: assuming signed data in 
>> '1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
>> gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
>> gpg: Good signature from "Christofer Dutz (Apache Comitter) 
>> <cd...@apache.org>" [unknown]
>> gpg: aka "[jpeg image of size 272202]" [unknown]
>> 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: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9
>> 
>> — Dale
>> 
>>> On Dec 6, 2017, at 10:44 AM, Christofer Dutz <christofer.d...@c-ware.de> 
>>> wrote:
>>> 
>>> Hi Dale,
>>> 
>>> I guess I updated the KEY manually and it seems to be ok the way it is now.
>>> 
>>> Regarding stuff in Nexus, we should remove before hitting the “release

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Christofer Dutz]

I think in the gpg GUI Tool you also have to explicitly "trust" a Key. 
Otherwise its Just a Key.

Chris

Outlook for Android<https://aka.ms/ghei36> herunterladen


From: Dale LaBossiere <dml.apa...@gmail.com>
Sent: Wednesday, December 6, 2017 5:31:03 PM
To: dev@edgent.apache.org
Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

I hear your pain :-)

FWIW, I did import your key using the (possibly incomplete?) directions 
reported by the script.
That’s why I was wondering if you saw the same thing for 1.2.0 and 1.1.0.

I did what it told me to below when it failed the 1st time I ran it.
buildTools/download_edgent_asf.sh —validate 1.2.0 1
...
If the following bundle gpg signature checks fail, you may need to
import the project's list of signing keys to your keyring
$ gpg downloaded-edgent-1.2.0rc1/KEYS# show the included keys
$ gpg --import downloaded-edgent-1.2.0rc1/KEYS
…


> On Dec 6, 2017, at 11:24 AM, Christofer Dutz <christofer.d...@c-ware.de> 
> wrote:
>
> Hi Dale,
>
> I'm still on the task of manually deleting Things. Will continue tomorrow. 
> Have to manually delete at least 4 Files for every artifact one at a time :-(
>
> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm No 
> expert on that. My key should be valid judging from the number of Apaches 
> that signed it. Eventually there is no path of trust and you need to import 
> it manually.
>
> Chris
>
> Outlook for Android<https://aka.ms/ghei36> herunterladen
>
> 
> From: Dale LaBossiere <dml.apa...@gmail.com>
> Sent: Wednesday, December 6, 2017 5:08:27 PM
> To: dev@edgent.apache.org
> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
>
> Thx re the nexus content.
>
> I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I 
> don’t
> get when downloading/validating 1.1.0.
> Might your KEY changes have an issue or you didn’t “published” your key or 
> such?
> Or maybe it’s just that with 1.1.0 I’m just validating something that I signed
> to it doesn’t complain for me?
>
> Do you get the WARNING below when you
> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
>
> Do you get the WARNING if for 1.1.0?
> Using the *master* branch for the script:
> buildTools/download_edgent_asf.sh  —validate 1.1.0
>
> When I run
> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
> ...
> Verifying the source bundle signatures...
> + /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
> 1.2.0-incubating/rc1
>
> Checking 
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz MD5 
> OK
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz SHA 
> OK
> gpg: assuming signed data in 
> '1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
> gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
> gpg: Good signature from "Christofer Dutz (Apache Comitter) 
> <cd...@apache.org>" [unknown]
> gpg: aka "[jpeg image of size 272202]" [unknown]
> 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: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9
>
> — Dale
>
>> On Dec 6, 2017, at 10:44 AM, Christofer Dutz <christofer.d...@c-ware.de> 
>> wrote:
>>
>> Hi Dale,
>>
>> I guess I updated the KEY manually and it seems to be ok the way it is now.
>>
>> Regarding stuff in Nexus, we should remove before hitting the “release” 
>> button:
>> - Intermediate poms are important as they are defined as “parent” of other 
>> artifacts. Maven downloads them in order to know the entire modules pom, if 
>> we omit the intermediate poms, all is broken. This is especially true for 
>> the edgent-parent pom.
>> - Yes, we should remove:
>> o Distributions
>> o Test-Jars
>> o Source-Release archives
>> (I’ll see if I can manually remove them otherwise, I would drop the staging 
>> repo … re-do the staging of the maven artifacts and then manually delete 
>> them before closing the repo)
>> - First thing we should then do in develop for 1.3.0 is to fine tune the 
>> maven-deploy-plugin to only deploy stuff we want it to.
>>
>> Chris
>>
>>
>>
>> Am 06.12.17, 16:32 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
>>
>>
>>   Re the KEYS, please update th

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Dale LaBossiere]

I hear your pain :-)

FWIW, I did import your key using the (possibly incomplete?) directions 
reported by the script.
That’s why I was wondering if you saw the same thing for 1.2.0 and 1.1.0.

I did what it told me to below when it failed the 1st time I ran it.
buildTools/download_edgent_asf.sh —validate 1.2.0 1
...
If the following bundle gpg signature checks fail, you may need to
import the project's list of signing keys to your keyring
$ gpg downloaded-edgent-1.2.0rc1/KEYS# show the included keys
$ gpg --import downloaded-edgent-1.2.0rc1/KEYS
…


> On Dec 6, 2017, at 11:24 AM, Christofer Dutz <christofer.d...@c-ware.de> 
> wrote:
> 
> Hi Dale,
> 
> I'm still on the task of manually deleting Things. Will continue tomorrow. 
> Have to manually delete at least 4 Files for every artifact one at a time :-(
> 
> Regarding the pgp issue i guess you have to Import my Key somehow. But i'm No 
> expert on that. My key should be valid judging from the number of Apaches 
> that signed it. Eventually there is no path of trust and you need to import 
> it manually.
> 
> Chris
> 
> Outlook for Android<https://aka.ms/ghei36> herunterladen
> 
> 
> From: Dale LaBossiere <dml.apa...@gmail.com>
> Sent: Wednesday, December 6, 2017 5:08:27 PM
> To: dev@edgent.apache.org
> Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
> 
> Thx re the nexus content.
> 
> I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I 
> don’t
> get when downloading/validating 1.1.0.
> Might your KEY changes have an issue or you didn’t “published” your key or 
> such?
> Or maybe it’s just that with 1.1.0 I’m just validating something that I signed
> to it doesn’t complain for me?
> 
> Do you get the WARNING below when you
> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
> 
> Do you get the WARNING if for 1.1.0?
> Using the *master* branch for the script:
> buildTools/download_edgent_asf.sh  —validate 1.1.0
> 
> When I run
> buildTools/download_edgent_asf.sh  —validate 1.2.0 1
> ...
> Verifying the source bundle signatures...
> + /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
> 1.2.0-incubating/rc1
> 
> Checking 
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz MD5 
> OK
> 1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz SHA 
> OK
> gpg: assuming signed data in 
> '1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
> gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
> gpg: Good signature from "Christofer Dutz (Apache Comitter) 
> <cd...@apache.org>" [unknown]
> gpg: aka "[jpeg image of size 272202]" [unknown]
> 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: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9
> 
> — Dale
> 
>> On Dec 6, 2017, at 10:44 AM, Christofer Dutz <christofer.d...@c-ware.de> 
>> wrote:
>> 
>> Hi Dale,
>> 
>> I guess I updated the KEY manually and it seems to be ok the way it is now.
>> 
>> Regarding stuff in Nexus, we should remove before hitting the “release” 
>> button:
>> - Intermediate poms are important as they are defined as “parent” of other 
>> artifacts. Maven downloads them in order to know the entire modules pom, if 
>> we omit the intermediate poms, all is broken. This is especially true for 
>> the edgent-parent pom.
>> - Yes, we should remove:
>> o Distributions
>> o Test-Jars
>> o Source-Release archives
>> (I’ll see if I can manually remove them otherwise, I would drop the staging 
>> repo … re-do the staging of the maven artifacts and then manually delete 
>> them before closing the repo)
>> - First thing we should then do in develop for 1.3.0 is to fine tune the 
>> maven-deploy-plugin to only deploy stuff we want it to.
>> 
>> Chris
>> 
>> 
>> 
>> Am 06.12.17, 16:32 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
>> 
>> 
>>   Re the KEYS, please update the file in the incubator-edgent source repo.
>> 
>>   FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing 
>> the release”
>>   process is supposed to *move* the exact staged/voted artifacts to the 
>> release area.
>>   I see the our buildTools/publish_release.sh script doesn’t bother to 
>> delete the
>>  

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Christofer Dutz]

Hi Dale,

I'm still on the task of manually deleting Things. Will continue tomorrow. Have 
to manually delete at least 4 Files for every artifact one at a time :-(

Regarding the pgp issue i guess you have to Import my Key somehow. But i'm No 
expert on that. My key should be valid judging from the number of Apaches that 
signed it. Eventually there is no path of trust and you need to import it 
manually.

Chris

Outlook for Android<https://aka.ms/ghei36> herunterladen


From: Dale LaBossiere <dml.apa...@gmail.com>
Sent: Wednesday, December 6, 2017 5:08:27 PM
To: dev@edgent.apache.org
Subject: Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

Thx re the nexus content.

I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I don’t
get when downloading/validating 1.1.0.
Might your KEY changes have an issue or you didn’t “published” your key or such?
Or maybe it’s just that with 1.1.0 I’m just validating something that I signed
to it doesn’t complain for me?

Do you get the WARNING below when you
buildTools/download_edgent_asf.sh  —validate 1.2.0 1

Do you get the WARNING if for 1.1.0?
Using the *master* branch for the script:
buildTools/download_edgent_asf.sh  —validate 1.1.0

When I run
buildTools/download_edgent_asf.sh  —validate 1.2.0 1
...
Verifying the source bundle signatures...
+ /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
1.2.0-incubating/rc1

Checking 
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz MD5 OK
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz SHA OK
gpg: assuming signed data in 
'1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
gpg: Good signature from "Christofer Dutz (Apache Comitter) <cd...@apache.org>" 
[unknown]
gpg: aka "[jpeg image of size 272202]" [unknown]
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: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9

— Dale

> On Dec 6, 2017, at 10:44 AM, Christofer Dutz <christofer.d...@c-ware.de> 
> wrote:
>
> Hi Dale,
>
> I guess I updated the KEY manually and it seems to be ok the way it is now.
>
> Regarding stuff in Nexus, we should remove before hitting the “release” 
> button:
> - Intermediate poms are important as they are defined as “parent” of other 
> artifacts. Maven downloads them in order to know the entire modules pom, if 
> we omit the intermediate poms, all is broken. This is especially true for the 
> edgent-parent pom.
> - Yes, we should remove:
> o Distributions
> o Test-Jars
> o Source-Release archives
> (I’ll see if I can manually remove them otherwise, I would drop the staging 
> repo … re-do the staging of the maven artifacts and then manually delete them 
> before closing the repo)
> - First thing we should then do in develop for 1.3.0 is to fine tune the 
> maven-deploy-plugin to only deploy stuff we want it to.
>
> Chris
>
>
>
> Am 06.12.17, 16:32 schrieb "Dale LaBossiere" <dml.apa...@gmail.com>:
>
>
>Re the KEYS, please update the file in the incubator-edgent source repo.
>
>FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing 
> the release”
>process is supposed to *move* the exact staged/voted artifacts to the 
> release area.
>I see the our buildTools/publish_release.sh script doesn’t bother to 
> delete the
>residual staged  dir.
>
>In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS 
> in the
>“release” area (from the “dev” area) so that will be taken care of 
> automatically if the script is used.
>It looks like it should work without any changes.
>
>Agreed, no need to cancel the RC1 vote at this moment since as you note,
>the RC1 source content hasn’t changed.  And generally, updating the 
> poms,etc
>for “what’s released” is OK to not include in the 1.2.0 source release.  
> But...
>
>I think some things MUST get removed from Nexus for 1.2.0.  Do you agree?
>  - edgent-distribution (for j8,j7,android)
>  - edgent-parent/*source-release* - or edgent-parent in its entirety?  
> (for j8,j7,android)
>  - …/*-1.2.0-tests.*   (for j8,j7,android)
>  - edgent-test* (for j8,j7)
>  - what about “pom-only” intermediate dirs - will those show up in MC? 
> Are they useful?
>- edgent-analytics
>- edgent-android
>- edgent-api
>...
>
>
>> On Dec 6, 2017, at 4:00 AM, Chr

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Dale LaBossiere]

Thx re the nexus content.

I’m getting a gpg warning validating the 1.2.0RC1 bundle signature that I don’t
get when downloading/validating 1.1.0.
Might your KEY changes have an issue or you didn’t “published” your key or such?
Or maybe it’s just that with 1.1.0 I’m just validating something that I signed
to it doesn’t complain for me?

Do you get the WARNING below when you
buildTools/download_edgent_asf.sh  —validate 1.2.0 1

Do you get the WARNING if for 1.1.0?
Using the *master* branch for the script:
buildTools/download_edgent_asf.sh  —validate 1.1.0

When I run
buildTools/download_edgent_asf.sh  —validate 1.2.0 1
...
Verifying the source bundle signatures...
+ /Users/dlaboss/git/incubator-edgent-develop/buildTools/check_sigs.sh 
1.2.0-incubating/rc1

Checking 
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz...
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz MD5 OK
1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz SHA OK
gpg: assuming signed data in 
'1.2.0-incubating/rc1/apache-edgent-1.2.0-incubating-source-release.tar.gz'
gpg: Signature made Fri Dec  1 03:32:10 2017 EST using RSA key ID 5C60D6B9
gpg: Good signature from "Christofer Dutz (Apache Comitter) " 
[unknown]
gpg: aka "[jpeg image of size 272202]" [unknown]
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: F156 813F F315 007E 36BA  6C13 0891 27C1 5C60 D6B9

— Dale

> On Dec 6, 2017, at 10:44 AM, Christofer Dutz  
> wrote:
> 
> Hi Dale,
> 
> I guess I updated the KEY manually and it seems to be ok the way it is now.
> 
> Regarding stuff in Nexus, we should remove before hitting the “release” 
> button:
> - Intermediate poms are important as they are defined as “parent” of other 
> artifacts. Maven downloads them in order to know the entire modules pom, if 
> we omit the intermediate poms, all is broken. This is especially true for the 
> edgent-parent pom.
> - Yes, we should remove:
> o Distributions
> o Test-Jars
> o Source-Release archives
> (I’ll see if I can manually remove them otherwise, I would drop the staging 
> repo … re-do the staging of the maven artifacts and then manually delete them 
> before closing the repo)
> - First thing we should then do in develop for 1.3.0 is to fine tune the 
> maven-deploy-plugin to only deploy stuff we want it to.
> 
> Chris
> 
> 
> 
> Am 06.12.17, 16:32 schrieb "Dale LaBossiere" :
> 
> 
>Re the KEYS, please update the file in the incubator-edgent source repo.
> 
>FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing 
> the release”
>process is supposed to *move* the exact staged/voted artifacts to the 
> release area.
>I see the our buildTools/publish_release.sh script doesn’t bother to 
> delete the
>residual staged  dir.
> 
>In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS 
> in the
>“release” area (from the “dev” area) so that will be taken care of 
> automatically if the script is used.
>It looks like it should work without any changes.
> 
>Agreed, no need to cancel the RC1 vote at this moment since as you note, 
>the RC1 source content hasn’t changed.  And generally, updating the 
> poms,etc
>for “what’s released” is OK to not include in the 1.2.0 source release.  
> But...
> 
>I think some things MUST get removed from Nexus for 1.2.0.  Do you agree?
>  - edgent-distribution (for j8,j7,android)
>  - edgent-parent/*source-release* - or edgent-parent in its entirety?  
> (for j8,j7,android)
>  - …/*-1.2.0-tests.*   (for j8,j7,android)
>  - edgent-test* (for j8,j7)
>  - what about “pom-only” intermediate dirs - will those show up in MC? 
> Are they useful?
>- edgent-analytics
>- edgent-android
>- edgent-api
>...
> 
> 
>> On Dec 6, 2017, at 4:00 AM, Christofer Dutz  
>> wrote:
>> 
>> Hi Dale,
>> 
>> So, I updated the scripts, deployed the RC in the correct area (I wonder why 
>> the other 1.0.0 and 1.1.0 areas are empty. Unfortunately, I had to test 
>> myself to the right solution by running the scripts and fine tuning my 
>> deployment and the scripts. But now I think we have a working solution. As 
>> nothing had to be changed with the source-bundle itself, I don’t think we 
>> need to cancel the RC and create a new one. What do you others think?
>> 
>> Chris
>> 
>> 
>> Am 06.12.17, 09:10 schrieb "Christofer Dutz" :
>> 
>>   HI Dale,
>> 
>>   as I mentioned in the other DISCUSS thread I already noticed this 
>> shortcoming. 
>>   I think the following path should be ok for us to follow:
>> 
>>   1. I manually add my pgp key to the list in KEYS in SVN
>>   2. I manually add the files created by the assembly plugin to SVN
>>   3. 

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Christofer Dutz]

Hi Dale,

I guess I updated the KEY manually and it seems to be ok the way it is now.

Regarding stuff in Nexus, we should remove before hitting the “release” button:
- Intermediate poms are important as they are defined as “parent” of other 
artifacts. Maven downloads them in order to know the entire modules pom, if we 
omit the intermediate poms, all is broken. This is especially true for the 
edgent-parent pom.
- Yes, we should remove:
o Distributions
o Test-Jars
o Source-Release archives
(I’ll see if I can manually remove them otherwise, I would drop the staging 
repo … re-do the staging of the maven artifacts and then manually delete them 
before closing the repo)
- First thing we should then do in develop for 1.3.0 is to fine tune the 
maven-deploy-plugin to only deploy stuff we want it to.

Chris



Am 06.12.17, 16:32 schrieb "Dale LaBossiere" :


Re the KEYS, please update the file in the incubator-edgent source repo.

FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing 
the release”
process is supposed to *move* the exact staged/voted artifacts to the 
release area.
I see the our buildTools/publish_release.sh script doesn’t bother to delete 
the
residual staged  dir.

In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS 
in the
“release” area (from the “dev” area) so that will be taken care of 
automatically if the script is used.
It looks like it should work without any changes.

Agreed, no need to cancel the RC1 vote at this moment since as you note, 
the RC1 source content hasn’t changed.  And generally, updating the poms,etc
for “what’s released” is OK to not include in the 1.2.0 source release.  
But...

I think some things MUST get removed from Nexus for 1.2.0.  Do you agree?
  - edgent-distribution (for j8,j7,android)
  - edgent-parent/*source-release* - or edgent-parent in its entirety?  
(for j8,j7,android)
  - …/*-1.2.0-tests.*   (for j8,j7,android)
  - edgent-test* (for j8,j7)
  - what about “pom-only” intermediate dirs - will those show up in MC? Are 
they useful?
- edgent-analytics
- edgent-android
- edgent-api
...


> On Dec 6, 2017, at 4:00 AM, Christofer Dutz  
wrote:
> 
> Hi Dale,
> 
> So, I updated the scripts, deployed the RC in the correct area (I wonder 
why the other 1.0.0 and 1.1.0 areas are empty. Unfortunately, I had to test 
myself to the right solution by running the scripts and fine tuning my 
deployment and the scripts. But now I think we have a working solution. As 
nothing had to be changed with the source-bundle itself, I don’t think we need 
to cancel the RC and create a new one. What do you others think?
> 
> Chris
> 
> 
> Am 06.12.17, 09:10 schrieb "Christofer Dutz" :
> 
>HI Dale,
> 
>as I mentioned in the other DISCUSS thread I already noticed this 
shortcoming. 
>I think the following path should be ok for us to follow:
> 
>1. I manually add my pgp key to the list in KEYS in SVN
>2. I manually add the files created by the assembly plugin to SVN
>3. We continue the voting
>4. In develop I try to automate the deployment of RCs for the next 
version
>5. We decide what to deploy and what not to and add exclusions to the 
poms for next time
> 
>You think that’s a valid approach?
> 
>Chris
> 
> 
> 
>Am 06.12.17, 00:09 schrieb "Dale LaBossiere" :
> 
>Chris, thanks for moving the release/RC along!
> 
>I’ve kicked off this DISCUSS thread because I'm unable to tell if 
the
>staged RC is good to go or not and I didn’t want to pollute the 
RC1 Vote thread.
> 
>Since this is a new process for the project and the nexus / maven 
release flow
>is new to me I’m confused and have to ask some questions before I 
can assess
>if the RC contents are ok.
> 
>I, and others, definitely can’t follow the directions in the 
VOTE's [6] 
>even reading between the lines and omitting the RM and “binary” 
parts of it :-)
> 
>Here’s where I’m stumbling:
> 
>- I’m of the belief that the traditional normally mandated ASF 
*source* release staging and
>  release areas must continued to be used for the release’s 
aggregate source bundle(s)
>  https://dist.apache.org/repos/dist/dev/incubator/edgent 

>  https://dist.apache.org/repos/dist/release/incubator/edgent 

> 
>  There isn’t anything staged in the “dev” area for 1.2.0.
>  If you look at the 

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Dale LaBossiere]

Re the KEYS, please update the file in the incubator-edgent source repo.

FWI, the 1.0.0 and 1.1.0 staging areas are empty because the "publishing the 
release”
process is supposed to *move* the exact staged/voted artifacts to the release 
area.
I see the our buildTools/publish_release.sh script doesn’t bother to delete the
residual staged  dir.

In you hadn’t noticed, buildTools/publish_release.sh will update the KEYS in the
“release” area (from the “dev” area) so that will be taken care of 
automatically if the script is used.
It looks like it should work without any changes.

Agreed, no need to cancel the RC1 vote at this moment since as you note, 
the RC1 source content hasn’t changed.  And generally, updating the poms,etc
for “what’s released” is OK to not include in the 1.2.0 source release.  But...

I think some things MUST get removed from Nexus for 1.2.0.  Do you agree?
  - edgent-distribution (for j8,j7,android)
  - edgent-parent/*source-release* - or edgent-parent in its entirety?  (for 
j8,j7,android)
  - …/*-1.2.0-tests.*   (for j8,j7,android)
  - edgent-test* (for j8,j7)
  - what about “pom-only” intermediate dirs - will those show up in MC? Are 
they useful?
- edgent-analytics
- edgent-android
- edgent-api
...


> On Dec 6, 2017, at 4:00 AM, Christofer Dutz  wrote:
> 
> Hi Dale,
> 
> So, I updated the scripts, deployed the RC in the correct area (I wonder why 
> the other 1.0.0 and 1.1.0 areas are empty. Unfortunately, I had to test 
> myself to the right solution by running the scripts and fine tuning my 
> deployment and the scripts. But now I think we have a working solution. As 
> nothing had to be changed with the source-bundle itself, I don’t think we 
> need to cancel the RC and create a new one. What do you others think?
> 
> Chris
> 
> 
> Am 06.12.17, 09:10 schrieb "Christofer Dutz" :
> 
>HI Dale,
> 
>as I mentioned in the other DISCUSS thread I already noticed this 
> shortcoming. 
>I think the following path should be ok for us to follow:
> 
>1. I manually add my pgp key to the list in KEYS in SVN
>2. I manually add the files created by the assembly plugin to SVN
>3. We continue the voting
>4. In develop I try to automate the deployment of RCs for the next version
>5. We decide what to deploy and what not to and add exclusions to the poms 
> for next time
> 
>You think that’s a valid approach?
> 
>Chris
> 
> 
> 
>Am 06.12.17, 00:09 schrieb "Dale LaBossiere" :
> 
>Chris, thanks for moving the release/RC along!
> 
>I’ve kicked off this DISCUSS thread because I'm unable to tell if the
>staged RC is good to go or not and I didn’t want to pollute the RC1 
> Vote thread.
> 
>Since this is a new process for the project and the nexus / maven 
> release flow
>is new to me I’m confused and have to ask some questions before I can 
> assess
>if the RC contents are ok.
> 
>I, and others, definitely can’t follow the directions in the VOTE's 
> [6] 
>even reading between the lines and omitting the RM and “binary” parts 
> of it :-)
> 
>Here’s where I’m stumbling:
> 
>- I’m of the belief that the traditional normally mandated ASF 
> *source* release staging and
>  release areas must continued to be used for the release’s aggregate 
> source bundle(s)
>  https://dist.apache.org/repos/dist/dev/incubator/edgent 
> 
>  https://dist.apache.org/repos/dist/release/incubator/edgent 
> 
> 
>  There isn’t anything staged in the “dev” area for 1.2.0.
>  If you look at the “release” area you’ll see what the expected 
> contents/layout are
>  (of course omitting the “binaries” dir for 1.2.0).
> 
>  FWIW, there seems to be inconsistency among what additional files
>  TLPs have - e.g., beam,nifi,camel only have the bundle, kafka 
> includes RELEASE_NOTES,
>  flex (which original edgent process derived from) has LICENSE, 
> README, ….
>  I guess we can follow the lean-and-mean ones if we want to :-)
> 
>  That said, that layout, and form of bundle name, is what the [6] 
> referenced
>  download-edgent-asf.sh tool expects so it simply won’t work.
>  I’m happy to fix the script, if appropriate, once I understand 
> things.
> 
>  Note: I see aggregate source release bundles *are* present in the 
> nexus dir:
>
> https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>  
> 
>  That said, the form of their names 
> (edgent-parent-1.2.0-source-releaase…) isn’t what's expected / required.
>  

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Christofer Dutz]

Hi Dale,

So, I updated the scripts, deployed the RC in the correct area (I wonder why 
the other 1.0.0 and 1.1.0 areas are empty. Unfortunately, I had to test myself 
to the right solution by running the scripts and fine tuning my deployment and 
the scripts. But now I think we have a working solution. As nothing had to be 
changed with the source-bundle itself, I don’t think we need to cancel the RC 
and create a new one. What do you others think?

Chris


Am 06.12.17, 09:10 schrieb "Christofer Dutz" :

HI Dale,

as I mentioned in the other DISCUSS thread I already noticed this 
shortcoming. 
I think the following path should be ok for us to follow:

1. I manually add my pgp key to the list in KEYS in SVN
2. I manually add the files created by the assembly plugin to SVN
3. We continue the voting
4. In develop I try to automate the deployment of RCs for the next version
5. We decide what to deploy and what not to and add exclusions to the poms 
for next time

You think that’s a valid approach?

Chris



Am 06.12.17, 00:09 schrieb "Dale LaBossiere" :

Chris, thanks for moving the release/RC along!

I’ve kicked off this DISCUSS thread because I'm unable to tell if the
staged RC is good to go or not and I didn’t want to pollute the RC1 
Vote thread.

Since this is a new process for the project and the nexus / maven 
release flow
is new to me I’m confused and have to ask some questions before I can 
assess
if the RC contents are ok.

I, and others, definitely can’t follow the directions in the VOTE's [6] 
even reading between the lines and omitting the RM and “binary” parts 
of it :-)

Here’s where I’m stumbling:

- I’m of the belief that the traditional normally mandated ASF *source* 
release staging and
  release areas must continued to be used for the release’s aggregate 
source bundle(s)
  https://dist.apache.org/repos/dist/dev/incubator/edgent 

  https://dist.apache.org/repos/dist/release/incubator/edgent 


  There isn’t anything staged in the “dev” area for 1.2.0.
  If you look at the “release” area you’ll see what the expected 
contents/layout are
  (of course omitting the “binaries” dir for 1.2.0).

  FWIW, there seems to be inconsistency among what additional files
  TLPs have - e.g., beam,nifi,camel only have the bundle, kafka 
includes RELEASE_NOTES,
  flex (which original edgent process derived from) has LICENSE, 
README, ….
  I guess we can follow the lean-and-mean ones if we want to :-)

  That said, that layout, and form of bundle name, is what the [6] 
referenced
  download-edgent-asf.sh tool expects so it simply won’t work.
  I’m happy to fix the script, if appropriate, once I understand things.

  Note: I see aggregate source release bundles *are* present in the 
nexus dir:

https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
 

  That said, the form of their names 
(edgent-parent-1.2.0-source-releaase…) isn’t what's expected / required.
  Also note, those names are different from what -Papache-release 
generates in the target dir
  (apache-edgent-—incubating-source-release…)

- I’m unclear on what I see staged in nexus will ultimately be released 
in nexus and mirrored to maven central,
  hence unclear whether the nexus contents are “correct”.

  Is everything present in the nexus’s RC staging repo going to get 
mirrored to Maven Central
  and if so, is that what’s desired?
  - there are the aforementioned aggregate edgent-parent source bundles 
(with names different from what's mandated - e.g. “incubating” in them)
  - there are individual component source jars - I can imagine those 
could be useful for associating src with a component
  - there are individual component test jars - those seem undesired
  - there’s the edgent-test* components - those seem undesired
  - there are edgent-distribution components that have 
aggregate/transitive “bin” bundles that we’re NOT releasing

Thanks in advance for the clarifications.
— Dale

> On Dec 5, 2017, at 3:40 AM, Christofer Dutz 
 wrote:
> 
> Apache Edgent (Incubating) 1.2.0 has been staged under [4] and it’s 
time to vote
> on accepting it for release.  All 

Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1

[Christofer Dutz]

HI Dale,

as I mentioned in the other DISCUSS thread I already noticed this shortcoming. 
I think the following path should be ok for us to follow:

1. I manually add my pgp key to the list in KEYS in SVN
2. I manually add the files created by the assembly plugin to SVN
3. We continue the voting
4. In develop I try to automate the deployment of RCs for the next version
5. We decide what to deploy and what not to and add exclusions to the poms for 
next time

You think that’s a valid approach?

Chris



Am 06.12.17, 00:09 schrieb "Dale LaBossiere" :

Chris, thanks for moving the release/RC along!

I’ve kicked off this DISCUSS thread because I'm unable to tell if the
staged RC is good to go or not and I didn’t want to pollute the RC1 Vote 
thread.

Since this is a new process for the project and the nexus / maven release 
flow
is new to me I’m confused and have to ask some questions before I can assess
if the RC contents are ok.

I, and others, definitely can’t follow the directions in the VOTE's [6] 
even reading between the lines and omitting the RM and “binary” parts of it 
:-)

Here’s where I’m stumbling:

- I’m of the belief that the traditional normally mandated ASF *source* 
release staging and
  release areas must continued to be used for the release’s aggregate 
source bundle(s)
  https://dist.apache.org/repos/dist/dev/incubator/edgent 

  https://dist.apache.org/repos/dist/release/incubator/edgent 


  There isn’t anything staged in the “dev” area for 1.2.0.
  If you look at the “release” area you’ll see what the expected 
contents/layout are
  (of course omitting the “binaries” dir for 1.2.0).

  FWIW, there seems to be inconsistency among what additional files
  TLPs have - e.g., beam,nifi,camel only have the bundle, kafka includes 
RELEASE_NOTES,
  flex (which original edgent process derived from) has LICENSE, README, ….
  I guess we can follow the lean-and-mean ones if we want to :-)

  That said, that layout, and form of bundle name, is what the [6] 
referenced
  download-edgent-asf.sh tool expects so it simply won’t work.
  I’m happy to fix the script, if appropriate, once I understand things.

  Note: I see aggregate source release bundles *are* present in the nexus 
dir:

https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
 

  That said, the form of their names (edgent-parent-1.2.0-source-releaase…) 
isn’t what's expected / required.
  Also note, those names are different from what -Papache-release generates 
in the target dir
  (apache-edgent-—incubating-source-release…)

- I’m unclear on what I see staged in nexus will ultimately be released in 
nexus and mirrored to maven central,
  hence unclear whether the nexus contents are “correct”.

  Is everything present in the nexus’s RC staging repo going to get 
mirrored to Maven Central
  and if so, is that what’s desired?
  - there are the aforementioned aggregate edgent-parent source bundles 
(with names different from what's mandated - e.g. “incubating” in them)
  - there are individual component source jars - I can imagine those could 
be useful for associating src with a component
  - there are individual component test jars - those seem undesired
  - there’s the edgent-test* components - those seem undesired
  - there are edgent-distribution components that have aggregate/transitive 
“bin” bundles that we’re NOT releasing

Thanks in advance for the clarifications.
— Dale

> On Dec 5, 2017, at 3:40 AM, Christofer Dutz  
wrote:
> 
> Apache Edgent (Incubating) 1.2.0 has been staged under [4] and it’s time 
to vote
> on accepting it for release.  All Maven artifacts are available under [3].
> If approved we will seek final release approval from the IPMC.
> Voting will be open for 72hr.
> 
> A minimum of 3 binding +1 votes and more binding +1 than binding -1
> are required to pass.
> 
> Per [5] "Before voting +1 [P]PMC members are required to download
> the signed source code package, compile it as provided, and test
> the resulting executable on their own platform, along with also
> verifying that the package meets the requirements of the ASF policy
> on releases."
> 
> You can achieve the above by following [6].
> 
> [ ]  +1 accept (indicate what you validated - e.g. performed the non-RM 
items in [6])
> [ ]  -1 reject (explanation required)
> 
> 
> Apache Edgent release process documentation:  [1] and