Re: GNUstep improvements bounty
On 2005-06-17 20:16:16 +0100 Lars Sonchocky-Helldorf <[EMAIL PROTECTED]> wrote: > > Am Freitag, 17.06.05 um 14:06 Uhr schrieb Stefan Urbanek: > >> Citát Riccardo <[EMAIL PROTECTED]>: >> >> Also, I think that trying to focus on perfecting GNUstep is a waste of time. >> Perfection will come together with usage and evolution(*). GNUstep already >> is >> "perfect enough to be used". Any additional bit of "perfection" will not >> attract any new user to GNUstep, nor will motivate new developers to develop >> for GNUstep. > > No, this only results in workarounds piled on other workarounds (somewhat the > situation we have now) and at some point the whole thing will colapse because > nobody knows any longer why several things are done in a certain fashion. I > strongly disagree (and I already have worked on a lot commercial solutions > that suffered from exactly that to know that this is the software hell > (mostly JAVA/J2EE/WO projects that I do for my job)). I agree with your view here (though not the assessment that we currently have workarounds piled on workarounds ... I think such thing in the core libraries is very rare, though the focus handling code might still be a case in point.) and I believe that it is policy of core developers to try their best to ensure that the *correct* solutions are found rather than quick hacks being put in. This has been what we have been trying to do for years (since mGstep was forked from GNUstep, partly because its author wanted to stick with workarounds, while the majority of developers wanted clean rewrites of broken code), and has IMO been an important factor in the current success of GNUstep. Certainly the determination to fix problems correctly (and use regression testing ... something the base library has, but has been difficult to achieve for the gui) has been a major factor in improving the code. Going back to basic errors and fixing them is a much faster way to progress in the long run than continually adding workarounds. I aso agree that you can't depend on bugs showing up in applications ... if bugs break applications too often, people just won't upgrade the core libraries ... so the bugs won't show up in the applications. >> Therefore I vote for new frameworks, be them GNUstep innovations or ported >> frameworks. They will move GNUstep forward, will add new value, will find >> new >> bugs, will attract and motivate new developers. Core will be fixed, I am not >> worried about that. > > No, exactly that is wrong. This would give the new frameworks a broken > foundation which is very hard to fix later on. Yes ... but it's not fun or glamorous ... we have to have a combination of both ... but I think, in the context of *paying* someone to do things rather than expecting them to do it for fun, we would be best off getting people to produce more regression tests, and review existing code behavior to ensure that it is correct (and the same as Apple's code unless their is clearly wrong). They could add/improve documentation at the same time as doing code review. Let's leave the adding of new frameworks etc for people to volunteer to work on and enjoy, rather than paying for them. Of course, picking out the highest priority areas for code review is a tricky problem in itsself. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Am Freitag, 17.06.05 um 14:06 Uhr schrieb Stefan Urbanek: Citát Riccardo <[EMAIL PROTECTED]>: I stress my point that it is only for the time being that I would stress the importance of completing and stabilizing -core before adding more meat to the fire. You port your mega-app to gnustep thanks to coredata and coreimage and then discover it is unreliable in operation because of some bug deep in -core ? wouldn't you be frustrated? This unreliable application will discover bugs that would not be discovered without this application. How can you find and fix all bugs in gnustep? You can: - Invest in full GNUstep testsuite for every feature. Is that doable in a reasonable time with reasonable number of resources? Are you able to identify all features that sohuld be teste? Are you able to identify all cases? If not, how you can be sure that the most important bugs are fixed? Some bugs are not visible at first look. - Or you can explore the code by yourself, looking at each line of code. Can anyone do that? - Or you can create or port bunch of applications and see what is wrong then fix it. The last option will "kill two flies with a single hit". New applications may help in the first run, but what usually happens with software is that you introduce new bugs when trying to fix some (think of the NSTableView issues lately). While it is possible to discover those bugs with those new applications the problem here is the unsystematic procedure: All cases need to be tested by hand, so some cases will be forgotten easily or only discovered by chance later on. This is the point were a test suite comes in handy: You'll run all tests automatically and unattended, you can see the results later in a protocol nicely grouped for every architecture you test. Premise is of course that the testcases are well-kept, every bug report will be required to have a test case generated which exposes the bug and so on. This requires, some might hate this word here, some discipline. A good idea is to have a look into the software development process which the GCC team employs: - There is a main line and release branches in the CVS. At a given point in time the main line goes into a bug fixing mode where nothing else than bug fixing is permitted. Only if the number of open bugs goes below a certain limit a release branch is created where no new features but bug fixes are allowed within. Only now the addition of new features to the main line are allowed. Bug fixes must be back ported to main line too. - Also in use by the GCC team is a elaborate review process: Unless you are maintainer for a certain section you're not allowed to commit an unreviewed patch to GCC, but you have to prove that you don't reintroduce older already fixed bugs (regressions) by running the test suites and get the o.k. for the patch by someone with reviewing authority for a certain section which ensures code quality. This was only a short introduction into the software quality assurance process employed by the GCC team. It is described more detailed here: http://gcc.gnu.org/contribute.html Well this all sounds annoying and if all the fun will be taken away from your hobby, this will be the only way to increase software quality of GNUstep. And never forget: If you want to collect stamps as your hobby (for instance), you can't do that on the floor or even in your bed since the results will be disappointing. You'll need a table and some tweezers at least. Also, I think that trying to focus on perfecting GNUstep is a waste of time. Perfection will come together with usage and evolution(*). GNUstep already is "perfect enough to be used". Any additional bit of "perfection" will not attract any new user to GNUstep, nor will motivate new developers to develop for GNUstep. No, this only results in workarounds piled on other workarounds (somewhat the situation we have now) and at some point the whole thing will colapse because nobody knows any longer why several things are done in a certain fashion. I strongly disagree (and I already have worked on a lot commercial solutions that suffered from exactly that to know that this is the software hell (mostly JAVA/J2EE/WO projects that I do for my job)). Therefore I vote for new frameworks, be them GNUstep innovations or ported frameworks. They will move GNUstep forward, will add new value, will find new bugs, will attract and motivate new developers. Core will be fixed, I am not worried about that. No, exactly that is wrong. This would give the new frameworks a broken foundation which is very hard to fix later on. Stefan Urbanek regards, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
> 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? Btw, how much does an advert on slashdot cost ? ;-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Citát Riccardo <[EMAIL PROTECTED]>: > I stress my point that it is only for the time being that I would stress > the importance of completing and stabilizing -core before adding more > meat to the fire. > You port your mega-app to gnustep thanks to coredata and coreimage and > then discover it is unreliable in operation because of some bug deep in > -core ? wouldn't you be frustrated? > This unreliable application will discover bugs that would not be discovered without this application. How can you find and fix all bugs in gnustep? You can: - Invest in full GNUstep testsuite for every feature. Is that doable in a reasonable time with reasonable number of resources? Are you able to identify all features that sohuld be teste? Are you able to identify all cases? If not, how you can be sure that the most important bugs are fixed? Some bugs are not visible at first look. - Or you can explore the code by yourself, looking at each line of code. Can anyone do that? - Or you can create or port bunch of applications and see what is wrong then fix it. The last option will "kill two flies with a single hit". Also, I think that trying to focus on perfecting GNUstep is a waste of time. Perfection will come together with usage and evolution(*). GNUstep already is "perfect enough to be used". Any additional bit of "perfection" will not attract any new user to GNUstep, nor will motivate new developers to develop for GNUstep. Therefore I vote for new frameworks, be them GNUstep innovations or ported frameworks. They will move GNUstep forward, will add new value, will find new bugs, will attract and motivate new developers. Core will be fixed, I am not worried about that. Stefan Urbanek (*) - Obligatory note repeated in many of my previous and future replies: look outside and meet the nature. It is definitely not perfect from design point of view and it is not "bug-free", but it is good enough and nice enough to survive. And it survives for pretty long time, does not it? ;-) -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Hello, On Friday, June 17, 2005, at 05:44 AM, Sheldon Gill wrote: 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. I agree on this point, but I would broaden the perspective: applications are important too. Thus a good and integrated HelpViewer could be a nice thing. A good editor. A documentation browser. And many other tools and apps we discussed so often. I stress my point that it is only for the time being that I would stress the importance of completing and stabilizing -core before adding more meat to the fire. You port your mega-app to gnustep thanks to coredata and coreimage and then discover it is unreliable in operation because of some bug deep in -core ? wouldn't you be frustrated? -R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Hello, On Thursday, June 16, 2005, at 08:08 PM, 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. I must agree with Adrian and Fabien. I discussed the matter on #irc too. While I welcome the idea of attracting developers to complete and fix gnustep, I think starting from CoreData is the wrong place. Since we have limited resources, it would be better to complete -back and -gui, to better portability and get some long-needed applications in the Gnustep "system". Those things are needed anyway. To rephrase a metaphor Jeff T. said: If you have limited money and two flat tires in your car, your money may be not best spent buying new alloy wheels! cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
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 Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
[EMAIL PROTECTED] wrote:
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
...
May be we could create smaller bounties for more specific stuff, here
are some ideas :
I'd like to add accessibility to the list:
http://developer.apple.com/documentation/Cocoa/Conceptual/Accessibility/AccessibilityCocoa.pdf
I think this going to be an increasingly hot issue for people deploying
applications into regulated environments such as government and
education sectors, in addition to the rather more basic interest in
making GNUstep useful to a diverse user population.
I also think Accessibility is an important addition but it is unfortunately a
rather complex topic.
{I worked with various special needs in the past and so have more experience
with accessibility than most}
The problem is compounded at the moment because there are many different
efforts to add better accessibility support to *nix, none of which are
reasonably mature.
Further, fully featured support is something that needs to be integrated into
the desktop rather than something that can be simply added to -core.
Thus, I don't think it's something we can just add to the list and attribute a
bounty to.
However, Accessibility and complex input methods are actually quite closely
related topics at the developer level. We can certainly move GNUstep closer to
the goal by working on support for diverse input methods. While this is only
part of what is required, it does get us closer and gives an immediate benefit
of better multi-lingual support which is also needed.
There are probably a few other small specific tasks we can add to the list to
prepare a better foundation for this, too.
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
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. On Jun 16, 2005, at 5:25 AM, Fabien VALLON wrote: Adam Fedor wrote: 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. Cheers, David I think it would be usefull to fix all bugs in AppKit / backend first see : http://savannah.gnu.org/bugs/?group=gnustep I think we can also improve UI too. For example: focused Views/Cells should be more "visible" ( add a black border on TextField for example ). Make stable and "bugs free" all we already have should be the first priority. Other suggestions : - Icons for the default NeXTish look. - a clone of HearderViewer ( and pre-compiled headers ) - Port of WebCore Fabien ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
On Thu, Jun 16, 2005 at 12:13:27PM +0200, Quentin Math? wrote: > >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 ... > I think it is a welcome idea, I would be really interested by a ... > May be we could create smaller bounties for more specific stuff, here > are some ideas : I'd like to add accessibility to the list: http://developer.apple.com/documentation/Cocoa/Conceptual/Accessibility/AccessibilityCocoa.pdf I think this going to be an increasingly hot issue for people deploying applications into regulated environments such as government and education sectors, in addition to the rather more basic interest in making GNUstep useful to a diverse user population. Peter ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Le 16 juin 05 à 00:38, Adam Fedor a écrit : 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? Hi Adam, I think it is a welcome idea, I would be really interested by a CoreData implementation, but it seems someone (Sašo Kiselkov) has already started to work on it. By the way, I have mostly implemented Predicates support one month ago (I'm just mentioning it in my reply to Sašo on discuss-gnustep list). May be we could create smaller bounties for more specific stuff, here are some ideas : - Better keyed archiving support (Cocoa compatible) - missing methods in various classes - NSTokenField & NSTokenFieldCell - NSStream, NSInputStream, NSOutputStream - NSFontDescriptor - NSLevelIndicator & NSLevelIndicatorCell - NSDatePicker & NSDatePickerCell - New Mac OS X 10.4 text classes : NSTextBlock, NSTextList, NSTextTab, NSTextTable, NSTextTableBlock. Quentin. -- Quentin Mathé [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
> Adam Fedor wrote: >> 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. > > Cheers, > David I think it would be usefull to fix all bugs in AppKit / backend first see : http://savannah.gnu.org/bugs/?group=gnustep I think we can also improve UI too. For example: focused Views/Cells should be more "visible" ( add a black border on TextField for example ). Make stable and "bugs free" all we already have should be the first priority. Other suggestions : - Icons for the default NeXTish look. - a clone of HearderViewer ( and pre-compiled headers ) - Port of WebCore Fabien ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Adam Fedor wrote: > 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. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Gregory John Casamento wrote: All, --- Nicolas Roard <[EMAIL PROTECTED]> wrote: Le 15 juin 05 à 23:38, Adam Fedor a écrit : 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 it's a good idea -- some of the recent additions by Apple like the bindings, CoreData, CoreImage.. are really interesting, so if we can manage to implement them it will be a good thing to the project -- First, it would help developers porting their apps on gnustep and vice-versa; but moreover, thoses kits are really cool by themselves :) -- particularly the bindings and CoreData. I am planning to do the NSController classes and KVO. Awesome. That will make a fine and complimentary addition to the CoreData/NSPredicate work. Later, GJC Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
All, --- Nicolas Roard <[EMAIL PROTECTED]> wrote: > > Le 15 juin 05 à 23:38, Adam Fedor a écrit : > > > 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 it's a good idea -- some of the recent additions by Apple > like the bindings, CoreData, CoreImage.. are really interesting, so > if we can manage to implement them it will be a good thing to the > project -- First, it would help developers porting their apps on > gnustep and vice-versa; but moreover, thoses kits are really cool by > themselves :) -- particularly the bindings and CoreData. I am planning to do the NSController classes and KVO. Later, GJC Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Le 15 juin 05 à 23:38, Adam Fedor a écrit : 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 it's a good idea -- some of the recent additions by Apple like the bindings, CoreData, CoreImage.. are really interesting, so if we can manage to implement them it will be a good thing to the project -- First, it would help developers porting their apps on gnustep and vice-versa; but moreover, thoses kits are really cool by themselves :) -- particularly the bindings and CoreData. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstep improvements bounty
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? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
