James Carlson wrote:
> Because I think the out-of-context excerpt in 4.3.2 appears to suggest
> that Sun has the final say here, and not the distributor, and is thus
> quite destructive on the face of it, I would vote against this opinion
> as drafted.
>
I've pointed out that the out-of-context excerpt only serves to
highlight the issue. There is no coherent conclusion from the members.
This section is poorly formed along many different axis.
More importantly, I was trying very hard (in the larger discussion) make
the point that the distributor has the final say. The distributor is
able to do anything, provided that they don't cross some line where they
can still call it "based on OpenSolaris".
Nexenta (sp?) married a gnu userland to a Solaris kernel - a rather
significant product content decision.
The missing context here is that Sun is a potential distributor - one of
many. Sun is talking the OpenSolaris source and modifying it, if they
should choose to do so. One of those choices is if they should deliver
a 32-bit or 64-bit userland.
Maybe it would be helpful if I outlined what I think this project
*should* be doing:
1) Augment the build environment (Makefiles) such that a single
flag/environment variable can toggle all the objects between
32-bit/64-bit. (Obviously, at the per utility level, objects that
aren't 64-bit clean or should only be 32-bit for some other reason,
would ignore this flag until "fixed".)
2) This project, and perhaps others, can go forth and make
whatever objects they want obey this flag.
Note, #1 and #2 are all about the source. There also isn't any
architecture here.
3) Any distribution (where Sun is just one possible distribution)
can set this flag as they see fit.
Note, #3 is all about the binaries and product definition. No
architecture here either.
The project team (Roland) seems to believe that Sun is responsible to
test (or provide test binaries) to check that his project doesn't
regress in the future. It doesn't work that way. Sun (or any
distribution) gets to test in the mode it desires. For over 10 years, I
built a weekly build of Solaris (er, SunOS) and ran some tests which
checked that some things I cared about didn't regress. (That "I" should
be interpreted as "The Joseph Kowalski Project Team".) This and all
project teams should follow this paradigm. If they don't do something
similar, they may be "contributors", but they certainly aren't
"maintainers".
Digression follows:
Perhaps some feel it is too difficult to build in this way. Scripts are
posted (nightly, etc.) which make this easy. Lacking machine
resources? Seems that OpenSolaris could easily find the resources to
build a common build every night, even if it only used machine resources
from individual contributors. (Its the community way). I *suspect* Sun
could provide a couple of medium strength machines to help this.
Consider:
Source -> Binary -> Packages -> Distribution
The first two arrows are trivial. The last arrow is very hard. You
only need the first two to provide a test build which can completely
controlled by the community - no distribution to be seen. (However,
then the various communities can argue about how the flags get set. The
distributions can just sit back and watch the discussions. In this
particular case, I doubt that setting the flag for the test build to be
"64-bit" would not be controversial.)
It is my believe that the fact that OpenSolaris has *everything* leads
many community members to believe they are building a product. They
aren't. In the Linux world, its pretty obvious:
kernel: from linux.org
core userland: from gnu.org
desktop: from gnome.org (or kde, or who
ever)
specialized components: too many to list,
In OpenSolaris, its less obvious:
kernel: from opensolaris.org
core userland: from opensolaris.org
desktop: from opensolaris.org
specialized components: from opensolaris.org
Note that desktop is only from opensolaris.org in name only. Its
basically gnome, with a couple of maintainers working on the Solaris
customizations. There was a big debate as to if there should be
anything gnomish in OpenSolaris. It was decided to to so, only so that
other OpenSolaris communities could get immediate access to Solaris
specific gnome changes without being constrained by release dates
(gnome.org has gone to a 6 month schedule).
- jek3
