Richard Lowe wrote: > Roland Mainz wrote: > > Richard Lowe wrote: [snip] > > 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.
Erm, getting the diffs from the SCM would require to putback the code unchanged and then appy the diff seperately... or how would you do it ? Right now the current update prodecure is (more or less) to backout the Solaris-specific diff, apply the patches from upstream, test that, reapply the Solaris-specific diff, test that and compare the test results for any differences and commit the tree to the Subversion repository. That way I'd hope gurantee that the frequent updates won't cause serious harm... > > [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. Sorry but why should I suddenly agree to the "SCM solves all the problems" approach ? I agree that the current solution is not pretty nor perfect... it's more like a compromise... but at least it has proven itself to work without problems since it was origianlly uploaded into the tree (AFAIK 14 or more updates were done that way), other parts of OS/Net like tcpd/perl/grub/etc. use the same method to track changes between the OS/Net sources and upstream versions (and none of these projects has AFAIK been asked to do it the "SCM way", right ? :-) ) and the current approach is at least "economical" and "understandable" (e.g. we know how it works, know the limitations and can handle it in a way without shooting ourselves into our feet) for the current maintainers (at least my experiemnce with Mercurial wasn't that good yet and I am still not familar with it... and I don't like to have an "unknown variable" in such a complex "equation" either. Yes, somewhere in my ToDo list is to learn how Mercurial really works but I can't do that within a week or two (and as I said I don't really want to play the "spearhead of development" in this case, please...) ...). What about the following compromise: 1. We upload the *.diff+README solution for now 2. After nine months (counter starts once the putback notification email hits onnv-notify at opensolaris.org) or after four ksh93-integration putbacks (not counting things like "fix lint error", please) we re-evaluate the situation and discuss whether the *.diff is still usefull or not. That compromise would avoid any possible harm in the near future, gives us time to evaluate how/if Mercurial can be used instead of the *.diff thing, sets a clear deadline to find a more permanent solution and we could work on the tree in peache (e.g. without the constant fear of screwing something up) ... ... would that be acceptable ? > (Hey, I didn't suggest the more traditional vendor-branch merge...) Is there any smiley for <user is rolling with his eyes and then explodes> ? :-) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
