If you use our forum or follow us on Twitter or other channels, you’ll often hear us ask Vivaldi users to submit reports whenever they encounter bugs. This is the easiest way for us to get all the information we need (things like version of Vivaldi and operating system), so we’re able to reproduce the bug and patch it.
The more information you can provide, the easier it is for us to get to the bottom of the issue and attempt to solve the problem. Your feedback helps us improve our product and make it better over time. We are thankful for that.
Bugs are introduced constantly, and some require us to stop what we’re doing in terms of building new features and tackle them right away. We, therefore, make sure we have capacity in the team to handle bugs and regressions as they come up. Over the past 30 days alone 692 issues were submitted, and 653 were resolved.
We use Jira for most of our project management, which includes keeping track of user-submitted bugs. Once a bug report has been submitted, it goes through several stages until the fix is live in our Stable version. Here is the usual life-cycle of a bug report.
A new bug report is created
When a new bug is reported, whether it’s internally or from Vivaldi users, its state is set by default to “unconfirmed”.
Verifying the bug
Here the test team will try to reproduce the bug based on the information and steps given in the report. Since Vivaldi is available on several different versions of Windows, Linux, and Mac, it requires the testers to have access to many different test environments. This means lots of monitors and (sometimes) messy desks. Once we’re able to reproduce the bug and verify it, the status is changed from “unconfirmed” to “confirmed”.
Assigning the bug to a developer
Once a bug is confirmed, we assign a priority level to it that ranges between 1 and 5, where 1 is the highest priority. At this point, it’s up to the engineer’s discretion which bugs need immediate attention and which can hold off for a bit. If an engineer feels up to the task, they’ll assign the bug to themselves to let everyone know that they are working on it. If we find a regression, which is usually caused by a previous bug fix, we assign it to the developer who caused it.
Push the bugfix to master branch and send out a build to our Soprano team
Once a bug has been fixed and has gone through our internal test processes, the engineer will push it to our master branch. We do test builds almost every day which we distribute out to beta-testers (also called Sopranos) before the version is made public. At this point, the Sopranos can start manual testing.
Regression tests
Here, along with the Sopranos, we test the overall system to find if bug fixes have caused any issues anywhere in the system. Sometimes when you fix a bug you introduce several new ones. Each build is automatically tested on all three platforms. Regression tests help us catch these bugs before the fix is pushed out to our Snapshot stream channel.
Submit the bugfix to the latest Snapshot
If the bug fix is working as intended, we’ll push the fix to the latest Snapshot. Snapshots are available to everyone to download – this is our test product stream. You can follow the Snapshot release blog and find out if you should be using Snapshot here.
Submit the bugfix to the latest release
As a last step, we push the fix to the latest Stable release. Once the bug fix is live the QA-team can finally put their legs on the table and ponder the finer things in life.
Release notes
For each release, whether it’s Snapshot or Stable, we’ll include release notes. Here you’ll get to see which bugs and regressions we’ve fixed along with their respective bug report numbers. So if you’ve sent us a bug report and you want to know when the bug is fixed, make sure you keep track of the bug report number (also known as the VB number).
Rejection of bug reports
Sometimes a bug report might be rejected. This could happen for several reasons.
- The bug report is from an old version of Vivaldi and the bug is not present in the current build.
- The steps described in the bug report are not clear enough or sufficient for us to reproduce the bug.
- We are unable to fully understand the bug report (this is often caused by incomplete information).
- The bug report is a duplicate. If the bug is known already, the report will be merged with the original bug report. If we receive a lot of duplicates from different users we know that solving the issue is important to you.
Bug tracker closed to the public
Our bug tracker is not public. We’ve often been asked to open it but feel that this will be counterproductive for the team. We receive a lot of reports and because of time constraints, we cannot explain in detail our reasoning behind solving each report. Nonetheless, we do our best to be as transparent as possible.
Photo by Farzad Nazifi on Unsplash
