Bugs, their care and stomping

Vincent Sanders vince at netsurf-browser.org
Tue Dec 17 17:14:25 GMT 2013

The NetSurf team are pleased to announce the availability of a new bug tracker [1]

The new tracker uses mantis [2] software which is usable from NetSurf

This move has been necessitated because of several issues, principally:

 - The SourceForge issue tracking system has been upgraded and is now
   unusable from NetSurf
 - The advertisements on the site have become aggressively invasive
 - The reliability of the site has come into question.

We have imported the bugs from SourceForge although this has resulted
in a renumbering of identifiers (bug numbers).

We have been able to put a link back to the old sourceforge bug
numbers in the "Additional Information" of every imported bug.

Please do not use the SourceForge tracker for any new bugs or update
any old ones there as they will be ignored.


We have created users within the new system for everyone who has
reported a bug. For most imported users the email address used was
their sourceforge contact address [3]

The new system does not allow for anonymous issue reporting, if this
is a problem for you we thank you for your opinion but this decision
is not negotiable.

To login please use the lost password interface [4] to update your
details if you wish.

If a user needs the address associated with their account altering and
cannot access it through sourceforge please contact us [5] giving as
much information as possible (including the user id and some
reasonable argument that the account is yours - we will set the
address to where you send the mail from)

Accounts have been created manually for the many users who usefully
put their contact details within their reports, additionally their
email details have been removed from the publicly visible reports
which should reduce spam harvesting.

We assure all users we will never use the email addresses given to the
system other than to reply to their bug reports.

New and existing bugs

Updates to bugs will (by default! this is configurable for each user
[6]) result in the reporter receiving an email. If you wish to update
a bug please use the web interface, replying to the emails means a
developer has to manually copy the reply to the bug. We may reconsider
changing the reply address to refuse mail if this becomes a burden.

New reports should contain as much information as the reporter can
provide we give some guidence [7] but ultimately the more information
you provide the more likely we can reproduce the issue and the more
likely it is to get resolved.

Debugging is hard [8] please do not have unreasonably high
expectations, we did *not* intend to have the bug that you found,
please do not take it personally.

I have currently triaged just over 10% of the open bugs and will make
my way through those that remain over the forthcoming weeks. Please
understand that there are very few active developers and many open
bugs so this work goes slow.

I have to be pretty harsh in my triage and will close incomplete bugs
(especially anonymous ones) without a detailed examination. These may
be reopened by the reporter but I request that as much information is
provided as you can.

What things mean

I know some reporters are already misunderstanding what the various
fields in a report are for, especially the severity and status

Severity refers to how severe the impact is on the project overall
i.e. if the bug causes a crash in normal operation (crash severity)
and is *not* a reflection on how important the bug is (we specifically
do not have a priority field for that). To be clear the *default* of
minor means, in this context, that the bug does not make the browser
unusable for *everyone*

Status is related to the bug work flow within the netsurf team. It
starts at new when the bug is reported, gets set to feedback when we
need more information from the user or a user reopens an unresolved

The acknowledged status means a developer has at least looked at
the report but not reproduced the issue whereas confirmed shows they
have reproduced it (not the reporter, we know they managed it!).

The assigned status means that one of the developers has decided they
are the best person to fix the issue and are actively examining the
problem. We are also using the assignment to the import user as a flag
that basic triage has not yet been performed on the bug.

Finally the resolved status implies that the resolution field should
be looked at to see how the issue was resolved and the closed status
implies the developer has finished with the report and no additional
activity will be made on the issue.

[1] http://http://bugs.netsurf-browser.org
[2] http://www.mantisbt.org/
[3] if the userid on sourceforge was kyllikki the email used was kyllikki at users.sourceforge.net
[4] http://bugs.netsurf-browser.org/mantis/lost_pwd_page.php
[5] help at netsurf-browser.org
[6] http://bugs.netsurf-browser.org/mantis/account_prefs_page.php
[7] http://bugs.netsurf-browser.org/
[8] Everyone knows that debugging is twice as hard as writing a program in the first place. - Brian Kernighan "The Elements of Programming Style", 2nd edition, chapter 2

Regards Vincent

More information about the netsurf-users mailing list