> Richard Lowe wrote: > > James Carlson <[EMAIL PROTECTED]> writes: > > > >> Mark J. Nelson writes: > >>> I think an upstream sync necessarily implies > pulling the current upstream > >>> source, integrating your changes, and building it > OUTSIDE of the context > >>> of ON. Anything else is negligent. Including > the unused-in-ON code > >>> provides no benefits that are immediately obvious > to me. > >> +1. > >> > >> It creates an ever-increasing amount of flotsam in > the gate, and thus > >> a storage and time penalty that every single > ON-based workspace must > >> pay. It's waste with benefit to few -- and likely > nobody at all. > >> > > > > And it would make tag searches, cscope, opengrok, > etc, needlessly noisy, if > > these are actual source files. That alone is bad > enough, in my view. > > OTOH, it means you're more likely to understand > other-platform effects of any > changes you may be contemplating by looking at an ON > workspace...
But if you're tracking them, you're presumably feeding back patches and such whenever possible, so as to hopefully minimize differences from the upstream. So insofar as keeping differences to a minimum is a benefit, you may have to consider other-platform effects if you want your patches to be accepted upstream. Maybe for that, it only matters to the usual maintainer(s) depending on whether they integrate before or after upstream incorporates (or rejects) their patches. But what about someone doing a patch that touches a lot of things all over the place? What assures they consider the effect of their changes on files that were excluded from ON? Maybe there needs to be a checklist of subtrees for which one needs to check with the in-house maintainers for upstream sync issues? Or a "taxonomy" of sync level goals? One way or the other, I sure hope as much as possible is learned from (for example) the ksh93 integration; it seems to have run into most of the problems (and also a lot of opportunities, given the upstream cooperation; I suspect that ksh93 itself has been improved more than a little as a result) of working with external source, and picked probably the toughest consolidation to do it in. If there aren't possibilities for process improvement there, I don't know where they'd be hiding... This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
