Re: Module proposal draft

["Luis Villa" <luis villa gmail com>]

On 4/1/06, Vincent Untz <vuntz gnome org> wrote:
> 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

More humility, please :) Everyone knows we have years of doing this,
no need to say it.

> 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.

Might add 'this will help us avoid the problems we had with
decision-making too late in the cycle during 2.14', or something to
that effect.

Otherwise, looks great.

Luis

> 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és.
>
> _______________________________________________
> release-team mailing list
> release-team gnome org
> http://mail.gnome.org/mailman/listinfo/release-team
>