Richard Lowe writes: > James Carlson <james.d.carlson at Sun.COM> writes: > > If necessary. It all depends on how cdm is packaged and delivered and > > how dependencies are maintained. > > cdm is in SUNWonbld, mercurial is the one in the WOS, SUNWmercurial. > There's no dependencies set at the packaging level, currently.
Yes, I know where it is right now. ;-} Slightly longer term, it'd be nice to look at the stability levels offered and figure out where the best place to package it might be. The things that are currently in SUNWonbld are things that generally have private dependencies on the guts of ON, but not elsewhere. (Ctf might be an exception to that ...) Longer term still, I think the point ends up being moot. When/if Indiana creates a single open package repository, we ship SUNWonbld (and cdm) via that same repository with SUNWmercurial, and all we need to do is make sure that the repository is sane. > > In any event, it sounds like an issue to bring up at an eventual ARC > > review, but not something that (assuming the right job gets done) is > > ever handled by a developer. > > An ARC review of the tools? of mercurial? OK, how about a lower-case "arc"? Seriously, if there's a dependency on possibly unstable bits, it'd be good to think about how to handle that properly. It's not as though architectural issues go away just because you're delivering to a different class of users. > The tools aren't interface delivered to users, I think the appropriate > thing would be a contract between the ON C-Team and SFW for the > mercurial internals. Yes, that'd be a decent way to handle it. Niftier still if it could one day swim upstream ... -- 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
