On Wed, Oct 28, 2009 at 2:20 PM, James Carlson <carls...@workingcode.com> 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? > > 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".) > > 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 ...) > >>> 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. > > 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? > > 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.
I'll throw out one real life example. The cassini chipset is still in very widespread use, the ce driver is closed. It is not GLDv3 compliant. My understanding is the responsible people in Sun for it have no intention to update it to GLDv3, open source it, nor will they allow anyone else (with suitable threats to prevent anyone with a Sun badge from ignoring them) to integrate a suitable replacement in ON, regardless of the desire of the rest of the community (or even potentially other parts of Sun). > >>> 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. > > 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? > > -- > James Carlson 42.703N 71.076W <carls...@workingcode.com> > _______________________________________________ > opensolaris-code mailing list > opensolaris-code@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/opensolaris-code > _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
