On 09/11/17 21:43, Gary Gregory wrote: > On Thu, Nov 9, 2017 at 2:35 PM, Mark Thomas <ma...@apache.org> wrote: > >> On 09/11/17 20:18, Gary Gregory wrote: >>> There is a lot of required information missing from this VOTE request. >> >> No there isn't. The VOTE contains more than the minimum necessary >> information for a VOTE that is consistent with ASF policy. >> >> Take a look at a typical httpd vote thread: >> http://markmail.org/thread/t5qjo3s6cnis6dag > > > This is not httpd, their PMC can decide on their own rules of engagement.
Yes and no. The minimum requirements for a valid release VOTE are set by ASF policy. Not individual PMCs. My point is that my original email contained more than enough information for the VOTE to be valid. >>> How about following the format in >>> http://commons.apache.org/releases/prepare.html ? >> >> Commons seems to have added an awful lot of additional requirements. >> Working through them: >> >> Listing the Maven artefacts and hashes is unnecessary given the staging >> repo URL and the auditing we have in place around repository actions. >> > > This is all about tractability of what we vote on. If cutting and pasting > the list of files and hashes from the email Nexus sends you is too much > work, well, I'm not sure what to say. We have all the traceability we need with repo URL. > Any SVN URL should be accompanied with a revision number. Not necessary (I did opt to add it for the tag as I sometimes delete a tag and recreate it although that didn't happen in this case). In the highly unlikely event we ever needed to prove that the release artefacts were the ones we voted on, we have everything we need in the archives. Yes it will be a little more work without the additional information pulled into the vote thread. However, I am not aware of a single case of the ASF ever having to prove that what we released is what we voted one. My preference is to save a little bit of effort on every release at the risk of requiring a larger effort to prove traceability in the highly unlikely event that we ever needed to do that. >> The site is not part of the release and as such does not need to be >> voted on. In addition, now that people.a.o does not allow shell access >> publishing a draft site is rather more involved. Simpler for folks just >> to build it locally and review it if they want to. >> > > The simple solution I've been using is to publish a zipped site on p.a.o. > It all depends on how much work you want to give reviewers. Some reviewers > like to compare what they build from source with what an RM puts out. Given that: - this is the first Daemon release in over 4 years; - there have been lots of changes to the build system since the last release; - the Daemon docs are rather light on where versions / dates etc. need to be updated when a release happens; and - we've updated the minimum Java and Windows versions. I'm expecting there to be all sorts of build / packaging niggles in RC2. I've already thrown away RC1 before it got as far as the VOTE because I realised that the release notes were empty. I'd rather concentrate my limited cycles on getting an extremely overdue release out than on collating traceability information we are almost certainly never going to need. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
