Older / previous Bugzilla upgrades information

Stuff wanted by OlavVitters

This page is about stuff OlavVitters or one of the other bugmasters want when Bugzilla is upgraded to 2.20. Not everything might be possible. There is no guarantee that ideas listed here will be implemented.

Don't add new items here, add them in the section Stuff wanted by others. You can however add comments to the existing items.

Status of Bugzilla upgrade

Server didn't had the required versions. These have been upgraded... and downgraded again. Test version is at http://bugzilla-test.gnome.org/. Mail has been disabled.

See /UpgradeStatus for current status of the upgrade. When I'm working I usually update the page often (if you subscribe, prepare to be spammed).

XML-RPC

Allows bug-buddy to submit bugs easily, without the message email sending. Would also allow attachments. Jeff Bailey is working on this and might be able to provide a patch for 2.20. The patch would be for 2.20 only.

Eventually it would go into main Bugzilla. The bug for that is at: mozilla bug 224577

Simpler page when user is not logged in

Currently when a user is not logged in Bugzilla shows all possible option. This to allow persons not logged in to log in afterwards. This makes for a very bad Bugzilla experience for persons new to Bugzilla (meaning not logged in). I only want to only the basic minimum possible; to add a comment and to CC yourself. For other tasks you have to log in. This means that we would require Cookies to be turned on. I (OlavVitters) do not think this is a problem.

Elijah: Part of this is due to bug_form.pl; grep for "if the person hasn't logged in ($::userid == 0)". We explicitly treat not logged in as being able to edit bugs. This was a change I made at Andrew's specific request (I didn't like it but he said it was needed in some cases and that cookies weren't reliable or something). Anyway, you might want to ping him.

Olav: Found the reason. Bugzilla also uses IP address. Some people are behind transparant proxies. I need to make some changes to handle that.

Outstanding b.g.o bugs

B.g.o is also a product in Bugzilla. I've targetted a few bugs against 2.18 and 2.20. Maybe I'll list them here too.

NEEDINFO bliss

Some of these might already work on b.g.o, but:

• Add a NEEDINFO state
• While in NEEDINFO, allow:
  • To reopen from NEEDINFO to UNCONFIRMED/NEW
  • To mark duplicate
  • Resolved as fixed/...
  • Reassign

Also while in NEEDINFO, there should be a knob that reopen the bug only if a comment is added.

There is a bug in b.m.o about this. I need to attached the patch there after it is finished.

Status: This is done. Needs lots of testing though. Also needs testing in 'changing multiple bugs at once'.

Separate reassignment from status changes

There should be two sets of knobs. One to change the state (change it to NEEDINFO/ NEW/ ASSIGNED/ REOPEN/ FIXED/ ...). Another set to change the assignment.

This is taken from RedHat. Maybe also send upstream.

Status: Done. Needs again lots of testing. Also needs testing in 'changing multiple bugs at once'.

Simplify the search pages

B.m.o already has a simple search interface. It should allow multiple searches. I want to make multiple simple search pages (each for a specific purpose). Maybe even put some reports under there.

Elijah: This is part of what I was doing with boogle. See my section below for some of my ideas on the matter.

Steal this: http://jira.codehaus.org/browse/BOO

UTF-8

See:

• mozilla bug 126266

• gnomebug:96376

This isn't enough. We need to convert our existing data to UTF-8. Unsure how to do this.

MarkusBertheau: Like this:

1. Dump the database in text format
2. Pipe through iconv -f ISO-8859-1 -t UTF-8
3. recode html..utf-8 (this recodes the html entities browsers send when the user types a character in the textbox that's not in the page's character set)
4. Load the dump

Comment by OlavVitters: That assumed everything is in iso-8859-1 right? From the Mozilla bug I understood it can be any charset, and detecting that is the problem. Oh, also see mozilla bug 280633. The best solution I read was ripping out the charset detection from Mozilla and using that (a comment somewhere in mozilla bug 126266). The Perl charset detection wasn't considered good enough.

Comment by MarkusBertheau: Yes. Since what Bugzilla sends out get's interpreted as ISO-8859-1 anyway, the data was always interpreted and displayed as ISO-8859-1. I don't think it's worth the trouble to go through a automatic charset detection.

Comment by OlavVitters: That isn't true, Mozilla/IE could detect the charset, as posted somewhere in 126266. Also see comment 172 there. Is says that comments are posted in all charsets. Maybe we can ignore this, but needs agreement from other bugmasters. Anyway UTF-8 is something I consider a requirement.

Bug-buddy and UTF-8

<bkor> fer: in what charset does bug-buddy send the emails?
[..]
<fer> it uses utf-8 always
<fer> but gdb process, that is not utf-8 aware
<fer> then the mail is sent in UTF-8 but imported by bugzilla as ISO8859
<bkor> ahh.. except for gdb that is perfect.. I want the next b.g.o to use utf-8.. at least for new bugs
<fer> great!
<fer> there will be no database troubles with that?
<bkor> don't think so, we'll be using MySQL 4.0 or 4.1
<bkor> but I want to fully test everything before going live.. and I haven't even started on it.. first the evolution migration

Plan for bug-buddy 2.14 is to use XML-RPC.

Indicate that someone can work on a bug

Elijah provided the gnome-love report. This is excellent as it (should) shows a comment by a maintainer explaining what needs to be done. I think almost all open bugs should be open for the taking. This may be the case now, but it needs to be more clear. Anyone (community) should be able to assign such a bug to him/herself and work on it. Maybe this also requires the 'whining' report. If not actively working on a bug, it should either be automatically put back in the 'open-for-the-taking' state or the currently assigned person should be whined upon. Solving this could be as easy as renaming the 'NEW' state, haven't fully thought about this yet.

I want a bug to easily show that someone is working on it or not. This isn't the same as gnome-love, because gnome-love bugs should be easily fixable and have a comment by a knowledgable person giving pointers.

Elijah: (1) Open bugs are open for the taking right now (unless, of course, someone else is working on them or a maintainer wants to handle it personally or something); are we doing something that gives the opposite impression? (2) If people assign bugs to themselves then people watching a product won't be getting emails about it anymore, which I don't think I'd like. Also, I like having bugs assigned to things like metacity-maint@gnome.bugs instead of being assigned directly to me (besides, if I reassign them to myself then Havoc doesn't get the emails and won't review my patches so I won't be able to commit). (3) I like the idea of being able to see if someone is active on a bug; I'm not sure how you'd do so.

Olav: I want to make dummy QA contact the same as the dummy maintainer. Also I'd want all components to have QA contacts. This will allow persons to assign bugs to themselves. Bugzilla at bugzilla.mozilla.org use this. Also they / 2.20 have a checkmark to assign a bug to yourself when adding a patch (changes assigned_to + status to ASSIGNED). At b.m.o they actively enforce this (they will assign it to you if you didn't). But for b.g.o that would be optional but hopefully encouraged. Olav (continued): You only assign it to yourself when you start working on it, not before. It should be reassigned if the bug had no activity for a while (I'd like to do that automatically). Maybe with a whine mail (warning) a week before or so.

Elijah: That sounds like a good system; it may be worth enforcing as well instead of just encouraging--we'll have to ping luis and aes, about it, though.

Gnome-love

Adding that keyword should require a comment. [LuisVilla4: should adding any keyword require a comment?]

Somehow simplify finding the correct product/component

Some components are in products you wouldn't expect. There should be a way to easily find the correct component.

Possibly crazy ideas:

• Pictures of the component
• Dummy components. ComponentA is listed in productA, but also in productB. Selecting the component in productB will however put the bug in productA
• Let users optionally enter a search text for a component and show components that match the text either in the name or the description

Not so crazy:

• Determine the crashed product in bug-buddy emails and force the product to the correct product/component based upon the application that crashed. This should be skipped if the user submitted the bug-buddy report for a library. [LuisVilla4: I'm tempted to say that bug-buddy should skip asking the user the product selection step altogether, and just figure out things server-side based on the binary name and version. If that data isn't available, maybe refuse to submit?]

Layout stuff

Ensure a comment doesn't cause the entire page to scroll. I think you can add the scrollbar to only the comment using:

• overflow: auto;

However, above will trigger a Mozilla/Firefox bug that prevents scrolling IIRC. Fixes in FF1.5beta / Moz1.8.

Steal this: http://bugzilla.ximian.com/natzilla/changes.cgi?id=47512

Also, when not logged in, don't show the email address. If no email address is set, defang it (s/[@.]/ /g). This is like bugzilla.redhat.com

Google

Allow Google to index Bugzilla, see gnomebug:142505. This must be cached, as Google otherwise brings down the server. Current idea is some sort of caching using a cron job. The cron job would use the delta_ts field to determine if a bug has been updated. If so, it updates the cache. This must be done intelligently (divided across the day) as not to rebuild all changes pages at once, but maybe using a simple algorithm like bug_id mod 4.

Or, look into Google Base as way to submit batch updates. I asked on their forum if this would be desirable/appropriate. -- GabrielBurt 2008-05-23 21:05:17

Make Gnome bugzilla pretty and easy

Yes, the title of this section implies that it is currently ugly and difficult to use. Anyway, side notes:

• should we just merge the layout, not-logged-in, and simplify-the-search sections into this one?
• Maybe merge some of the stuff from my (Elijah's) section as well?
• Or maybe keep separate sections with this one just serving as a quick reference list?
• I sort of like the idea of moving this section to the top of this wiki page as well...

Okay, on to the real section:

• the frontpage, header, and footer are all cluttered with way too many links

• we should have a simpler page when the user is not logged in

• The query page is a monstrosity (see Elijah's section for an idea to cover this)

• redhat did a lot of nice things with their bugzilla, examples:
  • mass changes can be made without sending emails
  • don't show email addresses when not logged in (redundancy alert...)
  • they can track another Bugzilla installation, which may come in handy--perhaps with freedesktop.org or mozilla.org

  • they have this: frontpage.cgi

• Other places that have nice layouts to look at
  • Red Hat bugzilla
  • KDE bugzilla (including the reports; they even made our weekly bug summary look better)

  • http://launchpad.ubuntu.com/malone

• Make it easier to see if a response is from a maintainer/bugmaster/etc. somehow (see Elijah's crazy idea on one way of how to do this)

Over the top radical ideas

Most of these might need to be implemented in main Bugzilla or not at all.

• Allow a user to request a limited editbugs/canconfirm ability (using a form of somesort). This allows someone to change only a specified number of bugs. After the specified changes, the user cannot edit bugs anymore. This goes into a report and for bugsquad/bugmasters to monitor and give the user permanent editbugs/canconfirm. I don't want this to be on permanently, because that would clutter the interface too much.

LuisVilla4 wanted to default to giving everyone canconfirm and editbugs and then we just remove the permissions from anyone that abuses it. This is what Ximian did for years with ~0 problems. That said, some mechanism which 'highlighted' first-time confirmers/editors and brought them in for special scrutiny would be good, both as a catch and as a way to say 'welcome to the club.'

Bugmaster Elijah

Various ideas:

1. Simplified query interface. Currently, my idea is to do something like mozilla's query page, but replacing their simple form with boogle (after it gets cleaned up to not look so nasty, plus bugs worked out and a few more things added), and adding a third tab that points to specialized reports.

2. Better patch handling Namely, (1) make it easier to do searches including patch-statuses (boogle is part of this), (2) add a whining system for unreviewed patches, (3) make it easier for users to detect unmaintained and undermaintained modules, and (4) port the new patch review system (drop-down boxes in attachment area of show_bug.cgi) from current Gnome bugzilla.

3. A crazy idea: replace the mailto links in show_bug.cgi with a describeuser.cgi?user=<username> link. On the describeuser.cgi link, provide some information: (a) email address if the user is logged in (and has sufficient permissions?), (b) groups that the user is a member of (gnome hackers, bugzilla maintainers), (c) how long they've had a bugzilla account (d) how many comments they have added to bugs in bugzilla (yeah, that'd be a long query), and (e) which products they are a maintainer for. To track who the maintainers are, one possiblity is to add a comma-separated list of accounts for each product to the products table (although this neglects people who are heavily involved in contributing to a module but aren't yet a maintainer). (Inspired by comments from BehdadEsfahbod)

4. Also, there's an old list of things (be sure to check the whole thread), some of which haven't yet been implemented. Your (Olav's) ideas, in particular the triaging mode, sounded cool.

5. Add a dupe_count and patch_count field to bugs ?
   • Keeping these in sync would be a pain, but:
   • Would allow buglist.cgi to draw attention to bugs with patches
   • Would remove the need for a cron job for duplicates.cgi
   • Would make recent-mostfrequent-utils.pl faster
   • Would make gnomebug:316653 feasible
   • Would be part of the necessary work for gnomebug:69691
   • Dupe_count could be displayed on show_bug.cgi, with a link that lists all the duplicates
   • Would remove the need for the bugsquadders to find the original bug and mark as a duplicate of that one (well, unless there's extra useful information that should be put in the original report)

Comment by OlavVitters: Latest CVS Bugzilla has a 'settings' thing in the user preferences. This is excellent for triage mode, also possibly others. I still need to read through that thread. Another Comment By OlavVitters: Bugzilla CVS has product groups, where you can have one group per product. In theory this could be used for security, but we can use that to determine the maintainers. Every maintainer should have that group. Persons within a product group should be permitted to add/remove other persons (only for the product groups they are part of).

Stuff wanted by others

List stuff you want / hate about https://bugzilla.gnome.org. Please include ways you think we could solve this. Also describe how you use Bugzilla (normal user, triager, developer, maintainer, ...). Note that we may edit to shorten things.

MarkusBertheau (normal bugzilla user), ChristianKirbach (bug triager): Automatic adding to cc list when making changes. Bugzilla report

BehdadEsfahbod: Normal user/developer. A few points:

Further ideas on determining competency/authority of a given user, like other forums and message boards do: Have users rank each other (like ebay--using a voting system?), rank by how long you've been a member, rank by who answers questions or marks bugs as fixed. Example: experts-exchange.com.

• Comment by Elijah: I edited the above for brevity. Sounds fairly involved and may be somewhat difficult; Olav said he wasn't likely to implement it. However, part of the ideas were pulled out as I provided a suggestion on how one could implement those in my section.

LuisVilla4: Olav and I spoke briefly at GUADEC 2005; we discussed (among other things) perhaps having 'leagues' for triage, which would require some reports hacking. Basic idea would be month-by-month (or perhaps quarterly) league tables, with a 'masters' level for those of us who are not sane, and a different level for those who (in past quarters) have done well but not proven to be completely out of their minds. Perhaps also a newbie level for those who have never triaged a bug in previous quarters. Scoring would be something like: 2 points for marking a bug FIXED, 1 point for marking it closed in some other way, or NEEDINFO, and a -1 if it is reopened or the resolution is otherwise changed (so that not only you lose the points gained earlier, but are penalized- sort of like a yellow card.

GabrielBurt: Either adding the voting ability that other bugzillas have, or add a column in the bug search results page for # of CC'd people on the bug.

General comments

Note: Quality of the various extensions is pretty low atm. Existance of extensions doesn't mean they're production quality.

Drop:

• Drop bug-buddy special interface
  Bug-buddy should be ported to use Bugzilla 4.2 XML-RPC API. Bug-buddy is broken atm anyway.

• add-version.cgi (replace with totally custom XML-RPC extension)
• Custom GNOME theme
• Changes to page fields.html
• DEFAULT_COLUMN_LIST change: upstream default is sane now

Add (created extension):

• addversionx XML-RPC method (to replace add-version.cgi), see GNOME extension

Keep (small):

• describeuser page (extension)
• patchreport page (extension)
• stockanswers page (extension)
• weekly-bug-summary page (extension)
• splinter extension
• traceparser extension

Keep (changed into extension)

• browse interface
• developers group
• GNOME extension:
  • custom pages: email.html, points.html, reports.html (?), 403.html
  • classifications.is_gnome
  • cf_gnome_target limited generic editcomponents (=release team)

  • Allow NEEDINFO->UNCONFIRMED status changes by reporter

  • TODO: Not emailing @gnome.bugs, by removing them from $args->{recipients} in the bugmail_recipients hook

Keep (port to extension)

• attachments.status

Keep (to be decided how):

• MAX_COMMENT_LENGTH increase

• Milestone URL -> Homepage

Undecided:

• keywords changeable by any
• Disallow unpriviledged reporter from re-opening WONTFIX bugs