Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

All commits that are not truly trivial, should be accompanied by a ticket in the Jira system. When filing Jira tickets, there are a few steps and guidelines that are in orderIf you are having an Issue, but no code changes, you should create a new Issue on Github. If you have a patch ready, there is no need to create an issue, instead create the Pull Request immediately, following normal Github procedures.

Is it a duplicate?

Before filing a new bug, we encourage at least a cursory search across the existing open bugs to look for duplicates. Now, this is not a requirement, and in fact, we prefer more bugs than fewer bugs, even if it means we get some duplicates. Everyone, and that means you too, can help triaging bugs, and help identifying duplicates or invalid bugs.

What issue type is the ticket?

There's a number of types a bug in Jira can be, for example:

  • Bug - This would be the typical ticket type, indicating something is broken.
  • Improvement - Changes to an existing feature, which is not a bug
  • New Feature - A new feature (well, duh)
  • Wish - Something you really wish for (like a Unicorn). This is rarely used, New Feature is more reasonable.


Not everything is urgent or critical, and in most cases, leave the Priority at the default value (which is Major). If you know it's something of more or less priority, feel free to change that of course.


Every bug must have at least one component assigned to it, and in many cases, more than one can be appropriate. The list of components is fairly large, so make a best effort as to what it should be. If unsure, pick "Core" or "HTTP", or ask on IRC what would be appropriate.

Fix Version?

The Fix Version can be left empty ("unknown") or targeted as appropriate. It's of utmost importance here that the Fix Versions are accurate, because they are used to generate release reports. Therefore, there are also 3 rules to follow when closing tickets:

  1. If closed with a "Fixed" on master, make sure Fix Version is the current dev version (v3.3.5 as an example) 
  2. If closed as Invalid/won'tfix/duplicate, remove the Fix Version entirely. 
  3. When the bug is a backport, make sure it's targeted for the correct backport Fix Version (e.g. v3.2.5).


Igor: Please fill in this section, or refer to another page describing the backport process?


Please add appropriate labels to each Issue and PR.


Every Issue and PR should have a milestone, most likely the current development major version (which is currently v8.0.0).