On 4/11/07, John Plocher <[EMAIL PROTECTED]> wrote:
Peter Tribble wrote:
> No, we have far too many packages.
And I still stand by this statement.
As background for anyone wishing to address this
perceived problem, the theory goes like this:
Developers develop features by writing source code.
Features evolve at different rates, have different
resources available and are parts of different
dependency graphs.
A component is made up of many features
Gatekeepers compile all the source code for a
component and produce one or more packages
Multiple components are combined to produce products
Release Engineering builds a product by selecting
a set of versioned components. These components are
in actuality simply lists of versioned packages.
You are asking good questions about the granularity of these
packages. Lets play with the granularity control: What would
happen if each component (like ON) were to be delivered as a
single large package? I believe chaos would be the result:
A) patching and updates would be cumbersome, as any change
to a component would require the redelivery and re-
installation of the entire component.
Two comments:
1. This essentially describes BFU and the Solaris Express update
model, and that doesn't seem to be a problem.
2. The split of a component into packages doesn't (or shouldn't) make
any difference. A patch delivers a set of revised files. Those revised
files are collected into partial packages according to which package
the file goes into. Changing the package granularity doesn't change
the mechanism or make it any more or less cumbersome.
B) Coordination and testing tends to stratify into a
bottlenecked linear process - everything in a component
must work before the component itself can be used.
So are you saying that components currently can contain
non-functioning parts?
How does the way that the delivered objects are split into
packages on the distribution media affect this process?
It's the same files being delivered that need testing.
C) Developers tend to be drawn into a centralized, waterfall
style development model, with a schedule that drags out
based on the slowest/poorest performing development team.
Again, how does the way that the delivered objects are split
into packages on the distribution media affect this process?
BFU is essentially an example of treating ON as a single
package - or at least a single unit. The development process
still works with this constraint, so replacing BFU archives with
large packages isn't going to make the world end.
I think there are likely to be more problems if we were to
consider packages that crossed consolidation boundaries.
D) Users/Admins are faced with an all or nothing choice.
Well, that's down to the one extreme. And in practice, users and
admins don't really have much choice at the moment. It's
becoming increasingly hard to build a functional system that
deviates much from one of SUNWCrnet or SUNWCall.
The other end of the spectrum is just as bad - millions
of little packages, all alike, each one a dependency-garnering
minefield to trap the unwary.
Pretty much the situation we have at present.
The middle ground we try to walk is to provide packaging
boundaries for subsystems and major features that enable
distributed and asynchronous development teams.
Or, looking at it the other way, packages map to the
output of an independent, distributed development
team. They are the ultimate "consolidation"
boundary - everything within a package is delivered
together as a unit and the package is expected to
always be self-consistent.
So what you're saying - explicitly - is that packages are only a
meaningful abstraction for the development process and aren't
designed to deliver useful units of functionality for customers?
And yet it's us administrators who have to deal with the
packaging system, while the development process is based
around features and code. I'm arguing that packaging should
be based on the functional needs of users/customers
rather than being an artifact of the development process.
--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
_______________________________________________
opensolaris-discuss mailing list
[email protected]
