1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
=========================
Handling of gitlab issues
=========================
.. contents::
This document describes the life cycle and handling of upstream gitlab issues.
Issue is an aggregate term for bug reports, feature requests, user questions
and discussions.
For members of the project this is a guideline how to handle issues and how to
transition them between states based on the interaction with the reporter.
It is imperative we collaboratively keep the issues organized and labeled,
otherwise we'll end up creating an unnecessary maintenance burden for us.
For others, this article should only server as an outline what to expect when
filing an issue.
Types of issues
---------------
Every issue in our GitLab tracker bears the ``kind::`` namespace prefix. Once
triaged, each issue will have one of the following types assigned to it.
Note that issues can be moved freely between the different issue kinds if
needed.
Bugs - ``kind::bug``
~~~~~~~~~~~~~~~~~~~~
This issue describes a flaw in the functionality. The user is expected to
describe how to reproduce the issue and add `debug logs`_ or a backtrace of all
daemon threads in case any of the components crashed.
Feature requests - ``kind::enhancement``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This issue type describes non-existing functionality the user would like to add
to libvirt. Generally the issue should first focus on what the user wants to
achieve rather than any form of technical detail so that it's obvious what the
end goal is.
Detailed technical aspects can be described later but should not be the main
focus of the initial report. With a clear end-goal it's sometimes possible to
recommend another solution with the same impact.
User support queries - ``kind::support``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This label is used with issues which don't directly correspond to a flaw or
a missing feature in the project like usage-related queries.
Discussions - ``kind::discussion``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Any form of discussion which isn't related to any existing bug or feature
request.
States of issues
----------------
States allow project maintainers filtering out issues which need attention, so
please keep the issue state updated at all times.
Confirmed issues - ``state::confirmed``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In case of ``kind::bug`` issues the **confirmed** state means that there is
a real problem with the functionality and there is (seemingly) enough
information to figure out where the problem is and fix it.
``kind::enhancement`` issues should be marked as **confirmed** as long as the
general idea of the required functionality makes sense and would be in line
of the project strategy.
**Note:** Unless the issue is assigned to a specific person, the **confirmed**
state does not necessarily mean that anybody is actively looking to implement
the functionality or fix the problem. See the `disclaimer`_.
Unconfirmed issues - ``state::unconfirmed``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
``kind::bug`` issues are considered **unconfirmed** when there is seemingly
enough information describing the problem, but the triager is not sure whether
the problem would be considered a bug.
In case of ``kind::enhancement`` issues the **unconfirmed** state is similarly
used for feature requests which might not make sense.
In general use of the **unconfirmed** state should be avoided if possible,
although if the initial triager requests all necessary information from the
reporter, but is not sure about the issue itself it's okay to defer it to
somebody else by setting the ``state::unconfirmed`` label and thus deferring it
to somebody with more knowledge about the code.
Issues needing additional information from reporter - ``state::needinfo``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If additional information is requested from the reporter of the issue the
``state:needinfo`` label should be added, so that the issues can be easily
filtered.
If the reporter doesn't respond to the request in a timely manner (~2 weeks)
the issue should be closed prompting the reporter to reopen once they provide
the required information.
Triage process
--------------
The following steps should be applied to any new issue reported.
* Set the labels categorrizing the area of the issue, e.g. ``driver-qemu``,
``virsh``, ``xml`` etc. If an appropriate label is not available, add it.
* Check whether the reporter described the issue sufficiently.
If something is missing or unclear, ask for additional data and set
``state::needinfo``.
* Once all requested information is provided set the appropriate state:
- ``state::confirmed`` if you are certain where the bug is or that the
feature request makes sense
- ``state::unconfirmed`` to defer the investigation to somebody else
Issues needing attention
------------------------
The following gitlab search queries provide lists of issues which require
attention from the upstream community.
`Untriaged issues`_
Issues which haven't undergone the `Triage process`_ yet.
`Unconfirmed bugs`_
Bugs which should have all the information needed but the initial triager
couldn't determine nor confirm the problem.
`Unconfirmed features`_
Feature requests having the proper description of the request but it's not
yet clear whether the feature makes sense.
Assigning issues
----------------
When you plan to address an issue please assign it to yourself to indicate that
there's somebody working on it and thus prevent duplicated work.
Contribution possibility for non-members of the project
-------------------------------------------------------
Anyone is very welcome to assist in handling and triage of issues.
Even though non-members don't have permissions to set the labels mentioned
above, you can always post a comment to the issue, describing your findings or
prompt the reporter to provide more information (obviously adhering to the
`code of conduct`_) or even analyze where the problem lies followed by
submitting a patch to the mailing list.
Someone from the project members will then take care of applying the correct
label to the issue.
Disclaimer
----------
Please note that libvirt, like most open source projects, relies on
contributors who have motivation, skills and available time to work on
implementing particular features or fixing bugs as well as assisting the
upstream community.
Reporting an issue can be helpful for determining demand and interest or
reporting a problem, but doing so is not a guarantee that a contributor will
volunteer to implement or fix it.
We even welcome and encourage draft patches implementing a feature to be sent
to the mailing list where they can be discussed and further improved by the
community.
.. _Untriaged issues: https://gitlab.com/libvirt/libvirt/-/issues/?sort=created_date&state=opened¬%5Blabel_name%5D%5B%5D=state%3A%3Aunconfirmed¬%5Blabel_name%5D%5B%5D=state%3A%3Aneedinfo¬%5Blabel_name%5D%5B%5D=state%3A%3Aconfirmed&first_page_size=100
.. _Unconfirmed bugs: https://gitlab.com/libvirt/libvirt/-/issues/?sort=created_date&state=opened&label_name%5B%5D=kind%3A%3Abug&label_name%5B%5D=state%3A%3Aunconfirmed&first_page_size=100
.. _Unconfirmed features: https://gitlab.com/libvirt/libvirt/-/issues/?sort=created_date&state=opened&label_name%5B%5D=kind%3A%3Aenhancement&label_name%5B%5D=state%3A%3Aunconfirmed&first_page_size=100
.. _debug logs: https://libvirt.org/kbase/debuglogs.html
.. _code of conduct: governance.html#code-of-conduct
|
