+1 (and long overdue)
I have trivial suggestions, such as the ability to build and package
a single component (this, and others could be discussed within the
community), but the bulk of the proposal seems sound to me.
---- Randy
On Wed, 28 Oct 2009, 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
>
> _______________________________________________
> driver-discuss mailing list
> driver-disc...@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
