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? > > 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. >
One of the biggest here (and something I've ranted about numerous times before) is this. I don't feel OpenSolaris bug tracking should continue to be retarded by the needs of one distributor's releases (and especially their prior, unrelated releases). So while it would be great to be able to support data migration seamlessly (the same for call records and such, too), I'm entirely against any kind of limitations on the open side induced by such things. (Not that I'm suggesting that this is what was being proposed, consider it a more general comment) -- Rich
