Fedora.us QA Queue

[Michael Schwendt]

On Fri, 21 Nov 2003 01:53:30 +1300 (NZDT), Michael A. Koziarski wrote:

> I'd like to propose a modification to the package submission procedure.
> 
> The current system is:
> 
> 1) New package submitted
> 2) QA
> 3) PUBLISH
> 4) PENDING
> 5) VERIFIED
> 6) CLOSED
> 
> With the QA step, naturally, taking the longest.

And sometimes the PENDING->VERIFIED step, because that's the step where
the packager(s) or reviewer(s) must decide whether the built binary
package is okay. 

I think, so far the fedora.us build system has produced working binaries
always, if it hasn't failed completely due to missing build requirements.

> In order to keep the QA
> queue relatively clean,  I'd like to see some kind of pre-QA keyword.
> 
> What I'm envisioning here is a step to rule out packages that:
> 
> 1) Don't build/install cleanly on the supported distributions
> 2) Sources can't be verified against upstream
> 3) Crash, print warnings or don't work when they are installed
> 4) Are duplicates
> 6) etc.
> 
> By ruling out such simple errors the talented QA people can focus on
> things like packaging standards, spec file errors and other such
> complicated things.  Whereas the enthusiastic-but-not-quite-there people
> (myself included) can help with the simpler errors.
> 
> Also, by staying in the bug's CC throughout its submission process, the
> pre-QA team will see the kind of errors that they're missing and will
> slowly but surely make the transition to Fully Fledged QA.
> 
> 
> Comments?  Flames?

Useful suggestions.

There's the NEEDSWORK keyword already, which, when replacing the QA
keyword, moves a bug entry out of the QA queue (http://fedora.us/QA) and
makes it appear in the http://fedora.us/NEEDSWORK queue only.

Everyone should feel encouraged to evaluate package requests in the QA
queue and help with comments on issues in the NEEDSWORK queue.

This could also help in deciding which packages are popular and which are
not and which should processed at a higher priority level. Else current
reviewers decide on what they find interesting, what they are familiar
with or where they think that common sense might suffice in order to
produce something that works.

Very helpful would be simple src.rpm rebuild attempts (and e.g. a look at
"configure"'s output for missing features) to see whether a package builds
and seems to work at least.  Having users in the "Cc" field, who would
signal "works for me / doesn't work for me" could speed up some approvals.

There's also the UPDATE keyword which can be used to find package updates
which usually are easier to review/approve than new submissions.

[...]

But also: many of the packages in the queue have a very special target
group, such as several dozens of special purpose programming language
packages or scientific applications. These would benefit from reviews by
small teams of users who are really familiar with the software.

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031121/fbe4ae30/attachment.sig>