[VOTE] - Pirk 0.1.0 Release

Hi, This is the vote for release 0.1.0 of Apache Pirk (incubating). The vote will be going for at least 72 hours and will be closed on Wednesday , August 16, 2016. The artifacts can be downloaded here: https://repository.apache. org/content/repositories/orgapachepirk-1001/org/apache/

[GitHub] incubator-pirk pull request #61: add parent pom

Github user asfgit closed the pull request at: https://github.com/apache/incubator-pirk/pull/61 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature

[GitHub] incubator-pirk pull request #61: add parent pom

GitHub user smarthi opened a pull request: https://github.com/apache/incubator-pirk/pull/61 add parent pom You can merge this pull request into a Git repository by running: $ git pull https://github.com/smarthi/incubator-pirk sundry Alternatively you can review and apply

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

Ok here's the rollback steps. In Nexus 1. 'Drop' the release from staging -> click on the Drop button Locally 1. mvn -Psigned_release versions:set -DnewVersion=0.0.1-Snapshot 2. mvn -Psigned_release versions:commit 3. git commit followed by git push 4. git push --delete apache ---> deletes

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

Yes, the close has failed due to the asc files not being present for each artifact. Isn't this supposed to happen automatically? Ugh. On Sat, Aug 13, 2016 at 8:30 PM, Suneel Marthi wrote: > Seems like we are missing the signature .asc files and Nexus has failed to >

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

Seems like we are missing the signature .asc files and Nexus has failed to push the artifacts to staging. We need to rollback the release from staging. Its easier if we got onto the Slack channel to resolve this quicker. We can later post the summary to the mailing lists. On Sat, Aug 13, 2016

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

Before u call for the Vote, here's what needs to be done. I see the staged artifacts in Nexus. 1. 'Close' the artifacts in Nexus > this pushes them to a staging area 2. Send the URL of the staged artifacts in the call for vote. On Sat, Aug 13, 2016 at 8:10 PM, Ellison Anne Williams <

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

... and in https://dist.apache.org/repos/dist/dev/incubator/pirk/ On Sat, Aug 13, 2016 at 4:23 PM, Suneel Marthi wrote: > The KEYS file has been pushed to https://dist.apache.org/repos/ > dist/release/incubator/pirk/ > > On Sat, Aug 13, 2016 at 4:08 PM, Josh Elser

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

:-) I was gonna suggest :- 1. push the artifacts to staging on Nexus at https://repository.apache. org/service/local/staging/deploy/maven2 2. call for a Vote on the staged artifacts 3. Once Vote passes, 'Release' the artifacts in Nexus and that would transfer them to

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

I'm realizing that I'm a bone-head and you didn't actually stage anything yet :) Too much coffee and not enough close-reading. Sorry for the spam. Hopefully some of it was helpful too. One more thing just to make sure, you should use https://dist.apache.org/repos/dist/dev/incubator/pirk/ for

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

Hi Ellison Anne, A couple of issues before getting to verifying the artfiacts: * Can you please add the SHA1 for the git hash that the source-release was built from? This is an important verification (I can see the point in the repository which this code was built from). * The KEYS file for

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

+1 to go with a single Vote process On Sat, Aug 13, 2016 at 10:24 AM, Ellison Anne Williams < eawilliamsp...@gmail.com> wrote: > So, different projects seem to follow different internal release processes. > Some follow a single vote and some follow the two-tiered approach. > > The point of the

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

So, different projects seem to follow different internal release processes. Some follow a single vote and some follow the two-tiered approach. The point of the first branch vote is to determine whether or not the community agrees on what will be contained in the release. The second vote is to

Re: [VOTE] Pirk's First Release - 0.1.0 - Branch Vote

I am thinking we could have one Vote that runs for 72 hrs, approving the candidate release branch would also mean testing and validating the artifacts. correct? On Sat, Aug 13, 2016 at 8:49 AM, Ellison Anne Williams < eawilliamsp...@gmail.com> wrote: > Hi All, > > After some hiccups last night

Re: Mentor Question -- Release and Pom File

Ok, each project does it a little different. Cool, we'll leave POM as it now. Filing an Infra ticket now to purge the release artifacts. On Sat, Aug 13, 2016 at 9:27 AM, Joe Witt wrote: > i don't believe that would be necessary. Here is the entirety of my > maven settings

Re: Mentor Question -- Release and Pom File

I had the real apache repo URL in POM as opposed to the staging URL. So that completely bypassed staging. If I am understanding correctly, we need to add the Parent POM and remove from POM - the later should be specified in settings.xml. Agree? On Sat, Aug 13, 2016 at 9:16 AM, Joe Witt

Re: Mentor Question -- Release and Pom File

Yep - that did it - thanks! On Sat, Aug 13, 2016 at 8:57 AM, Suneel Marthi wrote: > You should use -Psigned_release. > > Once u r past release:prepare and release:perform and u need to rollback. > > -- run mvn -Psigned_release release:rollback > mvn

Re: Mentor Question -- Release and Pom File

One quick thing I noticed is it doesn't look like we're using the apache parent pom. That helps a lot. On Sat, Aug 13, 2016 at 9:03 AM, Suneel Marthi wrote: > One other thing we need to figure out for next release. You shouldn't have > to specify the repository info in

Re: Mentor Question -- Release and Pom File

One other thing we need to figure out for next release. You shouldn't have to specify the repository info in POM, its best done in settings.xml (that's how we do it on Mahout). I tried doing it that way but it didn't work for whatever reason and I ended up explicitly declaring that in POM. On