[Top][All Lists]

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

Re: Release schedule

From: Tim Harrison
Subject: Re: Release schedule
Date: Thu, 3 Apr 2003 11:54:55 -0500

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

reply via email to

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