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