doc: add a section on what happens when a bug was resolved

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

diff --git a/doc/reporting-bugs.dox b/doc/reporting-bugs.dox
index 3ffe599a39f0bf4a229ec5f6f9c74d2b5084d41c..ad0a4aee82048be5909de8e853a86a552172b50d 100644 (file)
--- 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.
+
+<b>Do not re-open a bug just because it hasn't trickled down to your
+distribution's package version yet.</b>
+
+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.
+
+<b>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.</b>
+
+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.
+
+<b>If a bug needs to be fixed urgently, file a bug in your distribution's
+bug tracker.</b>
+
+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.
+
+<b>Do not re-open a bug because your distribution didn't update to the
+release.</b>
+
+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.
+
 */