fedora.us QA process

[Toshio]

I have Architectural Comments and Editorial Comments.  The former may
require discussion and rethinking of things while the latter should be
pretty easy to implement improvements.

On Wed, 2004-03-03 at 18:18, Erik LaBianca wrote:
> PLEASE look at it and tell me what you think. I think it is a solid step
> towards a lower barrier for entry.
>  
> http://www.ilsw.com/~erik/fedora-qa-quickstart.html

Architectural Comments:
* I like that you've split out blocker criteria from non-blocker
criteria.  I would split security out too so the new reviewer can
realize this list is _really_ important.  I purposefully didn't examine
what was in your lists of critical vs non-critical because I think we
need to discuss what standards we as a group want our packages to be
held up to.  I've been going on the assumption that everything on the
QAChecklist is mandatory.  If that's not so, it has to be discussed (and
perhaps voted) as it's our collective name as a quality repository
that's at stake.  [We might be seeking to make a bigger repository, but
we still have to balance that against quality.]

* I don't like the fact that the QAChecklist contains most of the things
in this document but is a separate document.  I think the QAChecklist
needs to be tuned up with categories of blocker, non-blocker.  And
perhaps in terms of order of doing things.  And then it can be
referenced from this page.  Having another page with overlapping
Checklists adds to the confusion of "which list do I follow?" and means
policy changes have to be updated in two places.

Editorial comments:
[3.1] - I remember having to add fedora.us to my yum.conf manually but
I'm not sure if that was before or after I installed FC1.  If FC1
doesn't include it, it needs to be mentioned.
  - mach needs apt installed as well.
[3.2] - I like gpasswd more than vigr because `gpasswd -a [USERNAME]
mach` is a more complete explanation than edit groups with vigr.
[3.x] - There needs to be something in here about modifying ~/.rpmmacros
to point to another build directory as /usr/src/redhat is FHS and
root-user problematic.
[4] - I'd add some note to pay attention to see what good and bad things
to look for.  How things are structured into Critical and non-critical
comments.  Reviews should include an SRPM MD5sum _at_minimum_.
[6] - Not all packages have MD5sums.  And the improtant part of this
step is to correlate a package to a gpg key.  Either MD5sums are
provided and signed with a gpg key (which needs to be gpg verified) or
the package itself needs to be rpm --checksig verified.  The Fedora.us
policy says that all packages need to be rpm --addsign'ed so you can
leave out the MD5Sum verification if you're feeling lazy.
[8] - Note to google.  Note to _not_trust_the_spec_ completely.  It's
important that the reviewer verify that the URL's and etc are not
leading to false download sources.
[14] - A use your judgement about additional things should be added. 
(And where to ask QA/Packaging questions -- irc #fedora-devel, mailing
lists, asking on the bugzilla, etc)
 - Other keywords need mentioning.  PUBLISH, NEEDSWORK, QA come to
mind.  REVIEWED only applies if no one else has already REVIEWED it.

[Example Review Template]
- There needs to be an example of a negative review as well.
- GPG signing is _important_.  It's not even mentioned.
- I like MD5Sums of all files in the SRPM.
- It's better to have the output of md5sum verbatim in the review. 
Easier to automate verification than having it split over multiple
lines.

It's a good start on a helpful document.

-Toshio
-- 
Toshio <toshio at tiki-lounge.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040304/003ee8b7/attachment.sig>