Attract QA'ers

[Enrico Scholz]

gauret at free.fr (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