Garrett D'Amore <garrett at damore.org> writes: > Darren Reed wrote: >> John Plocher wrote: >> >> >>> Darren Reed wrote: >>> >>> >>>> ie. Instead of trying to get part of bugster out of Sun, create >>>> a new bug reporting database >>>> >>> The dealbreaker for me is that there is no easy way to initially >>> populate this new database with the hundreds of thousands of open >>> bugs/rfes already in bugster, which effectively means that nobody >>> without bugster access will be able to fix/manage bugs, and if they >>> have bugster access, they have no need to use something else... >>> >> >> >> So OpenSolaris starts with a clean slate. >> What's wrong with that? :) >> >> This can only work in OpenSolaris' favour: it'll have less bugs >> than Solaris ;-) >> >> And if there is a desire to import bugster information later, just >> reserve some number space for that and start at some other >> place for OpenSolaris. >> > > Here's a suggestion for what I think is a better/simpler idea. > > Populate the existing bugs into the new database, but only copy over the > CR #, status, priority, severity and synopsis by default. I don't think > taken individually, any of those things give up proprietary > information. (Anyone who puts confidential information in the > *synopsis* deserves to be thrown into one of Roland's proverbial > komodo-dragon-filled-pits.)
I was thinking earlier that other than the technology to do it, there's no barrier to copying out any visible (via the current b.o.o) field, from any currently visible bug. We can see it now, after all... > Then include a "button" (perhaps enabled by a special keyword, > "master-in-bugster" or somesuch) that internal Sun folks can use to > selectively import details (vetting by hand) from "old" bugster. I'm not sure this can be automated any better than suggesting they cut/paste as they need to. I'm not sure how well that'd work in practice. The important, thing, I think, is to make sure we have a firm cutoff after which the new system is the master and the old shouldn't be (and effectively can't be) used. > Basically, lazy population of most of the data fields is what I'm > suggesting. I agree, for data that's not currently displayed it'll need to be a process of manual vetting. I'm not sure how easy it will be to encourage people to actually do it, though. > Its not perfect, but I think it could solve at least some of the > problems. But of course, it will require "effort" from someone to write > the populate/transfer tool. And that person's not me. (And yes, talk > is cheap. :-) And so are the electrons that delivered this message... I don't know how data is stored now, but I don't *think* it would be that painful (worse case, we can scrape b.o.o for it, or dig it out of whatever amended data b.o.o is backed by.). (if we're going to diverge into the DTS, this really should be on tools-discuss at ...) -- Rich
