> > > The QA checklist as it stands is a mishmash of nice ideas, > > mandatory checks, and instructions. > > What in particular do you think is misplaced? > I guess my primary gripe is that I don't see a clear path from the fedora.us home page to a successful QA review. There are a LOT of web pages to visit, and a lot of extra stuff to be inferred along the way. However, I'm working to fix that and am not yet done so I'll assume that when I AM done that particular problem will be fixed. With regard to the QA checklist in particular what I think I'd like to see is some categorization between showstopper bugs, and "stuff to watch for". As I see it currently, showstoppers are: Correct Naming and EVR Clean sources of documented origin Clean builds on target systems, including correct buildrequires Clean install and uninstall Secure install policy (non-root daemons and no default passwords currently) Package needs to work In my opinion, most of the QA checklist either fits one of those categories, or isn't a showstopper. Of these, many can be at least somewhat automated, and I'd sure like to see it happen eventually. That way the checklist can be Does the package pass fedora-qacheck? Are the upstream sources genuine? Does the package work? Is the package secure? All the nitty gritty details like checking for macros, license vs. copyright, epoch versions, clean builds on various targets, proper buildrequires, directory ownership, vfolder categories would be handled in code by fedora-qacheck, or even better immediately upon package submission. Heres to the future! --erik
