Re: Modulesets Reorganization


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.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]