incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: [VOTE] Apache Lucy (incubating) 0.2.0 RC 3
Date Wed, 10 Aug 2011 05:06:53 GMT
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


Mime
View raw message