Re: Queries about release specifications [Was: who gets in and why]

[Maciej Stachowiak <mjs noisehavoc org>]

On 02Sep2002 11:57AM (+0100), Michael Meeks wrote:
> Maciej,
> 
> On Sun, 2002-09-01 at 15:47, Maciej Stachowiak wrote:
> > One big difference between apps and platform libraries is that it's a
> > lot easier to drop an app from a future release if it turns out to
> > suck than to drop a platform library, given GNOME's compatibility
> > guarantees.
> 
> 	The point is - that companies can't just "drop" an app from the
> platform; if they ship it, there is an expectation that they will be
> moving it forward, and supporting it in the medium to long term, and
> that sort of constraint will only increase with time.

Apps can be, and indeed have been, obsoleted by a new better app in
the same category, although there may be a period when both must be
supported. Examples of past, current and future transitions of this
sort include:

gmc --> nautilus
enlightenment (never official, but de facto standard) --> sawfish
sawfish --> metacity
gnome-terminal --> whatever VTE-based thing is replacing it
gnome-help --> yelp
mozilla (never official, but de facto browser to use with GNOME) --> galeon (new de facto choice)

In general, these have been much less painful than platform library
transitions (like imlib --> gdk-pixbuf) because GNOME and third-party
components don't have dependencies on the UI of existing apps, the way
they have dependencies on APIs of existing libraries. This allowed
vendors to phase new apps in at their own rate, possibly supporting
both options for a brief period. And it allowed GNOME to adopt the new
app as official when actually ready, rather than having time
constraints brought about by the need to switch over many things at
once.

> > So while it's better to have a more open decision-making process,
> > using something like the GEP seems like overkill.
> 
> 	Well; propose something then. I don't see how the GEP is overkill, but
> I'm interested in your concrete, alternative proposal - and why it is
> superior. Vague criticism doens't help us at all.

I don't think it's my place to make a proposal, but since you asked, I
like Jeff's idea of a public discussion period on a designated list,
followed by a determination of rough consensus of the release
team. Perhaps the GEP process could be used as a last resort if there
is no clear consensus, but a solution is needed.

Regards,

Maciej



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