You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@edgent.apache.org by Dale LaBossiere <dm...@gmail.com> on 2017/12/05 23:08:54 UTC
[DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
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/dev/incubator/edgent>
https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
> to be valid we will update [1] and [2] to the latest changes.
>
> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
> [5] https://www.apache.org/dev/release.html#approving-a-release
> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Justin Mclean <ju...@classsoftware.com>.
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
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ch...@c-ware.de>:
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):
<distributionManagement>
<repository>
<id>apache.releases.https</id>
<name>Apache Release Distribution Repository</name>
<url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
</repository>
<snapshotRepository>
<id>apache.snapshots.https</id>
<name>${distMgmtSnapshotsName}</name>
<url>${distMgmtSnapshotsUrl}</url>
</snapshotRepository>
</distributionManagement>
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" <dm...@gmail.com>:
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 <https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation>
— Dale
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <ch...@c-ware.de> 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):
>
> <distributionManagement>
> <repository>
> <id>apache.releases.https</id>
> <name>Apache Release Distribution Repository</name>
> <url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
> </repository>
> <snapshotRepository>
> <id>apache.snapshots.https</id>
> <name>${distMgmtSnapshotsName}</name>
> <url>${distMgmtSnapshotsUrl}</url>
> </snapshotRepository>
> </distributionManagement>
>
> 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" <dm...@gmail.com>:
>
> 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 <https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation>
>
> — Dale
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Christofer Dutz <ch...@c-ware.de>.
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):
<distributionManagement>
<repository>
<id>apache.releases.https</id>
<name>Apache Release Distribution Repository</name>
<url>https://repository.apache.org/service/local/staging/deploy/maven2</url>
</repository>
<snapshotRepository>
<id>apache.snapshots.https</id>
<name>${distMgmtSnapshotsName}</name>
<url>${distMgmtSnapshotsUrl}</url>
</snapshotRepository>
</distributionManagement>
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" <dm...@gmail.com>:
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 <https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation>
— Dale
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation>
— Dale
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <http://www.apache.org/dev/release-distribution#sigs-and-sums>
Thanks
— Dale
> On Dec 7, 2017, at 4:00 AM, Christofer Dutz <ch...@c-ware.de> 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" <dm...@gmail.com>:
>
> 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 <ch...@c-ware.de> 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 <dm...@gmail.com>
>> ...
>> -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
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ch...@c-ware.de>:
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" <dm...@gmail.com>:
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 <ch...@c-ware.de> 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 <dm...@gmail.com>
> ...
> -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
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <dm...@gmail.com>:
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 <ch...@c-ware.de> 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 <dm...@gmail.com>
> ...
> -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
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <ch...@c-ware.de> 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 <dm...@gmail.com>
> ...
> -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
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <dm...@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 <ch...@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 <dm...@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 <ch...@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 <dm...@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 <ch...@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" <dm...@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 <ver> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>>>>
>>>> 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" <dm...@gmail.com>:
>>>>
>>>> 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/dev/incubator/edgent>
>>>> https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
>>>>> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
>>>>> to be valid we will update [1] and [2] to the latest changes.
>>>>>
>>>>> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
>>>>> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
>>>>> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
>>>>> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>>>>> [5] https://www.apache.org/dev/release.html#approving-a-release
>>>>> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <ch...@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 <dm...@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 <ch...@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 <dm...@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 <ch...@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" <dm...@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 <ver> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>>>>
>>>> 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" <dm...@gmail.com>:
>>>>
>>>> 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/dev/incubator/edgent>
>>>> https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
>>>>> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
>>>>> to be valid we will update [1] and [2] to the latest changes.
>>>>>
>>>>> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
>>>>> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
>>>>> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
>>>>> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>>>>> [5] https://www.apache.org/dev/release.html#approving-a-release
>>>>> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <dm...@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 <ch...@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 <dm...@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 <ch...@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" <dm...@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 <ver> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>>>
>>> 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" <dm...@gmail.com>:
>>>
>>> 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/dev/incubator/edgent>
>>> https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
>>>> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
>>>> to be valid we will update [1] and [2] to the latest changes.
>>>>
>>>> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
>>>> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
>>>> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
>>>> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>>>> [5] https://www.apache.org/dev/release.html#approving-a-release
>>>> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <ch...@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 <dm...@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 <ch...@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" <dm...@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 <ver> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>>>
>>> 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" <dm...@gmail.com>:
>>>
>>> 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/dev/incubator/edgent>
>>> https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
>>>> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
>>>> to be valid we will update [1] and [2] to the latest changes.
>>>>
>>>> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
>>>> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
>>>> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
>>>> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>>>> [5] https://www.apache.org/dev/release.html#approving-a-release
>>>> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <dm...@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 <ch...@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" <dm...@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 <ver> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>>
>> 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" <dm...@gmail.com>:
>>
>> 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/dev/incubator/edgent>
>> https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
>>> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
>>> to be valid we will update [1] and [2] to the latest changes.
>>>
>>> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
>>> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
>>> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
>>> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>>> [5] https://www.apache.org/dev/release.html#approving-a-release
>>> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>>>
>>
>>
>>
>>
>>
>
>
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Dale LaBossiere <dm...@gmail.com>.
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 <ch...@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" <dm...@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 <ver> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>>
>> 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" <dm...@gmail.com>:
>>
>> 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/dev/incubator/edgent>
>> https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
>>> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
>>> to be valid we will update [1] and [2] to the latest changes.
>>>
>>> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
>>> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
>>> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
>>> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>>> [5] https://www.apache.org/dev/release.html#approving-a-release
>>> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>>>
>>
>>
>>
>>
>>
>
>
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <dm...@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 <ver> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>
> 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" <dm...@gmail.com>:
>
> 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/dev/incubator/edgent>
> https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
>> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
>> to be valid we will update [1] and [2] to the latest changes.
>>
>> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
>> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
>> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
>> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>> [5] https://www.apache.org/dev/release.html#approving-a-release
>> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>>
>
>
>
>
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Dale LaBossiere <dm...@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 <ver> 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 <ch...@c-ware.de> 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" <ch...@c-ware.de>:
>
> 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" <dm...@gmail.com>:
>
> 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/dev/incubator/edgent>
> https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
>> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
>> to be valid we will update [1] and [2] to the latest changes.
>>
>> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
>> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
>> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
>> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
>> [5] https://www.apache.org/dev/release.html#approving-a-release
>> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>>
>
>
>
>
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <ch...@c-ware.de>:
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" <dm...@gmail.com>:
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/dev/incubator/edgent>
https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
> to be valid we will update [1] and [2] to the latest changes.
>
> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
> [5] https://www.apache.org/dev/release.html#approving-a-release
> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>
Re: [DISCUSS] validating Apache Edgent (Incubating) 1.2.0 RC1
Posted by Christofer Dutz <ch...@c-ware.de>.
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" <dm...@gmail.com>:
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/dev/incubator/edgent>
https://dist.apache.org/repos/dist/release/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/ <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-<ver>—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 <ch...@c-ware.de> 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 [2]. However, this is a first test of a Maven based
> Release described in the projects Maven site: src/site/asciidoc/releasing.adoc if this form of release proves
> to be valid we will update [1] and [2] to the latest changes.
>
> [1] https://cwiki.apache.org/confluence/display/EDGENT/A+guide+to+the+Apache+Edgent+release+process
> [2] https://cwiki.apache.org/confluence/display/EDGENT/Release+Manager's+Guide
> [3] https://repository.apache.org/content/repositories/orgapacheedgent-1002/
> [4] https://repository.apache.org/content/repositories/orgapacheedgent-1002/org/apache/edgent/edgent-parent/1.2.0/
> [5] https://www.apache.org/dev/release.html#approving-a-release
> [6] https://cwiki.apache.org/confluence/display/EDGENT/Staged+RC+Validation
>