RFC: fedora.us QA approval format

[Toshio]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040410/b7afa8ec/attachment-0002.bin