Re: Looking forward: 2.16 plans

["Elijah Newren" <newren gmail com>]

On 3/10/06, Vincent Untz <vuntz gnome org> wrote:
> Le vendredi 10 mars 2006 à 12:33 -0500, John (J5) Palmieri a écrit :
> > On Thu, 2006-03-09 at 21:24 +0100, Vincent Untz wrote:
> > > Hi all,
> > >
> > > As 2.14.0 is out next week, it'd be nice to start working on the 2.16
> > > schedule. Any volunteer for this?
> >
> > * J5 raises hand
>
> Cool :-)
> I guess a good first step is to take the schedule for 2.13/2.14 and add
> 6 months everywhere. You can already create a wiki page for it.

Sweet thanks, J5.  Note that we made the 2.13 cycle a week longer in
order to avoid having feature freeze too soon after Christmas again,
so you'd want to pull that week back out of the schedule instead of
just shifting by 6 months.  Another alternative would be to take the
2.11/2.12 schedule (http://www.gnome.org/start/2.11/) and just add a
year to it, well a year plus a week to account for the shift from the
longer 2.13 cycle.

> > Yes I like the idea of getting modules to be considered at the beginning
> > of the cycle, giving them deadlines and seeing if they can meet them.
> > Call it the gauntlet - if you can survive you are worthy ;-)  I can
> > write up a proposal.  What are the key points we want to make?
>
> Great! I don't know what other think, but key points are, IMHO:
>
>  + have to propose the module/announce the big change before the
>    2.15.1 release. This will enable everyone to have a good vision
>    of the potential important changes in 2.16.
>  + push for integration wherever possible in 2.15.1 and 2.15.2
>    => people proposing new modules or big changes should not wait that
>       others do the integration work
>  + finish most of the work for 2.15.3. Community will try to reach
>    a consensus before the 2.15.4 release, based on the experience of
>    using 2.15.3.
>  + when faced to a decision after 2.15.4, we will *really* consider
>    the most conservative choice
>    => "if you want to change something big, do it as early as possible"
>
> (deadlines can of course be changed to make more sense)
>
> This is not such a big change when you look at what we had before.
> However, it makes our position clearer: we should be aggressive when
> doing changes so that they're done (and known) early in the release
> cycle.

Yeah, something along these lines looks great to me.  :)