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



Hi Luis,

On Thu, 2002-08-29 at 23:30, Luis Villa wrote:
> > 	We don't need any more core modules with unworkable code and a
> > new maintainer whose hands are tied by that very fact when it comes to
> > trying to advance that module in new areas ... Enough GNOME modules
> > have been re-written ...
> 
> Sounds great. All we need are extensive docs saying exactly what code
> quality is

	Why ? do we need extensive docs on how maintainers reach a decision in
any other area - no. Ultimately code quality is relatively subjective -
and each case can be decided on it's own merit.

> and someone extensively committed to reviewing and assisting new
>  maintainers in this direction, like we do with UI, docs, QA, and a11y.

	Clearly the results of any review could be communicated with the
relevant authors. Most things like

	"Don't do (atoi (g_strdup_printf ("%3x", mynum)))"

	are difficult to document - beyond "get a clue".

> Oh, I forgot to add 'willing to write apps with better code quality when
> they turn down apps that work perfectly well'? Because that would be a
> requirement too. Apps that meet the criteria we've already laid out but
> are rejected in a code review had better have alternatives.

	Why ? simply becuase they are not part of 'Gnome' until we're happy
with the code quality; doens't mean that other people can't ship them.
It's simply a statement that we think this project meets certain minimum
requirements of cluefulness, and that we can support it going forward.
This is so that 'FooIMClient' doesn't pop in and out of the project
constantly.

> So, yes. When there is a code review team

	Reponsible maintainers [ and of course public comment and scrutiny -
the more the better ].

> and clear documents on what 'good code' is[1]

	not neccessary.

> then this sounds like a great idea and I'll support
> it completely[2]. I'm just not terribly holding my breath for such
> things to exist. 

	Au-contraire - we have a really, really serious issue of great heaps of
dung lying around, and a chance to avoid people foisting more stuff on
us by a serious of curious changes. Also would reduce bug count and make
your life easier - by coding for quality - instead of just testing for
it ;-)

	HTH,

		Michael.

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

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



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