QA for the testing repositoru
This is the first draft of this proposal by me (TimVerhoeven)
1. 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.
2. 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.
3. Proposal in logic form
- Builder put package into testing repository and :
does not sends mail to centos-devel -> package will be removed after 3 weeks
- sends mail to centos-devel
- People in centos-devel test package and provide feedback
- After package has been in testing for 3 weeks :
If only negative feedback -> delete package
If only positive feedback -> promote package
If both negative and positive feedback -> decision by QA coordinator and builder
4. Practical stuff
To make this work in real life the following things need to happen :
- Make sure QA coordinator gets informed of packages added to testing repo : done
- Make mail template that the builder can use to announce package
- A process that QA coordinator can delete packages from testing or move packages to CentOSPlus or Extras
- ... (stuff I forgot)
5. 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 |