Simon Phipps wrote:
Perhaps, but the difference is that all of the code in the OpenSolaris
codebase has been audited, etc. Whereas all of the content in the bug
database has not. You don't place customer information, confidentially
secured materials, etc. into the OpenSolaris code whereas you do with
the bug database from what I understand.
Agreed, which makes it an even harder problem. And doing legal due
diligence was hard enough as it is.
Despite it being crazy, many other projects have to do exactly this
thing. So I think it is inevitable that a way to manage it will have
to be found.
I don't know of any projects which have come up with a satisfactory
solution for this problem, if there are any I'd be interested to hear
about them.
I agree with Shawn. The issue here is to recognise the difference
between Sun's business and the community's work. Sun will continue to
need a way to track the information flowing from its relationships with
its paying customers, and that system must be private. Sun's staff are
then likely to file bug reports with OpenSolaris.
Filing bug reports isn't a single atomic operation, and the problem with
a split-database situation is deciding which information lives where.
Duplicating all the information in both systems and allowing both to be
read/write is not a practical option, as I said in my original mail.
And even if you think you know where information belongs when you file
the bug, that may change over the lifetime of the bug. You then need to
provide mechanisms for moving information between the two systems in a
controlled manner.
OpenSolaris needs a single, public bug tracking system and Sun then
needs an internal-use-only "overlay" that allows just the
relationship-confidential information to be stored and tracked, linked
to the public bug report that relates to that information.
Bootstrapping the new situation is a big issue, but the need for two
systems doesn't seem likely to go away.
Writing a bug tracking system is hard, much harder than it appears at
first sight. I'm not aware of any existing 'split' bug tracking systems
which means we probably aren't going to be able to find something to do
what we want.
Making Siamese twins out of two existing systems isn't going to work
acceptably either. Existing bug tracking systems will have been written
with the assumption that they are the master repository. Glynn already
pointed out how unsatisfactory this approach is.
You also can't feasibly expect people to use two different applications
to edit a single bug, and you can't weld together two existing systems
which weren't designed from the outset to be used in that way.
Most of the available open source bug tracking systems use a web browser
as the UI, and all such systems that I've used are less than
satisfactory. We tried using a browser interface ourselves when we
migrated from our old bug tracking system, and it was rejected as being
inadequate, which is why we ended up with a Webstart Java UI. I'd be
surprised if any of the existing Web-based bug tracking systems were
adequate for our needs.
And another issue that needs to be addressed - boundary systems. Many
of these are read-write, so we'd need a way of allowing access to the
bug database that didn't involve the use of a GUI. The present Sun
system uses SOAP to provide a set of access operations, we'd probably
need to do the same.
That's not to say this problem can't be solved, but I don't think we are
going to be able to adopt the approach we did to choose a new SCM, i.e.
look at what is available and pick something. In my opinion providing a
bug tracking system for OpenSolaris is going to be way harder and take
way longer than the SCM migration.
--
Alan Burlison
--
_______________________________________________
tools-discuss mailing list
[email protected]
