Some additional bug management questions needing decided are included in
this infra bug report:
More comments inline below:
On Mon, Feb 18, 2019 at 08:27:26PM +0100, Patrick Storz wrote:
Having worked with the tracker fo some time here's my list of
items (in no
particular order) that I feel need attention.
On Launchpad (LP) we used Milestones for targeting bugs (only
occasionally, though) but more importantly for tracking in which
release a fix landed. The latter seems of particular importance, as
release notes rely on it heavily.
I suggest to continue this practice and expand it to merge requests.
However this requires us all to make sure to actually set milestones
properly. Currently we often just close bugs without giving it
further thought (GitLab even does that automatically for us if a
suitable commit message is used), which would make it almost
impossible to keep track of the issues fixed in a particular
release. Even more so for MRs...
Yes, the workflow here is less structured than we had with
I agree that adding milestone labels is a good practice that we should
Linking to a MR, or even just pasting in the git commit message + SHA
can be vital not only for communicating that the issue is fixed, but
also where to find the fix (handy for packagers needing to cherrypick).
I'm a little unsure of how much we are going to be able to rely on
people remembering to do this, though. Are there other ideas for how we
could either enforce it, or implement something that'd do it
mechanically for us?
I feel that we need some mechanism to prioritize bugs. What is your
take on creating a set of prioritized labels of the form
"Importance: High" to replace LPs importance field?
I propose to use "Critical -> High -> Medium -> Low". Even above
critical I'd put the already existing label "Blocker". At the end of
the list I'd rank "Feature request". Does this sound reasonable? Or
is it too fine grained? Is handling "Blocker" and "Feature
as additional importance labels fine or should they be separate?
"Blocker" should not be used here; it's more something that should be
reserved for the discretion of the release management team. It
shouldn't be designatable by reporters or bug triagers.
Every bug is of utmost importance to whomever reports it, and so it's
natural to want your ticket to move to the head of the queue. Having a
"Blocker" state settable by bug reporters is awfully tempting to achieve
However, in most cases I think what people really want is to note that
they feel their issue is "Urgent", and maybe a "Regression". Those
might be more practical, useful tags.
(We may also want to have an escalation process, separate from labeling,
for the truly horrendous problems. However, between RocketChat and the
mailing lists I suspect we're ok for now. This is already mentioned in
Beyond that, I think "Critical" + Milestone (+ Assignee) should be
adequate for identifying ultra-severe bugs. If we have so many Critical
bugs that we need yet another state... well I think we must have bigger
So, I think your four state list of importances is good, and will be
straightforward to match with incoming Launchpad bugs. In SourceForge
we had a 10-point level for importance, but honestly that was too fine
grained and we mostly just used 3,6,9 iirc.
My guess is that developers care less about the importance level
assigned to a bug (unless its marked Critical), and more about if the
issue is a recent regression, or is against the section of code they've
been focusing on lately, or has an active user to engage with, or needs
an urgent fix.
I'm not sure labels are effective for tracking any of those, although
I've noticed some bug trackers (Bugzilla I think) have importance and
urgency as separate fields. Personally, for Inkscape, I think tracking
urgency gets a bit fiddly. We don't have a strictly managed bug
workflow, so it's very much a judgment call and won't map very well to
reality. And, if we did want a stricter workflow we'd probably best
look at the existing kanban functionality in gitlab first.
For Feature Requests we have this break out bug for reaching a decision:
From past discussions I've gathered the consensus is to hold
requests separately from actual bugs.
"Feature requests" actually comprise a spectrum from highly detailed
development plans, down to off-the-cuff random ideas and suggestions.
Part of what needs decided is what slice(s) of that spectrum we wish to
track, and where we want to track them.
My guess is if we allow some feature requests to commingle with the
bugs, it will be hard to judge what should and shouldn't be included,
so we could end up with a lot more piled into the tracker than we want.
"Only Actual Bugs in the Issue Tracker" is a clear distinction that will
be easier to control, I think. But I think we do need someplace for
them to end up.
o A general question is what labels we want to apply and how many
there should be. I'm a bit torn here, as a short list makes it
easier to keep track of the existing labels and avoids similar
issues being tagged differently, especially if there are
multiple similar choices or one tag is a sub/superset of
another. A longer list would help us categorize issues better
though. (For example: Do we want a tag for every packaging
option we have, e.g. AppImage, Flatpak, msi, exe, Windows Store,
...? Do we want a tag for every Linux distribution or just a
single "Linux" tag?).
Yes, this is a good question.
As a general philosophy, it may help to think, "Will this label help
towards getting the bug closed?"
I could see how having labels for issues specific to particular
packaging systems would be helpful - they'd enable those maintainers to
search for their bugs, and enable developers to ignore them. However, I
also wonder if it would be better if the packagers themselves had their
own separate bug trackers that focus on problems specific to that
package. For Ubuntu, Fedora, etc. there are already external bug
trackers (Launchpad and Bugzilla), and no need to duplicate efforts
there; but for non-Linux packages it might make more sense.
Where this may crop up in particular is for serious bugs that are fixed
in master, but need to be cherrypicked and hotpatched into the
packaging. We'd want those types of bugs marked Closed in our main
tracker since they are, indeed, resolved, but the packager would want to
have an open bug until they've had a chance to tackle it.
Beyond that, and in general, there is probably a balance between
"adequately categorized" and "over categorized", which is going to
depend a lot on the workflow of developers. For example,
labeling Gtk2, Gtk3, and Gtk4 issues distinctly would likely be useful,
whereas labels for what part of the UI the issue appears in may be
So, using the general philosophy mentioned above, I think labels should
be added where they enable developers to filter large classes of
issues they do or do not care about. I imagine this could include
crashes, regressions, SVG spec problems, file I/O, etc.
o Another question is if we want to categorize them (e.g.
"OS/Linux", "OS/Windows", "OS/Mac") or if we strip
category? The former ensures similar tags are sorted together
(otherwise they're sorted alphabetically) and *if* one remembers
the category name it makes it easy to get all relevant tags by
simply typing "OS", but then again tagging with just
seems more natural and the category might add noise. Also it
obviously requires some thought in order to create useful
categories (in contrast to just applying "random" tags that fit
and creating new ones on-the-fly). As I'm somebody who likes
order I tend to prefer categorization, but this is something I'd
like your opinion on. (Important note: The search is clever
enough to give you "OS/Windows" if you search for "win").
I've been using the web interface for adding labels, so if they are
prefixed with "OS/" that seems not to be a problem there. Being able to
organize them alphabetically seems really handy, and adopting a
consistent scheme will aid predictability. Once one got used to the
convention, then even tagging via slash commands or via email (if that's
possible) should be sufficiently convenient.
*On LP we had a detailed status field (new, confirmed, triaged, in
progress, fix commited, fix released - also: incomplete, opinion,
invalid, won't fix). Which of those do we want to replicate in
GitLab (and how?). We could obviously create a label for each of
them, but I have a feeling without a dedicated field it'd not be
o "new/confirmed" should be covered by "inkscape/inkscape" vs
"inkscape/inbox". Only confirmed issues should ever end up in
"inkscape/inkscape" (everything else should be confirmed or
moved to the inbox for triaging).
o "triaged" would be replaced by the presence (or
absence) of an
"Importance:" label should we choose to use them.
o "in progress": We already have a corresponding label
use it. Alternatively we could define that all assigned bugs are
"in progress" (i.e. only assign bugs if the assignee is going to
work on them eventually; un-assign otherwise)
In my experience developers are horrible about remembering to toggle
this state when they're actually working on a bug. It is usually pretty
obvious in context since they'll be commenting on it or have an attached
MR under way.
There are probably situations and development workflows where it makes
sense to have this. It may be useful if we're utilizing kanban, for
If developers feel it helps them organize their bugs they're currently
working on vs. ones they plan to do later, it may be worth having this
or similar tag. If not, then it's a superfluous tag we should drop.
o "fix commited/fix released": I don't know how to
reasonably. Is it even required?
I don't know how to replicate it either. I'd call it a nice-to-have
rather than required.
o "incomplete": We have "Need info" but such
bugs should usually
not be kept in "inkscape/inkscape" for extended periods of time
(if the info is not given, close or move back to "inbox")
Yes, agreed in general.
However, there are many situations where the bug is pretty well defined,
and easily reproducible, but there still isn't enough info for the
developer to work on it. E.g. they may need the user to run a special
build, or test out a diagnostic patch, or something.
o "opinion": should never exist in
o "invalid": Do we need a label? Or shall we just close in this
case and forget about it?
o "won't fix": should usually not make it into
- do we want a label or shall we just close (i.e. same question
as as for invalid?)
There are so many different reasons why a bug might get closed. In
addition to those three is also "Not our bug" and "Not actually a
I don't think we need labels for each contextual reason.
Better practice would be to include a message at time of closure
indicating a) the fix (e.g. git commit msg + SHA), or b) a short
explanation of the reason why it is being closed.
As suggested above we could use the assignee field to put devs who
are going to work on an issue eventually (i.e. indicate "this issue
is being looked into / will be looked into shortly").
Alternatively we could use it to indicate devs who are likely to be
able to fix the issue and are most suited for detailed triaging and
further investigation (i.e. indicate "we know somebody who might be
able to help, please wait until they find the time to check"). This
could be used to distribute and direct the workload a bit. However
we can likely do that with simple @mentioning?
I tend to prefer letting developers assign themselves bugs, except for
specific situations (like if they've created a regression, or if the
release team needs to direct attention on an urgent matter).
So, I really like the @mentioning approach. It flags attention without
committing them to owning the issue.
Sorry for the long text (I hope you all read up to this ;-)), it
got longer than intended... I'm looking forward to your opinions, though!
Thanks, all good issues I have been wondering about too.
Where do you think we should document these bug management guidelines?
A file in the inkscape/doc directory? Or wiki?