Garrett D'Amore wrote: > James Carlson wrote: >> 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.
It sounds like that's the problem that ought to be fixed. In other words, I think we're mostly agreed that the process ON has (excluding any management-meddling part) is mostly good, and keeps the dragons at bay. So why is this new consolidation different in that respect as well? I believe that's no accident. >> 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. Does it include pseudo-drivers, or only real bona-fide "hardware" drivers? So, when my driver requires ON-wide changes (no matter how small), am I forced into ON? Or do I fork yet another mini-consolidation? > I don't expect Sun to go into this consolidation looking for stuff to > integrate. Really? I expect this thing to be a dumping ground for one-off and mostly half-baked but still quite necessary x86 drivers. And when the next f*(&^%*(&^ SAS chipset comes down the pike, the only usable driver will be available here -- and not in ON and not in OpenSolaris. In fact, if I were a Sun employee, I'd strongly consider delivering here rather than in ON. Process is a drag. > 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. Early access is a problem that can be solved in ways other than creating a consolidation, I think. Just creating a project for the new driver and having a convenient way to publish fresh bits to /contrib would solve that problem. Heck, that'd solve many problems besides just drivers, and it's something the IPS folks want to see solved! > >> 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. I don't believe I have made that assumption. Mostly because I believe the opposite: it's hard to get into ON. And that's not all a bad thing. >> 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? And when VM and dtrace and ZFS and others in ON make optimizations that are either inapplicable or just downright incompatible with UltraSPARC 1, what exactly will you do? That was a very big part of the reason for shutting down UltraSPARC 1: to make things easier on those other project teams, so that they don't have to lug around the burden of long-dead hardware. And that brings me right back to my original point: you're not considering system architecture here, and what you're proposing may not be doable over the long term, except for trivial things such as monolithic and GLDv2-based Ethernet drivers. That's not a "consolidation," as it lacks coherent management. > 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 wish we had a better way to let them choose what they want out of the existing consolidations. Then we wouldn't see driver writers threatening to take their ball and go home. > 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). That sounds like "unintegrated project," and not "consolidation" to me. >> 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. So, if I don't care about (1), but the distributors do, then I'm still free to avoid ON and take the cheap way out, right? >> 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. I don't think so. I think it's worse than you imagine. ;-} > 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. So what's the justification of an "alternate" driver? Is that not a fork? > 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. If I don't like ON's rules and I'm writing a framework component, then it sounds like I need to create a third alternative for me and my buddies. :-/ > * 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* Create a project for your driver. Projects need not ever integrate. If they do, that's great. But they don't have to. Unintegrated projects can (and should) be allowed to deliver bits into distributions. In fact, they do this *today* -- IPS delivers via OpenSolaris. That model sounds to me nearly ideal for drivers. > 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. All I see are problems moving around, and extra work being added to manage a very loose (and not consolidated) set of sources. It's a CINO; a consolidation in name only. -- 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
