Greg DeKoenigsberg wrote:
More thoughts about this:
What *is* Bugzilla?
First of all, it's a database. It functions reasonably well as a
database, too. We track thousands of components, and all things
considered, it could be a hell of a lot worse.
It's also a UI in front of a database. In this respect, it's pretty
limited -- largely because we treat it as monolithic web UI, and
monolithic web UIs always, always suck in some fundamental way --
especially as complexity grows. I can certainly attest to this from my
days in RHN.
It's also a set of xmlrpc APIs. We don't use this functionality nearly as
well as we could -- but in my opinion, exploiting these APIs is the
future. Ultimately, we'll need lots of different UIs for lots of
different uses, and good APIs are the key to building these.
There were a bunch of key points that came out of a study that some Very
Smart People did in studying our errata and bug reporting process a few
months. Lots of people on this list know what I'm talking about. But
one of the most important things on that list was the concept that
bugzilla has exactly one view of data. Go to a bug and look at it and
you see everything that everyone could possibly care about. Bug flags,
status, what you can do next with it, every comment, every status field,
every possible status. One view that everyone wants to use.
So one of the suggestions was that everyone has their own view of the
data. As a developer I care about different things than QA or even as a
manager, who wants to know what his reports are working on and what his
or who group is responsible for. In the past, when someone wants to
"fix" something in bugzilla, they add another field or another button in
the interface. And that has turned it into something that no one
understands but everyone has to use.
So when you ask "what is it?" I reply "it's everything to everyone."
Certainly on the UI and workflow front, we need some very different
thinking about what it is. It could be so much better than it is.
--Chris
