Re: Module proposal draft

[Vincent Untz <vuntz gnome org>]

Hi,

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.

Looks good. Some comments inline:

> To all module maintainers,

I wouldn't put this: this is not only a procedure for existing
maintainers, but for everyone. So it's important that everyone feels
this mail is for her/him.

> 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

s/before the/before the 2.15.1/ so it's really clear.

> 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 (added to jhbuld/GARNOME, etc.) - preferably by

s/jhbuld/jhbuild/

> 2.15.1 or 2.15.2.  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.

I'd like to be a bit more explicit about integration: it should really
be clear that it's not just about "release engineering" integration, but
about the integration of the software in our desktop. Eg, g-p-m authors
should push everyone to use its API where it makes sense (by at least
raising awareness on the issue, opening bugs, etc. and making patches is
even better ;-))

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

Great draft!

Vincent

-- 
Les gens heureux ne sont pas press�