Re: Release schedule

[Chris B. Vetter]

On Wed, 2 Apr 2003 20:48:54 +0200
"Philippe C.D. Robert" <address@hidden> wrote:
> On Tuesday, April 1, 2003, at 08:26 PM, Chris B. Vetter wrote:
> > Uhm, maybe you should drop by #GNUstep and talk to the people in
> > there. There are some pretty good programmers, like Ludovic, and
> > most of them will probably tell you otherwise...
> If there are so many issues w/ GNUstep why is address@hidden then
> so quiet?

Resignation?
Some patches go to gnustep-discuss, some are mentioned on #GNUstep and,
if possible are fixed right away.

> > Don't get me wrong. I love GNUstep, and I think it's a great tool
> > for development, alas, it's current implementation is shaky at best.
> > There are too many bugs and "features" that are not getting
> > addressed.
> OK, I admit I am mostly using the FoundationKit, and this is pretty 
> stable as far as I can tell.

s/pretty/relatively/g

> > I'm not saying that Cocoa classes, like NSToolbar, are bad stuff.
> > I'm saying that GNUstep needs a _working_ _stable_ foundation
> > (preferably a complete Openstep implementation) before we can think
> > about implementing Cocoa classes.
> Again I agree, but the question is 'what is this foundation'? Is it 
> OpenStep which nobody really ever used, is it OPENSTEP 4.2, the 
> YellowBox or Cocoa, and if the latter what version?! If it is OPENSTEP
> then we should maybe not integrate any changes from Cocoa at this
> stage at all, since this might lead to the impression that we  target
> Cocoa, instead me might distribute such additions separately.

In my opinion (that is, I'm only talking for my person), core/ should be
a straight forward implementation of Openstep (whatever the correct
spelling is ;-)

Once that is accomplished, it would provide a common foundation we can
then use to implement "enhancements" in form of Cocoa classes and
methods, as categories, bundles, whatever.

Yes, I know that may be a bit naive, as such an approach is probably TOO
straight forward, since Cocoa replaces or changes behaviour of already
existing methods and classes.

> > I don't really think a fork is necessary if we can agree on a common
> > foundation, that satisfies everyone with respect to stability,
> > usability and completeness.
> This is a tough issue, there are many expectations and needs, but we 
> should at least give it a try, yes... :-)

Exactly.

-- 
Chris