Difference between revisions of "Bugzilla Administration"

From GnuCash
Jump to: navigation, search
(→‎On Version: now part of #Notes about Fields as new #Status)
(→‎{{BugServer}}: Spam: Reorder, add 'attachments')
 
(52 intermediate revisions by 4 users not shown)
Line 4: Line 4:
 
== Bug overview ==
 
== Bug overview ==
  
−
[https://bugzilla.gnome.org/browse.cgi?product=GnuCash 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.
+
[{{BugURL}}/browse.cgi?product=GnuCash 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 ==
 +
 
 +
 
 +
=== {{BugServer}} ===
 +
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. {{BugURL}}/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.
 +
;Fight Spam: Spam in this case means bug reports that have nothing to do with GnuCash and include a URI that the spammer is trying to promote. To frustrate the spammer we want to suppress those URIs as quickly as possible, ideally before the next visit from a search engine spider.
 +
:;On the bug: ''remove any references to non-GnuCash content'':
 +
::# Change the '''subject''' to <tt>Spam</tt>,
 +
::# clear '''URL''' and similar fields,
 +
::# ''tag'' the '''description'''/'''comment'''[s] as <tt>spam</tt><code>Enter</code> to hide them,
 +
::# ''close'' with '''Status''' <tt>Resolved</tt> '''Reason''' <tt>Invalid</tt>
 +
:; Edit each attachment:
 +
::'''delete'''
 +
::'''Reason''' <tt>Spam</tt>.
 +
:;If you have admin privs:
 +
:# go to [{{BugURL}}/editusers.cgi editusers], find the user
 +
:## Enter their bugzilla '''username''' as ''real name''. ''Login name'' with the username part of the email address works also.
 +
:## Follow the link.
 +
:# On the '''edit user''' page
 +
:## check ''disable <tt>bug mail</tt>'' and
 +
:## '''disable text''' <tt>Spammer</tt>, then save.
 +
 
 +
=== {{UVServer}} ===
 +
If you still have some time, compare the uservoice entries with the bugzilla entries and link them in both directions for easier maintenance.
 +
;Note:uservoice links come in 2 flavours:
 +
# {{URL:UV}}forums/101223-feature-request/suggestions/2654889-support-for-chiptan-comfort-smarttan-optic-flicke
 +
# {{URL:UV}}admin/v3/ideas/40788835/
 +
Because not every reader has admin rights at {{UVServer}} enter the first form as <tt>URL</tt> in bugzilla.
 +
At {{UVServer}}
 +
# login (e.g. with your google account)
 +
# click <tt>Admin-Konsole</tt>
 +
# search the idea
 +
# update the <tt>public status</tt> with the {{BugServer}} link and the current state.
 +
To get admin rights at {{UVServer}} you should
 +
# already have done some
 +
#* bug triage on {{BugServer}} or
 +
#* other user support.
 +
# ask on mailto:gnucash-devel.
  
 
== Notes about Fields ==
 
== Notes about Fields ==
 
Some explanations and conventions about the meaning and usage of the bugzilla fields:
 
Some explanations and conventions about the meaning and usage of the bugzilla fields:
  
−
=== Version and Target Milestone===
+
=== 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.
 
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  
+
;Version: is being used for the version where the bug was spotted and ''reported''.
−
spotted and reported. The "Target Milestone" shows the version when the  
+
;Target Milestone: shows the version when the ''solution'' (if solved) will or (else) should appear publicly. So an unresolved bug is considered as a blocker of release <Target Milestone>.
−
solution will appear publicly.
 
  
 
If you close a bug, you shouldn't modify the "Version" field because it still  
 
If you close a bug, you shouldn't modify the "Version" field because it still  
Line 22: Line 63:
 
means we will probably close it as DUPLICATE or OBSOLETE).
 
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 "SVN" as long as SVN doesn't have this feature.  
+
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  
 
However, there might be exceptions to this rule, in which case we should leave  
 
the Version field to the reporter's version.
 
the Version field to the reporter's version.
Line 29: Line 70:
 
;New: The starting state, but after the dropping of '''Unconfirmed'''/'''Confirmed''' general an open bug.
 
;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.
 
;Assigned: (devs only) work in progress, see also '''Assigned To''' and its Take button.
−
;NeedInfo *: devs are waiting for answers of the reporter.
+
;NeedInfo *: devs are waiting for answers from the reporter.
 
;Resolved *:  
 
;Resolved *:  
 
:;Fixed:
 
:;Fixed:
Line 35: Line 76:
 
:;NotABug: It's a feature! ;-)
 
:;NotABug: It's a feature! ;-)
 
:;NotGnome: Another software component is responsible.
 
:;NotGnome: Another software component is responsible.
−
:;Incomplete: Reporter gave not enough information.
+
:;Incomplete: Reporter did not give enough information.
 
:;Invalid:
 
:;Invalid:
 
:;Obsolete:
 
:;Obsolete:
Line 41: Line 82:
 
:;''Fields with *'': Reporter can select them from state NeedInfo. SO they can not reset it to New.
 
:;''Fields with *'': Reporter can select them from state NeedInfo. SO they can not reset it to New.
  
−
See also [https://bugzilla.gnome.org/page.cgi?id=fields.html#bug_status bugzilla fields]
+
See also [{{BugURL}}/page.cgi?id=fields.html#bug_status bugzilla fields]
  
 
== Stock messages ==
 
== Stock messages ==
Line 48: Line 89:
 
=== When closing an old bug as OBSOLETE ===
 
=== When closing an old bug as OBSOLETE ===
 
Thank you for taking the time to report this bug.
 
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 2.6.15.
+
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 {{Version}}.
  
 
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!
 
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!
Line 55: Line 96:
 
Thank you for taking the time to explain your enhancement request.
 
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.
+
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:
 +
# Start to program in gnucash yourself - see http://wiki.gnucash.org/wiki/Development .
 +
# Convince someone who is not yet part of the GnuCash team to join the team and implement your feature.
 +
# 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.
 
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 ===
 
=== 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.
+
Thanks a lot for your feedback. You are right, it was not nice for gnucash to not reply to your initial report for quite some time. We are very sorry for that. However, during 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.
 +
 
 +
=== Test Recent Stable Version ===
 +
Thanks a lot for your feedback.
 +
 
 +
Is it still the case with the currently last stable release {{Version}}
 +
:https://www.gnucash.org/download.phtml?
 +
If your Linux distribution does not offer that, test please following
 +
:https://wiki.gnucash.org/wiki/Flatpak.
 +
 
 +
== Administrative Settings ==
 +
{{BugURL}}/editparams.cgi allows admins editing Bugzillas parameters.
 +
 
 +
=== Deleting Attachments ===
 +
This option is for security reasons by default disabled. In rare cases like
 +
* a user uploaded a log file containing passwords or other confidential data and requests the deletion,
 +
admins can on the tab <tt>Attachments</tt>, section <tt>allow_attachment_deletion</tt> enable it, delete an attachment and disable it again.
 +
 
 +
= New Installation =
 +
 
 +
GNOME announced that they were migrating their git repositories and bug tracking from [https://bugzilla.gnome.org https://bugzilla.gnome.org] to [https://gitlab.gnome.org https://gitlab.gnome.org]. Since GnuCash didn't host our code repository at gnome.org it didn't make sense to use gitlab for tracking bugs so we've set up our own Bugzilla instance at [{{BugURL}} {{BugURL}}], which went live around 25th June 2018. All GnuCash bugs were imported into our new Bugzilla instance (and still exist read-only in the old repository). New issues can no longer be reported in the old repository. The following are some notes for the core team while we worked on getting it set up.
 +
 
 +
== Migration Scripts ==
 +
We wrote a script [[Bugzilla_Administration/BugzillaFetch | BugzillaFetch.pl]] to fetch all the data from Gnome's Bugzilla instance.
 +
 
 +
Then we use Bugzilla::Migrate and migrate.pl with the following [[Bugzilla_Administration/BugzillaPM | Bugzilla.pm]] (and a few minor code changes) to import the data into Bugzilla.
 +
 
 +
== Different Version ==
 +
Bugzilla.gnome.org used bugzilla version 4.4, Derek has installed bugzilla version 5.0.3 [https://bugzilla.readthedocs.io/en/5.0/ Documentation].
 +
 
 +
By default Bugzilla comes with the following list of Status states:
 +
{| class="wikitable"
 +
! Status !! Sort !! Can Delete?
 +
|-
 +
|UNCONFIRMED || 100 || No
 +
|-
 +
|CONFIRMED  || 200 ||
 +
|-
 +
|IN_PROGRESS || 300 ||
 +
|-
 +
|RESOLVED  || 400 || No
 +
|-
 +
|VERIFIED  || 500 ||
 +
|}
 +
 
 +
And resolution codes:
 +
{| class="wikitable
 +
! 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
 +
 
 +
{| class="wikitable"
 +
! From \ To !! ASSIGNED !! NEEDINFO !! NEW !! REOPENED !! RESOLVED !! VERIFIED
 +
|-
 +
! {Start}
 +
            !          ||          ||  X  ||          ||          ||
 +
|-
 +
! ASSIGNED  ||style="background-color: brown;"| 
 +
                        !    X    ||  X  ||          ||      X    ||
 +
|-
 +
! NEEDINFO  ||    X    ||style="background-color: brown;"|
 +
                                    !  X  ||          ||      X    ||
 +
|-
 +
! NEW      ||    X    ||    X    ||style="background-color: brown;"|
 +
                                            !          ||      X    ||
 +
|-
 +
! REOPENED  ||    X    ||    X    ||    ||style="background-color: brown;"|
 +
                                                        !    X    ||
 +
|-
 +
! RESOLVED  ||          ||          ||    ||    X    ||style="background-color: brown;"|
 +
                                                                    !    X
 +
|-
 +
! VERIFIED  ||          ||          ||    ||    X    ||    X    ||style="background-color: brown;"|
 +
|}
 +
 
 +
== 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.
 +
[[Category:QA]]
 +
 
 +
=== 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.
 +
 
 +
=== Migration Status ===
 +
 
 +
We are working to migrate data from Gnome's Bugzilla to our own instance.  This section contains the status:
 +
 
 +
As of 2018-05-24:
 +
 
 +
* GnuCash product, all components, all bugs, and all associated users as of 2018-05-12 are imported
 +
 
 +
* Four "Products" were created, with their own set of components:
 +
o GnuCash -- existing components (minus Docs and Website)
 +
o Documentation -- Help, Guide, Man Pages, and Tip of the Day
 +
o Packaging -- MacOS and Windows
 +
o Website -- Website and Translations
 +
 
 +
Bugs were moved into the appropriate product/categories using automated heuristics.  We tried to avoid false positives but there were probably false negatives (which means some manual intervention may still be required)
 +
 
 +
* Component Initial-CC lists are not downloaded via the GnomeBZ JSON API.  We have manually added them.
 +
 
 +
* User WatchList data is not downloaded via the GnomeBZ JSON API.  This means that all users will need to manually reset their watchers on the GnuCash meta-users (e.g. gnucash-general-maint@gnome.bugs)
 +
 
 +
* Gnome's Attachment Status extension has been changed to attachment flags.  The flag data itself is not available from the JSON API, however the change history is.  This change history still needs to be properly translated and flags assigned.
 +
 
 +
As of 2018-06-15:
 +
 
 +
* In addition to the above, all bugs as of 2018-06-11 have been imported
 +
* Attachment IDs have been stabilized
 +
* Attachment Status has been migrated to new flags
 +
* @gnome.bugs meta-usernames changed to @gnucash.bugs
 +
* extraneous history and change-date-changes have been mitigated
 +
 
 +
As of 2018-06-25:
 +
 
 +
* Fixed the timezone issues (e.g. for Australia/NZ)
 +
 
 +
As of 2018-06-26:
 +
 
 +
* Fixed duplicated attachment comments for attachment creation.
 +
 
 +
==== TODO ====
 +
Migration work still to do:
 +
* add desired GnomeBZ extensions:
 +
** their browse.cgi
 +
** (more?)
 +
* update this page with the new normal
 +
* Final dump / load from GnomeBZ
 +
 
 +
==== After Migration ====
 +
After the Migration we will need to manually:
 +
* Re-Enable Bug Creation
 +
* Go through bugs and possibly reassign to new product/components
 +
* Users will need to manually add watchers

Latest revision as of 14:15, 2 May 2022

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

bugs.gnucash.org

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://bugs.gnucash.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.
Fight Spam
Spam in this case means bug reports that have nothing to do with GnuCash and include a URI that the spammer is trying to promote. To frustrate the spammer we want to suppress those URIs as quickly as possible, ideally before the next visit from a search engine spider.
On the bug
remove any references to non-GnuCash content:
  1. Change the subject to Spam,
  2. clear URL and similar fields,
  3. tag the description/comment[s] as spamEnter to hide them,
  4. close with Status Resolved Reason Invalid
Edit each attachment
delete
Reason Spam.
If you have admin privs
  1. go to editusers, find the user
    1. Enter their bugzilla username as real name. Login name with the username part of the email address works also.
    2. Follow the link.
  2. On the edit user page
    1. check disable bug mail and
    2. disable text Spammer, then save.

gnucash.uservoice.com

If you still have some time, compare the uservoice entries with the bugzilla entries and link them in both directions for easier maintenance.

Note
uservoice links come in 2 flavours:
  1. https://gnucash.uservoice.com/forums/101223-feature-request/suggestions/2654889-support-for-chiptan-comfort-smarttan-optic-flicke
  2. https://gnucash.uservoice.com/admin/v3/ideas/40788835/

Because not every reader has admin rights at gnucash.uservoice.com enter the first form as URL in bugzilla. At gnucash.uservoice.com

  1. login (e.g. with your google account)
  2. click Admin-Konsole
  3. search the idea
  4. update the public status with the bugs.gnucash.org link and the current state.

To get admin rights at gnucash.uservoice.com you should

  1. already have done some
    • bug triage on bugs.gnucash.org or
    • other user support.
  2. ask on mailto:gnucash-devel.

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.

Version
is being used for the version where the bug was spotted and reported.
Target Milestone
shows the version when the solution (if solved) will or (else) should appear publicly. So an unresolved bug is considered as a blocker of release <Target Milestone>.

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 for gnucash to not reply to your initial report for quite some time. We are very sorry for that. However, during 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.

Test Recent Stable Version

Thanks a lot for your feedback.

Is it still the case with the currently last stable release 5.9

https://www.gnucash.org/download.phtml?

If your Linux distribution does not offer that, test please following

https://wiki.gnucash.org/wiki/Flatpak.

Administrative Settings

https://bugs.gnucash.org/editparams.cgi allows admins editing Bugzillas parameters.

Deleting Attachments

This option is for security reasons by default disabled. In rare cases like

  • a user uploaded a log file containing passwords or other confidential data and requests the deletion,

admins can on the tab Attachments, section allow_attachment_deletion enable it, delete an attachment and disable it again.

New Installation

GNOME announced that they were migrating their git repositories and bug tracking from https://bugzilla.gnome.org to https://gitlab.gnome.org. Since GnuCash didn't host our code repository at gnome.org it didn't make sense to use gitlab for tracking bugs so we've set up our own Bugzilla instance at https://bugs.gnucash.org, which went live around 25th June 2018. All GnuCash bugs were imported into our new Bugzilla instance (and still exist read-only in the old repository). New issues can no longer be reported in the old repository. The following are some notes for the core team while we worked on getting it set up.

Migration Scripts

We wrote a script BugzillaFetch.pl to fetch all the data from Gnome's Bugzilla instance.

Then we use Bugzilla::Migrate and migrate.pl with the following Bugzilla.pm (and a few minor code changes) to import the data into Bugzilla.

Different Version

Bugzilla.gnome.org used 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.

Migration Status

We are working to migrate data from Gnome's Bugzilla to our own instance. This section contains the status:

As of 2018-05-24:

  • GnuCash product, all components, all bugs, and all associated users as of 2018-05-12 are imported
  • Four "Products" were created, with their own set of components:
o GnuCash -- existing components (minus Docs and Website)
o Documentation -- Help, Guide, Man Pages, and Tip of the Day
o Packaging -- MacOS and Windows
o Website -- Website and Translations

Bugs were moved into the appropriate product/categories using automated heuristics. We tried to avoid false positives but there were probably false negatives (which means some manual intervention may still be required)

  • Component Initial-CC lists are not downloaded via the GnomeBZ JSON API. We have manually added them.
  • User WatchList data is not downloaded via the GnomeBZ JSON API. This means that all users will need to manually reset their watchers on the GnuCash meta-users (e.g. gnucash-general-maint@gnome.bugs)
  • Gnome's Attachment Status extension has been changed to attachment flags. The flag data itself is not available from the JSON API, however the change history is. This change history still needs to be properly translated and flags assigned.

As of 2018-06-15:

  • In addition to the above, all bugs as of 2018-06-11 have been imported
  • Attachment IDs have been stabilized
  • Attachment Status has been migrated to new flags
  • @gnome.bugs meta-usernames changed to @gnucash.bugs
  • extraneous history and change-date-changes have been mitigated

As of 2018-06-25:

  • Fixed the timezone issues (e.g. for Australia/NZ)

As of 2018-06-26:

  • Fixed duplicated attachment comments for attachment creation.

TODO

Migration work still to do:

  • add desired GnomeBZ extensions:
    • their browse.cgi
    • (more?)
  • update this page with the new normal
  • Final dump / load from GnomeBZ

After Migration

After the Migration we will need to manually:

  • Re-Enable Bug Creation
  • Go through bugs and possibly reassign to new product/components
  • Users will need to manually add watchers
Retrieved from "https://wiki.gnucash.org/wiki/index.php?title=Bugzilla_Administration&oldid=21055"