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. Accounts -------- 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 fields. 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 issue. 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 kylli...@users.sourceforge.net [4] http://bugs.netsurf-browser.org/mantis/lost_pwd_page.php [5] h...@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
