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

On Fri, 2002-08-30 at 05:05, Jody Goldberg wrote:
> Poor code is reflected by instability and feature problems.

	Worse, it's un-maintainable - maintainability has to be our no. 1
focus; if it's not possible to fix XYZ because the interactions are so
spaghetti like that they're incomprehensible except by person BAA it's a
ticking timebomb waiting to go off.

> Layering in beaurocracy to verify something that would get weeded on
> other criteria seems like a waste of precious resources.

	Problem is - as we see by umpteen examples it doesn't work that way -
people get seduced by partially working feature/bug riddled apps, with
bad UIs, and evil code.

>   If the community consensus is that a app is viable, then electing a
> collection of 'benevolent code fascists' to override them will not
> help.  Who would want to be put in the position to judge the code ?

	I think there is a perspective problem here; I'm talking about the
process adding apps from 5th toe into whatever the 'core' is called
these days. Who said anything about election ? judging ? etc. It's not
fascism to say "Your code needs fixing in these ways before it can be

> Lets try to keep the community fun.  If you think an app is crap say
> so with a smile :-)  People will listen.  Don't elect a committee to
> do it.

	That's just crazy; the thread started with "Who gets in and why"
the alternative proposals for getting stuff into the core go:

	a) Release team says what goes, in private
	b) The GEP process is used [ and incidentally we do some code 
				     review at the same time ].

	You tell me which one of these processes has an (un)'elected' committee

	Ultimately it seems to me we're arguing semantics - the badge 'In the
Gnome Core' is not to be haphazardly applied to things. That is the crux
- and I believe that sound technical review by eclectic authors, in
public, using the GEP is the only way to achieve that.



 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot

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