By the way, I'm not trying to block the way. ;-) I'm just trying to make a right release (process) this time. Please let me know if I can help with anything. I'll help to fix the (minimal) things to make a release as soon as possible. :-)
Regards, Woonsan On Mon, May 14, 2018 at 11:39 AM, Woonsan Ko <[email protected]> wrote: > On Mon, May 14, 2018 at 10:43 AM, Neil Griffin > <[email protected]> wrote: >> Hi Woonsan, >> >> We followed the same process as we did for the 3.0.0 release. >> >> The "building from source" requirement would be accomplished by building >> source from a Git tag. > > I don't think a Git tag can replace the requirement of a "valid > release package". > Pluto 3.0.0 release also contains a valid release package: > - > https://dist.apache.org/repos/dist/release/portals/pluto/pluto-3.0.0-source-release.zip > > From this voting email, I want to check if the release source package > is valid as an Apache release. > I cannot find the candidate source package we want to release. There > are binary links only in your voting e-mail for the Pluto 3.0.1. > What's the point of this voting if I cannot verify the candidate > source packages by building, unit-testing, checking signatures, > checking license headers, ...? > Please give me the links to download all the *source packages* as > release candidate this time, which I can build, test, verify things. > Otherwise, I cannot proceed. > >> >> However, the Git commits and tags have not been pushed to the Git repository >> yet, because of the following line: >> https://github.com/apache/portals-pluto/blob/master/pom.xml#L649 >> >> This was intentional, because it would allow us to roll back the release >> process if the voting process were to fail. > > That might be okay, but again please upload the source packages you > built and staged somewhere. I cannot verify nor vote against binaries. > > If possible, I recommend you to upload to > https://dist.apache.org/repos/dist/dev/portals/pluto/... for voting, > and later move to /release/ folder after voting passed. > The source packages for which we vote should become the actual > releases in the end if vote passed. Neither files you have locally nor > a git tag. > >> >> This approach also mirrors the concept of the "staging" repository which >> will not be released to Maven Central if the voting process were to fail. > > Another approach is just to bump up the version to 3.0.2 if 3.0.1 > voting failed and so 3.0.1 tag is not for a release. I don't see any > problem by having 3.0.1 tag exists as long as it's not published to > both maven repository and distribution site. > >> >> I can provide evidence of the tags and git commits in my local Git >> repository if that would help. > > Git commits or local files cannot help in our release voting and process, IMO. > It's better and safer to upload all the source packages and let people > verify them before casting a vote. > > Regards, > > Woonsan > >> >> >> Best Regards, >> >> Neil >> >> >> On 5/14/18 10:29 AM, Woonsan Ko wrote: >>> >>> -1 >>> >>> I couldn't find pluto-3.0.1 tag in >>> https://git-wip-us.apache.org/repos/asf/portals-pluto.git. I wonder >>> how the release candidate artifacts were made. The master branch's >>> version was not bumped up to 3.0.2-SNAPSHOT either. >>> Even worse, there's a stopper in the root pom.xml [1]: >>> >>> <profile> >>> <id>liferay</id> >>> <dependencyManagement> >>> <dependencies> >>> <dependency> >>> <groupId>com.liferay.portal</groupId> >>> >>> <artifactId>com.liferay.cdi.bean.portlet.extension</artifactId> >>> <version>1.0.0-SNAPSHOT</version> >>> </dependency> >>> </dependencies> >>> </dependencyManagement> >>> <repositories> >>> <repository> >>> <id>liferay-snapshots</id> >>> <name>Liferay Snapshots</name> >>> >>> <url>https://oss.sonatype.org/content/repositories/snapshots</url> >>> <releases> >>> <enabled>false</enabled> >>> </releases> >>> <snapshots> >>> <enabled>true</enabled> >>> </snapshots> >>> </repository> >>> </repositories> >>> </profile> >>> >>> Releases must not depend on a SNAPSHOT dependency. And the >>> com.liferay.cdi.bean.portlet.extension artifact has no clear copyright >>> notice. So this is not acceptable. >>> If the 'liferay' profile is necessary for Liferay specific TCK >>> testing, I'd recommend you to move it out to a special documentation >>> explaining how to run Liferay specific TCK testing by configuring >>> those in user's settings.xml instead, not in the source distribution. >>> >>> Regards, >>> >>> Woonsan >>> >>> [1] >>> https://git-wip-us.apache.org/repos/asf?p=portals-pluto.git;a=blob;f=pom.xml;h=1fb14997be03c4911ce97ebf0826f59f599a2198;hb=HEAD#l739 >>> >>> >>> On Fri, May 11, 2018 at 3:06 PM, Neil Griffin >>> <[email protected]> wrote: >>>> >>>> Dear Apache Portals Pluto Team and community, >>>> >>>> I've staged a release candidate for the new Apache Portals Pluto 3.0.1 >>>> release. >>>> >>>> This release candidate includes: >>>> >>>> * Fully compliant Reference Implementation of the new Portlet 3.0 >>>> Specification per JCR-362 >>>> https://www.jcp.org/en/jsr/detail?id=362 >>>> * Fully completed (and corrected) TCK (Test Compatibility Kit) for >>>> Portlet >>>> Spec 3.0 >>>> * Updated portlet-api with associated Javadoc improvements >>>> * General bugfixes >>>> * Updated archetypes >>>> >>>> Please review the release candidate for this project which is spread >>>> across the following THREE maven staging repositories: >>>> >>>> 1) portlet-api and pluto-portal components and dependencies: >>>> https://repository.apache.org/content/repositories/orgapacheportals-1018 >>>> >>>> 2) pluto+tomcat bundle: >>>> https://repository.apache.org/content/repositories/orgapacheportals-1019 >>>> >>>> (The bundle can be tested by unzipping it, >>>> and running start.sh from the bin directory, >>>> then navigating to http://localhost:8080/pluto >>>> and login as pluto/pluto.) >>>> >>>> 3) maven archetypes: >>>> https://repository.apache.org/content/repositories/orgapacheportals-1020 >>>> >>>> The Release Notes are available here: >>>> >>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10560&version=12338908 >>>> >>>> The KEYS file to verify the release artifacts signature can be found >>>> here: >>>> >>>> https://dist.apache.org/repos/dist/release/portals/pluto/KEYS >>>> >>>> Please review the release candidates and vote on releasing Apache Portals >>>> Pluto 3.0.1 >>>> >>>> Seeing as how I am sending this on a Friday, the normal vote of 72 hours >>>> seems unreasonable. Therefore I would like to extend the vote to 96 >>>> hours. >>>> >>>> Please cast your vote: >>>> >>>> [ ] +1 for Release >>>> [ ] 0 for Don't care >>>> [ ] -1 Don't release (do provide a reason then) >>>> >>>> >>>> Best Regards to all, >>>> >>>> Neil >>> >>> >> > > On Mon, May 14, 2018 at 10:43 AM, Neil Griffin > <[email protected]> wrote: >> Hi Woonsan, >> >> We followed the same process as we did for the 3.0.0 release. >> >> The "building from source" requirement would be accomplished by building >> source from a Git tag. >> >> However, the Git commits and tags have not been pushed to the Git repository >> yet, because of the following line: >> https://github.com/apache/portals-pluto/blob/master/pom.xml#L649 >> >> This was intentional, because it would allow us to roll back the release >> process if the voting process were to fail. >> >> This approach also mirrors the concept of the "staging" repository which >> will not be released to Maven Central if the voting process were to fail. >> >> I can provide evidence of the tags and git commits in my local Git >> repository if that would help. >> >> >> Best Regards, >> >> Neil >> >> >> On 5/14/18 10:29 AM, Woonsan Ko wrote: >>> >>> -1 >>> >>> I couldn't find pluto-3.0.1 tag in >>> https://git-wip-us.apache.org/repos/asf/portals-pluto.git. I wonder >>> how the release candidate artifacts were made. The master branch's >>> version was not bumped up to 3.0.2-SNAPSHOT either. >>> Even worse, there's a stopper in the root pom.xml [1]: >>> >>> <profile> >>> <id>liferay</id> >>> <dependencyManagement> >>> <dependencies> >>> <dependency> >>> <groupId>com.liferay.portal</groupId> >>> >>> <artifactId>com.liferay.cdi.bean.portlet.extension</artifactId> >>> <version>1.0.0-SNAPSHOT</version> >>> </dependency> >>> </dependencies> >>> </dependencyManagement> >>> <repositories> >>> <repository> >>> <id>liferay-snapshots</id> >>> <name>Liferay Snapshots</name> >>> >>> <url>https://oss.sonatype.org/content/repositories/snapshots</url> >>> <releases> >>> <enabled>false</enabled> >>> </releases> >>> <snapshots> >>> <enabled>true</enabled> >>> </snapshots> >>> </repository> >>> </repositories> >>> </profile> >>> >>> Releases must not depend on a SNAPSHOT dependency. And the >>> com.liferay.cdi.bean.portlet.extension artifact has no clear copyright >>> notice. So this is not acceptable. >>> If the 'liferay' profile is necessary for Liferay specific TCK >>> testing, I'd recommend you to move it out to a special documentation >>> explaining how to run Liferay specific TCK testing by configuring >>> those in user's settings.xml instead, not in the source distribution. >>> >>> Regards, >>> >>> Woonsan >>> >>> [1] >>> https://git-wip-us.apache.org/repos/asf?p=portals-pluto.git;a=blob;f=pom.xml;h=1fb14997be03c4911ce97ebf0826f59f599a2198;hb=HEAD#l739 >>> >>> >>> On Fri, May 11, 2018 at 3:06 PM, Neil Griffin >>> <[email protected]> wrote: >>>> >>>> Dear Apache Portals Pluto Team and community, >>>> >>>> I've staged a release candidate for the new Apache Portals Pluto 3.0.1 >>>> release. >>>> >>>> This release candidate includes: >>>> >>>> * Fully compliant Reference Implementation of the new Portlet 3.0 >>>> Specification per JCR-362 >>>> https://www.jcp.org/en/jsr/detail?id=362 >>>> * Fully completed (and corrected) TCK (Test Compatibility Kit) for >>>> Portlet >>>> Spec 3.0 >>>> * Updated portlet-api with associated Javadoc improvements >>>> * General bugfixes >>>> * Updated archetypes >>>> >>>> Please review the release candidate for this project which is spread >>>> across the following THREE maven staging repositories: >>>> >>>> 1) portlet-api and pluto-portal components and dependencies: >>>> https://repository.apache.org/content/repositories/orgapacheportals-1018 >>>> >>>> 2) pluto+tomcat bundle: >>>> https://repository.apache.org/content/repositories/orgapacheportals-1019 >>>> >>>> (The bundle can be tested by unzipping it, >>>> and running start.sh from the bin directory, >>>> then navigating to http://localhost:8080/pluto >>>> and login as pluto/pluto.) >>>> >>>> 3) maven archetypes: >>>> https://repository.apache.org/content/repositories/orgapacheportals-1020 >>>> >>>> The Release Notes are available here: >>>> >>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10560&version=12338908 >>>> >>>> The KEYS file to verify the release artifacts signature can be found >>>> here: >>>> >>>> https://dist.apache.org/repos/dist/release/portals/pluto/KEYS >>>> >>>> Please review the release candidates and vote on releasing Apache Portals >>>> Pluto 3.0.1 >>>> >>>> Seeing as how I am sending this on a Friday, the normal vote of 72 hours >>>> seems unreasonable. Therefore I would like to extend the vote to 96 >>>> hours. >>>> >>>> Please cast your vote: >>>> >>>> [ ] +1 for Release >>>> [ ] 0 for Don't care >>>> [ ] -1 Don't release (do provide a reason then) >>>> >>>> >>>> Best Regards to all, >>>> >>>> Neil >>> >>> >>
