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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list