Alan Coopersmith wrote: > Mark Martin wrote: >> Anyone else think it prudent to contemplate a migration from bugs.os.o >> to defect.os.o for SMF? > > You could copy the bugs out to defect.os.o, but until WebRTI and the ON > gatekeeper tools are fixed to work with bugzilla bugs as well, you'd have > to keep the old bug database versions as well, or you'd block ON putbacks > for fixes to those bugs. SMF bugs are also more likely than website bugs > to have confidential customer information or other details in that won't be > migratable.
Yep, unfortunately. It'd be a really big burden on Sun folks who work regularly with SMF to do the level of manual sycing currently required to consistently move d.o.o bugs back into bugster so that we could navigate the day-to-day process. I'm not really even sure it's really possible, as we'd have different sets of folks filing bugs in both locations for a while still. Project gates can and should track their stuff on d.o.o. (e.g. If I had some time to work on smf-doc, I'd be tracking issues through d.o.o, not bugster.) I'm also happy to help be a guinea pig for early processes/tools to migrate general OpenSolaris issues to d.o.o. However, until there's buy-in from the ON community and at least initial integration with the ON tools to make it feasible for people to keep getting work done, I'm not convinced it's prudent. (We also have to work with the internal Sun tools that support and sustaining engineers have to use, since most of our bugs also apply to pre-Nevada releases. That'll be a big hurdle too, but it's irrelevant if OpenSolaris ON still requires bugs to be in bugster and less interesting to the OpenSolaris community.) After we've got direct contributions to ON enabled, and webRTI access through osol.org, the inability for community members to edit bugs is going to be a huge tools hurdle. (Bug voting would rock, too!) If you've got some cycles, Mark, maybe it's worthwhile to talk with the ON community and tools folks to make sure that integration with d.o.o is on their technical roadmap, and possibly even help them out with that piece if it interests you. I do want to ensure that the SMF community stays at the forefront of allowing and encouraging quality contributions from both inside and outside of Sun. Any ongoing suggestions or help in making that possible without sacrificing too much day-to-day efficiency should definitely be raised here. liane
