Proposals for the Updates Testing Procedure

[Bill Nottingham]

Warren Togami (warren at togami.com) said: 
> Along with each announced test update, I believe it would be crucial to 
> include a link to a corresponding Bugzilla report.  While longer 
> discussions pertaining to packages can remain on fedora-test-list, all 
> pertinent information should be posted in one place within that test 
> update's Bugzilla report.  Why?
> 
> * Otherwise it is likely that other Bugzilla reports and important 
> information related to an update could easily be lost in the mailing 
> list noise.
> * All pending updates can easily be found by a single Bugzilla database 
> query.
> * Each report would become a one-stop-shop for information regarding 
> that update.  More responsible sysadmins with proper testing procedures 
> can read that report to help in their decision to update.

That could be useful.

> Discussion of the Update Approval Process
> =========================================
> We also have not yet discussed the fedora.redhat.com update approval 
> process.  I suggest the following to begin the necessary discussion. 
> Some of the below are similar in concept to the procedures currently 
> being used successfully at fedora.us as described in this document:
> http://www.fedora.us/wiki/PackageSubmissionQAPolicy

Whoa, lots of policy. More than I envisioned, actually.

> * Backport Patches v. Upgrade Version
> Most libraries, core system and server packages should always have 
> backport patches.

Ah, see, one of the things that was discussed most often is that
we'd be rolling forward to new versions of packages to fix problems.
Basically, the cases where we wouldn't would be:

a) when compatibility is affected
b) when it's easier to backport

> * Time-limit to publish where no negative comments are posted within the 
> Bugzilla report.  Senior developers reserve the right to hold an update 
>   if a good technical reason can be stated.  (Insert more details here.)

Sure, say, 2 days. :)

> http://www.fedora.us/wiki/QAChecklist
> There should be a checklist similar to this one used at fedora.us that 
> contributors must go through and say "Passes all checklist items." 
> within their report.  This checklist idea has successfully prevented 
> many common problems from being published in fedora.us.  Depending on 
> the criticalness of the update, the release managers decide when it is 
> the appropriate time to publish based upon proper & signed contributor 
> feedback.

Most of this is less relevant for updates. For initial inclusion
it makes more sense, but changes that would fail this shouldn't
be going out in updates, as all of this stuff will have been fixed
beforehand.

Bill