The b.o.o. team is not working on a bug tracking system. Their responsibility lies in making a bug gateway to bugster; so I don't think we need to talk to them.
AFAIK, the bugster team has not shown in prior interest in an open bug tracking system. At this point, I think it'd be easier for the OpenSolaris community to just forget opening Bugster and move to a new open bug tracking system. So given the options you listed below, I'd say save ourselves the heartburn and skip #1 entirely and just go straight to #2. cheers, steve 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. > -- stephen lau // stevel at sun.com | 650.786.0845 | http://whacked.net opensolaris // solaris kernel development
