Hi! This discussion is really becoming interesting and constructive. > The process could be something like: > - Release team decides what modules to thow away for GNOME 3.0 > - Gruesome exciting technical battles occur on d-d-l as the over-all > 3.0 module inclusion discussion heats up > - Release team and the community would have to help to defend > the relevance of older modules inclusion in GNOME 3.0 (for modules > who's maintainers can not be contacted). > - Accepted modules would at least have to build against the new > stack as a minimum bar for passing (i.e. fully GSEALed GTK+ and > only apis available in the new platform). > > I'm sure that 3.0 is a great time to throw away alot of stuff that > may have become irrelevant over the years. This route would also > hopefully offload a significant part of the work to the community > (each maintainer would have to re-defend their module's significance > in the new GNOME)... allowing the release-team to focus on other > things while the community dukes it out... > > This could even be a process with an undefined timeline, 3.0 > could just start with an empty applications suite and we could > go on in the usual way [re]adding new applications every 6 months. > > Thoughts ? I really support Tristan's idea of a restarted review process. This is time consuming but it is rather easy to do on the organsation and infrastructure level. It may or may not be more strict but it would also help to ensure we have some broader vision of application integration in GNOME 3.0. Mikkel's idea with the incubator has charm, too, but I think that should be rather a long time goal for a more formal review process past 3.0! Still, I agree with Bastian that it is far easier to contribute to modules that are centrally hosted than to manage multiple accounts and multiple version control systems. I have the feeling that not everybody is really aware of that especially for people that don't code and are rather unfamiliar with version control and its tools. Regards, Johannes
Attachment:
signature.asc
Description: This is a digitally signed message part