* 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? 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. - Stephen -- sch at sun.com http://blogs.sun.com/sch/
