QA for the testing repositoru

This is the first draft of this proposal by me (TimVerhoeven)

Situation

The testing repository compared to normal releases in the fact that QA needs to be a continues effort instead of a coordinated effort when a new release is being built. So there is a need for a different method of doing QA for these packages. This is my proposal on how we would go about that. All feedback is welcome.

Proposal

The core of this proposal is this. When a package (a package here is a specific version, release and build of a package) gets added to the testing repository there person who has put that packages into the build system (called builder from now on) has 2 options. If the package is not intented to end up into the CentOSPlus or Extras repo (it's a test package, first version, quick hack, ...) the builder has to take no further action.

If the package is intended to end up into CentOSPlus or Extras the builder should sent a mail to the centos-devel mailinglist to say that a package has been added to the testing repo, what the package is about (a one-liner is usually sufficient) and indicate into which repo (CentOSPlus or Extras) it should end up.

It is then expected/hoped for/presumed that people subscribed to the centos-devel mailinglist will test the package and provide feedback on their results. But negative and positive feedback is expected. We don't expect that everything tests everything, but that people interrested in it or using certain features will test packages related to their interests.

After 3 weeks since the package has appeared into the testing repo the package will be removed from the repo if there was no initial mail from the builder, if there was no feedback (good or bad) for the package or if their was only negative feedback. The package will be promoted to the CentOSPlus or Extras repo if there was only positive feedback. In case there was both positive and negative feedback the QA coordinator together with the builder will take the decisision to promote the package or not.

Proposal in logic form

  1. Builder put package into testing repository and :
    1. does not sends mail to centos-devel -> package will be removed after 3 weeks

    2. sends mail to centos-devel
  2. People in centos-devel test package and provide feedback
  3. After package has been in testing for 3 weeks :
    1. If only negative feedback -> delete package

    2. If only positive feedback -> promote package

    3. If both negative and positive feedback -> decision by QA coordinator and builder

Practical stuff

To make this work in real life the following things need to happen :

What to do with the packages currenlty in testing

To transition to this new way of working we need to first clean out the current packages in the testing repository. This is my suggestion on what to do with the package currently (28/05/2008)

Package(s)

Intended repo

Action to take

CentOS Directory Server

Extras or seperate repo ?

Move when trademark issue is cleared up

backuppc

Extras

Move

cobbler + deps

Extras

Move

func + deps

Extras

Move

cft

N/A

Delete

openldap

CentOSPlus

Move

facter

N/A

Delete

fdstools

Extras

Move

freenx + nx

Extras

?

iptables-extras

Extras

only if not present in 5.2

jasper

N/A

Delete

java-1.6.0-openjdk

Extras

Move

java-1.7.0-icedtea

N/A

Delete

bz321111 kernel

N/A

Delete (no longer needed in 5.2

kernel-rt

CentOSPlus

?

kernel-vm

CentOSPlus

Move

kvm

CentOSPlus

Delete (.44 and .66 were not stable)

maakit

Extras

Move

mysql

CentOSPlus

Move

nas

N/A

Delete

perl packages

Extras

Move

php-suhosin

Extras

?

puppet

Extras

Delete (outdated versions)

qtparted

Extras

Delete

seedit

Extras

Delete

smolt

Extras

?

yumex

Extras

Delete

QaWiki/TestingRepo (last edited 2008-05-28 12:48:55 by TimVerhoeven)