Richard Lowe writes: > Mike Kupfer <mike.kupfer at sun.com> writes: > > Jim> Niftier still if it could one day swim upstream ... > > > > Yeah. I hadn't really thought much about that option. What would be > > involved to turn cdm into a bundled Mercurial extension, like MQ? We'd > > probably want to pull out the ON-specific policy checks. > > Most of the things we need cdm for are either not applicable to the > world at large, or things the Hg folks find distasteful. I don't know > what would be involved in pushing bits of it upstream. I don't > entirely see what the benefit would be, the parts that delve deepest > are also the parts I would doubt would be taken.
That seems a rough position to be in. Doing things that require the use of bits that may well break but that the upstream doesn't like and thus can't be kept in sync is a bad recipe for the long term. Perhaps I'm worrying too much here, but I think it would be bad if we ended up in a situation where a large community depends on these tools, but the tools are unstable and (as a result) need frequent maintenance. At some point, we'll all be off in greener pastures, and the gatekeepers and gatelings will be left to fend for themselves. That's sort of what happened to 'pmake,' and it wasn't pretty. It might be good to look into ways to factor the problem so that the part that gets pushed upstream is something they can live with -- a stable shim layer that provides us the bits we need, but that protects their eyes from our apparently wayward development practices. I don't think it's a "now" item or even a "before putback" item, but it's a longer term risk. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
