Re: Release schedule

[Richard Frith-Macdonald]

Argh ... nowadays it seems I'm too busy at work etc to do anything like 
as much work on GNUstep as I'd like, and I'm certainly too busy to 
spend a lot of time on mailing list debates, but this thread just seems 
to keep going, so I guess I'd better at least state my opinion, though 
I don't want to get into the debate.

1. I think Nicola is right to say that the old/existing mission 
statement is OK, and it shouldn't mention stability... The word 
'stability' has different interpretations, but I think the useful ones 
can/should be taken as a given aim and should not need stating.  The 
extreme form, where nothing ever changes, bugs are never fixed, and the 
software is never ported to other systems for fear of breaking things 
is obviously a bad thing.  The existing statement already says that we 
will not remove the OpenStep APIs even if apple does!

2. Personally, I do not like the horizontal MacOS menu bar, and don't 
approve of the new gui classes associated with it.  I don't think that 
most of the new MacOS-X gui classes are good, and I'd quite happily see 
a standard GNUstep user interface guideline document included with the 
gui library advising you not to use them ... and providing examples of 
how to achieve similar/better results using the 'main' API.  Then 
people who want to work on them can, and they would be available as an 
aid to porting apps from MacOS-X.
In the base library I added an Additions library for stuff MacOS-X 
users would need to port GNUstep code to MacOS-X.  This code is 
automatially incorporated into the base library but can be built 
standalone on MacOS,
It might make sense to add a MacOS library for people who want it to 
supply MacOS-X classes which we *don't* want in the GNUstep base (eg 
apple scripting) ... these wouldn't be incorporated into the base 
library, but would be available for people who wanted them.
We could do the same thing in the gui library ... with one area for  
classes that MacOS doesn't have, and an area for classes that MacOS has 
and we don't normally want.
All that being said ... I don't really feel that this is a big issue 
... I already feel quite free *not* to use MacOS-X classes if I don't 
want to, without having them separated into another library.

3. The OpenStep/OPENSTEP4.2/MacOS-X API argument that seems to keep 
being raised with regards to stability is IMO almost completely bogus.  
Application problems are not due to changing API so much as changing 
implementation details.  All three suggested APIs are incompletely 
documented and ambiguous in places, so the most common application 
breakage (apart from bugs I guess) is down to changes in undocumented 
parts of the API.
Saying we will conform to one particular documented API (we already say 
we will conform to OpenStep) does not have any effect on this issue.
Saying we will conform to the implementation of OpenStep is impossible 
... developers don't have a reference implementation to test against.
Saying we will conform to the implementation of OPENSTEP4.2 is 
practically impossible ... most developers don't have a reference 
implementation to test against.
So realistically, we only have the choice of testing 
undocumented/ambiguous parts of the GNUstep API against the MacOS-X 
implementation or just going our own way and probably being 
incompatible with both MacOS-X and OPENSTEP.  Testing against MacOS-X 
at least gives us a good chance that our code will also match OPENSTEP 
implementations.

4. Stability in general ... of course we have a stable (OpenStep) API, 
but as I pointed out, that's of limited use in practice.
I consider the base library stable on GNU/Linux ... in that it's as 
stable as any other (non-dead) system out there (certainly as stable as 
the Apple Foundation).  It's really only just becoming stable on 
windows.  Most changes are bugfixes or optimisations.
Even the gui library is pretty stable in terms of what it's trying to 
do ... it just needs a lot more bugfixes to be contributed!!!
Most application problems I see are simply either -
a. Bugs in the libraries which need fixing and are unrelated to API 
specifications or project aims
or
b. Application passing invalid arguments to methods (or depending on 
undocumented behavior) and being surprised when the behavior changes 
due to internal bugfixes or improvements in internal consistency within 
the libraries.
We can improve (a) by fixing bugs, and we can improve (b) by not fixing 
bugs :-)
Actually, the best thing for (b) is to improve the documentation.
IMO we should -
first, locate ambiguities in the documentation
second, check that the GNUstep implementation matches MacOS-X in 
ambiguous cases
third, ensure that the GNUstep documentation says what the actual 
behavior is, and/or says that it should not be relied upon as we may 
want to change it to track MacOS
Of course, this is a long slow process and needs people to do it rather 
than just talk about it.