Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id B72D6200D37 for ; Thu, 9 Nov 2017 23:27:58 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id B5B41160BEF; Thu, 9 Nov 2017 22:27:58 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 072D81609C8 for ; Thu, 9 Nov 2017 23:27:57 +0100 (CET) Received: (qmail 90914 invoked by uid 500); 9 Nov 2017 22:27:57 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 90903 invoked by uid 99); 9 Nov 2017 22:27:57 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Nov 2017 22:27:57 +0000 Received: from [192.168.23.12] (host81-156-41-218.range81-156.btcentralplus.com [81.156.41.218]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 7E4DE1A0048 for ; Thu, 9 Nov 2017 22:27:56 +0000 (UTC) Subject: Re: [VOTE] Release Apache Commons Daemon 1.1.0 based on RC2 To: Commons Developers List References: <140579de-09e7-b184-8892-b9539c5eb93e@apache.org> From: Mark Thomas Message-ID: <2fcc9938-c70e-c080-3838-74b1bae574d9@apache.org> Date: Thu, 9 Nov 2017 22:27:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit archived-at: Thu, 09 Nov 2017 22:27:58 -0000 On 09/11/17 21:43, Gary Gregory wrote: > On Thu, Nov 9, 2017 at 2:35 PM, Mark Thomas 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-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org