Re: getting on a longer release cycled

[Shaun McCance <shaunm gnome org>]

On Fri, 2006-09-08 at 10:17 +0200, Rodrigo Moya wrote:
> On Thu, 2006-09-07 at 13:56 -0400, Pat Suwalski wrote:
> > Hubert Figuiere wrote:
> > > I would like to suggest at one point to try to break with the 6 month release 
> > > schedule of Gnome to do a "major" release with a certain number of feature 
> > > that would involve possible infrastructure changes in the platform. 
> > 
> > I have been thinking about this as well, just from observing how "shit 
> > hits the fan" near the end of the cycle.
> > 
> > I'd like to throw out a suggestion that perhaps GNOME should alternate 
> > on a six-month-twelve-month release cycle, regardless of "major release" 
> > or not. It might make planning a little more complicated, but I'm sure 
> > it would be appreciated by developers and users alike.
> > 
> I think 12 months is too much time. And if we need to do a major
> release, we can, for instance, branch now for gnome-2-18, do there only
> minor bugfixes and small feature additions for the upcoming 2-20 and, at
> the same time, dedicate the 12 months (2-18 + 2-20) to work on HEAD for
> the major release.
> 
> That is, there is nothing in the schedule preventing us from working on
> a major release for 1/1.5 years while at the same time keeping up with
> the 6-month release cycle.

This is pretty much always given as the reason why longer cycles
aren't needed.  And what it completely fails to address is the
issue of non-programmer contributors.

As a programmer, I can absolutely get myself ten straight months
of unbridled hacking time by skipping a release.  In fact, I've
done it once before with Yelp.  But the documentation team still
only gets six weeks.  Not only that, they now have six weeks to
document everything you were able to change in ten months.

Programmers are the only people who can take advantage of this.
Nobody else can.  The documentation team can't just sit out a
release cycle and force the programmers to keep their modules
static while we do so.

We need more expert reviews (accessibility, user interface,
strings), more testing, and more documentation work.  That
means more time.  And if we ever hope to have translated
documentation, the documentation team needs to finish even
earlier, so the translators have a chance.

The documentation team can't conceivable consider anything
finished until after the UI and string freezes.  In 2.16,
that gave us four weeks.  Now let's try to finish two weeks
early to give translators a sporting chance.  That gives us
two weeks.  Two weeks to document whatever programmers can
manage to do in four to five months.  That's insane.

--
Shaun