Return-Path: X-Original-To: apmail-incubator-general-archive@www.apache.org Delivered-To: apmail-incubator-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A6D518338 for ; Wed, 10 Aug 2011 05:07:48 +0000 (UTC) Received: (qmail 11935 invoked by uid 500); 10 Aug 2011 05:07:39 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 11056 invoked by uid 500); 10 Aug 2011 05:07:27 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 11045 invoked by uid 99); 10 Aug 2011 05:07:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Aug 2011 05:07:20 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [88.84.128.168] (HELO samaflost.de) (88.84.128.168) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Aug 2011 05:07:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by samaflost.de (Postfix) with ESMTP id 66D2A40E000A for ; Wed, 10 Aug 2011 07:06:53 +0200 (CEST) Received: from samaflost.de ([127.0.0.1]) by localhost (v35516.1blu.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjJoM1W1Y5fS for ; Wed, 10 Aug 2011 07:06:53 +0200 (CEST) Received: by samaflost.de (Postfix, from userid 1000) id 20BAE40E0009; Wed, 10 Aug 2011 07:06:53 +0200 (CEST) From: Stefan Bodewig To: general@incubator.apache.org Subject: Re: [VOTE] Apache Lucy (incubating) 0.2.0 RC 3 References: <20110807192524.GA27957@rectangular.com> <87r54wrs0l.fsf@v35516.1blu.de> <20110809010054.GA11722@rectangular.com> <871uwvti4s.fsf@v35516.1blu.de> <20110810002339.GA27336@rectangular.com> Date: Wed, 10 Aug 2011 07:06:53 +0200 In-Reply-To: <20110810002339.GA27336@rectangular.com> (Marvin Humphrey's message of "Tue, 9 Aug 2011 17:23:40 -0700") Message-ID: <8739h9ua6q.fsf@v35516.1blu.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Checked: Checked by ClamAV on apache.org On 2011-08-10, Marvin Humphrey wrote: > On Tue, Aug 09, 2011 at 04:48:19AM +0200, Stefan Bodewig wrote: >> You might want to use a different extension in the future (.sha512) to >> reduce the confusion in particular since most Java projects only provide >> sha1 hashes. > That makes sense to me, but it's contrary to the documentation on the > release-signing page, which A) states that when provided, an "SHA checksum" > file *must* be suffixed ".sha", B) recommends against using SHA1, and C) > provides sample code for using GPG to generate an SHA512 file with a ".sha" > extension. > http://www.apache.org/dev/release-signing.html#reading I never read that page ;-) All I can say is that it is not done that way by any Maven built project and not done that way by any Ant built project I'm aware of as either tool comes with built-in checksum support and their formats are quite different from the one used by GPG (/me takes notice of this as an enhancement request to add a new format option to the Ant task). Releases by the Ant project come with .md5, .sha1 and .sha512 hashes. > Though release-signing.html claims that it is "not normative", unless someone > presses the issue, I think it's best to leave the SHA-generating sections of > the Lucy release_commands.pl file unchanged, so that our next release will > also have an SHA512 sum in a file with a ".sha" extension per the instructions > above. Absolutely. >>> It would be nice if we could comment the rat-excludes file and have >>> the relevant comment show up next to each excluded file in the report, >>> as that would make auditing easier. >> Sounds like an enhancement request for RAT. > I guess it did sound that way... but I think RAT's pretty great as is! Anything can be improved and it could be an alternative exclude file format. But yes, it would likely lead to a bigger XML or json or whatever file with little value added. I don't think the current format allows for any kind of comments, though. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org