On 2 May 2016 at 15:00, Josh Elser <els...@apache.org> wrote: > Also, please re-read the end of the previous thread on compatibility. > > I clearly stated that there were some changes which I consider not worth > changing about the TarArchiveEntry code. If you feel like these are not > acceptable, please start a discussion about this so you can come to > consensus on how the changes should be addressed.
The release vote mail really needs to include all the release-specific information that the reviewer needs to do the review. If there are caveats etc relating to the Clirr report these need to be included in the vote mail. Both to make it easier for the reviewers, and for the historical record to show that these items were considered. > > Josh Elser wrote: >> >> Sebb -- did you actually read the changes? >> >> You should note that those are all method additions which we already >> decided were allowed >> >> sebb wrote: >>> >>> I have now found the Clirr Report at >>> >>> >>> http://home.apache.org/~elserj/commons/commons-vfs-2.1/commons-vfs2/clirr-report.html >>> >>> >>> There are still some breaking changes that affect BC as far as I can >>> tell, so that means I need to vote >>> >>> -1 >>> >>> >>> >>> On 2 May 2016 at 11:31, sebb<seb...@gmail.com> wrote: >>>> >>>> Also the sandbox tree is missing from the source archives. >>>> Yet there are sandbox jars in Nexus. >>>> We cannot publish source to Maven that is not also in the source >>>> artifacts. >>>> >>>> If the sandbox code is not intended to be released, it should be moved >>>> from trunk. >>>> >>>> >>>> On 2 May 2016 at 11:16, sebb<seb...@gmail.com> wrote: >>>>> >>>>> Also please include a link to the KEYS file, i.e. >>>>> >>>>> https://www.apache.org/dist/commons/KEYS >>>>> >>>>> Note that the standard download page is >>>>> >>>>> >>>>> http://home.apache.org/~elserj/commons/commons-vfs-2.1/download_vfs.html >>>>> >>>>> >>>>> I think that should be in the site menu. >>>>> >>>>> The "Download and Build" page is more suitable for developers than end >>>>> users (especially if it points to trunk, which is not voted on) so >>>>> should not be the primary download page. >>>>> >>>>> Also there seem to be two identical copies of each of the non-Maven >>>>> release artifacts: >>>>> commons-vfs-2.1-bin >>>>> and >>>>> commons-vfs2-distribution-2.1-bin >>>>> >>>>> etc. >>>>> >>>>> >>>>> Are they supposed to be the same? If not what is missing from one of >>>>> them? >>>>> >>>>> On 2 May 2016 at 10:40, sebb<seb...@gmail.com> wrote: >>>>>> >>>>>> On 2 May 2016 at 05:28, Josh Elser<els...@apache.org> wrote: >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> Please consider the following for Apache Commons VFS2 version 2.1 >>>>>>> (rc0). >>>>>>> >>>>>>> Maven repository: >>>>>>> >>>>>>> https://repository.apache.org/content/repositories/orgapachecommons-1161 >>>>>>> >>>>>> The e-mail should contain the hashes of the release items as the above >>>>>> URL is transitory. >>>>>> The hashes allow one to tie the released files back to the vote >>>>>> thread. >>>>>> >>>>>> They can be copied from the Nexus mail. >>>>>> >>>>>>> Artifacts: >>>>>>> https://dist.apache.org/repos/dist/dev/commons/vfs/{binaries,source} >>>>>> >>>>>> Likewise here we include the revision id of the URL: >>>>>> >>>>>> https://dist.apache.org/repos/dist/dev/commons/vfs/ >>>>>> >>>>>> >>>>>>> Staged site: >>>>>>> http://home.apache.org/~elserj/commons/commons-vfs-2.1/index.html >>>>>> >>>>>> There's no Clirr report that I could find. >>>>>> >>>>>> Also the download page links to trunk rather than the specific tag. >>>>>> >>>>>>> All reports are available in the provided staged Maven site. >>>>>>> JIRA-generated >>>>>>> release notes are available in the dist.a.o "Artifacts" >>>>>>> repository. Unit >>>>>>> tests pass and the RC was built util JDK6. >>>>>> >>>>>> E-mail should really have URL to make it easy for reviewers. >>>>>> >>>>>>> The current code is available in branches/VFS-2.1 at r1741921. >>>>>>> This is what >>>>>>> will be copied to tags upon successful passing of this vote. >>>>>> >>>>>> Full URLs in e-mails please. >>>>>> Also it should be a TAG not a branch, as it should be kept if the vote >>>>>> is successful >>>>>> >>>>>>> This vote will be open for 72-hours, 2016/05/05 0500 UTC. >>>>>>> >>>>>>> [ ] +1 Release these artifacts as version 2.1 >>>>>>> [ ] 0 OK, but... >>>>>>> [X] -1 I oppose these artifacts as version 2.1 because.. >>>>>> >>>>>> As above. >>>>>> >>>>>> No need necessarily to rebuild everything as most of the concerns >>>>>> relate to the vote e-mail and the site. >>>>>> e.g. you can rename the branch as a tag. >>>>>> >>>>>>> - Josh >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
