ARC Project Task 4
From Genunix
Back to Opening the ARC Process
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@sun.com for arc[-discuss]@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:
- The need to keep the existing (Sun internal) ARC process functioning smoothly for all the non-opensolaris things that Sun does,
- 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)
- The difficulty of creating automation *on* the opensolaris site itself, and
- The requirement to not violate Sun's internal network security policies.
Contents |
Sub Tasks
A. We need a way to tie into the existing automated ARC tool infrastructure.
Since creating infrastructure on OS.o is effectively impossible, and the ARC process requires significant automation (mail handling, archiving, workflow management, statistics and reports, etc), we need to be able to leverage off of the existing SAC tools if possible.
An easy way to do this is to create a new, parallel ARC (aka PSARC-EXT) that is tied into all the infrastructure and tools, but gets its membership rosters from the community.
See ARC Project Task 4A Detail for details of what this infrastructure looks like today.
Plan
- Create a new set of these aliases with -EXT@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@opensolaris.org
- Set up NetAdmin to allow 'postings to these aliases from the Internet'.
- Figure out how to manage SPAM and interactions with the OS.o jive forums.
B. We need a way for the community to initiate ARC cases
This includes fasttracks and full review projects.
Plan
- Create one-pager-ext@sun.com that filters incoming onepager templates and tags them with a "contents are open source" tag and then sends them 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 these aliases
Going native on OpenSolaris.Org means answering a few questions:
- How do I create a new ARC case
Creating a new case today means sending a proposal to an alias called one-pager, where it is digested by some mail filtering code and assigned a case number. At a minimum, we need an OS.o alias that connects to it.
- How do I talk about ARC stuff?
As things stand today, we have two aliases on OpenSolaris today:I am assuming that the opensolaris-arc alias could become the OpenSolaris equivalent of Sun's PSARC alias, though the choice of name isn't set in stone.
- arc-discuss - this alias
- opensolaris-arc - the other one :-)
- How do I join the ARC discussions?
We will need to create additional infrastructure to support this in a natural manner (i.e., the core contributer role holders of all the OS.o communities as well as the current PSARC members and interns should all be auto-subscribed to this alias...) We should also set things up so that arc community observers automatically get added to the -interest alias so that they can observe the ARC discussions as they happen. If possible, the core (or all?) contributers from the originating OpenSolaris.Project should also be included in mail related to their project. The SunARC infrastructure does this by looking for case numbers in the Subject: line and using that info to select additional interest lists. The above easily solves the "how do I subscribe" question - you don't. At least, not explicitly. You become an ARC member by virtue of being selected as a core contributer in your community, or you choose to observe the ARC community, and thus become an observer. Bootstrapping all this will require adding Sun ARC members/interns to these lists, but that can be done with today's infrastructure (presuming that the "can't post unless you are specifically subscribed" bug is fixed, since most Sun ARC members/interns will not (and probably should not) be subscribed to the OpenSolaris ARC mailman list...)
Plan
- Create NEWPROJECT@OpenSolaris.org that points to one-pager-EXT@sun (pick a better name?)
- Pick a name for the opensolaris ARC (and replace the PSARC-EXT references below with it)
- Create PSARC-EXT (etc)@OpenSolaris.org and have them point to the @Sun versions
- Create a set of interest aliases (agendas, opinions, new cases)
- cogitate about how to tie all this into some sort of RSS scheme...
D. Need to involve the right people
We need to figure out how to identify and include all core contributers to all the OS.o projects, because it is they who are the real ARC members. 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".
Plan
- Have the OS.o people create a mechanism for identifying the set of all communities
- Have the OS.o people create a mechanism for identifying the set of core contributers for each community (i.e., an alias in each community)
- Have the OS.o team create a dynamic alias that expands to include the core contributers from all communities (i.e, the OS.o ARC members)
- Create sac-review-ext@Sun, have it reference both the set of sac-review subscribers and the set of all OS.o core contributers
E. Per case email logs
We need to figure out if/how we want to deploy the per-case email logging feature out on OS.o, or if we simply want to have the sac perl::Mechanize tools create and manage "hypermail" copies itself.
