Re: new module decisions [was Re: gnome-screensaver]

On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote:
> On 2/16/06, Danilo Šegan <danilo gnome org> wrote:
> > Hi Vincent,
> >
> > Today at 8:24, Vincent Untz wrote:
> >
> > > We'll be trying something new for new modules in 2.16. I think most of
> > > us agree that it didn't turn out well for this cycle.
> >
> > Like: lets remove all desktop modules, and reevaluate them again?
> >
> > Not that it would bring any concrete results, but I'd love the
> > flamefest (d-d-l is seriously lacking these days :)
> >
> > Now, seriously, can you at least give us a hint of what you have in
> > mind?  And who is "we" dammit? :)
> There are a couple of ideas floating around, so there's no concrete
> change to propose yet.  But you'll note that we have sucked at new
> module decisions in all release cycles for the past
> who-knows-how-long.  I personally think part of the problem is that
> the end date for new module proposals coincides with the date for the
> final decision.  The "discuss it" period is also way too wide open
> making it hard to keep on top of.  One of the suggestions is to have
> the cut-off date for new module proposals be sooner, have a focused
> and relatively short (a week or so?) discussion period after that
> (though still allowing the open ended discussion period that currently
> exists, just making it in some sense less official than the focused
> one), and then followed by an actual date by which decisions need to
> be made.
> I brought this up at a recent release-team meeting and other ideas
> were also brought up that were somewhat similar in nature (read: I
> don't remember the details).  We didn't have anything concrete and
> were running out of time, and besides, 2.14 is taking precedence right
> now.  So we agreed to discuss more later and get some community input
> maybe near or after 2.14 is out.  But now that it has come up...
> Anyone else have any ideas on making us not suck at getting module
> decisions done two months before the release as specified on the
> schedule as opposed to one month like we usually achieve?
one thing I don't like is how the decisions get done. That is, if
someone raises some concerns about a proposed module, then "some people
don't like it" is the reason given for not accepting the module (ie, see
gnome-power-manager/screensaver thread). Of course, there would always
be someone who doesn't like something about a proposed module. So, what
if we just set a list of things a module has to conform with to get
accepted and base our decisions on that?

For instance, we could have:
* uses at least basic platform libs (GTK mainly)
* uses existing platform libraries for everything possible (that is,
does not use libs implementing an already existing feature in GNOME
* follows GNOME standards (coding standards, freedesktop specs, HIG,
documentation, licensing, release dates and freezes, etc)
* is source in GNOME CVS?

If we have a complete and concise list, the decision is easy to be made,
since you just have to tick or not the corresponding column in the list.
When all columns are ticked, the module gets accepted.

Also, any concern about proposed modules should be only valid if
accompanied by a detailed bug report.
Rodrigo Moya <rodrigo gnome-db org>

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