== What do you want to help out with? ==
We are using a heavily customized version of 2.18 for most of our
internal development bug tracking. We just recently moved from a
PostgreSQL based backend to a MySQL backend mainly for the more robust
replication ability. We hope to continue on our plan to migrate to the
3.x codebase in the next few months. Currently we are working on some
performance optimizations in our current code base to address some
usability concerns with the UI. We are currently pushing some of
Bugzilla's limits in number of products, components, etc. and are
testing new features utilizing Ajax to help speed some parts of the UI.
We host the Fedora project in our instance of Bugzilla and just that
product alone has over 5500 components.
We also utilize a custom XMLRPC API pretty heavily within the company.
Using the API, many of our departments have written custom applications
to help manage their bugs and processes. We are planning on converting
all of our XMLRPC code to the new 3.x WebServices code during our
development and to submit patches for the changes for review.
Also the Ajax functionality will be ported over. We will be working very
hard to make all of these changes as generic as possible and submit all
patches upstream so that they might be incorporated into the mainline
We also hope to improve our interaction with the Bugzilla community in
the coming months. We have several people to help out with Bugzilla now
full-time whereas in the past it has been hard due to resource
restraints to help out as much as we wanted.
== Historical qualifications ==
I have been maintaining our company instance of Bugzilla on and off for
the last 8 years. I originally converted our instance to work on Oracle
for a while in hopes of integrating with our corporate support database.
Then when we came out with our own database product called Red Hat
Database based on PostgreSQL we decided to convert Bugzilla to work with
that where we stayed until recently. I also created our current
Hardware Certification database (https://hardware.redhat.com) which is
using Bugzilla as it's backend with heavily customized templates on
the frontend. I have worked with other departments as well to help
Bugzilla communicate with their tracking tools. Many of our internal
applications also communicate with Bugzilla for single sign on
authentication. I have also spent some of my time working on RHTS ( Red
Hat Test System) which is our automated testing framework for the
distribution. For a stretch I headed up our QA efforts in testing a RHEL
update release which took me away from Bugzilla for a while.
I look forward to working with my team and the Bugzilla community
in the future.
No, but that does look promising for when we go to 3.x. Currently we
just have the
external applications use their respective xmlrpc client to connect to
which simply auths the user and then returns the same cookies that would
be returned if using the
web UI. The calling client caches these cookies or passes them on to the
to the external app. Then when the user connects again to the external
app, it gets the login cookies,
remaps the domain to the Bugzilla server's and calls bugzilla.login()
again (minus any parameters)
which will use the passed cookies. Or they can call any other xmlrpc
method that is exported
using the cookies instead of passing in a username and password.
Jochen Wiedmann wrote:
> On 9/11/07, Dave Lawrence <[hidden email]> wrote:
>> Bugzilla communicate with their tracking tools. Many of our internal
>> applications also communicate with Bugzilla for single sign on
> May I ask, whether you've got something better than mod_authn_bugzilla
> (see bug 392482)? If so, are you interested in sharing it?
David Lawrence, RHCE [hidden email] ------------------------------------
Red Hat, Inc. Web: www.redhat.com
1801 Varsity Drive Raleigh, NC 27606