Re: GNUstep improvements bounty

[Lars Sonchocky-Helldorf]

Am Freitag, 17.06.05 um 14:06 Uhr schrieb Stefan Urbanek:

> Citát Riccardo <address@hidden>:
>
> <snip>
>
> > I stress my point that it is only for the time being that I would 
> > stress
> > the importance of completing and stabilizing -core before adding more
> > meat to the fire.
> > You port your mega-app to gnustep thanks to coredata and coreimage and
> > then discover it is unreliable in operation because of some bug deep 
> > in
> > -core ? wouldn't you be frustrated?
>
> This unreliable application will discover bugs that would not be 
> discovered
> without this application. How can you find and fix all bugs in 
> gnustep? You
> can:
>
> - Invest in full GNUstep testsuite for every feature. Is that doable 
> in a
> reasonable time with reasonable number of resources? Are you able to 
> identify
> all features that sohuld be teste? Are you able to identify all cases? 
> If not,
> how you can be sure that the most important bugs are fixed? Some bugs 
> are not
> visible at first look.
> - Or you can explore the code by yourself, looking at each line of 
> code. Can
> anyone do that?
> - Or you can create or port bunch of applications and see what is 
> wrong then fix
> it.
>
> The last option will "kill two flies with a single hit".

New applications may help in the first run, but what usually happens 
with software is that you introduce new bugs when trying to fix some 
(think of the NSTableView issues lately). While it is possible to 
discover those bugs with those new applications the problem here is the 
unsystematic procedure: All cases need to be tested by hand, so some 
cases will be forgotten easily or only discovered by chance later on.

This is the point were a test suite comes in handy: You'll run all 
tests automatically and unattended, you can see the results later in a 
protocol nicely grouped for every architecture you test. Premise is of 
course that the testcases are well-kept, every bug report will be 
required to have a test case generated which exposes the bug and so on. 
This requires, some might hate this word here, some discipline.

A good idea is to have a look into the software development process 
which the GCC team employs:

- There is a main line and release branches in the CVS. At a given 
point in time the main line goes into a bug fixing mode where nothing 
else than bug fixing is permitted. Only if the number of open bugs goes 
below a certain limit a release branch is created where no new features 
but bug fixes are allowed within. Only now the addition of new features 
to the main line are allowed. Bug fixes must be back ported to main 
line too.

- Also in use by the GCC team is a elaborate review process: Unless you 
are maintainer for a certain section you're not allowed to commit an 
unreviewed patch to GCC, but you have to prove that you don't 
reintroduce older already fixed bugs (regressions) by running the test 
suites and get the o.k. for the patch by someone with reviewing 
authority for a certain section which ensures code quality.

This was only a short introduction into the software quality assurance 
process employed by the GCC team. It is described more detailed here: 
http://gcc.gnu.org/contribute.html


Well this all sounds annoying and if all the fun will be taken away 
from your hobby, this will be the only way to increase software quality 
of GNUstep.

And never forget: If you want to collect stamps as your hobby (for 
instance), you can't do that on the floor or even in your bed since the 
results will be disappointing. You'll need a table and some tweezers at 
least.

> 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)).

> 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.

> Stefan Urbanek

regards, Lars