[Top][All Lists]

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

Re: GNUstep improvements bounty

From: Sheldon Gill
Subject: Re: GNUstep improvements bounty
Date: Fri, 17 Jun 2005 11:44:55 +0800
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Adrian Robert wrote:
I agree with Fabien's opinion (below). People are always interested to work on new features -- it seems like the CoreData stuff for example is already well on its way even though Tiger's just out -- but it's the more thankless work like fixing bugs and filling in rarely-invoked implementations that most needs to be compensated to occur at all.

Alex Perez has suggested using some of the funds that GNUstep has
(and/or directed donations from individuals) to fund a part-time
programmer to improve GNUstep.  Some specific projects include CoreData
and Predicates. Are other people interested in seeing these things added to GNUstep?

I think the general idea of the improvements bounty is great.  CoreData
and Predicates both seem interesting are probably good candidates to
figure out how to structure such bounty project.

I think that CoreData, Predicates, KVO and a number of other things are actually very bad candidates. The reason is this:

Community projects tend to get lots of work done in the areas which are considered interesting or which are clearly visible to others. It is the things which don't and probably won't get done which should have the bounty as incentive.

Also, as the GNUstep funds and administration are very limited, I'd suggest it best that bounty tasks be small, contained and very well defined. They should be work on the -core libraries which provide benefit to large numbers of users.

As there are commercial interests using GNUstep, it would be great if those companies would offer bounties for functionality they'd like. Instead of paying an internal programmer, offer the sum as a bounty with a time limit. Then there is a chance that the work is already done before your internal programmers get to the task. You can actually shorten your project timeline at the same cost without risk.

I think it would be usefull to fix all bugs in AppKit / backend first
see :

Make stable and "bugs free" all we already have should be the first priority.

Agreed in principle.

Other suggestions :
- Icons for the default NeXTish look.
- a clone of HearderViewer ( and pre-compiled headers )
- Port of WebCore

I'd vote against all three of these. There are icons out there already to use. More can be done. They are quite visible and there is recognition factor in contributing them so I don't think icons are a good candidate at this stage.

HeaderViewer is an app. If enough people want it, it'll happen. The functionality can come through other means anyway.

There already has been quite some effort in porting WebCore and the concensus seems to be to wait for ObjC++ support in GNU gcc. Hence, WebCore will happen in time anyway.

Pre-compiled header support in -make is definitely a good thing. I believe Nicola and some others have already looked into this...


reply via email to

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