[Note that I Bcc'd Sun's internal "All ARC members" alias. If you
are getting this email because you are on that alias and you wish to
participate in this discussion, you will need to subscribe to the
OpenSolaris ARC community alias "arc-discuss at opensolaris.org".
How do you subscribe?
Send an empty email to arc-discuss-subscribe at opensolaris.org.
or
Visit the web forum that mirrors the email at
http://www.opensolaris.org/jive/forum.jspa?forumID=92
-John]
Richard Lowe wrote:
> I'd even suggest that it'd be far better (in future, obviously) to use
> exactly the same documentation on both sides of fence
Amen! See
http://www.opensolaris.org/os/community/arc/arc-faq/arc-publish-historical-checklist/
for a list of "edits" that we are obligated to do on archived
historical content. It is obviously in all our best interests to
minimize the quantity of new stuff that comes under those publishing
rules. Towards that end, we (in general, Sun's ARC people; in
particular, Eric Boutilier, Claude Noshpitz, Danek Duvall and myself)
are working on a 12^^H^H 4 step plan:
Opening the ARC process - A Proposal
Goal: The existing ARC process and its OpenSolaris bound
projects and artifacts needs to be both observable
and usable by external members of the OpenSolaris
community.
Tasks:
Task 1: Publish content of selected historical ARC cases
Iterate as requested.
Done. "some" material from the following cases
has been manually collected, redacted, folded and
mutilated:
1991/031/ 1992/059/ 1993/226/ 1999/289/
1991/061/ 1999/645/
2001/313/ 2004/471/ 2005/220/ 2006/030/
2001/679/ 2004/472/ 2005/378/ 2006/062/
2002/240/ 2004/532/ 2005/441/ 2006/082/
2003/172/ 2004/620/ 2005/485/ 2006/134/
2003/687/ 2004/652/ 2005/711/ 2006/153/
2003/690/ 2004/770/ 2006/163/
2006/269/
2006/307/
2006/369/
This effort has shown us that it is extremely labor
intensive to manually publish archived materials.
Task 2: Publish synopsises of historical ARC cases
Need to decide what the synopsis should contain
(name, casenumber, date, status) and what cases
to expose (all, open, how to differentiate?)
as Glynn Foster wrote:
> While it's certainly encouraging ... to see
> detailed listings like -
>
> http://www.opensolaris.org/os/community/arc/caselog/testbed/
The various pages (1991, 1992... 2006) under this
testbed are my current attempt at this, trying to
balance the desire for "as much info as possible"
against the scalability constraints brought on by
"having over 5000 archived ARC cases".
We are still working with Derek to figure out how to
present this much information without causing the website
to blow out the left hand nav structure on every ARC
community page.
The current "simple pages" will replace the existing
"TBD" pages under arc/caselog/yyyy this week.
Task 3: Publish content of the 240-ish ARC cases that
have integrated into OpenSolaris-ON and are referenced
by the ONNV Flagday pages. Also include the content
from the above manually produced pages so we don't regress.
This is the other part of the effort - Danek has
identified about 240 ARC cases that have put back
into OpenSolaris. As such, we have more latitude
about the information we can publish about them.
At a minimum, I am trying to publish timeline
and contact information about each case with the
option for the various project teams to self-cleanup
their materials (see above link) so the publishing
script can auto update the opensolaris arc community
arc case web pages.
This also pushes us into the nav bar explosion problem.
This should also be done this week, with the testbed replacing
the existing caselog pages produced by task1 above.
For examples, see the links to individual cases
on the above testbed "year-by-year" pages, or try out
these cherry-picked ones:
http://www.opensolaris.org/os/community/arc/caselog/testbed/1991/031/
http://www.opensolaris.org/os/community/arc/caselog/testbed/1991/061/
http://www.opensolaris.org/os/community/arc/caselog/testbed/2005/220/
This task is ripe for additional work, gated by
the above balance of automatic -vs- manual work.
Task 4: Create a set of aliases and SAC infrastructure
that will allow participation in ARC reviews by
internal and external contributers.
This is the real goal - as Glynn and Rich (and others) said,
> are we getting to a point where we can substitute
> psarc/lsarc at sun.com for arc[-discu...@opensolaris.org?
This is where I need help coming up with a plan that is
complete enough to be doable in the next month without
being so grandiose or disruptive that it fails.
The following is an incomplete list of what I think needs
to be done from where we are today. It tries to balance the
following disjoint goals:
o The need to keep the existing (Sun internal) ARC process
functioning smoothly for all the non-opensolaris things
that Sun does,
o The desire to have a smooth transition from internal-only
to shared parallel processes to completely external ARC
processes (with a focus on getting to the 2nd stage)
o The difficulty of creating automation *on* the opensolaris
site itself, and
o The requirement to not violate Sun's internal network
security policies.
A. We need a way to communicate that ties into the
existing automated ARC tool infrastructure. This
includes a bunch of convenience aliases that are
backed by custom mail filters that direct the mail
based on case numbers found in the Subject line.
Create a new set of these aliases with -EXT at sun.com
to comply with Sun's net security policy.
Populate rosters with existing PSARC
members, interns, licensees and interest,
as well as arc-discuss at opensolaris.org
NetAdmin needs to allow 'postings to these
aliases from the Internet'. Need to figure out
how to manage SPAM and interactions with the
jive forums.
B. We need a way for the community to initiate
fasttracks and full review projects.
Create one-pager-ext at sun.com that filters
incoming onepager templates and tags them
with a "contents are open source" tag
and sends on to SAC's existing onepager
processing toolchain. Modify the rest of said
toolchain to know about "open" cases and the
OS.o connection.
Worry about the architecture of what is being done
so that other open projects that are not part of
opensolaris can still tie into this open ARC
infrastructure.
C. We need to make OS.o the host for all
these new OpenSolaris ARC related aliases.
Create NEWPROJECT at OpenSolaris.org that
points to one-pager-EXT at sun (pick a
better name?)
Create PSARC-EXT (etc)@OpenSolaris.org,
have them point to the @Sun versions
Create a set of interest aliases (agendas,
opinions, new cases) and cogitate about how
to tie into some sort of RSS scheme...
D. Today, an approved ARC cases draft opinion gets
reviewed by the ARC that reviewed the case, and then
is peer reviewed by all the extended ARC membership.
This email-only exercise is called "sac-review".
We need to figure out the logistics and
mechanics of doing sac-review of an "open"
case without running afoul of the "mail going
outside of Sun" net security restrictions.
E. Figure out if/how we want to deploy
the per-case email logging feature out
on OS.o.
-John
