gnustep-dev
[Top][All Lists]
Advanced

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

Re: GNUstep improvements bounty


From: Richard Frith-Macdonald
Subject: Re: GNUstep improvements bounty
Date: Fri, 17 Jun 2005 21:00:20 +0100

On 2005-06-17 20:16:16 +0100 Lars Sonchocky-Helldorf <address@hidden> wrote:

> 
> Am Freitag, 17.06.05 um 14:06 Uhr schrieb Stefan Urbanek:
> 
>> Citát Riccardo <address@hidden>:
>> 
<snip> 
>> Also, I think that trying to focus on perfecting GNUstep is a waste of time.
>> Perfection will come together with usage and evolution(*). GNUstep already 
>> is
>> "perfect enough to be used". Any additional bit of "perfection" will not
>> attract any new user to GNUstep, nor will motivate new developers to develop
>> for GNUstep.
> 
> No, this only results in workarounds piled on other workarounds (somewhat the 
> situation we have now) and at some point the whole thing will colapse because 
> nobody knows any longer why several things are done in a certain fashion. I 
> strongly disagree (and I already have worked on a lot commercial solutions 
> that suffered from exactly that to know that this is the software hell 
> (mostly JAVA/J2EE/WO projects that I do for my job)).

I agree with your view here (though not the assessment that we currently have 
workarounds piled on workarounds ... I think such thing in the core libraries 
is very rare, though the focus handling code might still be a case in point.) 
and I believe that it is policy of core developers to try their best to ensure 
that the *correct* solutions are found rather than quick hacks being put in.  
This has been what we have been trying to do for years (since mGstep was forked 
from GNUstep, partly because its author wanted to stick with workarounds, while 
the majority of developers wanted clean rewrites of broken code), and has IMO 
been an important factor in the current success of GNUstep.

Certainly the determination to fix problems correctly (and use regression 
testing ... something the base library has, but has been difficult to achieve 
for the gui) has been a major factor in improving the code.  Going back to 
basic errors and fixing them is a much faster way to progress in the long run 
than continually adding workarounds.

I aso agree that you can't depend on bugs showing up in applications ... if 
bugs break applications too often, people just won't upgrade the core libraries 
... so the bugs won't show up in the applications.
 
>> Therefore I vote for new frameworks, be them GNUstep innovations or ported
>> frameworks. They will move GNUstep forward, will add new value, will find 
>> new
>> bugs, will attract and motivate new developers. Core will be fixed, I am not
>> worried about that.
> 
> No, exactly that is wrong. This would give the new frameworks a broken 
> foundation which is very hard to fix later on.

Yes ... but it's not fun or glamorous ... we have to have a combination of both 
... but I think, in the context of *paying* someone to do things rather than 
expecting them to do it for fun, we would be best off getting people to produce 
more regression tests, and review existing code behavior to ensure that it is 
correct (and the same as Apple's code unless their is clearly wrong).
They could add/improve documentation at the same time as doing code review.

Let's leave the adding of new frameworks etc for people to volunteer to work on 
and enjoy, rather than paying for them.

Of course, picking out the highest priority areas for code review is a tricky 
problem in itsself.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]