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]>: >> <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