Important Announcement: Please read the latest status update for Fedora infrastructure (2008-08-22 1200 UTC). Additional details can be found in RHSA-2008-0855.
New SSH Fingerprints for Public Servers: Please verify SSH Fingerprints against https://admin.fedoraproject.org/fingerprints.

SIGs/QA

From FedoraProject

Jump to: navigation, search


Contents

QA Special Interest Group

Mission

The purpose of the Fedora QA SIG is to monitor the many aspects of the life cycle of a package in Fedora.

Packagers/Reviewers/People interested


Several processes which need QA

Here is an attempt to outline some QA tasks that need to be performed on a regular basis. I guess it'd be nice if some people could agree to watch after one or more on a regular basis.


Package review process

Many aspects of the package review process are now checked by the parseBZbugList Perl script. Basically, the script examines BZ tickets filled for "Package Review" and reports anomalies and stagnation.

Things that need improvement:

New package inclusion process

The parseBZbugList also does some checking here, about owners.list inclusion and checking that the package actually shows up in the repo. More checks should be done, though:


Package build process

This is a copy of Bill's message... I don't think we have anything in place here.

The build system should have a framework where simple post-build checks can run. Simple design would be:

These tests could then be:

Doing this allows for simple, automated, QA; it can check that things that are caught in the package review for initial import are then caught later if they regress, and it can catch other things.

Examples of tests:

I'm sure people could come up with a lot more. By making it a simple framework, it allows for easier contribution.


Package sign and push to repo process

Michael has a nice script going (seems to live at http://home.arcor.de/ms2002sep/tmp/ under the name repoclosure...)

My understanding is that it will soon be run automatically after signing and pushing new packages.

I don't think it automatically files BZ tickets for offending packages (but I could be wrong...)


Fedora release time process

Several ideas from Thorsten:


Package transfer between Core and Extras process

The parseBZbugList script does some sanity checks.


Package orphaning process

All goes rather OK when a maintainer declares a package orphaned, but something needs to be defined when a maintainer kinda disappears. The parseBZbugList script attempts to spot inactive maintainers, but I'm not sure it is very successful.


BZ ticket handling process

The parseBZbugList script tries to detect inactive tickets. Request for enhancements are ignored at this point. Security related issues should be watched more closely (no special handling ATM).


Package maintenance process

All CVS messages go through the commits list, and I know some people keep an eye on things there. No real idea if anything could be automated here...


Package retirement process

At the moment, put them on the ["Extras/PackagesNoLongerInDevel"] page. Maybe long-time orphaned packages should be migrated there with a proper notice...


Ideas/Proposals

References