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
Am Freitag, 17.06.05 um 14:06 Uhr schrieb Stefan Urbanek: Citt Riccardo [EMAIL PROTECTED]: snip 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
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: Citt Riccardo [EMAIL PROTECTED]: snip 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
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
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
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 (Sao 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 Sao 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
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
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