[EMAIL PROTECTED] wrote: > > >>> - All AST sources are in usr/src/lib/lib(ast|pp|dll|cmd|shell)/common/ > >>> and usr/src/cmd/ast/. All files are 100% identical with the upstream > >>> (AT&T) versions except those listed in > >>> "usr/src/lib/libshell/misc/ksh93_solaris_builtin_patch.diff". > > >> I don't understand why this is necessary, the SCM will provide you with > >> diffs and their associated comments. > > I have to agree with Richard here - putting back the *.diff file is not > necessary. > If there is an issue with the (external) SCM now which > prevents you from being to regenerate your diffs, then please let the > folks at [EMAIL PROTECTED] know. But putting back this > extra file seems unnecessary.
IMHO it is neccesary for now. Our codebase is currently hosted on a Subversion tree and not Mercurial. For now I really like to track things this way and EOL it after 1) this putback is done 2) a reasonable plan gets accepted how we can prevent the ksh93 codebase from being overrun with Solaris-specific changes which are not submitted to upstream 3) a way to allow offline, non-Mercurial users to update the ksh93 codebase without messing with Mercurial at all. Right now none of the conditions are met... and I think we should keep the status quo and defer this discussion to a date after the putback (please...) ... > > AFAIK there are at least two justifications for such a *.diff: > > 1. The old ksh88 in the Solaris tree was hacked to death in various bad > > ways, making it impossible to track changes without causing potential > > harm for older bugfixes. AFAIK Sun has a SCM for those sources but > > somehow this failed to work. IMHO such a policy is mandatory to prevent > > current and future maintainers to play around with the codebase randomly > > and causing it to diverge from the upstream sources which may result (in > > the worst case) incompatibilities between our version of ksh93 and the > > upstream version. THIS MUST NOT HAPPEN AGAIN!! And yes, I am trying to > > There's no need to shout. Erm... sorry... that wasn't thought as shouting, that was more thought as giant exclamation mark (I usually don't shout... I can't even remember shouting this year for any reason... :-) ). > Actually, the reason ksh88 is in the shape it is is that it's fallen > into disrepair. There have been various bug fixes to it over the years > but no substantial attention has been paid to it. When it was "ported" > to Solaris, my guess is that nobody knew at the time that David Korn > and ATT would eventually open source "ksh" and that ksh93 would appear > at some point. Umpf... part of the problem are exactly these "fixes". Originally the discussion which started this project included some very bitter and depressed comments from two vendors how ksh88 in Solaris has become incompatible to ksh88 on other platforms like AIX and HP-UX. That's why I agree that all hope is lost for the old /usr/bin/ksh and am am desperately trying to prevent that something will ever happen again to the new korn shell in Solaris. I am not looking at 2007 or the next five years, I am looking ten or more years into the future and I am worried about the results of human nature and things like "lazyness". I fear that without stricter rules we will have the same kind of problems in ten years. And your comments make me even worry more (or short: You've introduced a new monster in my nightmares...) since this kind of argumentation wasn't enougth to prevent the old /usr/bin/ksh falling into pieces. > > be adamant in this case since I do not want to see the ksh93 in Solaris > > fall into pieces like it happened with the old /usr/bin/ksh. We really > > need an additional safeguard. The whole ksh93-integration project uses > > interoperabilty as it's foundation, that's why we had all the main other > > many months over three ARC cases to get it "right". > > There are other ways of safeguarding this. For one, random people > aren't going to be able putback changes. As with other source code in > OpenSolaris, there are processes to make sure the right thing happens. > Sometimes things happen (bugs get introduced) but usually the processes > prevent the sort of thing you fear happening. And in the case of > externally derived open source, gratuitous changes are highly > discouraged and need justification. Why was OpenSSH then fork()'ed in Solaris (OkOk, maybe a bad example since AFAIK it involved some rampage with SSH upstream) ? Why did the old ksh88 diverged from the upstream sources ? What about the status of Motif and CDE in Solaris ? There are many examples in Solaris where it went horribly wrong and I really don't feel pacified by the "...the SCM and review will handle it for you..."-comments. Beyond this arguments there is a practical purpose: For now April&&I maintain the code and for now the *.diff file is the easiest way to do the updates in our case. Any other solution would require some time to become familar with this new infrastructure and I'd like to avoid this until the work with the Mercurial gate has been stabilizsed and all normal development goes through that gate. The ksh93-integration project already explores so many new features and I really don't like to be the spearhead of development and testing for the SCM stuff, too (at least one piece of the development should be on a stable basis and my last tests with Mercurial resulted in the partial loss of data and I don't really like it to spend hours on a fix and then loose the data). Remember I am not a full-timer (e.g. I still have to work on other things for food) and I am running this project usually after 23:00h... I really can't do everything... ;-( > > 2. We'd like to update many many times, keeping ksh93 in Solaris in sync > > with the upstream development. This will likely result in half a dozend > > or more updates per year and a seperate patch which tracks the > > Solaris-specific changes is very usefull to back them out between > > updates (without having to mess around with a SCM; the update procedure > > should IMHO be completely SCM independant). It also allows tight control > > over Solaris-specific changes to the AST/ksh93 codebase. In theory all > > patches should be submitted to upstream, NOT to the Solaris codebase. > > The *.diff policy should remind maintainers that changes should go > > through upstream and then make it into Solaris with the next source > > update from upstream. > > I'd like to suggest that although everyone wants the latest features > coming down from ATT and there's certainly a benefit to getting some > early exposure in some cases by integrating changes often, what we > value in ON is a more deliberate, thought-out sets of changes. These > typically might be keyed to a new version or something. It's often > said that the ON gate (or really, any consolidation's trunk) is no > place for experimentation or debugging the project into existence. I fully agree with that. The idea of the frequent updates is to get the collection of fixes into OS/Net. All development is done in the upstream sources, tested there and after testing results in "green light" we pull the matching release into OS/Net. The only difference is that we're doing lots of fixes+changes for Solaris right now and even more are scheduled (like getting "chmod" synced) which will result in more frequent updates. > >>> Anyone who is patching files in > >>> usr/src/lib/lib(ast|pp|dll|cmd|shell)/common/ and usr/src/cmd/ast/ > >>> without storing diffs+READMEs in usr/src/lib/libshell/misc/*.diff will > >>> be <insert-some-horrible-torture-here (gatekeepers should decide how the > >>> punishment should look like... I'd suggest the usage of deep pits filled > >>> with komodo dragons, hot iron, boilling acid etc. (in random order))>. > > Actually, that's completely unnecessary. What usually happens is that > instead the ON CRT (change review team) > > http://opensolaris.org/os/community/on/crt/ > > will ask if the right set of people have reviewed the code. If there > is a change proposed to ksh93 and you're not listed as one of the code > reviewers, I would typically put such a request on hold and ask the > submitter to have you review the changes. See my comments above. > >> I'd like to see an > >> explanation of why you can't just use the SCM to fulfill your needs. (I > >> can > >> accept one may exist, I just don't see what it is...) > > > > See above. Basically I do not want to see that ksh93 in Solaris sufferes > > the fate of the old /usr/bin/ksh. Somehow Solaris-specfic changes should > > be kept at the smallest possible minimum level (and I am already not > > very happy (or better: grouchy) about the cut-down list of builtins but > > accept this as a oblation to Solaris's backward-compatibilty policy. But > > it still hurts me... ;-( ). > > It won't fall into that sort of disrepair as long as the community > values the project and honors the process. I wish the process would include a little bit more protection from running into problems like ksh88 in Solaris did... > Yes, mistakes might be made > at times but those can be remedied. But how ? How do you undo the changes if you do not have access to the SCM ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
