So it looks like the ball has started rolling on this one... but this will undoubtedly be a somewhat long process due to the many stakeholders involved.
I think tackling the community/project organisation, and/or cleaning up the core contributor lists should be done in parallel. It's an important task, doesn't involve any stakeholders other than the OpenSolaris community and the OGB, and directly affects governance (which is, after all why the OGB exists). So to get us back on track to Glynn's original thread: let's set a time to have a concall meeting next week and I'd like to propose we make this one of the agenda items we address. Alan noted that a not-completely-awful time would be: 9pm Amsterdam (Casper), 3pm Boston (James), Noon Pacific (Alan, Keith, Myself, Rich), 7am Wellington (Glynn). What days are people available? I can noon pretty much anyday, though I would prefer Monday, Wednesday, or Friday. cheers, steve On Fri, Mar 30, 2007 at 10:15:44AM -0700, Alan Coopersmith wrote: > So the top vote getter from the priorities poll was: > Deploy a public defect management system > > It seems there's two obvious steps to start out with, which can > be done in parallel: > > 1) Have the bugs.opensolaris.org team and the bugster teams > inform us of their plans for making a open bug tracking system. > An e-mail summary would be preferred, but if they want to make > slides to present on a con-call, we could handle that too. > > 2) Decide what we expect in a public defect management system. > > Once we have those we can determine if the best course of action > is to continue to push on the current bugs.os.o/bugster system or > ask the Tools community to turn the list from #2 into software > system requirements and begin evaluating candidates to replace > bugs.os.o. > > Off the top of my head, for #2, I'd start with these requirements, > but expect others to think of more: > > - almost all actions available to any valid OpenSolaris > contributor, whether Sun employee or not, including: > - filing reports > - updating reports > - accepting ownership of reports > > - ability to limit visibility of reports to selected contributors > for a limited time, to allow for keeping security vulnerabilities > embargoed until publication, and for keeping pre-release platform > details embargoed until release (whether those be Sun, Intel, AMD > or any other vendor who may choose to work with the OpenSolaris > community). > > - if not using the Sun internal bug database directly (as bugs.os.o > does now), then the ability to have Sun employees easily clone bugs > from the internal db on a bug-by-bug basis, to migrate data from the > traditional Solaris bug db. I'd rather see this as a simple tool > anyone with access to the Sun bug db can use, so we can split the > load of migrating the data and deciding which parts are clear to > export among hundreds of people - give each a subcat or list of a > few dozen bugs at a time, and use the power of the masses to make > easier work of the impossible-to-automate process of determining > which data is truly confidential and which isn't. > > -- > -Alan Coopersmith- alan.coopersmith at sun.com > Sun Microsystems, Inc. - X Window System Engineering > > _______________________________________________ > ogb-discuss mailing list > ogb-discuss at opensolaris.org > http://opensolaris.org/mailman/listinfo/ogb-discuss -- stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development
