Versioning in bugzilla

VERSION 2.0!

Given:

The bugsquad does not have the number of people required to retriage every bug every 6 months to decide whether the 2.3 bugs are applicable to 2.4
Most developers don't care about if the bugsquad version is even or odd, anyway
The even and odd distinction is mostly duplication from other fields, including "Enhancement" and "string, usability, ui-review" keywords

It can be concluded that:

We suck.
Or that GNOMEVER-style versioning is fairly broken.

Requirements of a short-term versioning solution:

(Note that in the long term, we might need something terrifically complicated, especially since Sun/Ximian/etc. need to support versions much older than the community. This is not doable in the near timeframe.)

To know the last version a bug was reported in.
(The community works on 1 branch primarily, so all bugs reported against 2.3/4 are applicable to the 2.4-stabilisation and the 2.5-development cycles. Older versions need to be individually triaged by Your Friendly Bug Squad, although especially in smaller modules developers are known to fix them regardless of their version.)
To know if we need to get this in before freezes.
(ie. keywords.)
To know if this is a Big Bad Bug (ie. regression from previous stable)
Others?

Implementation

Implementation is going to be custom fields, since that's the tool we have available. It's quite well suited for the task, and the work is there in bugzilla-new.

Implementation details

This is the controversial (?) bit.

The GNOME Version field should have the following values:

Unspecified
(with protection in the submit process to stop bugs actually having this value; still, we need a default. FIXME: Might need to think about demanding gnome versions in the submit process since non-gnome-core apps, and gtk, will go on a killing spree. Maybe have a modules hash, extend aldug's modules-to-do-reports-on hash to decide which modules to demand a version for?)
Unversioned enhancement
(enhancements are excluded from all versioning. This is a lesson we learnt from having to do mass-migrations of keywords, when we assumed all enhancements were versioned as "next unstable")
2.0
2.1 and 2.2
2.3 and 2.4
2.5 and 2.6
etc.

A lot of the setting of this can be nicified in the submit process: the submit bug pages need to be rewritten in bugzilla-new: I am working on this. "Unversioned enhancement" is a particularly ugly hack, but imho needed to clarify the understanding that enhancements don't get versioned. Otherwise they go out of date and people get confused.

This fixes requirement 1. Requirement 2 is handled by keywords. Requirement 3 can easily be handled by utilising a "regression" keyword, as "1.x-parity" was meant to be used for in the pre-2.0 days. Hopefully the number of bugs with this keyword will be few enough that a small group of people (*cough* r-t *cough*) can track them and stick them on milestones.

The notable difference to GNOMEVER is that development and stable cycles are merged together. Rationale:

Separate versions are just more to maintain, and information that nobody uses
It could conceivably be useful if we tested all the 2.3 bugs after 2.4.0 to see if they are still valid, but we can't do this (manpower)
Most (all?) of the criteria for deciding if a bug should be GNOMEVER2.4 or GNOMEVER2.5 depends on its status in freezes, information which is encoded in the keywords (we should get the keywords right as part of our triage process)

Notes

Renaming custom field values is ugly and should be avoided if possible.