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