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

[Luis Villa <louie ximian com>]

On Thu, 2002-08-29 at 17:33, Mark McLoughlin wrote:
> Hi Michael,
> 
> On 29 Aug 2002, Michael Meeks wrote:
> 
> > I think we need a whole lot more scrutiny of applications we're adding
> > to the platform - particularly [!] guaging code quality, something that
> > might seem revolutionary - but I think it's worth insisting on some
> > minimal code quality requirements to get stuff in, in some formal way
> > rather than "It works for me" sort of things - but hopefully if I'm
> > wrong there other people will point that out.
> 
> 	I particularily agree with you on this point :-) Lets face it,
> when a new app is added, there's a reasonably good chance the original
> maintainer(s) will disappear off the scene leaving someone else to
> come in and take on the role. We need to have a high degree of
> confidence that the code quality is such that a new maintainer can
> come in and actually build on the existing code ...
> 
> 	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, and someone extensively committed to reviewing and assisting
new maintainers in this direction, like we do with UI, docs, QA, and
a11y. 

<crickets chirping>

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.

<crickets chirping>

So, yes. When there is a code review team, and clear documents on what
'good code' is[1], 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. 

Luis

[1]the three year old unmaintained guidelines don't really count.

[2]Yes, code quality is important. Despite the tone of this email, I'm
not against code review- I think it's great. I just refuse to set and
issue standards that are going to be impossible to get people to
actually implement. The guidelines we just wrote were written completely
with an eye to the possible- what docs do we have, what manpower do we
have. hypothetical 'it would be nice' standards should remain just that-
hypothetical.