Valerie Anne Bubb wrote:
On Fri, 13 Apr 2007, Stephen Hahn wrote:
* Valerie Anne Bubb <[EMAIL PROTECTED]> [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
_______________________________________________
tools-discuss mailing list
[EMAIL PROTECTED]
