Attract QA'ers

[Michael Schwendt]

On Fri, 19 Mar 2004 00:02:36 +0100, Enrico Scholz wrote:

> (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.

The NEEDSWORK keyword is an old one and a very useful one, too, because it
moves package requests out of the QA queue, which cannot be reviewed,
because they don't build or have serious issues and must be developed
further. If they were left in the QA queue, you would have a hard time
finding package requests which are ready to be reviewed. Also, instead of
the reviewer, the packager can drop package requests from the QA queue
himself, when a package is not being developed further for a longer time.

For reviewers, who need a second approval according to the current publish
criteria ( http://www.fedora.us/wiki/PUBLISHCriteria ), the REVIEWED
keyword is an attempt at making it easy to find reviewed package requests
which need another review:

  http://tinyurl.com/33zj3

[snip]
>
> 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.

Packagers ought to be more responsible as when they think a package is
ready. We do have the tools to test for missing build requirements, and
although the combination of "mach" and apt-rpm fails in some cases, it
does a good job in many other cases.

Ultimately, I would prefer if I didn't need to read spec files in detail
to understand why a build fails. I would prefer to skim over the spec,
rebuild binary packages without problems and review the binaries instead.

--