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 : http://savannah.gnu.org/bugs/?group=gnustep
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...
Regards,
Sheldon
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
