Richard Lowe wrote: > Roland Mainz wrote: >> David.Comay at Sun.COM 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 website-discuss at opensolaris.org 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 > > I really don't like the idea of leaving crud in the tree, for just that > reason. > >> 1) this putback is done > > This is review *for* this putback, but... > >> 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 > > Whether they're submitted or otherwise is entirely unrelated (as I think > was pointed out before), the question is whether they're left crudding > up the tree. To deal with that, look at changes as they go back using > the SCM, or as was also mentioned codereview of said changes, which I, > too, would assume you'd be involved with. > >> 3) a way to allow offline, non-Mercurial users to update the ksh93 >> codebase without messing with Mercurial at all. > > To be blunt, Hell No. > > You want a way to interact with the SCM ON will use without ever using > it, or needing to use it at all? I can't even think of a technical way > to satisfy this, and to be frank, if I could see one I wouldn't even > dream of implementing it. > >> 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...) ... > > Again, I don't like it being left crudding up the tree for (what I see > as) no good reason. You're free to keep these diffs somewhere else if > you so choose, and you're free to create and manage them as you desire, > but I see no compelling reason to keep them in the tree. >
To clarify (and respond to myself, sorry). I imagine the plan is that you send these diffs upstream, so that the AST folks can incorporate them (or not) as their desires dictate. These diffs can be generated by you fairly easily, either from the changesets introducing these changes, via a straight diff between AST and ON sources... probably other ways too. The diff's your suggesting people putback to the tree are the same diffs the SCM would show you if you were to look through the history of changes to the ksh93 sources. This wouldn't involve the AST folks dealing with our SCM, you would be dealing with it anyway, the diffs would show the same things and wouldn't rely on engineers remembering to generate them. I fail to see how this is any harder than putting them back, in fact, I'd say it's easier and more reliable *and* tidier. -- Rich
