Bugzilla Administration
Note: this page is for developers and other QA people that manage GnuCash bugs in bugzilla. People that simply wish to look up bugs, or report new bugs can have a look at the general Bugzilla page.
Bug overview
Bugzilla's browse mode provides a very handy startpage to analyse GnuCash' bugstatus. It has overviews of bugs grouped on Component, Version, Severity and many others and it allows to drill down in any of these overviews.
Pending Tasks
While you browse you might see:
- Duplicate reports
- Resolve the younger as duplicate of the older.
- Specify Component
- The list of the component 'General' is often used by fist time reporters. https://bugzilla.gnome.org/editcomponents.cgi?product=GnuCash shows the components with their description. Assign the right one.
- Assign to default
- There are many older bugs assigned to single developers which probably are no longer active. Assigning to default will set Assignee and QA to the groups explained in Bugzilla#Configure Notifications. So people currently involved will get informed.
Notes about Fields
Some explanations and conventions about the meaning and usage of the bugzilla fields:
Version and Target Milestone
Bugzilla provides a "Version" field and a "Target milestone" field. Both allow you to set a GnuCash version to associate with the bug.
The "Version" field is being used for the version where the bug was spotted and reported. The "Target Milestone" shows the version when the solution will appear publicly.
If you close a bug, you shouldn't modify the "Version" field because it still contains information that we might not have in any of the other fields, as sometimes the bug might have disappeared in the current version already (which means we will probably close it as DUPLICATE or OBSOLETE).
For enhancement requests, this can be different: usually it is not necessary to know the reporter's version anymore. In that case it should be set to "git-master" as long as git-master doesn't have this feature. However, there might be exceptions to this rule, in which case we should leave the Version field to the reporter's version.
Status
- New
- The starting state, but after the dropping of Unconfirmed/Confirmed general an open bug.
- Assigned
- (devs only) work in progress, see also Assigned To and its Take button.
- NeedInfo *
- devs are waiting for answers from the reporter.
- Resolved *
-
- Fixed
- WontFix
- NotABug
- It's a feature! ;-)
- NotGnome
- Another software component is responsible.
- Incomplete
- Reporter did not give enough information.
- Invalid
- Obsolete
- Fields with *
- Reporter can select them from state NeedInfo. SO they can not reset it to New.
See also bugzilla fields
Stock messages
Feel free to copy this messages into the comment when closing bugs for certain reasons that occur regularly.
When closing an old bug as OBSOLETE
Thank you for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. The GnuCash developers are no longer working on that version, so either this bug has already been fixed or unfortunately there will not be any bug fixes for the version that you use. The current stable version of gnucash is 5.9.
In the (hopefully unlikely) case you discover the same bug in the very latest stable version, do not hesitate to REOPEN it again. Also, feel free to file other bugs or enhancement requests that you find. Thank you very much!
When refusing an enhancement request as WONTFIX or setting priority=low
Thank you for taking the time to explain your enhancement request.
The described enhancement is a good proposal and would be an advantage for the software. However, as a volunteer-driven project with limited resources, the GnuCash developers have their own priorities about the features which are most likely being worked on in the near future. In that sense, the current GnuCash developers decided not to work on your proposed feature in the next 4-6 months. In case you would like to have this feature implemented in any case, you have the following option: 1. Start to program in gnucash yourself - see http://wiki.gnucash.org/wiki/Development . 2. Convince someone who is not yet part of the GnuCash team to join the team and implement your feature. 3. Pay some of the GnuCash developers to implement your feature - ask on the mailing list gnucash-devel@gnucash.org in that case. Thank you very much.
Feel free to file other bugs or enhancement requests that you find, though.
For explaining why we ask questions even though the original report might be very old
Thanks a lot for your feedback. You are right, it was not nice from gnucash to not reply to your initial report for quite some time. We are very sorry for that. However, at the sporadic occasions when some of us check *all* currently open bugreports (even though this part of gnucash used to be in someone else's responsibility) we only have the choice to either continue not to reply, or add a reply even though the original report is already several months old (or years). In your case, we have decided it is better to reply late than not to reply at all. Thank you very much for bearing the imponderables of a large volunteer project such as ours.
New Installation
GNOME announced that they're migrating their git repositories and bug tracking to an instance of gitlab. Since GnuCash doesn't host our code repository at gnome.org it doesn't make sense to use gitlab for tracking bugs so we're setting up our own Bugzilla instance. It isn't yet live; we're still working on importing bugs. The following are some notes for the core team while we work on getting it set up.
Different Version
Bugzilla.gnome.org uses bugzilla version 4.4, Derek has installed bugzilla version 5.0.3 Documentation.
By default Bugzilla comes with the following list of Status states:
Status | Sort | Can Delete? |
---|---|---|
UNCONFIRMED | 100 | No |
CONFIRMED | 200 | |
IN_PROGRESS | 300 | |
RESOLVED | 400 | No |
VERIFIED | 500 |
And resolution codes:
Resolution | Sort | Can Delete? |
---|---|---|
100 | No | |
FIXED | 200 | No |
INVALID | 300 | |
WONTFIX | 400 | |
DUPLICATE | 500 | No |
WORKSFORME | 600 |
For the GnuCash installation, we have removed the IN_PROGRESS status, and have disabled UNCONFIRMED in the GnuCash project.
Following the practice on Gnome's Bugzilla, we've added ASSIGNED, NEEDINFO, NEW, REOPENED and removed CONFIRMED.
And resolutions: INCOMPLETE, NOTABUG, NOTGNOME, OBSOLETE
We have migrated NOTGNOME to NOTGNUCASH
Other status/resolution migrations are still under discussion, as is the bug workflow
Bug Status Workflow
The following table shows the workflow enabled in the new installation, reflecting at present the Gnome workflow. Given a status in the left column, it may move to any status with an X marked in the column for the "new" status
From \ To | ASSIGNED | NEEDINFO | NEW | REOPENED | RESOLVED | VERIFIED |
---|---|---|---|---|---|---|
{Start} | X | |||||
ASSIGNED | X | X | X | |||
NEEDINFO | X | X | X | |||
NEW | X | X | X | |||
REOPENED | X | X | X | |||
RESOLVED | X | X | ||||
VERIFIED | X | X |
Users
We can import user's emails and real names, but only users can access other values on their accounts so users will need to reset their passwords and configure their accounts including resetting any email watchers.
Admins will need to reset user permissions as well.
Developers, Admins, etc.
Are set by the migration script.
Bugzilla Parameters
System parameters are stored outside of the database so adjustments will persist.
Product Parameters
On import, milestones are imported from the bugs, not the products, so any unused milestones that we want will need to be added after the final import, and any undesired milestones will need to be manually removed.