fdo-mirrors/libinput
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/libinput/libinput.git synced 2026-05-09 08:18:02 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

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

Browse source 
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit is contained in:
Peter Hutterer 2018-04-13 10:44:34 +10:00
parent b0a0627ae2
commit e9c53e09cf
1 changed files with 54 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

54
doc/reporting-bugs.dox
View file

@ -231,4 +231,58 @@ by the libinput version or whether a libinput context is currently active.
@dotfile evemu.gv @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.
*/ */