Multiple databases through a single Bugzilla installation
Spielorjh
After having had Bugzilla installed and running for several months,
the powers that be have noticed that there is only one bug database,
and issues are assigned numbers based on the next number available.
Therefore, as I'm sure you know, Product 1 gets issues 1-4. Product 2
gets 5-10, 1 gets 11, and product 3 gets 12-14, et cetera.
This, they tell me, is Really Bad. They want to be able to query
through SourceSafe and tic off each issue as they find it in the
code-change comments, so that, for example, they can tell that issues
1-500 are all addressed in the code, and they have traceability they
can show the FDA. They want to be able to do this in each product
currently entered into the present Bugzilla environment.
My questions are as follows:
1. Is it possible to have multiple products in a single installation
of Bugzilla, so that each product's issues are numbered sequentially
starting with 1 with no gaps or sharing numbers between projects?
2. If this is not possible in a single database, which I highly
suspect is the case, is it possible to direct each product to a
separate database of its own, while still only having one installation
of Bugzilla?
3. Or, is my only option to have multiple installations of Bugzilla,
each in their own directory with their own databases?
Thank you very much.
Gervase Markham
> After having had Bugzilla installed and running for several months,
> the powers that be have noticed that there is only one bug database,
> and issues are assigned numbers based on the next number available.
> Therefore, as I'm sure you know, Product 1 gets issues 1-4. Product 2
> gets 5-10, 1 gets 11, and product 3 gets 12-14, et cetera.
>
> This, they tell me, is Really Bad.
You should try your hardest to persuade them otherwise. It is Really
Good as soon as you find the first bug that you thought was in Product 1
but is actually in Product 2 (and this could be "code" and "docs", or
anything - it does happen) and you want to move it. It's Really Good as
soon as they want Bugzilla customised in any way, and you only have to
apply that customisation once. It's Really Good because they can't then
get you to customise different ones in different ways. It's Really Good
when you want to upgrade Bugzilla, and only have to upgrade a single
install.
> They want to be able to query
> through SourceSafe and tic off each issue as they find it in the
> code-change comments, so that, for example, they can tell that issues
> 1-500 are all addressed in the code, and they have traceability they
> can show the FDA. They want to be able to do this in each product
> currently entered into the present Bugzilla environment.
FDA? Food and Drug Administration?
As far as I can understand this requirement, surely it could be met by
writing some sensible Bugzilla queries which only included the bugs in a
certain product?
> My questions are as follows:
> 1. Is it possible to have multiple products in a single installation
> of Bugzilla, so that each product's issues are numbered sequentially
> starting with 1 with no gaps or sharing numbers between projects?
No.
> 2. If this is not possible in a single database, which I highly
> suspect is the case, is it possible to direct each product to a
> separate database of its own, while still only having one installation
> of Bugzilla?
No.
> 3. Or, is my only option to have multiple installations of Bugzilla,
> each in their own directory with their own databases?
Yes. And there are a whole load of reasons why this is bad - for you as
an admin, and for your users.
Gerv
Seth Foley
I can testify that it's a pain to keep everything separate, but I've wrung a
few concessions from the QA lead (the guy who actually 'owns' the database,
although he doesn't know anything about Bugzilla or its administration.)
I've written up documents for my co-workers in case I'm out sick and they
need a new database pronto about this. It takes about two hours to do all
the minor tweaks and fixes for each database, and I'll be happy to send the
procedures to you privately if you're interested.
> > My questions are as follows:
> > 1. Is it possible to have multiple products in a single installation
> > of Bugzilla, so that each product's issues are numbered sequentially
> > starting with 1 with no gaps or sharing numbers between projects?
>
> No.
It is technically possible; I've hacked together a test database where I did
this by adding another column as ps_id (project-specific ID), where the
value is incremented according to the last one in that project. It took a
few other changes to buglist.cgi, query,cgi, longlist,cgi, etc so that they
could use URLs with that new ID, but it seems to be somewhat working and
it's still an idea if you can't get around it.
That said, merging CVS diffs is a real pain on customized installs, though
better than trying to do it across six different databases (the current way
we're solving this.)
> > 3. Or, is my only option to have multiple installations of Bugzilla,
> > each in their own directory with their own databases?
>
> Yes. And there are a whole load of reasons why this is bad - for you as
> an admin, and for your users.
Agreed. They're starting to see the light here -- we had a nasty meeting
about it where all of us programmers were screaming that their reasons for
wanting multiple DB's were crap, and all of QA were screaming that bugs
would get lost without sequential numbering. We've since showed them
through a few test projects that their concerns were unfounded, but they
still have a preference for having everything in one project be sequential.
It gets really tiresome adjusting the code for each one -- you have to
separate the cookies so that login prefs aren't stored between databases and
different ones don't reset those cookies; I had to create separate headers
and tweak templates for each installation so that they're visually
distinguishable; and like I mentioned earlier, going to 2.16.3 was not
pretty. I spent about three days with several broken databases before I
figured out what was missing.
Sorry 'bout the nasty sig, required to do on all my work e-mails now ...
Seth Foley, Associate Programmer
RavenWorks - Washington National Guard Center for Courseware Development
Gervase Markham
> this by adding another column as ps_id (project-specific ID),
"No", of course meant "Not without changing a lot of code", which you
appear to have done.
> Agreed. They're starting to see the light here -- we had a nasty meeting
> about it where all of us programmers were screaming that their reasons for
> wanting multiple DB's were crap, and all of QA were screaming that bugs
> would get lost without sequential numbering.
They are obviously used to a bug system with vastly inferior querying
capabilities. :-)
Gerv
Jim Walters
> > about it where all of us programmers were screaming that their reasons for
> > wanting multiple DB's were crap, and all of QA were screaming that bugs
> > would get lost without sequential numbering.
>
> They are obviously used to a bug system with vastly inferior querying
> capabilities. :-)
If you can't convince them non-sequential IDs are OK may want to
consider a custom field for sequential numbering. Might reduce the
amount of work associated with integrating upgrades.
Regards
Jim
__________________________
Jim Walters Director of Technology
Bugopolis, Inc.
phone: +1 206 447 8315
email: ji...@bugopolis.com
web: http://www.bugopolis.com
_________________________
Gervase Markham
> If you can't convince them non-sequential IDs are OK may want to
> consider a custom field for sequential numbering. Might reduce the
> amount of work associated with integrating upgrades.
But two index numbers per bug would be terribly confusing...
Gerv
Lenroc
news:bk3vvc$ok...@ripley.netscape.com...
You could theoretically use a string of letters for the sequential field.
So, bug TRVAAAAA is bug #5689, which affects a certain product, and the next
bug that affects that same product is TRVAAAAB, regardless of it's internal
bug number (could be #7832 for all we care).
--
Lenroc