QA/Bugzilla/Administration

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

This page provides some information about the Administration of Bugzilla.

Introduction

If you have additional information, please document the steps carefully here.

Administrators

Need account help? Want to be added to the 'contributors' group so you can prioritize bugs? Please contact one of the primary admins via email or IRC:

Admin	Email	IRC nick
Xisco Fauli	xiscofauli @ libreoffice dOt org	x1sc0
Joel Madero		jmadero
Florian Reisinger		reisi007
Buovjaga		buovjaga
Tommy		tommy27
Christian Lohmaier		cloph
Joren De Cuyper		jorendc
Alex Werner		awerner

(Admins Only: The complete list of Bugzilla Administrators is available here)

Deleting Attachments

In some very rare instances, we may need to delete attachments from Bugzilla.

We don't have a formal policy in place yet, but given that we provide users with multiple warnings about the license terms and public nature of attachments, we're only going to remove attachments if absolutely required.

Before deleting an attachment, please check the following:

The request is coming from the same user who uploaded the document, or the clear rights-holder
The attachment is not being referenced in other bug reports
- This is important because we don't want to 'pull the rug out' from under other bugs and QA activity in Bugzilla

Gardening

Like thatching a lawn or pruning an orchard, it's important to do some periodic maintenance on our Bugzilla install lest it become overgrown, tangled, and unusable by QA or developers:

QA/Bugzilla/Gardening

Deleting Bugs

Bugs for deletion need to have the component 'deletionrequest'.

Actually deleting them

Go through the list linked above and confirm that everything really needs to be deleted.
- Often random bugs will show up with this component, and my general rule is that only bugs *clearly created for testing purposes* should be deleted.
  - If a bug is invalid and bad, we can just leave it in that state for now.
  - (If we end up with thousands and thousands of invalid bugs, we can have a discussion about if/when to delete them at a later date)
Turn on bug deletion
- Go here
- Switch allowbugdeletion to 'On'
Go to the deletionrequest component and click on 'Delete this component' at the bottom of the page
You'll get a red Confirmation prompt along the lines of "There are 66 bugs entered for this component! When you delete this component, ALL stored bugs and their history will be deleted too."
As long as everything looks kosher, click 'Yes, delete'.
Now IMMEDIATELY turn OFF bug deletion (before you forget!)
- Go here
- Switch allowbugdeletion to 'OFF'
You'll now need to recreate the deletionrequest component.
- click here to add one
- #Deletionrequest default params will give you the values for the fields.
After component creation, double-check to make sure everything looks correct.

Deletionrequest default params

To recreate the component, you'll need these values:

Component: deletionrequest
Component Description: Select this Component for bugs what have been created only for testing Bugzilla or Bug Submission Assistant. Bugs with this component will be deleted from time to time. Details see here!
Default Assignee: libreoffice-bugs@lists.freedesktop.org
Default QA contact:
Default CC List:

Deleting User Accounts

Generally speaking, we avoid completely deleting user accounts and all the bugs, comments, and attachments provided, as those are often an important part of our QA process and are items on which we worked in good faith. What we can easily do (after account ownership verification) is to go in as an administrator and change a user's settings to something like:

 Login Name:  removed_0001@example.net
 Real Name :  -- removed --
 Bugmail Disabled: [check the box]            # This will prevent most email from being sent
 Disable text: removed account                # This will prevent people from logging-in to the account

Default Assignees

It can be helpful to keep track of the default assignees by component:

SELECT p.name AS Product,
        c.name AS Component,
        u.login_name AS DefaultAssignee,
        initialqacontact AS DefaultQA
 FROM products p, components c, profiles u
 WHERE p.id = c.product_id AND
      u.userid = c.initialowner
 ORDER BY Product, Component;

Members of a group

Getting a list of all users of a particular group is pretty easy

Go to the Edit Users page
Restrict the search to the particular group in which you're interested

Sometimes you may want to further-restrict the search. So here's the basic search as you would run it as SQL:

SELECT p.login_name AS User,
        ug.isbless AS "can grant privs?"
 FROM profiles p, user_group_map ug
 WHERE ug.group_id = 27 AND   -- 'contributors' has group.id = 27
       p.userid = ug.user_id;

(Note that even though one might not have the can-grant-privs flag set, if they are a Bugzilla admin, they'll have enough power to grant privs)

Events in chronological order

The web-based search tools are woefully inadequate for telling us information such as when did we first use the tag "needAdvice"?.

As a practical example, let's figure out who performed the 1000th bibisection (and labeled it as such in Bugzilla):

NOTE: bibisect information originally lived in the Whiteboard, but has now (mostly) migrated to Keywords.

SELECT DISTINCT ba.bug_id AS "Bug",
        p.login_name AS "User",
        ba.bug_when AS "When",
        ba.added,
        ba.removed
 FROM bugs_activity ba, profiles p
 WHERE fieldid BETWEEN 9 AND 10            -- Keywords has fieldid = 10; The Whiteboard has fieldid 9
       AND added LIKE '%bibisected%'       -- Match 'bibisected' 'bibisected35' or multiple tags added
       AND removed NOT LIKE '%bibisected%' -- No count if the bug was already bibisected!
       AND ba.who = p.userid
 ORDER BY ba.bug_when
 LIMIT 1000;

Of course, these types of queries can only provide the basic data. For something like a bug with Keyword needAdvice, it's rather straight forward about the first time we used it (chronologically speaking), but for our bibisect query, one needs to look a bit further at the results and confirm that yes, bugs marked as bibisected are in fact actually bibisected, and so forth.

User Statistics

Who doesn't like stats? Here are some handy queries so I don't have to remember anything:

Total bugzilla users

bugzilla=# select count(userid) from profiles;
  count
 -------
  17888

Bugzilla users active during

The past week

bugzilla=# select count(last_seen_date) from profiles where last_seen_date > CURRENT_DATE - 7;
  count
 -------
    448

The past month

bugzilla=# select count(last_seen_date) from profiles where last_seen_date > CURRENT_DATE - 30;
  count 
 -------
   1304

Bugzilla users who haven't logged-in since the Freedesktop migration

bugzilla=# select count(cryptpassword) from profiles where cryptpassword = '!';
  count 
 -------
  17002

Bugzilla users who migrated with us from FDO

We've migrated to our own Bugzilla in January 2015, which will give us complete control over all aspects of the bug from FreeDesktop.org.

Based on some digging (bugzilla=# select distinct on (userid) userid, profiles_when from profiles_activity WHERE profiles_when < '2015-01-24' AND userid > 52705 limit 10;), it looks like user 52710 is the last user to sign up on FDO before the migration. So we can use that info to simplify our querying.

Further digging indicates that some people signed up on the 24th (select * from profiles where cryptpassword = '!' and userid > 52710;

), so make that userid 52724

Here's a list of all users who signed-up on FDO, and have logged-in (i.e. reset their password) since the Jan 24th migration:

bugzilla=# select count(cryptpassword) from profiles where cryptpassword != '!' AND userid <= 52724;
  count 
 -------
    536

New users since the migration

bugzilla=# select count(userid) from profiles where userid > 52724;
  count 
 -------
    355

Top Bug Reporters

For 2014

bugzilla=# select COUNT(bug_id) bcount, reporter from bugs where creation_ts >= '2014-01-01 00:00:00' AND creation_ts < '2015-01-01 00:00:00' GROUP BY reporter ORDER BY bcount DESC;

Top 5 were:

632
127
67
66
57

With names:

bugzilla=# select COUNT(bug_id) bcount, login_name, realname from bugs, profiles where creation_ts >= '2014-01-01 00:00:00' AND creation_ts < '2015-01-01 00:00:00' AND reporter = userid GROUP BY login_name, realname ORDER BY bcount DESC;

Top Bug Commenters

Grab out some comment information

bugzilla=# select * from longdescs where bug_id = 89613 limit 1;

Notes:

comment_id appears to be a unique value for each row in the longdescs table
Use same mechanism for counting bugs filed

For 2014

bugzilla=# select COUNT(comment_id) ccount, login_name, realname from longdescs, profiles where bug_when >= '2014-01-01 00:00:00' AND bug_when < '2015-01-01 00:00:00' AND who = userid GROUP BY login_name, realname ORDER BY ccount DESC;

Access Control

We try to keep as much of Bugzilla as open as possible.

We have made a few restrictions to various parts of Bugzilla, including adding access control onto the so-called "Importance" fields (Severity & Priority) to help us more effectively use those fields and have other teams (e.g. Development) put greater trust in the values present. For more information, see the links to each of the fields.

Severity

Using the 'blocker' level of Severity is off-limits for all. Technically speaking, admins have access, but as we don't actually use this level in our projects, admins should limit use to maintenance and testing only.

Priority

Access to the Priority field is restricted to admins and users in the 'Contributors' group. We consider this limitation a small "speed bump" to changing the value, ensuring that users have at least a modicum of information about QA before they try to triage the bug. See the Priority wiki page for more details.