Re: chopping and changing ...

[Jeff Waugh <jdub perkypants org>]

<quote who="Michael Meeks">

> 	All of this miltates against switching to a new application, and in
> favour of maintaining the old. Thus it seems to me increasingly
> important - as Gnome gains market share, and serious commercial support
> - that we eschew the "hey we'll just switch some modules in core" in
> favour of a more public, accountable, open, protracted process.
> Furthermore, it seems to me that since we'll have to be maintaining
> these things for the concievable future - we should pay careful
> attention to what we're letting ourselves in for, especially if we are
> blessing them as part of the Gnome core.

Okay, so Mark has just accosted the release team about this too, but your
points here are the strongest I've seen for imposing some bureaucracy on the
choice of desktop modules.

So, I'd like to propose a minimal, knowledge-retaining, efficient
bureaucracy for this purpose. :-)

  - For each release process in which GNOME Desktop module changes are
    proposed, a single, extended GEP will document the decisions and
    discussions regarding the entire release module list. It will be named
    after the release, eg. "GEP X: GNOME 2.2 Desktop Modules".

And for the developer platform changes:

  - For each release process in which GNOME Developer Platform module
    changes are proposed, individual GEPs will document the decisions and
    discussions regarding a particular addition, change or removal. It will
    be named after the release and module, eg. "GEP X: GNOME 2.2 Developer
    Platform: libexample".

Yeah, so I've used legalese to describe them, bite me. :-) Thoughts?

- Jeff

-- 
   "I came for the quality, but I stayed for the freedom." - Sean Neakums   
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers