RFC: fedora.us QA approval format

Panu Matilainen pmatilai at welho.com
Thu Apr 1 17:24:12 UTC 2004


On Thu, 1 Apr 2004, Aurelien Bompard wrote:

> Hi all,
> 
> Erik and myself have been working on a QA check script to automate the QA
> process at fedora.us. The script is getting quite correct, and can even be
> useful ;-)
> At the end of the checks, the script outputs a QA approval report, which can
> be edited, gpg-signed, and pasted into bugzilla. The question is: what
> should a QA approval look like to have all the minimum QA requirements and
> be as parseable as possible by a publishing script for the release manager.
> Erik and I have different minds on what has to be in the review, so we
> though we should discuss it here, especially with the release managers.
> I have setup a wiki page with a primary format proposal, and I invite you to
> have a look at it and comment on it: http://www.fedora.us/wiki/QAFormat

For one it should be such that it's easy to verify that two reviews got 
the same results. Currently since everybody uses slightly different format 
of QA reviews you need to look very carefully to spot possible differences 
(meaning the package has been changed since previous check which could 
mean something nasty is going on) in two reviews and is prone to 
human error.

For source md5sum's I'd say mark any source checked against upstream with 
(ok) or such, for sources that can't be verified from web do include 
md5sum for it anyway, it allows checking if the file has changed from one 
version to another for example.

> 
> If the script is to get into fedora-rpmdevtools, a complete newbie could
> contribute meaningful QA's in a format which would be useful to the release
> manager. This would lower the bar to QA, and standardize the process a
> little bit more.

This is very welcome.. while the QA cannot be completely automated (eg you 
can't just blindly trust whatever happens to read as the package source 
url, it could be somebody's own website with hacked tarball, human sanity 
check is needed) removing boring, error prone manual steps from it is a 
Good Thing. 

	- Panu -





More information about the devel mailing list