[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Release schedule
Re: Release schedule
Thu, 3 Apr 2003 11:54:55 -0500
On Thursday, Apr 3, 2003, at 03:56 Canada/Eastern, Richard
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
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.
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 >
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
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
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
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
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
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,
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
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.
Re: Release schedule, Tim Harrison, 2003/04/01
Re: Release schedule, Yen-Ju Chen, 2003/04/01
Re: Release schedule, Willem Rein Oudshoorn, 2003/04/01
Re: Release schedule, Adam Fedor, 2003/04/02
- Re: Release schedule, (continued)
- Re: Release schedule, Philippe C . D . Robert, 2003/04/01
- Re: Release schedule, Chris B. Vetter, 2003/04/01
- Re: Release schedule, Philippe C . D . Robert, 2003/04/02
- Re: Release schedule, Chris B. Vetter, 2003/04/02
- Re: Release schedule, Tim Harrison, 2003/04/02
- Re: Release schedule, Chris B. Vetter, 2003/04/02
- Re: Release schedule, Adam Fedor, 2003/04/02
- Re: Release schedule, Richard Frith-Macdonald, 2003/04/03
- Re: Release schedule,
Tim Harrison <=