Garrett D'Amore writes:
> > I think there's the problem: you assume that only things that Sun can and
> > will support can live in ON.
>
> That is the precedent to date.
True, but in my opinion that's the fundamental problem here. In another
open source project I know well (GCC), it works completely differently: SVN
trunk contains all the code that is deemed appropriate by the release
process and the maintainers. Even though many of them are payed by the
likes of Redhat, Suse, Google, Intel and AMD, they use the project's rules
for deciding what goes into the tree. Since vendors often want to ship
modified versions of the code, either with patches that are not yet ready
for mainline, or completely inappropriate for trunk, they maintain vendor
branches where all this happens. At least ON is different here: only Sun
business and support interests dictate what's allowed into the hg
repository, no matter what the community thinks is appropriate. I'm
certainly not opposed to the ARC process and strict requirements for code
review and testing here, quite the contrary: in my opinion, those are the
strong points of the OpenSolaris project. But Sun dictatorship doesn't
seem right for a community project here: this is quite different from a
benevolent dictator who follows documented though strict community rules
for what can go into the tree. In my opinion, this is a central
OpenSolaris governance issue. Unfortunately, Michelle Olson couldn't come
to OSDevCon '09 in Dresden last week as planned, otherwise I'd have liked
to raise the issue with the OGB there.
> I'm not going to disagree with your sentiments... but to date there are
> many situations where Sun's business interests trump those of the
> community. As long as the ON consolidation is staffed entirely by folks
> who owe allegiance to Sun (or its successors), then it will be hard to
> effect any change that allows the community to integrate "community
> sustained" sources.
The GCC example makes it abundantly clear that this needn't be the case:
while the core maintainers are paid by various companies, as long as
decisions are made for trunk, they are based on community rules, even if
they are contrary to those of the company paying their paychecks. This is
of course different for the vendor branches.
There are also precedents against the strict prohibition of support for
unsupported hardware in commercial distributions: e.g. in the Tru64 V5.1
(or 5.0, I don't remember exactly) days, several older Alpha machines were
declared unsupported by Compaq, yet the code stayed in the distribution and
continued to work. You only couldn't call support if something didn't work
as expected.
> At the end of the day, its not clear to me that this is really that
> great of a problem. Its perfectly reasonable to create other
> consolidation with non-Sun sources (or with sources that Sun doesn't
> approve of) that live side by side with ON. There is no intrinsic need
> that legacy hardware support stuff has to be in ON.
It depends on where the necessary changes live: if they are just a couple
of additional drivers, you may be right, but if there are changes to shared
code, it requires a full-fledge fork of ON. Say all OpenSolaris
distributors but Sun want this support, so they have to maintain that fork
together instead of putting the burden on Sun to either declare the
machines unsupported or not ship the code in their branch.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
