[opensolaris-summit] Brandorr's comments on proposed Summit topics

[John Plocher]

Alan DuBoff wrote:
> This is where an ARC would do the OpenSolaris community an
> injustice if they impose limitations on the software that
> can be contained in a repository of user-land, open source software.

Nobody but you has said anything about general software availability
in random repositories.

I'm talking about the systems we choose to build out of specific
things from specific repositories.  It may well be that we get a
severe case of stupidity and create several incompatible versions
of libc and place them in various repositories.  No problem there
(other than being stupid, of course).  It should be obvious that
one can't simply randomly pick one of those libc's and expect the
rest of their system to "just work" - there is a dependency chain
that links your libc choice to the stuff that will work with it.
Same for most everything that is in or near the core of a system.

The systems engineering and architecture I'm concerned with focuses
on the decisions that a distro producer needs to make to ensure that
their distro starts off self consistent - and remains so over time.

If you want to go off and do your own thing without any regard to
how your behavior impacts projects that have come to depend on
you, feel free to do so.  Just don't expect others to be very
happy with you if you jerk them around by behaving irresponsibly.
What do I mean by irresponsible behavior?  Effectively, not
setting expectations for those who would consume your stuff,
or once having set them, breaking them.

> The current ARCs would blow a fuse at the thought of putting anything in 
> /usr/bin:/usr/sbin I suspect, but am only speculating.

You /are/ speculating - wildly and without much basis in fact.  Most
of the ARC's focus in the last couple of years has been on doing
exactly that.

The whole point of Systems Engineering - as opposed to unconstrained
hacking - is to develop a model for how we /desire/ a system to behave
and to ensure that what we /do/ matches that model.  This includes
changing that model as time goes by and expectations change.

The Solaris model is one of stability of interfaces over time.  The
model says that we desire that all code and scripts that were written
following the rules will continue to operate correctly on any and
all minor and micro releases of Solaris in the future.

This obviously is not the same model that is desired for Indiana.

Unfortunately, nobody has articulated the specifics of what this
new model are, nor have they put any effort in developing transition
plans to move between the old and new models.  Topping it all off,
we (Sun, OpenSolaris,...) only have a "stable tree" to work with.
There is no "unstable development branch" where we can do all those
chaotic things that you seem to desire.

This all makes it hard for developers, architects, distro producers
and users to understand what they need to do.

   -John