* Valerie Anne Bubb <Valerie.Bubb at sun.com> [2007-04-13 17:26]: > 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: > > 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. It's pretty evident that this scenario can happen inside a single bug database, if the second submitter and/or the evaluating engineers fail to search the set of bugs prior to taking one or more actions. Thus, my question about specific operations, since a search operation that spans databases is a technically achievable outcome (and I expect that operations supporting construction of up-to-date searchable corpora will be a requirement of any new system). Are there other operations adversely affected by segmentation?
> 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). A distribution-specific problem, and not really gating the OpenSolaris Community's efforts. Certainly a problem for Solaris (and if also a problem for other distributions, then something to explore for potential requirements). > > 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) In the bug/issue systems that attempt to differentiate between local and upstream bugs, the link transmits information (state modifications, relevant timestamps, release information) beyond a reference count. Systems that only do "see also" assert all connections between bugs are of equal significance; information is being excluded from the system, since that assertion is false. - Stephen -- sch at sun.com http://blogs.sun.com/sch/
