On 2005-10-26 15:55:22 +0100 Fabien VALLON <[EMAIL PROTECTED]> 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?
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev