Joseph Kowalski wrote: > > > From: Roland Mainz <roland.mainz at nrubsig.org> > ... > > Well, I hoped that it is somehow possible to have more than one ARC case > > for the ksh93-integration, e.g. put this version back, collect user > > feedback and then implement&&ARC the necessary suggestions/changes... > > which is now a little bit tricky since the profile shell is now excluded > > from the case. > > This paragraph may highlight some of the disconnects we've been experiencing. > > If I read Roland right, he wants to try things out on a consumer base and > then react to the feedback. Some people positively refer to this as > "Extreme Programming" while others negatively refer to it as "hack it > into existence".
Uhm... this wasn't designed as "extreme programming". Usually I strongly prefer the solution to design something and then implement it (as it should be done for any good project) - and this was the original "plan" for the ksh93-integration project. However based on "feeling in the stomach" I started writing some prototype code (this was "prototype001") which revealed so many issues with the original plan that we quickly abandoned this prototype code and restarted from scratch with a new one, based on experience and internal feedback with the first (and failed) attempt. Even te 2nd attempt was not perfect from the beginning but it was at least "adjustable" and both prototype codebases delivered lots of feedback for the ARC case (for example one of the results is the introduction of /etc/ksh.kshrc , allowing system-wide settings for interactive shells (like setting a default editor mode ; the lack of "working cursor keys and history" is still one of the major reasons why many people prefer bash over Solaris ksh. Fixing this item has generated lots of positive feedback and is one of the major improvements visible to the end-users compared to the old Solaris ksh)). > That's not the way Solaris works, nor the way the OpenSolaris charter > (from the CAB) asserts OpenSolaris should work. > > For projects to be integrated into the trunk, they should be as perfect > as possible. The catch phrase within the ON group of Solaris is "FCS > quality at all time". Yes, I know. However I could argue that exactly this attempt to generate something "perfect" costs more than SIX MONTHS to do the finetuning which could have been invested in other work instead (or better: we could have done more things in parallel...). We would have been MUCH faster with an immediate integration (around june 2006) and then collecting the resulting feedback and integrating it in an incremental way while working on all the other issues in parallel. Unfortunately the "FCS quality all the time" rule forced us to work the whole thing sequential in a row which will likely mean that a possible putback will now happen around januar 2007 (yes, I am pessimitic, a more optiminstic prediction would be the end of november 2006). Just a small comparisation: SuSE integrated ksh93 within less than three weeks[1]... ... I think it may be interesting to revisit the issue later (after our putback is done) and look whether we can do any optimisations... [1]=Ok, this is not a fair comparisation - we need lots of bugfixing, Solaris-specific adjustemnts and precise interface definitions (and Linux has no "pfksh93" nor does it suffer from the Solaris libcmd squatter) - but someone who just looks at the time needed until the binaries were shipping (like my professors did) may wonder about huge difference between three weeks (SuSE Linux) and eight months (OpenSolaris). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
