Hi, I can understand the current limitations of the website, and the approach to opening up the existing cases - not sure I have anything to add to that discussion, however I am interested in what happens after...
John Plocher wrote: > 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, > [snip] > > 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, So I guess this is the single big issue - how do we separate what should be reviewed in the public, as opposed to internally within Sun. I wonder how much of the various ARCs [and I assume for this conversation we can just say LARC and PSARC, right?] current and previous cases are dealing with open source software? How much of it do we expect to keep internal? If those numbers are high and low respetively, then it's clear that open source should be the driver in any new process. > 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. One way of potentially doing this is just to subscribe a set of internal aliases to the opensolaris lists, and mark them as 'read only' - if only for the purposes of the various mail filters, and encourage people to contribute on the public lists. Then other non-public discussion can continue on the existing internal aliases where necessary. The various -EXT or NEWPROJECT aliases sounds a little overkill, though admittedly I'm not quite sure I have a handle on the various issues. Darren's suggest may be worthy of some thought too. Glynn
