James Carlson wrote:
Garrett D'Amore wrote:
James Carlson wrote:
Garrett D'Amore wrote:
Shawn Walker wrote:
This is the sort of project that needs to stay in sync with whatever
the ON community is doing so they can be aware of big gate or process
changes, and so that they can work together.
I don't like the idea of making this project formally subservient to the
ON Core Contributors (who are ultimately also its C-Team). The point of
this consolidation is to deal with stuff that has been *excluded*
from ON.
Does this mean that the new consolidation has some sort of a "first
refusal" agreement with ON? In other words, can you (or "should you")
deliver via the new consolidation without bothering to see whether ON
would reject you, or do you have to apply to ON first?
I'd not anticipate any such requirement. Application to ON would be
required only if you wanted to be part of any official Sun release. If
you don't care, you can contribute here.
And yet elsewhere you wrote:
The idea here is not to compete with ON, but to provide an
*alternative* when getting into ON is unrealistic.
Does that imply that Sun never pulls bits from this consolidation? Even
if they're good bits that people want?
Whether Sun pulls or not is up to Sun. The point is that Sun's business
needs don't get to determine the rules for integration into this
consolidation.
Why are drivers in particular special in this regard? What about people
wanting to deliver base OS applications that ON doesn't want? Can they
also integrate code into this alternate ON? (E.g., consider replacing
ksh93 with "some-person's-name-sh".)
I'd like to keep this focused on drivers. Drivers (and platform
support) are special because they might be needed at early boot, and a
common consolidation is the best way to deliver this for use by other
distros.
Non-drivers can integrate via /contrib now.
What about changes that span across kernel interfaces, such as alternate
file systems or networking protocols? What about common kernel
components that are in use by multiple drivers?
These are the sorts of issues that a unified consolidation deals with.
Even if this is limited to "just" drivers, I think that the boundaries
are badly drawn. The future (to me) looks like a bunch of make-work
projects that involve "integrating" individual cherry-picked drivers
from this consolidation into ON. (I guess if there isn't time to do it
right the first time, there's always time to do it over ...)
When a driver integrates into ON, I'd expect we'd remove it from this
consolidation.
I don't expect Sun to go into this consolidation looking for stuff to
integrate. I do think some drivers might come here *first* before
they're ready to make the commitments that ON requires, and eventually
later integrate into ON. Yeah, its more work. But the payoff here is
potentially an early access to the bits for end users.
I think part of the goodness of the consolidations that feed into the
OpenSolaris distribution is that the software is made easily available.
It's all packaged up and shipped properly. Thus, having projects that
might consider this new consolidation deliver though an established
consolidation instead, all else being equal, would be a good thing for
all users and should be encouraged.
You are assuming that OpenSolaris is the One True Distribution. I'm
contending that this is not necessarily the case. This consolidation is
for stuff that won't be delivered via that mechanism.
The folks who designed the OpenSolaris distribution have said (on more
than one occasion) that the intention was to create a set of software
that forms at least the _base_ of every OpenSolaris derivative. I
believe that to be true.
That may be their intent. But its still mostly a Sun-determined
playground, and that's the
problem. If someone wants to deliver something that the Sun powers
don't want to support, then too bad.
I agree that this leaves open the possibility that others may deliver in
ways that don't get included in that distribution, but isn't it
_obvious_ that integrating into the OpenSolaris distribution
(particularly by way of ON) is a *guarantee* that the project in
question is widely-available?
It is. But you keep making this assumption that its easy to get into ON.
That's the point I'm making. If the driver is good, and everybody wants
it, then having it in the base OS rather than camping out in an
architecturally questionable (private interface stretching) home
directory consolidation would be a benefit for all -- including other
distributions.
"Everybody" is subjective. Case in point : UltraSPARC 1. Lots of
people want it. Lots more people think its pointless at this late date,
and Sun doesn't want it in ON because they don't want to support it
anymore (for good reason, actually!)
Who's right?
My point is that by making this available, we don't have to force the
question. Let the users, and the distribution builders choose what they
want.
I guess I should clarify here -- I don't expect anything in this
distribution to "mainstream". It might be stuff that once was
mainstream, but at the time of integration into CSHW, it will almost
certainly represent bits that are believed (by Sun at least) not to be
mainstream (or bits for hardware that might be mainstream, but for which
the driver is simply not yet mainstream ready).
How exactly do the products of this consolidation's work get
distributed? And how does this consolidation encourage folks to do
things with longer-term benefits?
The intent here is to allow other distros (e.g. Milax, Nexenta,
whatever) have access to hardware support that they can't get from ON.
Binary distribution is a matter for the distribution folks... like ON,
this is just a source repo. (Sure we'll have nightly builds, so you can
download bits, and we might deliver some stuff into /contrib via IPS or
some other repo, but to really be useful I expect much of this stuff
will have to be built into an install media.)
Yes, I understand that. But the apparent need to do away with ON's
process as an integral part of the proposal means that this really is
something other than "just" a source repo. It's a competing universe.
My question is how project teams should choose between the two universes
and whether this new consolidation would ever reject a proposed
contribution.
I suppose rejections will happen far less frequently than ON does. Its
a simple question, really:
1) If you want to be on the "standard" installs, and pretty much
deployed everywhere, try for ON.
2) If your bits are much more limited in interest, or you can't get
agreement to get them into ON, then CSHW is your route forward.
Suppose I decided to rewrite Nemo and proposed that I toss the results
into this new consolidation. Would you accept or reject such a plan
because of its overlaps with ON?
You've already said you'd accept competing or "alternative" drivers, so
where is the line?
I think you're trying to make the problem worse than it should be.
As Nemo represents a common "framework", and such changes really do
belong in ON, I think my first reaction would be to reject this
particular instance. It mostly violates the "duplicated functionality"
that I already described in my original proposal.
That it is not to say that we would never reject such a proposal -- if
the sponsor could justify why this was necessary and useful, and why
delivery through ON was not practical, the CCs might agree to it. But
it would require fairly extenuating circumstances, and right now I can't
think of any reason we'd do this.
Conversely, if you wrote a new framework to support a new type of I/O
(or an old one!) -- imagine bus support for VME (or reviving ISA
support) for example -- then I could more easily see that coming in here.
Let me say one more thing, for the benefit of folks who see no point in
this project:
* if significant community members decide that they want continued
support for some piece of hardware -- lets say cg6 for example -- how do
you believe they should proceed?
a) try to get into ON -- fail because Sun won't do it
b) try another consolidation? Which one? (This is why I'm
proposing CSHW).
c) give up. that's the only option available *today*
Again, I'm trying to *solve* problems here, not create them. If I can't
solve them in the context of the OpenSolaris community, then I'll do it
elsewhere.
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
