Am Freitag, 17.06.05 um 14:06 Uhr schrieb Stefan Urbanek:
Citát Riccardo <[EMAIL PROTECTED]>:
<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
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev