Re: getting on a longer release cycled

[David Neary <dneary free fr>]

Hi,

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. 

More important than moving away from the time-based release is
reinjecting some feature-based planning and goals.

In the coming weeks, I'll be sending a mail to module maintainers (as
listed in the MAINTAINERS files) asking them to identify major features
they want to do for 2.18 and 2.20. The goal is to get maintainers
thinking about what they're going to do next, rather than continue
organic development, and to identify areas where maintainers or projects
are moving in similar directions, and get alignment on those issues to
generate momentum.

This doesn't change time-based releasing. Some maintainers will choose
not to answer my mail, and some maintainers will be deliberately
pessimistic to avoid pressure to deliver features. That's not my vision
of this, though. I expect maintainers to be honest about their short and
medium term goals, and to have no qualms to bumping a major goal if it's
not going to be production ready for 2.18.

I will update this "roadmap" (or whatever you want to call it) at the
half-way period in the 2.18 cycle and do my best to make sure it
reflects reality most of the time. It's not a stick to beat people with,
it's a central place for us to tell each other what we're working on or
planning.

Subversion uses a planning cycle like this, and it works very well. They
get good incremental improvement, but they have their eyes on bigger
features and goals all the time, and they knock at least one major goal
off at each release. Thinking 2 releases ahead can help us do the same too.

Cheers,
Dave.

-- 
Dave Neary
bolsh gimp org
Lyon, France