You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Neil Griffin <ne...@portletfaces.org> on 2018/05/11 19:06:05 UTC

[VOTE] Release Apache Portals Pluto 3.0.1

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

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
Hi,

I'm not sure if the release includes the source packages properly.
"The fundamental requirement for a release is that it consist of the
necessary source code to build the project." [1]
See my comments inline for each package.

[1] http://www.apache.org/dev/release-publishing.html


On Fri, May 11, 2018 at 3:06 PM, Neil Griffin
<ne...@portletfaces.org> 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

These do not include source packages to *build* after downloading.
Neither maven artifacts such as pluto-portal-driver-3.0.1-sources.jar
nor GIT tag is qualified as "source code to build the project" in our
releases.
Do those projects not have apache release maven profile or not use the
profile in the release process?

>
> 2) pluto+tomcat bundle:
> https://repository.apache.org/content/repositories/orgapacheportals-1019

This one doesn't include source package either.

>
>     (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

These ones have source packages (e.g,
bean-portlet-archetype-3.0.1-source-release.zip) to build in
https://repository.apache.org/content/repositories/orgapacheportals-1020/org/apache/portals/pluto/archetype/bean-portlet-archetype/3.0.1/.
It should have been mentioned in this VOTE E-Mail message with either
the specific staging maven repo link or distribution links in
https://dist.apache.org/repos/dist/dev/portals/... (note /dev/, not
/release/ in pre-official-release steps) after copying those to the
directory in the release process, IMO.
But I notice that this step is missing in [2] too as a pre-voting
step. It has a post-vote step to copy those though. I believe it's
better to copy those source package zip file and signature files in
https://dist.apache.org/repos/dist/dev/... when proposing votes
because we need to validate each source package builds properly, has
been signed properly, etc.

[2] https://github.com/apache/portals-pluto/blob/master/RELEASE-PROCEDURE.txt

I believe we should fix the two problems before proceeding: (a)
include source artifacts in portlet-api and pluto-poartal components,
(b) include source artifacts in pluto+tomcat bundle.
Solution would be just either adding apache release maven profile in
those projects or using it in the release process.

Please let me know if I miss anything.

Regards,

Woonsan


>
> 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

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Werner Keil <we...@gmail.com>.
I guess JCR-362 means JSR-362, as JCR (Java Content Repository) also
relates to Portlets but those are different JSRs.

Regards,
Werner



On Fri, May 11, 2018 at 9:06 PM, Neil Griffin <neil.griffin@portletfaces.org
> 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?proje
> ctId=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
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Neil Griffin <ne...@portletfaces.org>.
Hi Woonsan,

I can remove the dependency. I will also pursue getting the license changed to Apache 2.0 before the production release of the dependency so that it can be put back in at some point in the future.

Regarding Git commits, tags, etc. How about I push the commits and tags to a forked Gut repo? That way the build can be verified by checking out the tag from the fork.

I would much rather do that then have 3.0.1 tags pushed to the upstream Git repo that were not voted +1 by us all.

Thank you,

Neil

On 5/14/18 11:39 AM, Woonsan Ko wrote:
> Yes, please remove the profile. We cannot use LGPL-like dependency in
> our source.
> 
> Regards,
> 
> Woonsan
> 
> On Mon, May 14, 2018 at 10:45 AM, Neil Griffin
> <ne...@portletfaces.org> wrote:
>> Regarding the "liferay" profile, it is a profile that is not required to be
>> specified for building the TCK on Pluto.
>>
>> If that is not sufficient, then the profile can be removed and we can do the
>> release again.
>>
>>
>> On 5/14/18 10:43 AM, Neil Griffin 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
>>>> <ne...@portletfaces.org> 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
>>>>
>>>>
>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
Yes, please remove the profile. We cannot use LGPL-like dependency in
our source.

Regards,

Woonsan

On Mon, May 14, 2018 at 10:45 AM, Neil Griffin
<ne...@portletfaces.org> wrote:
> Regarding the "liferay" profile, it is a profile that is not required to be
> specified for building the TCK on Pluto.
>
> If that is not sufficient, then the profile can be removed and we can do the
> release again.
>
>
> On 5/14/18 10:43 AM, Neil Griffin 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
>>> <ne...@portletfaces.org> 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
>>>
>>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
Yes, please remove the profile. We cannot use LGPL-like dependency in
our source.

Regards,

Woonsan

On Mon, May 14, 2018 at 10:45 AM, Neil Griffin
<ne...@portletfaces.org> wrote:
> Regarding the "liferay" profile, it is a profile that is not required to be
> specified for building the TCK on Pluto.
>
> If that is not sufficient, then the profile can be removed and we can do the
> release again.
>
>
> On 5/14/18 10:43 AM, Neil Griffin 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
>>> <ne...@portletfaces.org> 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
>>>
>>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Neil Griffin <ne...@portletfaces.org>.
Regarding the "liferay" profile, it is a profile that is not required to be specified for building the TCK on Pluto.

If that is not sufficient, then the profile can be removed and we can do the release again.

On 5/14/18 10:43 AM, Neil Griffin 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
>> <ne...@portletfaces.org> 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
>>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Brett Randall <ja...@gmail.com>.
Please note this policy:

http://www.apache.org/legal/release-policy.html#release-approval

<quote>
Before casting +1 binding votes, individuals are REQUIRED to download all
signed source code packages onto their own hardware, verify that they meet
all requirements of ASF policy on releases as described below, validate all
cryptographic signatures, compile as provided, and test the result on their
own platform.
</quote>

Brett

On 15 May 2018 at 08:27, Neil Griffin <ne...@portletfaces.org> wrote:

> Hi Woonsan,
>
> I tried adding this to portals-pluto/pom.xml and it didn't work:
>
>     <profile>
>       <id>apache-release</id>
>       <build>
>         <plugins>
>           <plugin>
>             <groupId>org.apache.maven.plugins</groupId>
>             <artifactId>maven-assembly-plugin</artifactId>
>             <configuration>
>               <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot>
>             </configuration>
>           </plugin>
>         </plugins>
>       </build>
>     </profile>
>
> I also tried -DrunOnlyAtExecutionRoot=true on command line and it didn't
> work.
>
> In other words, when I run the release procedure from the top
> (portals-pluto/) the maven-assembly-plugin will only generate a
> "source-release" ZIP for pluto-3.0.1-source-release.zip and nothing else.
>
> Since that the only source-release ZIP that has been released in the past,
> shouldn't that be adequate for this 3.0.1 release?
>
> Thank you,
>
> Neil
>
> On 5/14/18 4:51 PM, Neil Griffin wrote:
>
>> Hi Woonsan,
>>
>> Thank you for your efforts to make sure the release process is correct.
>>
>> 1) Regarding the "source-release" bundles:
>>
>> I *think* I found the problem as to why they are missing -- it is likely
>> due to the following config of the maven-assembly-plugin in the apache-16
>> parent-most pom descriptor:
>>
>>       <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
>>
>> See: https://search.maven.org/remotecontent?filepath=org/apache/
>> apache/16/apache-16.pom
>>
>> Since we ran the Maven release plugin from the portals-pluto root, none
>> of the jars like pluto-container-api.jar, etc. had the companion
>> "source-release" bundle.
>>
>> The reason why the archetypes worked, is because I released them
>> individually from their respective "root" directories.
>>
>> BTW, as far as I can determine, the "source-release" problem is not new.
>> It has been there for many years. For example, see:
>> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apac
>> he.portals.pluto%22%20AND%20a%3A%22pluto-container-api%22
>>
>> Anyway, I'll fix it before re-releasing.
>>
>> 2) Regarding Git, in the 3.0.0 release Scott pushed the 3.0.0 *commits*
>> for the vote, but _not_ the *tags* until the vote was final. That worked
>> well because he actually had to roll-back the release. I recommend we do it
>> that way again.
>>
>>
>> -- Neil
>>
>> On 5/14/18 11:53 AM, Woonsan Ko wrote:
>>
>>> 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 <wo...@apache.org> wrote:
>>>
>>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
>>>> <ne...@portletfaces.org> 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/plu
>>>> to-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
>>>>>> <ne...@portletfaces.org> 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/orgapache
>>>>>>> portals-1018
>>>>>>>
>>>>>>> 2) pluto+tomcat bundle:
>>>>>>> https://repository.apache.org/content/repositories/orgapache
>>>>>>> portals-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/orgapache
>>>>>>> portals-1020
>>>>>>>
>>>>>>> The Release Notes are available here:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>>>>>> ctId=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
>>>> <ne...@portletfaces.org> 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
>>>>>> <ne...@portletfaces.org> 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/orgapache
>>>>>>> portals-1018
>>>>>>>
>>>>>>> 2) pluto+tomcat bundle:
>>>>>>> https://repository.apache.org/content/repositories/orgapache
>>>>>>> portals-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/orgapache
>>>>>>> portals-1020
>>>>>>>
>>>>>>> The Release Notes are available here:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
>>>>>>> ctId=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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
Hi Neil,

On Wed, May 16, 2018 at 5:48 PM, Neil Griffin
<ne...@portletfaces.org> wrote:
> Hi Woonsan,
>
> Step 12 is "Release the bundle Zip file"
> https://github.com/apache/portals-pluto/blob/master/RELEASE-PROCEDURE.txt#L129-L146
>
> And Step 13 is "PUT THE RELEASE CANDIDATE UP FOR A VOTE"
> https://github.com/apache/portals-pluto/blob/master/RELEASE-PROCEDURE.txt#L148-L164
>
> Q1. I think I need to add a step in between that uploads
> pluto-3.0.0-source-release.zip to Nexus. Would you agree?

That's an option. But I don't think it is required to upload the the
source-release.zip to Nexus. It could be a convenient, automated
option though.
The reason why I suggested you upload the source-release.zip to
/dist/dev/... folder is because:
- assuming the existing build process generates source-release.zip
file already (based on the fact that there was 3.0.0
source-release.zip in /dist/releases/... folder before), it could be
easier for you just to copy the locally generated source-release.zip
to the temporary /dist/dev/... folder for voting purpose. No change to
improve the pom; just adding one more manual step for now, which seems
easier, quicker to me for now.
- An Apache release is basically a source release in
/dist/releases/... Binaries or maven artifacts in Nexus are for
convenience. Therefore, it is actually good to upload release
candidate source artifacts to /dist/dev/portals-pluto-3.0.1/ folder
for voting because it is just a matter of copying from the
/dist/dev/... folder to /dist/release/ folder in the end as part of
"14. Finalize release process" step for instance. Simpler than Nexus
directory in a sense in voting and post-voting process. However, if
you feel it's easier to upload the source-release.zip file to Nexus
and link to that in voting e-mail message, feel free to do so. Fine as
long as the source-release.zip is downloadable and verifiable.

>
> Q2. Is the "dist/dev" step you mentioned necessary? The release instructions
> don't mention "dist/dev" -- only "dist/release" in Step 14 (after the vote).

I explained it above. I thought it would be more convenient for you as
well, but feel free to upload it to Nexus if it's more convenient and
add links to those in voting e-mail message.

Regards,

Woonsan

>
> Thank you,
>
> Neil
>
>
> On 5/15/18 3:51 AM, Woonsan Ko wrote:
>>
>> Hi Neil,
>>
>> Thank you very much for the elaborated answers.
>>
>> I think the only thing required as minimum is to upload the
>> pluto-3.0.1-source-release.zip and its signature files (.asc, .sha) to
>> https://dist.apache.org/repos/dist/dev/portals/pluto/pluto-3.0.1/, and
>> put the link to the directory containing the source zip and signature
>> files, in the new VOTE e-mail message.
>>
>> As I see pluto-3.0.0-source-release.zip in the release dist site, it
>> contains everything: portlet-api, pluto-portal and maven archetypes.
>> Therefore that should be good enough for our release process.
>> Please note that the files you upload should be moved to
>> https://dist.apache.org/repos/dist/release/portals/ directory after
>> voting passed. In that way, we can be sure what's voted for is the
>> same as the real release files.
>>
>> Git tag is secondary in the release process. It can be tampered on my
>> machine or on your machine. By uploading the
>> pluto-3.0.1-source-release.zip which you built locally to the dist
>> folder and verifying that together, we can be sure the release
>> artifacts are fine and we can move to the release distribution folder
>> as an official release.
>>
>> In summary, would you be able to cut a new release and upload
>> pluto-3.0.x-source-release.zip to the /dev/portals directory? And
>> could you include the directory link where we can download from, for
>> verification in the next voting message?
>> Then I can proceed with verification and cast my vote afterward.
>>
>> Thanks in advance,
>>
>> Woonsan
>>
>>
>> On Tue, May 15, 2018 at 12:27 AM, Neil Griffin
>> <ne...@portletfaces.org> wrote:
>>>
>>> Hi Woonsan,
>>>
>>> I tried adding this to portals-pluto/pom.xml and it didn't work:
>>>
>>>      <profile>
>>>        <id>apache-release</id>
>>>        <build>
>>>          <plugins>
>>>            <plugin>
>>>              <groupId>org.apache.maven.plugins</groupId>
>>>              <artifactId>maven-assembly-plugin</artifactId>
>>>              <configuration>
>>>                <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot>
>>>              </configuration>
>>>            </plugin>
>>>          </plugins>
>>>        </build>
>>>      </profile>
>>>
>>> I also tried -DrunOnlyAtExecutionRoot=true on command line and it didn't
>>> work.
>>>
>>> In other words, when I run the release procedure from the top
>>> (portals-pluto/) the maven-assembly-plugin will only generate a
>>> "source-release" ZIP for pluto-3.0.1-source-release.zip and nothing else.
>>>
>>> Since that the only source-release ZIP that has been released in the
>>> past,
>>> shouldn't that be adequate for this 3.0.1 release?
>>>
>>> Thank you,
>>>
>>> Neil
>>>
>>>
>>> On 5/14/18 4:51 PM, Neil Griffin wrote:
>>>>
>>>>
>>>> Hi Woonsan,
>>>>
>>>> Thank you for your efforts to make sure the release process is correct.
>>>>
>>>> 1) Regarding the "source-release" bundles:
>>>>
>>>> I *think* I found the problem as to why they are missing -- it is likely
>>>> due to the following config of the maven-assembly-plugin in the
>>>> apache-16
>>>> parent-most pom descriptor:
>>>>
>>>>        <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
>>>>
>>>> See:
>>>>
>>>> https://search.maven.org/remotecontent?filepath=org/apache/apache/16/apache-16.pom
>>>>
>>>> Since we ran the Maven release plugin from the portals-pluto root, none
>>>> of
>>>> the jars like pluto-container-api.jar, etc. had the companion
>>>> "source-release" bundle.
>>>>
>>>> The reason why the archetypes worked, is because I released them
>>>> individually from their respective "root" directories.
>>>>
>>>> BTW, as far as I can determine, the "source-release" problem is not new.
>>>> It has been there for many years. For example, see:
>>>>
>>>>
>>>> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.portals.pluto%22%20AND%20a%3A%22pluto-container-api%22
>>>>
>>>> Anyway, I'll fix it before re-releasing.
>>>>
>>>> 2) Regarding Git, in the 3.0.0 release Scott pushed the 3.0.0 *commits*
>>>> for the vote, but _not_ the *tags* until the vote was final. That worked
>>>> well because he actually had to roll-back the release. I recommend we do
>>>> it
>>>> that way again.
>>>>
>>>>
>>>> -- Neil
>>>>
>>>> On 5/14/18 11:53 AM, Woonsan Ko wrote:
>>>>>
>>>>>
>>>>> 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 <wo...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
>>>>>> <ne...@portletfaces.org> 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
>>>>>>>> <ne...@portletfaces.org> 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
>>>>>> <ne...@portletfaces.org> 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
>>>>>>>> <ne...@portletfaces.org> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
Hi Neil,

On Wed, May 16, 2018 at 5:48 PM, Neil Griffin
<ne...@portletfaces.org> wrote:
> Hi Woonsan,
>
> Step 12 is "Release the bundle Zip file"
> https://github.com/apache/portals-pluto/blob/master/RELEASE-PROCEDURE.txt#L129-L146
>
> And Step 13 is "PUT THE RELEASE CANDIDATE UP FOR A VOTE"
> https://github.com/apache/portals-pluto/blob/master/RELEASE-PROCEDURE.txt#L148-L164
>
> Q1. I think I need to add a step in between that uploads
> pluto-3.0.0-source-release.zip to Nexus. Would you agree?

That's an option. But I don't think it is required to upload the the
source-release.zip to Nexus. It could be a convenient, automated
option though.
The reason why I suggested you upload the source-release.zip to
/dist/dev/... folder is because:
- assuming the existing build process generates source-release.zip
file already (based on the fact that there was 3.0.0
source-release.zip in /dist/releases/... folder before), it could be
easier for you just to copy the locally generated source-release.zip
to the temporary /dist/dev/... folder for voting purpose. No change to
improve the pom; just adding one more manual step for now, which seems
easier, quicker to me for now.
- An Apache release is basically a source release in
/dist/releases/... Binaries or maven artifacts in Nexus are for
convenience. Therefore, it is actually good to upload release
candidate source artifacts to /dist/dev/portals-pluto-3.0.1/ folder
for voting because it is just a matter of copying from the
/dist/dev/... folder to /dist/release/ folder in the end as part of
"14. Finalize release process" step for instance. Simpler than Nexus
directory in a sense in voting and post-voting process. However, if
you feel it's easier to upload the source-release.zip file to Nexus
and link to that in voting e-mail message, feel free to do so. Fine as
long as the source-release.zip is downloadable and verifiable.

>
> Q2. Is the "dist/dev" step you mentioned necessary? The release instructions
> don't mention "dist/dev" -- only "dist/release" in Step 14 (after the vote).

I explained it above. I thought it would be more convenient for you as
well, but feel free to upload it to Nexus if it's more convenient and
add links to those in voting e-mail message.

Regards,

Woonsan

>
> Thank you,
>
> Neil
>
>
> On 5/15/18 3:51 AM, Woonsan Ko wrote:
>>
>> Hi Neil,
>>
>> Thank you very much for the elaborated answers.
>>
>> I think the only thing required as minimum is to upload the
>> pluto-3.0.1-source-release.zip and its signature files (.asc, .sha) to
>> https://dist.apache.org/repos/dist/dev/portals/pluto/pluto-3.0.1/, and
>> put the link to the directory containing the source zip and signature
>> files, in the new VOTE e-mail message.
>>
>> As I see pluto-3.0.0-source-release.zip in the release dist site, it
>> contains everything: portlet-api, pluto-portal and maven archetypes.
>> Therefore that should be good enough for our release process.
>> Please note that the files you upload should be moved to
>> https://dist.apache.org/repos/dist/release/portals/ directory after
>> voting passed. In that way, we can be sure what's voted for is the
>> same as the real release files.
>>
>> Git tag is secondary in the release process. It can be tampered on my
>> machine or on your machine. By uploading the
>> pluto-3.0.1-source-release.zip which you built locally to the dist
>> folder and verifying that together, we can be sure the release
>> artifacts are fine and we can move to the release distribution folder
>> as an official release.
>>
>> In summary, would you be able to cut a new release and upload
>> pluto-3.0.x-source-release.zip to the /dev/portals directory? And
>> could you include the directory link where we can download from, for
>> verification in the next voting message?
>> Then I can proceed with verification and cast my vote afterward.
>>
>> Thanks in advance,
>>
>> Woonsan
>>
>>
>> On Tue, May 15, 2018 at 12:27 AM, Neil Griffin
>> <ne...@portletfaces.org> wrote:
>>>
>>> Hi Woonsan,
>>>
>>> I tried adding this to portals-pluto/pom.xml and it didn't work:
>>>
>>>      <profile>
>>>        <id>apache-release</id>
>>>        <build>
>>>          <plugins>
>>>            <plugin>
>>>              <groupId>org.apache.maven.plugins</groupId>
>>>              <artifactId>maven-assembly-plugin</artifactId>
>>>              <configuration>
>>>                <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot>
>>>              </configuration>
>>>            </plugin>
>>>          </plugins>
>>>        </build>
>>>      </profile>
>>>
>>> I also tried -DrunOnlyAtExecutionRoot=true on command line and it didn't
>>> work.
>>>
>>> In other words, when I run the release procedure from the top
>>> (portals-pluto/) the maven-assembly-plugin will only generate a
>>> "source-release" ZIP for pluto-3.0.1-source-release.zip and nothing else.
>>>
>>> Since that the only source-release ZIP that has been released in the
>>> past,
>>> shouldn't that be adequate for this 3.0.1 release?
>>>
>>> Thank you,
>>>
>>> Neil
>>>
>>>
>>> On 5/14/18 4:51 PM, Neil Griffin wrote:
>>>>
>>>>
>>>> Hi Woonsan,
>>>>
>>>> Thank you for your efforts to make sure the release process is correct.
>>>>
>>>> 1) Regarding the "source-release" bundles:
>>>>
>>>> I *think* I found the problem as to why they are missing -- it is likely
>>>> due to the following config of the maven-assembly-plugin in the
>>>> apache-16
>>>> parent-most pom descriptor:
>>>>
>>>>        <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
>>>>
>>>> See:
>>>>
>>>> https://search.maven.org/remotecontent?filepath=org/apache/apache/16/apache-16.pom
>>>>
>>>> Since we ran the Maven release plugin from the portals-pluto root, none
>>>> of
>>>> the jars like pluto-container-api.jar, etc. had the companion
>>>> "source-release" bundle.
>>>>
>>>> The reason why the archetypes worked, is because I released them
>>>> individually from their respective "root" directories.
>>>>
>>>> BTW, as far as I can determine, the "source-release" problem is not new.
>>>> It has been there for many years. For example, see:
>>>>
>>>>
>>>> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.portals.pluto%22%20AND%20a%3A%22pluto-container-api%22
>>>>
>>>> Anyway, I'll fix it before re-releasing.
>>>>
>>>> 2) Regarding Git, in the 3.0.0 release Scott pushed the 3.0.0 *commits*
>>>> for the vote, but _not_ the *tags* until the vote was final. That worked
>>>> well because he actually had to roll-back the release. I recommend we do
>>>> it
>>>> that way again.
>>>>
>>>>
>>>> -- Neil
>>>>
>>>> On 5/14/18 11:53 AM, Woonsan Ko wrote:
>>>>>
>>>>>
>>>>> 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 <wo...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
>>>>>> <ne...@portletfaces.org> 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
>>>>>>>> <ne...@portletfaces.org> 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
>>>>>> <ne...@portletfaces.org> 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
>>>>>>>> <ne...@portletfaces.org> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Neil Griffin <ne...@portletfaces.org>.
Hi Woonsan,

Step 12 is "Release the bundle Zip file"
https://github.com/apache/portals-pluto/blob/master/RELEASE-PROCEDURE.txt#L129-L146

And Step 13 is "PUT THE RELEASE CANDIDATE UP FOR A VOTE"
https://github.com/apache/portals-pluto/blob/master/RELEASE-PROCEDURE.txt#L148-L164

Q1. I think I need to add a step in between that uploads pluto-3.0.0-source-release.zip to Nexus. Would you agree?

Q2. Is the "dist/dev" step you mentioned necessary? The release instructions don't mention "dist/dev" -- only "dist/release" in Step 14 (after the vote).

Thank you,

Neil

On 5/15/18 3:51 AM, Woonsan Ko wrote:
> Hi Neil,
> 
> Thank you very much for the elaborated answers.
> 
> I think the only thing required as minimum is to upload the
> pluto-3.0.1-source-release.zip and its signature files (.asc, .sha) to
> https://dist.apache.org/repos/dist/dev/portals/pluto/pluto-3.0.1/, and
> put the link to the directory containing the source zip and signature
> files, in the new VOTE e-mail message.
> 
> As I see pluto-3.0.0-source-release.zip in the release dist site, it
> contains everything: portlet-api, pluto-portal and maven archetypes.
> Therefore that should be good enough for our release process.
> Please note that the files you upload should be moved to
> https://dist.apache.org/repos/dist/release/portals/ directory after
> voting passed. In that way, we can be sure what's voted for is the
> same as the real release files.
> 
> Git tag is secondary in the release process. It can be tampered on my
> machine or on your machine. By uploading the
> pluto-3.0.1-source-release.zip which you built locally to the dist
> folder and verifying that together, we can be sure the release
> artifacts are fine and we can move to the release distribution folder
> as an official release.
> 
> In summary, would you be able to cut a new release and upload
> pluto-3.0.x-source-release.zip to the /dev/portals directory? And
> could you include the directory link where we can download from, for
> verification in the next voting message?
> Then I can proceed with verification and cast my vote afterward.
> 
> Thanks in advance,
> 
> Woonsan
> 
> 
> On Tue, May 15, 2018 at 12:27 AM, Neil Griffin
> <ne...@portletfaces.org> wrote:
>> Hi Woonsan,
>>
>> I tried adding this to portals-pluto/pom.xml and it didn't work:
>>
>>      <profile>
>>        <id>apache-release</id>
>>        <build>
>>          <plugins>
>>            <plugin>
>>              <groupId>org.apache.maven.plugins</groupId>
>>              <artifactId>maven-assembly-plugin</artifactId>
>>              <configuration>
>>                <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot>
>>              </configuration>
>>            </plugin>
>>          </plugins>
>>        </build>
>>      </profile>
>>
>> I also tried -DrunOnlyAtExecutionRoot=true on command line and it didn't
>> work.
>>
>> In other words, when I run the release procedure from the top
>> (portals-pluto/) the maven-assembly-plugin will only generate a
>> "source-release" ZIP for pluto-3.0.1-source-release.zip and nothing else.
>>
>> Since that the only source-release ZIP that has been released in the past,
>> shouldn't that be adequate for this 3.0.1 release?
>>
>> Thank you,
>>
>> Neil
>>
>>
>> On 5/14/18 4:51 PM, Neil Griffin wrote:
>>>
>>> Hi Woonsan,
>>>
>>> Thank you for your efforts to make sure the release process is correct.
>>>
>>> 1) Regarding the "source-release" bundles:
>>>
>>> I *think* I found the problem as to why they are missing -- it is likely
>>> due to the following config of the maven-assembly-plugin in the apache-16
>>> parent-most pom descriptor:
>>>
>>>        <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
>>>
>>> See:
>>> https://search.maven.org/remotecontent?filepath=org/apache/apache/16/apache-16.pom
>>>
>>> Since we ran the Maven release plugin from the portals-pluto root, none of
>>> the jars like pluto-container-api.jar, etc. had the companion
>>> "source-release" bundle.
>>>
>>> The reason why the archetypes worked, is because I released them
>>> individually from their respective "root" directories.
>>>
>>> BTW, as far as I can determine, the "source-release" problem is not new.
>>> It has been there for many years. For example, see:
>>>
>>> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.portals.pluto%22%20AND%20a%3A%22pluto-container-api%22
>>>
>>> Anyway, I'll fix it before re-releasing.
>>>
>>> 2) Regarding Git, in the 3.0.0 release Scott pushed the 3.0.0 *commits*
>>> for the vote, but _not_ the *tags* until the vote was final. That worked
>>> well because he actually had to roll-back the release. I recommend we do it
>>> that way again.
>>>
>>>
>>> -- Neil
>>>
>>> On 5/14/18 11:53 AM, Woonsan Ko wrote:
>>>>
>>>> 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 <wo...@apache.org> wrote:
>>>>>
>>>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
>>>>> <ne...@portletfaces.org> 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
>>>>>>> <ne...@portletfaces.org> 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
>>>>> <ne...@portletfaces.org> 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
>>>>>>> <ne...@portletfaces.org> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
Hi Neil,

Thank you very much for the elaborated answers.

I think the only thing required as minimum is to upload the
pluto-3.0.1-source-release.zip and its signature files (.asc, .sha) to
https://dist.apache.org/repos/dist/dev/portals/pluto/pluto-3.0.1/, and
put the link to the directory containing the source zip and signature
files, in the new VOTE e-mail message.

As I see pluto-3.0.0-source-release.zip in the release dist site, it
contains everything: portlet-api, pluto-portal and maven archetypes.
Therefore that should be good enough for our release process.
Please note that the files you upload should be moved to
https://dist.apache.org/repos/dist/release/portals/ directory after
voting passed. In that way, we can be sure what's voted for is the
same as the real release files.

Git tag is secondary in the release process. It can be tampered on my
machine or on your machine. By uploading the
pluto-3.0.1-source-release.zip which you built locally to the dist
folder and verifying that together, we can be sure the release
artifacts are fine and we can move to the release distribution folder
as an official release.

In summary, would you be able to cut a new release and upload
pluto-3.0.x-source-release.zip to the /dev/portals directory? And
could you include the directory link where we can download from, for
verification in the next voting message?
Then I can proceed with verification and cast my vote afterward.

Thanks in advance,

Woonsan


On Tue, May 15, 2018 at 12:27 AM, Neil Griffin
<ne...@portletfaces.org> wrote:
> Hi Woonsan,
>
> I tried adding this to portals-pluto/pom.xml and it didn't work:
>
>     <profile>
>       <id>apache-release</id>
>       <build>
>         <plugins>
>           <plugin>
>             <groupId>org.apache.maven.plugins</groupId>
>             <artifactId>maven-assembly-plugin</artifactId>
>             <configuration>
>               <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot>
>             </configuration>
>           </plugin>
>         </plugins>
>       </build>
>     </profile>
>
> I also tried -DrunOnlyAtExecutionRoot=true on command line and it didn't
> work.
>
> In other words, when I run the release procedure from the top
> (portals-pluto/) the maven-assembly-plugin will only generate a
> "source-release" ZIP for pluto-3.0.1-source-release.zip and nothing else.
>
> Since that the only source-release ZIP that has been released in the past,
> shouldn't that be adequate for this 3.0.1 release?
>
> Thank you,
>
> Neil
>
>
> On 5/14/18 4:51 PM, Neil Griffin wrote:
>>
>> Hi Woonsan,
>>
>> Thank you for your efforts to make sure the release process is correct.
>>
>> 1) Regarding the "source-release" bundles:
>>
>> I *think* I found the problem as to why they are missing -- it is likely
>> due to the following config of the maven-assembly-plugin in the apache-16
>> parent-most pom descriptor:
>>
>>       <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
>>
>> See:
>> https://search.maven.org/remotecontent?filepath=org/apache/apache/16/apache-16.pom
>>
>> Since we ran the Maven release plugin from the portals-pluto root, none of
>> the jars like pluto-container-api.jar, etc. had the companion
>> "source-release" bundle.
>>
>> The reason why the archetypes worked, is because I released them
>> individually from their respective "root" directories.
>>
>> BTW, as far as I can determine, the "source-release" problem is not new.
>> It has been there for many years. For example, see:
>>
>> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.portals.pluto%22%20AND%20a%3A%22pluto-container-api%22
>>
>> Anyway, I'll fix it before re-releasing.
>>
>> 2) Regarding Git, in the 3.0.0 release Scott pushed the 3.0.0 *commits*
>> for the vote, but _not_ the *tags* until the vote was final. That worked
>> well because he actually had to roll-back the release. I recommend we do it
>> that way again.
>>
>>
>> -- Neil
>>
>> On 5/14/18 11:53 AM, Woonsan Ko wrote:
>>>
>>> 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 <wo...@apache.org> wrote:
>>>>
>>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
>>>> <ne...@portletfaces.org> 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
>>>>>> <ne...@portletfaces.org> 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
>>>> <ne...@portletfaces.org> 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
>>>>>> <ne...@portletfaces.org> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
Hi Neil,

Thank you very much for the elaborated answers.

I think the only thing required as minimum is to upload the
pluto-3.0.1-source-release.zip and its signature files (.asc, .sha) to
https://dist.apache.org/repos/dist/dev/portals/pluto/pluto-3.0.1/, and
put the link to the directory containing the source zip and signature
files, in the new VOTE e-mail message.

As I see pluto-3.0.0-source-release.zip in the release dist site, it
contains everything: portlet-api, pluto-portal and maven archetypes.
Therefore that should be good enough for our release process.
Please note that the files you upload should be moved to
https://dist.apache.org/repos/dist/release/portals/ directory after
voting passed. In that way, we can be sure what's voted for is the
same as the real release files.

Git tag is secondary in the release process. It can be tampered on my
machine or on your machine. By uploading the
pluto-3.0.1-source-release.zip which you built locally to the dist
folder and verifying that together, we can be sure the release
artifacts are fine and we can move to the release distribution folder
as an official release.

In summary, would you be able to cut a new release and upload
pluto-3.0.x-source-release.zip to the /dev/portals directory? And
could you include the directory link where we can download from, for
verification in the next voting message?
Then I can proceed with verification and cast my vote afterward.

Thanks in advance,

Woonsan


On Tue, May 15, 2018 at 12:27 AM, Neil Griffin
<ne...@portletfaces.org> wrote:
> Hi Woonsan,
>
> I tried adding this to portals-pluto/pom.xml and it didn't work:
>
>     <profile>
>       <id>apache-release</id>
>       <build>
>         <plugins>
>           <plugin>
>             <groupId>org.apache.maven.plugins</groupId>
>             <artifactId>maven-assembly-plugin</artifactId>
>             <configuration>
>               <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot>
>             </configuration>
>           </plugin>
>         </plugins>
>       </build>
>     </profile>
>
> I also tried -DrunOnlyAtExecutionRoot=true on command line and it didn't
> work.
>
> In other words, when I run the release procedure from the top
> (portals-pluto/) the maven-assembly-plugin will only generate a
> "source-release" ZIP for pluto-3.0.1-source-release.zip and nothing else.
>
> Since that the only source-release ZIP that has been released in the past,
> shouldn't that be adequate for this 3.0.1 release?
>
> Thank you,
>
> Neil
>
>
> On 5/14/18 4:51 PM, Neil Griffin wrote:
>>
>> Hi Woonsan,
>>
>> Thank you for your efforts to make sure the release process is correct.
>>
>> 1) Regarding the "source-release" bundles:
>>
>> I *think* I found the problem as to why they are missing -- it is likely
>> due to the following config of the maven-assembly-plugin in the apache-16
>> parent-most pom descriptor:
>>
>>       <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
>>
>> See:
>> https://search.maven.org/remotecontent?filepath=org/apache/apache/16/apache-16.pom
>>
>> Since we ran the Maven release plugin from the portals-pluto root, none of
>> the jars like pluto-container-api.jar, etc. had the companion
>> "source-release" bundle.
>>
>> The reason why the archetypes worked, is because I released them
>> individually from their respective "root" directories.
>>
>> BTW, as far as I can determine, the "source-release" problem is not new.
>> It has been there for many years. For example, see:
>>
>> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.portals.pluto%22%20AND%20a%3A%22pluto-container-api%22
>>
>> Anyway, I'll fix it before re-releasing.
>>
>> 2) Regarding Git, in the 3.0.0 release Scott pushed the 3.0.0 *commits*
>> for the vote, but _not_ the *tags* until the vote was final. That worked
>> well because he actually had to roll-back the release. I recommend we do it
>> that way again.
>>
>>
>> -- Neil
>>
>> On 5/14/18 11:53 AM, Woonsan Ko wrote:
>>>
>>> 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 <wo...@apache.org> wrote:
>>>>
>>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
>>>> <ne...@portletfaces.org> 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
>>>>>> <ne...@portletfaces.org> 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
>>>> <ne...@portletfaces.org> 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
>>>>>> <ne...@portletfaces.org> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Neil Griffin <ne...@portletfaces.org>.
Hi Woonsan,

I tried adding this to portals-pluto/pom.xml and it didn't work:

     <profile>
       <id>apache-release</id>
       <build>
         <plugins>
           <plugin>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-assembly-plugin</artifactId>
             <configuration>
               <runOnlyAtExecutionRoot>false</runOnlyAtExecutionRoot>
             </configuration>
           </plugin>
         </plugins>
       </build>
     </profile>

I also tried -DrunOnlyAtExecutionRoot=true on command line and it didn't work.

In other words, when I run the release procedure from the top (portals-pluto/) the maven-assembly-plugin will only generate a "source-release" ZIP for pluto-3.0.1-source-release.zip and nothing else.

Since that the only source-release ZIP that has been released in the past, shouldn't that be adequate for this 3.0.1 release?

Thank you,

Neil

On 5/14/18 4:51 PM, Neil Griffin wrote:
> Hi Woonsan,
> 
> Thank you for your efforts to make sure the release process is correct.
> 
> 1) Regarding the "source-release" bundles:
> 
> I *think* I found the problem as to why they are missing -- it is likely due to the following config of the maven-assembly-plugin in the apache-16 parent-most pom descriptor:
> 
>       <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>
> 
> See: https://search.maven.org/remotecontent?filepath=org/apache/apache/16/apache-16.pom
> 
> Since we ran the Maven release plugin from the portals-pluto root, none of the jars like pluto-container-api.jar, etc. had the companion "source-release" bundle.
> 
> The reason why the archetypes worked, is because I released them individually from their respective "root" directories.
> 
> BTW, as far as I can determine, the "source-release" problem is not new. It has been there for many years. For example, see:
> https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.portals.pluto%22%20AND%20a%3A%22pluto-container-api%22
> 
> Anyway, I'll fix it before re-releasing.
> 
> 2) Regarding Git, in the 3.0.0 release Scott pushed the 3.0.0 *commits* for the vote, but _not_ the *tags* until the vote was final. That worked well because he actually had to roll-back the release. I recommend we do it that way again.
> 
> 
> -- Neil
> 
> On 5/14/18 11:53 AM, Woonsan Ko wrote:
>> 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 <wo...@apache.org> wrote:
>>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
>>> <ne...@portletfaces.org> 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
>>>>> <ne...@portletfaces.org> 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
>>> <ne...@portletfaces.org> 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
>>>>> <ne...@portletfaces.org> 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
>>>>>
>>>>>
>>>>
>>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Neil Griffin <ne...@portletfaces.org>.
Hi Woonsan,

Thank you for your efforts to make sure the release process is correct.

1) Regarding the "source-release" bundles:

I *think* I found the problem as to why they are missing -- it is likely due to the following config of the maven-assembly-plugin in the apache-16 parent-most pom descriptor:

     <runOnlyAtExecutionRoot>true</runOnlyAtExecutionRoot>

See: https://search.maven.org/remotecontent?filepath=org/apache/apache/16/apache-16.pom

Since we ran the Maven release plugin from the portals-pluto root, none of the jars like pluto-container-api.jar, etc. had the companion "source-release" bundle.

The reason why the archetypes worked, is because I released them individually from their respective "root" directories.

BTW, as far as I can determine, the "source-release" problem is not new. It has been there for many years. For example, see:
https://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.portals.pluto%22%20AND%20a%3A%22pluto-container-api%22

Anyway, I'll fix it before re-releasing.

2) Regarding Git, in the 3.0.0 release Scott pushed the 3.0.0 *commits* for the vote, but _not_ the *tags* until the vote was final. That worked well because he actually had to roll-back the release. I recommend we do it that way again.


-- Neil

On 5/14/18 11:53 AM, Woonsan Ko wrote:
> 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 <wo...@apache.org> wrote:
>> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
>> <ne...@portletfaces.org> 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
>>>> <ne...@portletfaces.org> 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
>> <ne...@portletfaces.org> 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
>>>> <ne...@portletfaces.org> 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
>>>>
>>>>
>>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
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 <wo...@apache.org> wrote:
> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
> <ne...@portletfaces.org> 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
>>> <ne...@portletfaces.org> 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
> <ne...@portletfaces.org> 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
>>> <ne...@portletfaces.org> 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
>>>
>>>
>>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
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 <wo...@apache.org> wrote:
> On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
> <ne...@portletfaces.org> 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
>>> <ne...@portletfaces.org> 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
> <ne...@portletfaces.org> 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
>>> <ne...@portletfaces.org> 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
>>>
>>>
>>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
<ne...@portletfaces.org> 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
>> <ne...@portletfaces.org> 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
<ne...@portletfaces.org> 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
>> <ne...@portletfaces.org> 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
>>
>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
On Mon, May 14, 2018 at 10:43 AM, Neil Griffin
<ne...@portletfaces.org> 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
>> <ne...@portletfaces.org> 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
<ne...@portletfaces.org> 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
>> <ne...@portletfaces.org> 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
>>
>>
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Neil Griffin <ne...@portletfaces.org>.
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
> <ne...@portletfaces.org> 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
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
-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
<ne...@portletfaces.org> 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

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
Hi,

I'm not sure if the release includes the source packages properly.
"The fundamental requirement for a release is that it consist of the
necessary source code to build the project." [1]
See my comments inline for each package.

[1] http://www.apache.org/dev/release-publishing.html


On Fri, May 11, 2018 at 3:06 PM, Neil Griffin
<ne...@portletfaces.org> 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

These do not include source packages to *build* after downloading.
Neither maven artifacts such as pluto-portal-driver-3.0.1-sources.jar
nor GIT tag is qualified as "source code to build the project" in our
releases.
Do those projects not have apache release maven profile or not use the
profile in the release process?

>
> 2) pluto+tomcat bundle:
> https://repository.apache.org/content/repositories/orgapacheportals-1019

This one doesn't include source package either.

>
>     (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

These ones have source packages (e.g,
bean-portlet-archetype-3.0.1-source-release.zip) to build in
https://repository.apache.org/content/repositories/orgapacheportals-1020/org/apache/portals/pluto/archetype/bean-portlet-archetype/3.0.1/.
It should have been mentioned in this VOTE E-Mail message with either
the specific staging maven repo link or distribution links in
https://dist.apache.org/repos/dist/dev/portals/... (note /dev/, not
/release/ in pre-official-release steps) after copying those to the
directory in the release process, IMO.
But I notice that this step is missing in [2] too as a pre-voting
step. It has a post-vote step to copy those though. I believe it's
better to copy those source package zip file and signature files in
https://dist.apache.org/repos/dist/dev/... when proposing votes
because we need to validate each source package builds properly, has
been signed properly, etc.

[2] https://github.com/apache/portals-pluto/blob/master/RELEASE-PROCEDURE.txt

I believe we should fix the two problems before proceeding: (a)
include source artifacts in portlet-api and pluto-poartal components,
(b) include source artifacts in pluto+tomcat bundle.
Solution would be just either adding apache release maven profile in
those projects or using it in the release process.

Please let me know if I miss anything.

Regards,

Woonsan


>
> 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

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Vernon Singleton <vs...@gmail.com>.
+1

On Fri, May 11, 2018 at 3:06 PM, Neil Griffin <neil.griffin@portletfaces.org
> 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?proje
> ctId=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
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Werner Keil <we...@gmail.com>.
I guess JCR-362 means JSR-362, as JCR (Java Content Repository) also
relates to Portlets but those are different JSRs.

Regards,
Werner



On Fri, May 11, 2018 at 9:06 PM, Neil Griffin <neil.griffin@portletfaces.org
> 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?proje
> ctId=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
>

Re: [VOTE] Release Apache Portals Pluto 3.0.1

Posted by Woonsan Ko <wo...@apache.org>.
-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
<ne...@portletfaces.org> 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