Garrett D'Amore wrote:
Rich Reynolds wrote:
I have read through the discussion, and this reeks of an opportunity for a high volume code fork...

all the detail is great, but i have a problem with the organizational structure..

I suspect this needs to be a project in device drivers...

I have other reasons for not wanting it to be in that community.

1) this potentially extends well beyond just "device drivers", into platform support and such

so if the ON community can not or will not support a project of this nature then the project MUST be risen to community status.

2) device-drivers is basically a defective community with almost no cohesion and *no* leadership (look at the stale pages for it that haven't changed since 2005)

this could be viewed as a way to invigorate that community, but see above...

3) I think we want CC grants that might deserve representation outside of the normal interests of "device-drivers" -- there are platform support considerations as well, for example


I do see a strong argument for this, which would unfortunately exclude ON as well. I had hopped that the ON community would be the keeper of all technology, but it hasnt worked out that way, as seen by the unhooking of the tadpole tree...<sigh>

That said, I hate the idea of governance getting in the way of things here. Its been pointed out to me that if the governance issues here become too burdensome, maybe the simplest thing to do is post a repository somewhere (not on opensolaris.org) and let those who want to participate do so.

The organizational concerns here should not get in the way of providing a solution to the problem of making drivers and platform support available for those who want it.

   - Garrett


rich


Garrett D'Amore wrote:
Now that Sun has made official moves to de-support certain hardware (and to be fair this is not new ... for example some people have wanted UltraSPARC 1 support for a while now, but now it will be expanded to all SPARC workstations other than U25 and U45), it seems like it might be a good idea if we had a "community supported hardware" group and perhaps a dedicated code base.

What I'm thinking of is:

1) a new consolidation

   * call it CSHW (community supported hardware) for now (other names?)
   * (structured somewhat like ON, but probably considerably simpler)
   * containing platform support and drivers not in ON
   * drivers might also include userland components (X11 modules?)

2) the consolidation would be built "in parallel" to ON

* compile against a checked out copy of the ON source base at the same time.
   * then build 150 of CSHW would also be built against build 150 of ON
   * (and possibly other consolidations such as X?)
* binary distro would only be "correct" if it made up of matching components * don't duplicate what is in ON -- this isn't a "fork", its an extension of ON. * will probably use a much simpler Makefile system without ON's limitations
   * I will offer to set up the initial repo for it.

3) Sun would have no official support for this new consolidation.

   * no support in bugster for this stuff
   * not part of any official Sun distro
   * caveat emptor

4) The "C-Team" for it would be made up of people from the community

   * might or might not be Sun employees (have some thoughts here)
   * majority non-Sun kernel contributors
   * would be Core contributors
   * if you want to be on this list, let me know
   * volunteer gatekeeper and backup gatekeeper
   * use OpenSolaris public systems for doing builds
* builds should not be very resource intensive -- there isn't that much that has to be compiled

5) Initial things I'd think of integrating into it:

   * the Tadpole SPARCLE support I recently yanked from ON
* restored SDcard functionality for SPARC (by simply compiling the ON bits) * drivers for audiocs4281, and perhaps other less popular audio hardware * perhaps "alternative" drivers for LSI "mfi" and "ce" hardware from community authors
   * stp4020 driver (after removal from ON)
   * bpp driver (after removal from ON)
   * other legacy PCMCIA drivers (pcram/pcmem ?!?)
   * platmod support for SPARC workstations as they are removed from ON
   * support for Ultra-1 systems from Rainer
   * perhaps a revived le driver ported from NetBSD?
* perhaps other "architecture ports" ?? This might be trickier than you think!

6) Rules for integration would be far, far looser than ON:

   * code has to compile
   * you have to assert that you have tested it
   * no long term support commitment required
   * no webrti, instead just an e-mail based review/approval for now
   * (what do other consolidations use for rti approval?)
   * code review still required
   * include documentation (man page) as part of integration
   * no ARC approval required
   * can import ON Consolidation Private interfaces
* no duplicates of stuff in ON or other consolidations without justification
   * sign-off by one of the Core Contributors

7) Obviously this would require a new Community Group inside OpenSolaris

* three core contributors needed (need to identify two more besides me)
   * mailing lists and webpages on opensolaris.org
   * code hosted in mercurial on hg.opensolaris.org
   * possibly separate defects.os.o category?  not sure.

I'm willing to start the process on this - including setting up an initial consolidation -- if there is enough other community interest. I need at least two other folks who are willing to act as CC's though. My first nominations on this would be Juergen Keil, Rainer Orth, Steve Stallion, and Jason King. Of course, I've not really verified any of this with them yet; I'm happy to take other suggestions or volunteers.

Note that I'm also willing to volunteer as the initial gatekeeper on this, performing builds, etc.

If I hear the necessary support from the community-at-large and receive confirmation of willingness to volunteer from appropriate CC's, then I'll go ahead and start the process.

   - Garrett

_______________________________________________
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

Reply via email to