[Top][All Lists]

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

Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)

From: Richard Frith-Macdonald
Subject: Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
Date: Wed, 26 Oct 2005 17:11:43 +0100

On 2005-10-26 15:55:22 +0100 Fabien VALLON <address@hidden> wrote:

For the 1.0 release, what do you think about an
"OpenStep-compliant release" ?

- This is the first goal of GNUstep.
- There is already some bugs to fix for "OpenStep-compliants" classes.
- There is already documentation for "OpenStep-compliants" classes.

I think developpers can only target on it for the 1.0.

I wouldn't get hung up about compliance ... some OpenStep stuff may not be implemented for years (if ever) as nobody uses it ... if it was dropped from OPENSTEP 4.? or early MacOS-X for instance.

Part of the reason I think having a centralised set of applications under the GNUstep umbrella is that they could consitute a gui testbed of sorts ... what I think we want to see from a 1.0 release is not necessarily complete implementation of a particular API, but rather a core library distribution which gives us a *delightful* (not just workable) user experience with common applications on at least one core platform (eg. gnu/linux, X, windowmaker) more if we can manage it. That is to say, the parts of the library we want to work 'perfectly' are those parts used by the apps most people will want to use.

1.2 could be Windows / OpenStep + bug fix

About Cocoa ( the Cocoa in MacOS 10.1 for example ) could be a 2.0 target.
Can we create a GNUstepAppleExtentions in a separate framework for it ?

I think a set of API compliance targets is probably not good except as a rough guideline ... there is a mixture of good stuff and rubbish in the moving target that is MacOS-X, so I think we should try to make sure that we are compatible where we implement the same methods/classes, but not try to do everything.

As far as separate frameworks go (I prefer simple libraries unless there is actually a good reason to use a framework), I do think it would be good to have a structured approach. I'd like to see at least the following non-core library or framework packages -

1. base extras, gnustep specific
eg. linked list implementation of NSMutableArray, a cache class, perhaps the classes I put in the SQLClient library etc.
2. base extras, apple specific core data if anyone is interested in contributing it.
3. gui extras, gnustep specific
   eg. the equivalent of the MiscKit stuff
4. gui extras, apple specific
apple stuff that we don't want to support as 'core', but would like someone to contribute.

The main reason I've not done anything about this is that I don't know what to do about access control and copyright assignment issues. Perhaps we need to have two lots of each library ... one for code where people have assigned copyright to the FSF and one where they haven't. I'd like things like this to be as readily accessible as possible (ie mean write access to the source code repository), but we obviously grant free access for people who haven't done an FSF copyright assignment to code that's signed over to the FSF. Ideally we'd combine both FSF and non-FSF classes in the same library, but have the SCM control who could access which class ... but I don't know if any SCM gives us that sort of control ... the gnu arch stuff looks interesting for that sort of customisability, maybe svn can do it too?

reply via email to

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