Alan Coopersmith wrote:
> Garrett D'Amore wrote:
> > We don't have a good fill in replacement for the ON C-Team as far as ON
> > goes right now.
>
> Frankly I'm about two weeks away from proposing to disband and reform the
> ON community, since they still have no forums to hold discussions or votes
> on - I'm just waiting to see if the people who promised to fix that will
> do so once they've gotten back from the holidays. It seems ludicrous to
> begin our election process with the community hosting one of the most
> active parts of our code base not being able to name Core Contributors
> because there's nowhere to discuss naming them.
>
> (Before anyone goes off the deep end, the net effect of such a move would
> simply be the OGB decides to create a forum and names the new leadership
> of the ON community, but the community otherwise stays unchanged - under
> the Constitution we can't take any action to make decisions for the
> community, can only disband the existing one and reform it with the same
> charter/resources/webpages/etc. and a newly specified mailing list.)
>
> > 1) Create a list of projects and processes which currently are Sun
> > internal, that need to be replaced or removed in order to make the
> > process fully open. As part of this list, there should be specific ways
> > that both internal and external folks can help out. A task list, if you
> > will.
>
> Seems reasonable. Off the top of my head, this list would start with:
>
> 1) Bug updating - see #3 in your list
> 2) ARC case submission - see #2 in your list
> 3) Permission to commit - depends on consolidations - for many, large
> projects require a C-Team checklist, but bug fixes/RFE's do not.
> For many, all putbacks require some sort of review (code & process)
> - in ON, this is WebRTI; in X, this is CRT; etc. JDS is the only
> consolidation I know of to have any part of this open, since their
> integration review for putbacks happens on an opensolaris.org mailing
> list, but they still don't have the C-Team checklist for projects open.
> 4) Package Request-to-Integrate - a simple text form submitted to the WOS
> RE when a new package is added to the OS telling them the information
> they need to know to set the right properties in the installer/image
> (Does it need to be in the miniroot? End User or Developer install?
> Does it replace an existing package? etc.) Since this is a text form
> submitted via e-mail, it could be easily published on opensolaris.org.
>
> Someone who has actually done an ON putback would have more insight to any
> ON-specific processes than I do of course.
>
> Of course, Sun employees have to go through a bunch of additional processes
> for Solaris integration that don't necessarily apply to OpenSolaris:
>
> - Legal review - though as long as Sun hosts OpenSolaris.org, it requires
> legal review for anything posted on the site it owns/operates. This
> only applies to sources brought in from outside projects under its own
> license, not those developed for an OpenSolaris community under that
> communities specified license(s) and contributed under a SCA or similar
> agreement.
>
> - Accessibility review - required to verify that Solaris can be sold to
> US government agencies under Sec. 508, or to other customers with
> similar requirements due to laws on general business like the Americans
> with Disabilities Act or to government regulations on government
> purchases in other countries.
>
> - Export control review - making sure that Sun complies with the various
> import & export regulations around the world, mostly around encryption,
> though again, Sun requires this for anything hosted on the site it runs
> as well.
>
> > 2) Formally request that an OpenSolaris ARC be formed, perhaps staffed
> > initially with the PSARC membership,
>
>
>
> > 3) Mandate that the RTI tools be made available outside of SWAN, with a
> > fixed deadline to be decided upon by OGB. This is a key process, and it
> > need not depend on SWAN.
>
> How can the OGB mandate that this happen and impose a deadline? What do
> we do if it's missed? Issue a strongly worded statement that we're unhappy?
> We can't force Sun to assign resources or punish anyone if they're not.
> We can declare that OpenSolaris consolidations cannot require RTI's for
> putbacks until it's outside the firewall, but until the code is outside and
> outside committers are named, Sun can still require its employees to require
> them. Hell, since most of us are employed by Sun, Sun can require us to
> not vote for ignoring their mandated processes if the matter is forced into
> a standoff, so setting up an ultimatum seems liked a doomed strategy.
>
> That said, you might want to pay more attention to tools-discuss:
> http://mail.opensolaris.org/pipermail/tools-discuss/2007-December/007495.html
>
A strongly worded mandate would be better than remaining quiet on it.
Ultimately, the tools we need to manage code commits must be openly
available. One thing OGB can do is form a task group or committee to
work on addressing this need if it appears that a resolution on the Sun
internal tool is not forthcoming.
An OGB that is completely impotent to enact or enforce anything is not
terribly useful, and I think it would be good for all involved if the
OGB became a little more proactive versus reactive. (In other words, I
think we ... by that I mean myself and I believe many other members of
the community ... expect OGB to fill more than just a judicial role for
the community at large.)
-- Garrett
