Migrating OOo's IssueZilla to Kenai's BugZilla

Note: This page is outdated, and kept for reference only.

At the moment, this is a rather lose collection of issue encountered when playing with BugZilla, with the idea of moving current OpenOffice.org's IssueZilla to BugZilla. They're in no way sorted by priority or such, but happily mix serious stoppers with nice-to-have wishes.

A concrete TODO-list, basically distilled from this page here, also exists.

Observations (End User)

• IZ' "Component" is named "Product", "Sub component" is named "Component"
• Attachments can be created at submission time - cool
• "Platform" and "OS" are somewhat limited (e.g. no "Solaris")
• There's a "clone this bug" feature
• There's a preference whether or not to automatically add yourself to CC when modifying an issue
• resolutions LATER/REMIND do not exist (good)
• it's possible to change the resolution (FIXED / INVALID / WONTFIX / DUPLICATE / WORKSFORME) for issues in status RESOLVED / VERIFIED / CLOSED. (Good or bad?)
• it's possible to move a CLOSED issue back to RESOLVED - which doesn't make sense, does it?
• attachments can be declared as obsolete now (good!)
• Unlike in IZ, there's no "QA contact" field, but this is handled via a default-CC, which seems to be set up per component
• Currently, only Martin's account (oooratte) seems to have a real name, which is displayed (e.g. in issue lists, or in issue comments he made). For all other accounts, the @kenai.com mail address is displayed.
• There are "Email me when someone asks me to set a flag" and "Email me when someone asks me to set a flag" settings in BZ's user preferences. This sounds promising, as it seems to indicate that the Bugzilla installation supports the flags known from Mozilla's BZ installation, such as "blocking release X". This might be useful to improve our work flow.
• closed issues do not appear in the dependency tree of the issues they block/depend on.
• the "Dependency Graph" feature, seemingly served by some external site (www2.research.att.com) does not work

Observations (Admin)

• you can close a project for bug entry.
• you can control the status workflow, i.e. define which status transitions are allowed. Might be interesting for us.
• you can edit the values for status/resolution - great, we can get rid of "STARTED" (and rename it to ACCEPTED), which caused lotta confusion in the past.
• you can define custom fields. This might open a possibility to actually track the CWS a bug belongs to in BZ itself, not in a separate application (EIS), making work outside Sun more convenient.
• There are "Flags", with the possible status "requested", "denied", "granted". This might allow us, in the future, to track release-blocker issues via flags, instead of those (somewhat cumbersome) blocker issues.
• BugZilla has a group system to define fine grained permissions.

Problems

• changing the owner of an issue is currently not possible, except for the owner him/herself. If this is a general feature, and cannot be addressed by giving permissions, it's a serious blocker, as it would be highly incompatible with significant parts of our work flow.
• where the heck is the "Target milestone" field, or anything equivalent? We don't even need to talk about migrating without it.
• At submission time, "Assigned To" is currently disabled, and defaulted. Under which conditions does it become available?
• BugZilla seems to have no (feasible) session timeout - currently I can reload a BZ page after ~24 hours, and my session still seems to last. Don't think this is a Good Thing (TM).
• There is no "Issue Type" field
• Voting is disabled in kenai.com's installation, at least I didn't find any way to vote for an issue, and there's no display of any votes (even 0) attached to an issue

Desired Changes

• defaults for Severity/Priority should be changed to normal/P3
• "This is the person in charge of resolving the bug", taken from https://kenai.com/bugzilla/page.cgi?id=fields.html#assigned_to. Not true, at least it doesn't reflect our work flow, where the assignee is in charge of *dealing* with the bug.
• should change the introductionary text on the "Find a specific bug" page - it talks about browsers currently
• there currently is *no* link back from BugZilla to kenai. Quite inconvenient.
• BugZilla notification mails should have a "From" header with the instigator of the change. Currently, they all come from "bugzilla-daemon", which slows down the handling of those mails.
• would like to customize the "New" link in Buzilla's menu bar to point to our pre-submission page (something like ftp://qa.openoffice.org/issue_handling/pre_submission.html), instead of the usual (way too huge) project list
• the "issue tracking" link at the left hand side of a project page should not open an issue list, this is nonsense. Instead it should lead to some sort of introduction page for issue handling.

Questions

• How does BZ administration (e.g. adding versions and the like) look like? Didn't find anything like this, not even a possibility for the project admin to grant respective roles.
• How do I actually (request to) join a project? Needed this for my alt account and the test2ooo project, but didn't find anything ... (that's might be stupid /me, only)
• How does the role system in BZ look like? What's the granularity of permissions, how are they distributed over different roles? Are roles in BZ the same as the roles in the project itself (where you can be an Observer, a Content Developer, a Tester, a Software Developer, or an Administrator)?
• Is there an interface to determine most recently changed bugs?

things to play with

the chapter collects things I still want/need to play with, without a claim of completeness.

• issue work flow - can it capture what we need / are used to? (P1)
• BZ administration (P2)
• BZ classification, see bug fields/useclassification, http://www.bugzilla.org/docs/3.0/html/classifications.html , KENAI-1843 will enable this for the OOo instance.
• quick ideas for classes: nlc native language confederation; extensions; App = Word Processor, Presentation, ...; code = API, ucb, ... ; infrastructure = website, distribution, ...

Comparison of NetBeans' BZ with kenai.com's BZ

NetBeans, respectively netbeans.org, is also served by kenai. Thus, working with NetBeans' BZ might will give us ideas what is possible here.

Observations

• There's no severity in NB - seems they removed it from the UI. Personally, I am undecided whether it is good to have a severity. In the past, we always said that a priority alone does not fully capture what is needed to prioritize on issues. However, looking at the list of pre-defined severities, an imagining they being combined with 5 priorities, I think this could make the system way too complex for the average user, effectively rendering it useless.
• The owner of an issue can be changed both at submission time, and when editing an issue. Good, so this is something which is either simply not enabled in the default installation at kenai.com, or can be added relatively easy.
• There is a "Target milestone". Together with what Martin said about administrating milestones, I assume that indeed this feature just did not make it into the UI at kenai.com, but is available in general.
• BZ is embedded into the general NB UI (i.e. with the menu at the top, etc.), so there's a "way back", in opposite to kenai.com's BZ
• NB has an "Issue Type", with values DEFECT / ENHANCEMENT / TASK. Supposedly this is customizable per BZ installation, too.
• NB allows voting on issues