Package list policy

[Maciej Stachowiak <mjs eazel com>]

Hi everyone,

The below is now the official package list process policy for GNOME
1.4 (and hopefully GNOME releases going forward), by approval of the
steering committee and lack of objections on gnome-hackers.

I've checked it in to the releng module in gnome cvs. I will start by
converting the package list in the releng module to meet the new
format. Then I will start closing out the various open proposals on
http://releng.eazel.com/

I also hope that the GNOME 1.4 Extra Applications release
coordinator(s) once appointed, will see fit to use the same policy. I
think it works pretty well.

To give people enough time to submit any further proposals for GNOME
1.4 proper, I'd like to set October 21 as the package list freeze
date, which means October 14 would be the last day to make a proposal,
to allow for the one week minimum discussion period. However, I am
open to comments in this area. It will be up to the extra apps release
coordinator(s) to pick a package list freeze date for the latter
release.

 - Maciej Stachowiak


--------------------


Package List Process Proposal


Overview

The package list for any GNOME release starts with the list actually
shipped for the previous GNOME release.

Packages may be added or removed by proposals, which anyone may
submit.


Proposals

Anyone may submit proposals to add packages to the release or remove
packages from the release. Proposals should be sent to the appropriate
release engineering mailing list for the list.

The release coordinators will declare when package list change
proposal submissions may begin. They should allow adequate time before
the package list freeze date. 

Proposals to add a package should specify the following:

* The package name

* The current version

* Whether the package should be considered Critical or Non-Critical (see below)

* A contact (preferrably the maintainer, but it's OK to have someone
  else be the contact for GNOME release coordination purposes).

* If a package is Non-Critical, whether there a suitable fallback
  release is out that could be shipped instead of the target release.

* Whether the maintainers are aiming to stabilize an unstable
  version. This is primarily for informational purposes - it is up to
  the individual maintainers to impose appropriate freeze policies for
  their own packages.


Discussion Period

Each proposal will be followed by a discussion period of at least a
week. This means that the deadline for proposal submission is a week
before the package list freeze date.

After the discussion period, the release coordinators will decide
whether to accept a package list change proposal, considering
community consensus and their own judgement of what belongs in a GNOME
release; the GNOME Steering Committee and the GNOME community at large
will provide guidance on what should go in a GNOME release and the
goals for any specific release.


Package List Freeze Date

The package list freeze date should be declared up front, and should
be at least a month before the target release date. The package list
freeze date may be adjusted by the release coordinators according to
their judgement. 

After the package list freeze date, only the Steering Committee can
change the package list or move a package from Critical to
Non-Critical or vice versa. Hopefully they will exercise this power
only in an emergency.


Critical vs. Non-Critical Packages

Critical packages are ones for which a new release (or an initial
release) is required to release the new version of GNOME. That is, if
the proper release of a Critical package is not ready, the release
will be slipped (see the [upcoming] Release Timetable proposal for
more details).

If a package is Non-Critical, it's OK to ship with an older existing
release, or not ship at all, if the desired latest version is not
ready. 

For Non-Critical packages, an additional pieces of information are
stored in the package list: whether a release is currently available
that we could ship with. If there is such a release, we'd use that if
the target version is not done on time. If there is not, we'd drop the
package if the target version is not done on time. This field may
fluctuate during the release cycle as new releases are made.


Appeals

Any decision of the release coordinators may be appealed to the GNOME
Steering Committee for a vote. This includes decisions about whether
to adopt a proposal, whether a package should be Critical or
Non-Critical, etc.