James Carlson wrote: > > William James writes: > > > If someone doesn't actually want to see his work reviewed, then I > > > think it'd probably be better to find a gate that doesn't care about > > > peer reviews. Of the ones to choose, ON is historically probably > > > among the most picky. > > > > Does this necessarily include rigidity? I mean Roland has given a fair > > rationale why this kind of file should be in the CVS and then even > > offered a compromise which includes a removal of the file if it is no > > longer required. I find it a bit unfair that this is being ignored. > > Frankly, the rigidity I see isn't all on the side of the reviewers. > > In fact, I've seen folks bending over backwards to accomodate this > project, including agreeing to the (in my opinion) incorrect inclusion > of SUNWastdev in SUNWCdev. That one's a much larger concession, as it > will end up littering _customer_ systems for no useful reason that I > can discern. > > The point here isn't to trade favors or make people happy. It's to > arrive at solutions that work well and don't end up making a mess in > the future. It's still quite unclear to at least some of the folks > looking at this why a file that can be regenerated at will via "diff > -r" and that plays no part in either the build process itself or in > documenting the source is something that's worthwhile to store in > every copy of the repository.
Erm, in this case the *.diff _IS_ documentating the source - it describes the differences between the upstream version of the ast-ksh sources and the source checked into OS/Net. Sure, the *.diff could live elsewhere but at some point this will get VERY messy since the diff changes betwen putbacks. Storing it elsewhere means we have to store the diffs for each putback seperately and track the progress of the OS/Net tree OUTSIDE the tree, too... including branches for Solaris 11/FCS, branches for S11U1, S11U2, S11U3, etc. and OpenSolaris trunk. At some point we will run into huge trouble to determinate which of the diffs belongs to which tree or branch in a tree and getting this "wrong" may introduce some nasty bugs and/or cause headaches for those who maintain the code. Or short: Getting this wrong may likely lead to a degradation of the code quality and/or our abilty to deploy updates quickly. --- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
