Re: 2.4 Module List and Rationale (aka GEP10 and 11)

[Luis Villa <louie ximian com>]

On Thu, 2003-03-13 at 14:35, Andrew Sobala wrote:
> On Thu, 2003-03-13 at 18:56, Luis Villa wrote:
> > I've put up GEP 10, Standards for Inclusion in the GNOME , as well as
> > GEP 11, Module List for 2.4.
> > 
> > http://developer.gnome.org/gep/gep-10.html
> > http://developer.gnome.org/gep/gep-11.html
> 
> My comments:

Thanks for the feedback, Andrew.

> - 2.3.3 GNOME-ness
> 
> I don't think we should specify that apps must use "GNOME 2
> technologies", but rather should completely interoperate with other
> GNOME 2 applications and the desktop or some such wording. Using GNOME 2
> technologies is ambiguous and implies that an app _must_ link against
> libgnomeui (or other libraries). Some of these such libraries (such as
> libgnomeui) should be in Gtk anyway.

I can't think of a single app in the desktop that would fall into this
category right now, and I don't want to overbroaden this definition into
vague meaningless-ness in order to include apps that don't exist and
aren't likely to.

> I think if a Gtk app operates well with the rest of GNOME with no holes,
> there's no reason why it shouldn't be included. Or even if a KDE/Qt app
> integrates well with GNOME (although this is not the case with the
> current implementation of GNOME and KDE technologies), why it should
> necessarily be excluded.

My sense is that any app that isn't GNOME-based will fail many or all of
the other tests.

Note that I think I'm assuming gtk is, effectively, a part of the 'gnome
technologies.' Maybe that should be more clear?

> 2.3.4 Free-ness
> 
> What do we mean by "Free or Open?" Presumably this means licenses that
> GNU say are compatible with the GPL
> (http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses) or
> are approved by the OSI (http://opensource.org/licenses/).

Presumably, yes. I don't want to turn the GEP into a linkfarm,
especially for terms that have familiar value to those in the community.
But if other think that this would be useful then it can be changed.

> 2.4.1 Quality
> 
> If we exclude repeatable crashers, some core GNOME modules don't qualify
> :-). Maybe this should read something along the lines of "Very few (I
> mean <=2) repeatable crashes, and the maintainers are dedicated to
> fixing bugs like this quickly".

I have already used the phrase 'basically no' and 'reasonable rate' to
imply what you're stating. Brevity is a virtue, though, so anything you
propose that is at least as short and still flexible I'm willing to roll
with :) 

> 2.4.5 Use of GNOME resources
> 
> I think the important bits here are:
> 
> -> CVS and translations. How well do the translation team cope with apps
> out of GNOME CVS (like gstreamer, IIRC). I think this is the only reason
> an app actually needs to be in GNOME CVS.
> 
> -> If not in GNOME CVS, should have a public CVS repository. The GNOME
> cycle revolves around having bleeding-edge testability.
> 
> -> My biased point of view is all modules _must_ be in bugzilla.
> Otherwise, forwarding bugs to maintainers is a total PITA.

This document must be general and flexible, so I really don't want to
get into these levels of specificity in it. 

> Extra bit
> 
> What about saying that modules must be prepared to conform to the GNOME
> freezes in at least one CVS branch.

Very, very good point. Will add later tonight.

Luis

> My thoughts...

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers