On Sat, 2004-04-10 at 08:04, Aurelien Bompard wrote: > Toshio wrote: > > * Regarding the Sources lines: I'd include the full URL for the > > tarball and say it comes from a canonical source rather than simply > > "is valid". > > * http://www.caliban.org/files/bash/bash-completion-20040331.tar.gz is > > the canonical Source location > > Maybe the full URL is not necessary in the review, we could just add that > canonicalness has been checked. > I'm worried about the fact that bugzilla's mails are reformated to 80 (or > some) characters columns, thus breaking GPG check. I try to avoid long > lines, and an URL will probably be too long. > An alternate solution to leaving it out is to put the URL on its own line. (Was going to verify this wouldn't munge things on https://bugzilla.redhat.com/bugzilla-devel, but that seems to be non-existant right now.) OTOH your point that the full URL might not be necessary is true. It's in the SRPM and any second reviewer really should be getting it from there, not the bugzilla entry. New thoughts: * I like bullets for lists of things. Helps to delimit separate entries on a page. * I'd leave the src.rpm under MD5Sums so if the hash algorithm gets updated a program will parse the type of hash before encountering its first hash. * I'd put the recommendation (PUBLISH +1| NEEDSWORK) as the first line. It's the most important thing to pick out of the clutter of the review. All the rest is "supporting evidence" of the recommendation. * What are your thoughts on which parts of the review will be used by automated tools? I would say the Recommendation and MD5Sum section are definites. The Sources section a maybe, and the rest probably not. In any case, if it is going to be machine parsed then I'd use one phrase for "Positive result" and one for "Negative result" (possibly one for "Not-Applicable") (OK | NOT OK | N/A). That way a parser will have fewer words to search for. After the result keyword there could be any other words as comments. If an entry isn't going to be machine parsed, then I'd stick it into a Good: vs NEEDSWORK: section and forgo the (OK|NOT OK) * It doesn't show up in this review -- I'd put any patches in the Sources section, would you agree? Here's my take on what I'd like a review to look like http://www.fedora.us/wiki/QAFormatAlt This assumes that automated tools aren't going to check whether Package Name/SRPM Signature/etc were verified. If you think they should be then I'd take your example with a header (ex: Essential Checks) and bullets and normalize all the entries to OK instead of OK, VALID, and YES. Hope some of my comments sound reasonable to you, -Toshio -- _______S________U________B________L________I________M________E_______ t o s h i o + t i k i - l o u n g e . c o m GA->ME 1999
Attachment:
signature.asc
Description: This is a digitally signed message part
