From e9c53e09cf7325aac1be15146bb3ef189647bcfc Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 13 Apr 2018 10:44:34 +1000 Subject: [PATCH] doc: add a section on what happens when a bug was resolved Signed-off-by: Peter Hutterer --- doc/reporting-bugs.dox | 54 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/doc/reporting-bugs.dox b/doc/reporting-bugs.dox index 3ffe599a..ad0a4aee 100644 --- a/doc/reporting-bugs.dox +++ b/doc/reporting-bugs.dox @@ -231,4 +231,58 @@ by the libinput version or whether a libinput context is currently active. @dotfile evemu.gv +@section fixed_bugs My bug was closed as fixed, what now? + +libinput's policy on closing bugs is: once the fix for a given bug is on git +master, the bug is considered fixed and the bugzilla entry will be closed +accordingly. + +Of course, unless you actually run git master, the bug will continue to +affect you on your local machine. You are most likely running the +distribution's package and you will need to wait until the distribution has +updated its package accordingly. + +Do not re-open a bug just because it hasn't trickled down to your +distribution's package version yet. + +Whether the bug fix ends up in your distribution depends on a number of +things. Any given bug fix **may** be cherry-picked into the current stable +branch, depending on its severity, impact, and likelyhood to cause +regressions. Once cherry-picked it will land in the next stable branch +release. These are usually a few weeks apart. + +Do not re-open a bug because it wasn't picked into a stable branch +release or because your distribution didn't update to the latest stable +branch release. + +Stable branches are usually discontinued when the next release comes out. + +Your distribution may pick a patch up immediately and ship the fix +even before the next stable branch update is released. For example, Fedora +does this frequently. + +If a bug needs to be fixed urgently, file a bug in your distribution's +bug tracker. + +Patches on git master will end up in the next libinput release. Once your +distribution updates to that release, your local libinput version will +contain the fix. + +Do not re-open a bug because your distribution didn't update to the +release. + +You can always run libinput from git master (see @ref building_libinput). +Even while in development, libinput is very stable so this option isn't as +scary as it may sounds. + +@subsection reporting_bugs_reopen When is it ok to re-open a fixed bug? + +Any time the bug was considered fixed but it turns out that the fix is +insufficient and/or causes a regression. + +However, if the regression is in behavior unrelated to the fix itself it is +usually better to file a new bug to reduce the noise. For example, if a fix +to improve tapping breaks two-finger scrolling behavior, you should file a +new bug but reference the original bug. + */