Danek Duvall wrote: > On Tue, Jan 30, 2007 at 01:24:01AM +0100, Roland Mainz wrote: > > 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 > > The plan for this is vigilance by people who are knowledgable and care, and > the sanity of the CRT, as David explained.
... I wish there would be some kind of automated or semi-automated way to deal with the problem... > You ask why this didn't work for Motif, CDE, and ksh88. I can't say much > about the first two, except that as they're not part of ON, they are not > known to have the same rigorous integration requirements that ON does. Right... that was one of the reasons to squish ksh93 (like ksh88) into OS/Net... to make sure the strict policy used for the OS/Net tree will prevent the mistakes of the past. At least ksh88 and dtksh in Solaris both have a giant history of finding new and innovative ways to deliver tears to the faces of the customers and I'd like prevent at least the well-known problems of the forerunners of this project. [snip] > I don't think I've seen an unreasonable backout > request yet (except the occasional frustrated outburst from a gate staff > member). Heh... I've seen worse things... :-) ... for example mozilla.org's CVS has several "intersting" backout comments in cases where a commit broke all tinderbox machines (usually happens after the tree was re-opened for normal commits, followed by some dozend commits within less than ten minutes (everyone just waiting for the tree being reopened with the finger directly over the <ENTER> key to start the commit) ... two hours later all tinderbox machines are "RED" (=build failure) and the tree sherrif starts to backout patches to get the situation under control again (I am not going to cite the curses here... =:-) ) ... ) ... :-) BTW: Did anyone thought about something like an automated build and test system similar to "tinderbox" which runs over the tree, tests it and then tries to BFU a system ? > Your vigilance should be enough to make sure that divergence doesn't happen > arbitrarily. Like David said, any RTI for a ksh change that doesn't > include you as a code reviewer should be suspect. Alternately, once we've > opened the RTI process, you could be a perfectly good candidate for the > CRT, with a specialty of ksh (though that's up to the CRT, not me). What about myself or April... how should we store the patch ? IMO it should be treated as part of the "documentation" and stored with the normal sources (as said in my other postings some parts of OS/Net like grub, tcpd, perl etc. do the same without impunity) ... just to avoid things which happened to dtksh in the past (read the end of http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-January/002117.html). Both the *.diff file(s), "buildksh93.ksh" and the "touristguide.xml" are likely to differ for each single putback, reflecting the changes, modifications, special problems and other things done exactly for this single putback. I really like to have a good way to organise this somehow both for me and those who may come after me (BTW: Please read http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-January/002122.html ... it outlines a possible compromise...). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
