Richard Lowe writes: > James Carlson wrote: > > Stephen Hahn writes: > >> descriptions (E7). (I'm also curious about operational requirements > >> about offering the entire community bug corpus, but that's probably > >> separate.) > > > > I don't think it's separate from the DTS requirements at all. > > > > I see offering the raw database itself as a fundamental issue of > > openness. In the same way that we allow others to create independent > > repositories of the OpenSolaris code itself, and thus cover for any > > possible (however unlikely) failure on the part of Sun to deliver in > > the future, we must also provide equivalent access to defect > > tracking. The code and the bug database are not independent. > > Doing that while maintaining the confidentiality aspects could be complex, > depending on backend storage, but I think it's a reasonable requirement too.
I think that complexity is inherent in the underlying problem itself, not in this particular requirement. In other words, suppose that we do have confidential data and that we _don't_ offer raw access to the repository. That implies that this one system somehow stores confidential data from multiple sources (Sun and other distributors), and, although the repository would be operated by at least one entity, that it's somehow trusted not to release the wrong data to the wrong people. How would we operate in that sort of scenario? Is it really reasonable to expect Sun to hand over sensitive customer-related data to some third party? If it's not, then why should other parties hand equivalent information over to Sun or anyone else? I think we do have to have a way to maintain referential integrity between the open bug database and private data stores, but I don't think we can avoid the problem merely by hiding away the raw (open) repository. > > My guess would be that Phase 1 could start right after getting the new > > system running -- perhaps as soon as a few months. Phase 2 would take > > a more substantial switch-over and coordination with other groups that > > are not well-represented in OpenSolaris yet. Perhaps a year or so. > > phase 2 specifies that only bugs present in the new DTS would integrate, but > bugs could be filed to the old one. I'm not sure of the practical benefits > here, given to integrate any bug would have to be copied to the new DTS. > > Where's the benefit? (I'm obviously missing something, I just can't tell what) There's some benefit to Sun, I think, and also some OpenSolaris benefit. The benefit to OpenSolaris is that the new DTS starts working correctly right away, even if it lacks history. The benefit to Sun is that we get a chance to start the presumably long retraining period for the myriad testing and support groups that also file bugs. It won't switch in a day. > > In addition to the initial evaluator list, Bugster associates > > categories (actually subcategories) with responsible managers. The > > theory is that the manager is then responsible for making sure that an > > engineer is eventually assigned. Does the same sort of thing exist > > here (who are the "technology owners?" -- are they the community > > groups?), or do we give up on that concept? > > I think that's a concept that doesn't translate well at all. Maybe. In general, I think it's helpful to know who is "responsible" for a given bit of technology, so that issues with it can be dealt with by something other than broadcast email messages on opensolaris-discuss. This issue has mapped into Bugster as the "responsible manager," and I completely agree that the identical concept is without meaning for OpenSolaris, but I suspect that there's some equivalent that would be just as valuable -- such as "owning community group." > > I'd suggest adding the ability to track problems in private projects > > as one of the requirements. > > Yes, I agree there too depending on precise values "private" (be it > invisible to any but a select group, or only meaningful to a select group, > both are important). "Private" here just means "not yet integrated." I think they ought to be visible and usable by others -- we don't really have secrets among the projects -- but it should be clear that they have nothing to do with the current, integrated source base. You're right that I wasn't clear on that. I'm not advocating for closed project development, or any means to support it. Unlike closed ARC cases, I don't see a need for OpenSolaris to provide any special bug tracking resources for closed projects. The two issues are pretty different. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
