Re: Module proposal draft

[Vincent Untz <vuntz gnome org>]

Le vendredi 24 mars 2006 �9:01 +0100, Vincent Untz a �it :
> Le vendredi 24 mars 2006 �8:59 +0100, Vincent Untz a �it :
> > Le vendredi 17 mars 2006 �8:28 -0500, John (J5) Palmieri a �it :
> > > This should go along with the schedule once we have something we wish to
> > > send to the gnome community so they can look it over and propose
> > > changes.
> 
> I blame evolution for the empty mail :-)
> 
> John, did you have time to update a bit your draft with the comments? Or
> do you want someone else to do it?

Here's an updated version. I'll send it to devel-announce-list at the
end of the week-end if nobody complains :-)

=================
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.
This new procedure is built on top of years of experience doing GNOME
releases and it is our hope that it will lead to less confusion and up
the quality of our already stellar releases. In that vein 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 possibilites 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.

=================

Vincent

-- 
Les gens heureux ne sont pas press�