discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Which ObjC2.0 features are missing in the latest GCC?


From: Maxthon Chan
Subject: Re: Which ObjC2.0 features are missing in the latest GCC?
Date: Mon, 25 Nov 2019 22:34:50 +0800

I am tempted to suggest a crazy idea: fork GNUstep, and maintain them in a similar fashion as Fedora versus RHEL/CentOS: same team, same general code base, different goal.

The fork would represent the cutting edge for GNUstep, aiming to support all modern Cocoa features and hopefully one day catch up to what Apple is releasing. This is similar to Fedora in the comparison. To begin with, the fork should not support GCC, instead it uses exclusively clang as the build tool. It would be free of GCC compatibility #define’s, and make extensive use of modern feature like object literals, ARC, blocks etc. The fork should be excluded from GNU project itself so it is relatively shielded from the FSF internal turmoil, although some form of copyright assignment arrangement is still needed so code can be merged when it is time for GNUstep proper to rebase.

The main GNUstep project is the slower compatibility-aimed version that maintains GCC compatibility and ships with all the compatibility patches and manual memory management added back. This is similar to RHEL/CentOS in the comparison. Main GNUstep would periodically rebase from a tag on the fork, and reapply all the compatibility patches so it would build using the old system.

As of Debian, they can ship both at the same time, as long as they are marked as conflicting packages.

On Nov 25, 2019, at 10:07 PM, H. Nikolaus Schaller <hns@goldelico.com> wrote:


Am 25.11.2019 um 12:29 schrieb Gregory Casamento <greg.casamento@gmail.com>:


Nikolaus,

On Mon, Nov 25, 2019 at 6:06 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
Because not everybody will follow your focus. GNUstep is not a for-profit organization.

I'm well aware of this.  I've been with the project since 1999.  Lead maintainer since 2008 and maintainer of Gorm since 2002.

It's a thankless job, believe me.  No one can know until they have held it.  I simultaneously take the blame for all of the decisions made on the project whether they are mine or not and I am unable to effect unilateral change.

I believe that and do not at all doubt, since I have been in several project leaders roles myself in the past... It is like tending fleas. And it is
often minimizing contradiction, because it turns out to be rare that all decisions are accepted by everybody (although that is always my goal).
Therefore I try to find creative-and solutions which means that in an either-or decision situation I try to find a way to include both of the
initially exclusive options. This may turn out to be very difficult.

Since I have to admit that I never did: let me express my thanks here for taking this role!
And congrats for 20 year's anniversary of participation.
I think I came in first contact with GNUstep in Sept 2002 (at least this is the first mail of this list I can find) and GNUstep has moved forward significantly during that time.

My job is to act for the greater good of the project and that is what I am attempting to do here.

Sure and I do not doubt that. I just have a slightly different opinion what the right moment to deprecate some fundamental component
(compiler) where everything is based on. And before breaking down the basement I'd try to repair it.



reply via email to

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