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@xxxxxxxxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part
