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

[Richard Frith-Macdonald]

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
   eg.apple 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?