gauret@xxxxxxx (Aurelien Bompard) writes: > As an proposal, I think QA'ers should make sure they set the NEEDSWORK > keyword and remove the QA keyword when they think the package should > be improved. I do not think that the current bugzilla based QA is very effectively since there is needed lot of manual work and no way to enforce proper usage. The current unstructured QA list is too complex and deters people. This will not be changed by adding new keywords or specifying their usage. IMO it will have the opposite effect since the process becomes more and more complicated. What we need is an userinterface which reflects the QA process: it begins with the registration of a package, over a QA checklist till the final publishing, the addition of bugzilla components and writing the package-announce. While registration, the package description, URLs, software categories and perhaps a classification of the packagecomplexity should be submitted. After that, trivial automatic tests for e.g. missing BuildRequires:, fileconflicts or unowned directories could be executed and rpmlint-results or buildlogs be provided. Since this has security implications some precautions must be done to prevent abuse. The QA checklist should contain mandatory items (source verification, build/(de)installation correctness, ...) and place for optional comments, and the tester can click 'Yes, I approve it' finally or have the chance to veto it. Everywhere, a way must exist to say "does not apply to this package" (with an attached textfield for the reason), and GPG signing of votes must by enforced and should be aided. When having such structured information, it would be much more easy to identify the current state of a package: whether it needs work, whether it has the two "publish" votes, if there were vetos after the first "publish". With some other, structured information about the package (application group, complexity) tester could find packages which are matching their interests and skills. I am not sure about the role of bugzilla in this process; perhaps some parts (e.g. userauthentification) could be reused. But most work must be done from scratch probably. Perhaps, actions/comments should be automatically submitted into bugzilla for documentation purposes. The question is, whether it would be worth to begin such an implementation for fedora.us or if it would be wasted time since it conflicts with Red Hat's ideas about the Fedora Project. Enrico
