Fixing bugs in Vaadin

Here at Vaadin, we take software quality seriously. At the core of delivering quality software is learning from past mistakes and continuously improving the way we work.

During the past few months, we have introduced some changes to the way we handle bugs. The two biggest improvements visible to the Vaadin community are the more transparent communication on the ticket progress and a faster release cycle. By introducing new ticket statuses we are now able to share more detailed information about the tickets progress while it’s being worked on. When it comes to shipping the fixes, we release a new maintenance release (at least) every two weeks. Shipping regularly has a major implication to the community - after a bug has been marked as fixed you can be sure it will be available for download within the next two weeks.

Meet The Master Team

So, who’s fixing the bugs at Vaadin? Well, as you probably expected, we have a maintenance team for that in R&D. And because the team is responsible for the Vaadin master branch, we’ve started calling it The Master Team. What you probably didn’t expect is that the Vaadin Master Team is actually a virtual team where anybody working at Vaadin can join. Having a virtual team like this allows people to share their knowledge about the Vaadin Framework and learn new things about maintaining and improving it further. Ultimately, the developers will have even more tools and skills at their disposal to help customers build quality software and achieve great success with Vaadin.

Master Team also coordinates and releases fixes done by the community contributors.

Ticket lifecycle

Let’s go through the different steps involved in the lifecycle of a ticket. In the illustration below you can see how the different ticket statuses (the blue boxes) relate to different phases in the bug resolution process.

New is pretty obvious - this is the first status a ticket has after it has been added to the ticket system.

When the Master Team begins working on a new ticket, the ticket will first have to be Verified. Verifying the ticket involves making the described issue reproducible and making sure that the issue is an actual defect in the framework instead of working as intended. The verification process can in some cases also lead the ticket to be closed as can’t fix or duplicate. In these cases, an explanation for the reason is provided.

While verifying, the ticket reporter may be requested to provide additional information on the issue. Attaching a test case in the form of a UI class is the fastest way to get a ticket verified.

After the ticket has been verified, it will enter the Master Team’s work queue. Tickets prioritized by our support customers are handled before any other tickets to ensure their development never stalls because of a bug in Vaadin.

When a ticket is being worked on, it can have three different statuses: Developing (Accepted in the ticket system), Reviewing, or Designing. During the process, the status may switch back and forth between these statuses multiple times. The different statuses are mainly meant to communicate and reflect what’s actually going on with the ticket. There isn’t a set pattern in which order these statuses usually appear, but it’s fairly safe to say that developing takes place in between designing and reviewing.

After the ticket has passed the code review and the patch has been merged into the Vaadin master branch, it’s Fixed. The ticket milestone is then changed to Fixed in master to reflect the fact that the fix is merged.

Fixes in master branch are queued to be Released. Usually the fix is released during the next maintenance release which is shipped every two weeks. After the Master Team has picked the fix to the next maintenance release, the ticket milestone is again changed to reflect the maintenance release version. In some cases, the fix might introduce backwards incompatible changes that cannot be published in a maintenance release - then the milestone will be changed to the next minor or major release version.

Check out recently closed issues