Stephen Hahn writes: > * James Carlson <james.d.carlson at sun.com> [2007-09-12 12:46]: > > 2. We currently rely on the fact that consolidations are all > > built all at once in a coordinated action, and then > > delivered as a matched set. This lets us ignore some > > complicated problems that occur when interfaces used across > > projects are allowed to have arbitrary and not-necessarily- > > compatible change. > > The system will allow groups of packages to be co-delivered with > matched versions (and with constrained version flow). Departing from > the version flow of those groups will require an explicit act by the > deployer.
My read of that implies that (except as done by "explicit act" and therefore likely well off the beaten and supportable path), the user can choose only points along a version line for the group as a whole, and not individual points for a single component within that group. "In for a penny, in for a pound" on updates at a consolidation level. If that's what you're saying, then I'll hum a +1 on the project proposal. > > One way around this would be to say that each consolidation > > delivers just one new-fangled package: ON is a single lump of > > stuff, at least until we take pains (over a long period of time, > > probably) to refactor ON into smaller parts. Is that part of the > > future plan? > > I would expect that consolidations would use the group packages to do > something similar to this, although I expect few would use a single > package to represent their various deliverables. Provided that they're actually controlling the interfaces between those components in a way that allows asynchronous delivery, that sounds reasonable. If they're not, chaos can be the result. The case I want to avoid here is where we build _assuming_ that the bits will be used in coherent groups that we've tested and/or verified in some way, but we just "allow" users to pick arbitrary clumps of those bits or (worse) provide no documentation or hint that they're doing something foolish by upgrading individual parts. It's way too easy for users to wander off the reservation in that way, and end up getting hurt badly by hidden dependencies. They end up coming back to us and asking us to document those dependencies. The problem we have then is that we don't, in fact, always know what the dependencies are, and we're usually unwilling to even try to do the reverse engineering necessary to discover them. The best we can offer (as we have with the various "minimization" schemes) is that it ought to work, but nobody's ever tested it that way, and so you're just on your own. It's a cycle of misunderstanding and broken promises that doesn't sit well with a lot of users. At the root of the problem is a set of software delivery mechanisms that don't actually match the engineering and design practices. We build one thing, test another, and users install something else entirely. :-/ -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
