New procedure for proposed modules

[Vincent Untz <vuntz gnome org>]

Hi all,

The GNOME Release Team, after some discussion, has come up with a new
procedure for getting modules accepted into the next release of GNOME.
It is our hope that the new procedure will lead to less confusion. This
is more of a tweak than an overhaul, taking into account lessons learned
from the past.

Procedure for proposing modules for inclusion:

All modules should be proposed BEFORE the 2.15.1 release. Any existing
modules planning big changes should also announce this before the 2.15.1
release. This allows everyone to have a good overview of the direction
we wish to head towards for 2.16. It also puts potential modules on
notice and allows us to track their progress throughout the release
process making it easier to decide which modules are ready to be
accepted into the next release.

Module integration:

All modules and changes proposed for 2.16 should be integrated early in
the release process - preferably by 2.15.1 or 2.15.2. For example, the
author of a new module proposing some great new service should push
other maintainers to use the new service where it makes sense (by at
least raising awareness on the issue, opening bugs, etc. and making
patches is even better ;-)). It should also be easy to build the modules
(think jhbuild/GARNOME, etc.). This allows for testing early and allows
us to better see where we are heading. Don't propose a module and rely
on other developers to integrate it.

Module progress:

Modules should show a steady progress throughout the release cycle.
Module owners should show they can hit release deadlines and towards the
end concentrate on stabilization over feature addition. One of the
stipulations of becoming part of the GNOME release cycle is to be able
to maintain regular releases in sync with the rest of the desktop. Doing
so before the module is part of GNOME gives the release team confidence
that it should be included.

Module rejection:

GEP-10 (http://developer.gnome.org/gep/gep-10.html) is a summary of the
standards for inclusion of a module. New modules should meet as many
criteria as possible listed in this GEP. If a module has not proved
itself by the 2.15.4 release, we will take the most conservative choice
and drop or revert it in the release. This is to avoid yay/nay votes
from happening late in the cycle. It is our hope that by this point it
will be clear which module will make the cut.

About dependencies:

New dependencies for features should be added as soon as possible. There
are three possibilities for dependencies: make them optional, bless them
as external or include them in one of our suites. New dependencies
should be known before feature freezes. A dependency can be proposed for
inclusion AFTER the 2.15.1 release because it might need more time to be
ready.

Your lovely release team :-)