On Wed, Oct 28, 2009 at 12:25 PM, Randy Fishel <randy.fishel at sun.com> wrote:

>
>  +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-discuss at opensolaris.org
> > http://mail.opensolaris.org/mailman/listinfo/driver-discuss
> >
> _______________________________________________
> on-discuss mailing list
> on-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/on-discuss
>

Nice Garrett! +1

-- 
Cheers,

Steven
-----------------------
Steven Acres
Toronto OpenSolaris User Group <TOROSUG>
Leader
http://opensolaris.org/os/project/torosug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.opensolaris.org/pipermail/on-discuss/attachments/20091028/778a11c0/attachment-0001.html>

Reply via email to