Roland Mainz wrote: > Richard Lowe wrote: >> Richard Lowe wrote: >>> Roland Mainz wrote: > [snip] >> 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. > > Erm... did you take a look at the diff yet ? I wouldn't even _dare_ to > offer this patch to upstream. The only purpose of the patch is to reduce > the list of builtins to those defined in PSARC 2006/550 > (http://www.opensolaris.org/os/community/arc/caselog/2006/550/). This > list will be changed with upcoming putbacks (like enabling the "chmod > "builtin once the ACL feature has been provided) etc. ... IMO this does > not belong into the upstream sources until the contents of this patch > have been stabilizsed.
I was meaning future changes that may be made that, of course, you'd hope would go upstream. I'm aware your current changes are largely not of that nature. >> 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. > A "straight diff" doesn't work as April described. The situation is a > little bit more compliciated and fetching the patch, adjusting it and > then checking for possible "hiccups"/"mistakes" will be time-consuming. > Right now the update can be done in less than 20mins (= > recompiling+testing) and this plan to involve a SCM sounds like it will > just cost much more time without any benefits. In theory this could be > done via a script... but where should we store that script ? Again, that bit was mainly referring to changes outgoing from us to AST, not incoming. I still fail to see the motivating difference between manually creating the diffs prior to putback and including them in the tree, and asking the SCM for those same diffs afterwards. > [snip] >> 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. > > I have to disagree VERY strongly in this case. Right now the idea to use > the SCM sounds like an instable, time-consuming and risky procedure (and > your description of a possible solution made me even MUCH more opposed > to such a crudding hack). No, thanks. If you say so. (Hey, I didn't suggest the more traditional vendor-branch merge...) -- Rich
