Philip Brown wrote:
On Mon, Apr 17, 2006 at 04:23:17PM -0700, Alan DuBoff wrote:
So, how would it be possible to build a large set of libraries that everyone
could update and use together? Is this at all possible? Sun has basically
proposed to work with the community, and that is happening, albeit
slowly...so would it at all be possible to work with the community and
create one large set of libraries we all work with and update together?
Hate to say it, but: "no", because of all the qualifiers you put in.
If you take some out, then yes it is possible.
possible.. but not likely.
For example, if you simply take out "with the community", it is possible.
The reason being, of some people's hard requirements that the libraries
they use be "from sun".
"from sun + the community" is NOT "from sun".
Sun would have to go 180 degrees in the direction they have gone, and hire
full-time staff, to keep the "important stuff" up to date, solely by sun's
efforts.
Sun would have to then have a split-versioning strategy, where one version
of the libs would get used by cdrom-burned releases, but then newer
versions of the libs were easily and automatically downloadable via the
net, so people can more easily/quickly keep up to date. and then keep their
team actually busy working on keeping the libs highly up to date.
However, there are still multiple problems with this:
1. things change slowly in "core" solaris for a reason. some of sun's
customers are very change-averse. So, to have bits in sun-shipped
solaris, change rapidly, would possibly alienate that important
userbase.
[it might be possible if sun split out that stuff to a separate chunk,
and said, "ok, we commit to stability for stuff <over here>, but
stuff on this GNOME cdrom/whatever we do not commit to keeping
unchanged for x number of years, or even x number of months]
2. Some of the issues of keeping nasty open source libs up to date, is
then that you have to recompile a buncha stuff, because there is an
extreme lack of API stability in the open source world. It's the linux
disease of "oh, you should just recompile everything"
3. Sun would have to actually comit to the long-term expenditure of
creating and maintaining such a team.
Hurdle #1 there, is sun actualy doing the comitting.
Hurdle #2, which at this point is far bigger, would be in convincing
everyone else that sun is actually serious this time.
I for one would not believe it for at least 2 years after it was
started.
The cost to convert everything, and then get dumped after a year,
is simply too high to take a risk on it at this point.
Re-engineer 1500 packages... and then re-engineer them AGAIN?
no thanks.
It would be more useful to take this analysis (a really well-thought-out
one, IMO) and put in a context where the arbitrating body is based on
_current_ (as opposed to past) Solaris development policy/process[1]. See:
http://www.opensolaris.org/os/community/onnv/os_dev_process/
In other words, it'd be really interesting to rewrite the analysis in
the context of Nevada (aka Solaris "next") development, and also revisit
each place where the word "Sun" is used and replace it with "OpenSolaris
governance".
Eric
[1]: The "Devproc" is governed by -- not Sun management -- but the CAB/OGB:
http://www.genunix.org/wiki/index.php/OpenSolaris_Governance
... and the CAB/OGB was officially empowered (not too long ago actually)
by the OpenSolaris Charter:
http://www.genunix.org/wiki/index.php/OpenSolaris_Charter
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
