Re: Release schedule

[Tim Harrison]

On Thursday, Apr 3, 2003, at 03:56 Canada/Eastern, Richard 
Frith-Macdonald wrote:

> 1. I think Nicola is right to say that the old/existing mission 
> statement is OK, and it

Based on the need for this discussion, and the fact that it is still 
continuing, there appears to be a need to reconsider the wording of the 
current mission statement.

> 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

That shouldn't mean that GNUstep should *prevent* the ability to create 
a bundle that implements it.  You might not like it, and the OS X 
classes might suck, but some people do, and if better classes can be 
written, why should a developer not be able to use those?

> 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

I'd like to see massive amounts of documentation done, but most of the 
time, the answer is "go to Apple's site".  This, I feel, is totally 
insufficient.

> 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

I disagree totally.

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

I think that's a terrible excuse.  Just because you believe that all 
three APIs are incompletely documented does not mean that GNUstep 
should be unstable.

The way I read this statement, it comes across as:

"GNUstep is unstable because Cocoa and OpenStep aren't documented very 
well."

That's ridiculous.  For a project that claims to want to make 
"technically superior modifications", why, then, is there not 
technically superior design documentation?

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

It does, if one isn't following that stated goal.

> Saying we will conform to the implementation of OpenStep is impossible 
> ... developers don't have a reference implementation to test against.

Okay, pardon me if I missed something, but did you not just say that 
"we already say we will conform to OpenStep"?  Are you saying that the 
stated goals of the project are impossible?

> Saying we will conform to the implementation of OPENSTEP4.2 is 
> practically impossible ... most developers don't have a reference 
> implementation to test against.

Once again, are you saying that the stated goals of the project are 
impossible?

I think availability could be a bit of an issue, but it certainly is 
less of a problem than a moving target.

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

I think there are enough people out there with OPENSTEP available to 
them (and if people want to use my cube and/or a PC with OPENSTEP 4.2 
installed on it, I'll put them in the data centre, and give selected 
access) to test things.  Just giving up and saying that it can't be 
done is defeatist.

> 4. Stability in general ... of course we have a stable (OpenStep) API, 
> but as I pointed out, that's of limited use in practice.

We do?  It is?  I think "limited use" is totally subjective.

> 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

But it has this schitzophrenic lack of focus (no, I'm not referring to 
the focus issues in -gui ;)).  Porting from OPENSTEP to GNUstep is 
difficult, and porting from Cocoa to GNUstep is difficult, because it's 
such a mixed bag.

Not to mention, Linux (RMS can come beat me up, but I'm not going to 
play politics and put GNU/ in front of Linux all the time -- you know 
what I mean) isn't the only platform out there.  I think GNUstep being 
Linux-specific is frustrating for a lot of developers (hey Chris!).

>  only just becoming stable on windows.  Most changes are bugfixes or 
> optimisations.

How do we know?  There's no documentation, or official decision 
regarding what the API *should* be.  Saying "look at Apple's site" is 
meaningless, if you're not totally tracking Cocoa.

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

I think this is fairly inaccurate.  My coding skills are lacking, but I 
do spend a lot of time listening to the people who are developing 
applications, and they're definitely unhappy about the state of, 
specifically, -gui.

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

Once again, I'd like to ask... what documentation can a developer 
follow?  You're saying that none of the three (OpenStep, Cocoa, or 
GNUstep) have sufficient documentation, but then saying that problems 
are being caused by application developers depending on undocumented 
behaviour.  How can anyone then develop robust applications, if all 
behaviour is undocumented?

> 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

Or simply create documentation.

> second, check that the GNUstep implementation matches MacOS-X in 
> ambiguous cases

Unless the OS X implementation sucks, in which case, I would think, 
OpenStep behaviour would be assumed, unless that, too, sucks.  Then, it 
becomes a matter of creating a GNUstep implementation, from an initial 
design, and documenting the hell out of it.

> 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

Which I think is a cop out.  I don't think that there should be any 
documentation that says that there's no documentation (or unreliable 
documentation) because GNUstep hasn't decided which side of the fence 
they're on.   Then you're officially telling an application developer 
that their app might be forever unstable, because tomorrow, the 
implementation might change, and totally break their app.

> Of course, this is a long slow process and needs people to do it 
> rather than just talk about it.

Right now, from what I'm reading, I think talk is EXTREMELY important.  
There is a lot of confusion, a lot of frustration, and a lot of people 
are on the brink of giving up because of that frustration.  Rushing 
headlong into action might be the worst thing to do.


Tim Harrison
address@hidden
http://www.linuxstep.org/