Peter Tribble wrote:
No, we have far too many packages.
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.
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.
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.
D) Users/Admins are faced with an all or nothing choice.
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.
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.
Sometimes we screw up, breaking a subsystem up into way
to many pieces - or not enough. Othertimes we have no real
choice because other constraints force our hand - if the
subsystem needs to work with zones or diskless clients,
it needs multiple packages. Whether it is targeted at
developers or at end users also plays a role.
Just my $0.02
-John
_______________________________________________
opensolaris-discuss mailing list
[email protected]
