Valerie Anne Bubb wrote: > 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.
I'm not sure "all data lives in bugster" is acceptable either, assuming that data would thus be locked up within Sun. > 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. Separate databases are antithetical to OpenSolaris, we are one community of developers, all working on the same thing. A key requirement is that *everyone* uses the same database, interfaces, and everything else. So while in the separate systems scheme of things, this may be a problem, given that the scheme itself is unacceptable, I don't think it could ever become an issue. > 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. That is not just "The right answer" it is an absolute requirement both for the system and for truly open development. > 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). Adjust the internal systems to be able to make detailed reference to bugs from the real (external, open) bug tracker seems like it would work. Management of prior releases is something Sun would have to come up with a method to deal with. -- Rich
