On Fri, 13 Apr 2007, Stephen Hahn wrote: > * Valerie Anne Bubb <Valerie.Bubb at sun.com> [2007-04-13 17:04]: >> On Sat, 31 Mar 2007, Paul Jakma wrote: >> >>> On Fri, 30 Mar 2007, Alan Coopersmith wrote: >>> >>>> The thoughts currently bouncing around my head are that we'll have the >>>> bug db for OpenSolaris outside, and when a bug needs to be backported >>>> into S10 or earlier releases, it will be filed in the internal bug db as >>>> a placeholder with a description something like "See >>>> http://bugs.opensolaris.org/query?bugid=XXXXXXX"; for the internal >>>> escalation/patch tools to work off. >>> >>> Some of the open-source bug DBs have explicit support for tracking >>> external bugs, e.g. where some 'distro' tracks a bug in the DB of some >>> 'upstream' provider of a software component in that distro. >>> >>> Theoretically adaptable to integrate with bugster, obviously... >> >> In the past (and possibly even currently?) we've had a bugzilla->bugster >> bug bridge for other products in Sun. That is certainly one option we can >> look at. My main concern is that the data not get segmented across >> databases. >> >> Due to the way our source "grows", a bug found in OpenSolaris is >> likely also in S10 (and vice versa). Keeping the data connected would >> be a good thing for Sun's customers, internal and external developers. >> That way, the information can be shared between folks working on >> different releases - no need to reinvent the wheel for each release. > > Which operations are affected by "segmentation" in this picture? That > is, when would the connections be preserved and when would they be > lost?
The bug bridges that have been done in the past (which weren't for solaris, so I am not familiar with all the details) were read-only, so all data still lived in bugster. Obviously, read-only won't be acceptable for bugs for OpenSolaris (we already have that now with b.o.o.), but it is an idea we could pursue. My reason for not wanting completely separate and disconnected databases should be obvious: * bug is found in OpenSolaris by community member, filed in external database * by happenstance, same bug is found internally to Sun & filed in bugster * Two engineers (one internal, one external) pick up the bug, possibly spending weeks working on a solution. The bugs would have a different number & different synopsis, which would cause delays in recognizing the same problem was being worked by two different groups. Seems like it would be a severe waste of effort by one person. Perhaps the right answer is that all Solaris bugs be tracked in an external database. Then we have problems with our older releases that for the time being we still must maintain & support, and as I noted before, the various releases are very likely to have common bugs (esp with the current trend of putting many features into the s10 updates). > Paul's mentioned an aspect I think is particularly important (and much > more informative than vanilla "see also" fields), given the changing > mix between software written by OpenSolaris developers and software > integrated by OpenSolaris developers. Please elaborate. I've been home all week with a head cold of nasty proportions, so that may be my problem - but I just don't grok the above. Perhaps I didn't fully understand what Paul was talking about (what I *thought* he was talking about was something very similar to a see-also, but that linked between databases) Valerie -- Valerie Bubb, http://blogs.sun.com/bubbva Solaris Security Technologies, Developer, Sun Microsystems, Inc. 17 Network Circle, Menlo Park, CA, 94025. 650-786-0461
