Re: Features-oriented releases

[Frederic Peters <fpeters gnome org>]

Hello Alexandre,

We will soon have 3.2 released, and it's quite time to discuss things
for 3.4, and as I said previously, while the features focused process
is something we really want, the way it happened for 3.2 was
suboptimal. Let's work on this, here are some thoughts.


My goal for features is to strenghten the position of the release
team, it shouldn't just be a list of things put on a wiki page at the
beginning of the cycle, we should demand schedules, progress reports,
status updates, during the whole cycle, and over cycles, as a feature
can span several of them.

This will be an important job and we should therefore concentrate on a
limited set of features, and here comes an important point, there is a
lot of place for features that are coordinated in an ad hoc manner,
without the assistance of the release team.

Still it is useful for features to be presented and discussed on the
desktop-devel list, as the exchanges will be signs of the directions
the GNOME project want to take; and this is on that basis that the
release team will have its own discussions, and declare support for
some of them.

What would be in it? I wrote about new requirements the release team
would have, but what are the benefits? This is unfortunately hard to
tell, ultimately module maintainers are the decision makers, what are
the steps the release team could take to help features happen?
Fortunately this shouldn't have to be about forcing patches to get in,
maintainers will express themselves in the discussion period, and will
agree with the direction of the project. (I do not foresee changes,
and hopefully maintainers are ok with the current direction).


Comments?


        Fred