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



fre 2002-08-30 klockan 08.04 skrev Mark McLoughlin:
> Hi Jody,
> 
> On Fri, 30 Aug 2002, Jody Goldberg wrote:
> 
> > Poor code is reflected by instability and feature problems.
> 
> 	Not neccessarily. Its perfectly possible to get an app to a
> certain level of acceptability even with poor code. Its future
> maintenance and feature addition problems I'm worried about -
> particularily when someone else has to take over the maintainership.

Since you are working on the panel which pretty much everyone who has
looked at the code agree that it's really nasty I guess this is what you
are talking about (mainly, even though it applies to all modules with
unmaintainable code).

My question is, would this kind of review ensure that the panel code
would be more maintainable? Was there several panels being written but
this one was chosen when there was others that had a better code base.
If not this procedure wouldn't have solved anything.

My point is, how often do we have several projects that has an app that
is equally good but only differ on code quality? 

Another thing is that GNOME is highly modular and you can easily change
a certain module for one that is maintained and has a better code base,
look at zvt -> vte, sawfish -> metacity (not sure about better code base
but written in a language that GNOME hackers are more comfortable with).
On an application level this is even easier.

Sure, this takes more time than if the module had been written with
nicer code in the first place _but_ they did there job for a long time
and old code tend to be rather cluttered after a while anyway. Should
this same code review group review all patches too (so that no
maintainer happens to accept a patch with bad code?).

Of course if the code is really ugly and not following GNOME style we
can point this out to the maintainer of the module so that he can work
on cleaning it up. But let's face it, we need to put the user in the
focus, if we have an application that is badly needed but the code isn't
that great imho we shouldn't exclude it just because of that.

Regards,
  Mikael Hallendal

-- 
Mikael Hallendal                micke codefactory se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918




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