On Tue, Jan 08, 2019 at 07:18:07PM +0100, Tim Düsterhus wrote:
> Willy,
> Am 08.01.19 um 18:30 schrieb Willy Tarreau:
> > I totally agree. This is the tool I'm missing the most currently. I'm
> > not aware of a *good* and manageable issue tracker. Having a status for
> > a bug per branch most likely eliminates most of them...
> I'm not sure this is required. The bugfixes naturally land in the
> current development repository and have the affected branches in their
> commit message. They naturally "trickle down" to the maintained
> branches. So if the issue is marked as fixed the fix will *eventually*
> appear in the stable branch of the reporter.

Except that the "naturally" part here is manually performed by someone,
and an issue tracker is nothing more than an organized todo list, which
*is* useful to remind that you missed some backports. It regularly happens
to us, like when the safety of some fixes is not certain and we prefer to
let them run for a while in the most recent versions before backporting
them to older branches. This is exactly where an issue tracker is needed,
to remind us that these fixes are still needed in older branches.

If the issue tracker only tracks issues related to the most recent branch,
it will only solve the problem for this branch. For example, Veiko Kukk
reported in November that compression in 1.7.11 was broken again. How do
I know this ? Just because I've added an entry for this in my TODO file.
This bug is apparently a failed backport, so it requires that the original
bug is reopened and that any backport attempt to an older version is paused.
Without having cross-branches indications, you can't reliably do this. There
is a significant risk that the faulty fix gets backported to 1.6 before
anyone qualifies the issue.

This can possibly be dealt with using labels, I'm not sure how convenient
it will be.

> In my experience non-issues (a.k.a. RTFM) are usually easy to detect
> when reading through the explanation.

As long as there is manpower to clear them up it's OK, but this means
that some of us will count on you guys for this. With e-mails I don't
even need to do anything to stop reading a faulty bug report. The mail
is marked read once I glance over it, and I don't see it anymore. I
can also mark a whole thread as read when I see that any of the people
I trust here on the list start to respond. When reading an issue tracker,
the same issues pop up until I've done something with them. This makes a
huge difference. This is why I've always been highly concerned with the
risk of pollution.

> >> What you are describing basically is a unmaintained issue tracker,
> >> which is of course useless.
> >>
> >> But keeping people from filing new issues is the wrong approach to
> >> this, imho. Proper templating, triaging and correct labeling of the
> >> issues is the difference between a useless and a useful issue tracker
> >> from my point of view.
> > 
> > I do have strong doubts but I'm open to trying :-)
> I have to agree with Lukas here. Proper triaging is key here. And this
> is no different to email. You have to read email to decide what to do.

Yes but you don't have to act on them to stop seeing them ;-)

> And you have to read the issue to decide what to do.

Most of the time many of us will conclude they have nothing to do because
they're not the best people for this. When you have 10 people responsible
for different areas, on average 10% of the issues will be of interest to
them, and I want to be sure that we will not end up with developers looking
at the issue tracker and constantly seeing stuff that's not for them without
an easy way to definitely skip it and focus on their stuff. Again with
e-mail it's easy because without doing anything you don't see the same
e-mail again. Here if you have to label or ack all the stuff that's not
for you just in order not to see it again, it's inefficient.

But it can likely be improved with proper triaging.

> Labels in the issue tracker are like folders in your mailbox and the
> issue tracker itself is like a public mailbox.

That's exactly the problem. With e-mails, there's one state per reader,
here there's a single state that everyone has to share.

> I'd throw my hat into the ring as well. I maintain a few Open Source
> projects myself (though not of the size and importance of haproxy) and
> actually use the GitHub issue tracker.

Thanks. From what I've been used to see on github, very very few projects
do care about maintenance. Most of them are rolling releases. It actually
took me a very long time to try to figure one project with multiple
maintenance branches to see how they dealt with issues, and the few I
found by then had disabled issues, which could have already been a hint
about its suitability to the task. Just a few examples :

   Apache  : https://github.com/apache/httpd
   Squid   : https://github.com/squid-cache/squid
   Nginx   : https://github.com/nginx/nginx
   Linux   : https://github.com/torvalds/linux
   FreeBSD : https://github.com/freebsd/freebsd
   glibc   : https://github.com/bminor/glibc
   Gcc     : https://github.com/gcc-mirror/gcc
   binutils: https://github.com/bminor/binutils-gdb
   Xorg    : https://github.com/freedesktop/xorg-xserver
   OpenSSH : https://github.com/openssh/openssh-portable

You'll note that for many of them the repository is only a mirror by
the way, so that's another hint.

OpenSSL might be the only exception I could find :


It doesn't mean it's true for all projects, but there are not that many
projects taking care of maintenance, those above being the first ones that
come to mind, and surprisingly, except for one, they're in the same situation
as we are. I think they can't all be wrong :-)

Really github is cool for "develop fast, deploy fast" type of projects,
some of those deployed using "curl | sudo sh". In this model, issues are
more about "I just found a bug in latest version", "now it's fixed, pull
again", "confirmed".

I'm not saying it cannot be adapted to a more serious model taking care
of stable branches like the various projects above, I'm just saying that
it's easy to overlook its limitations which can make it more painful to
use in such a context, and that likely the projects above didn't figure
how to adapt it either.

> > Thanks a lot for these links, they are very informative. This utility
> > doesn't "yet" support cross-branches, but it's said that bugseverywhere
> > does. But bugseverywhere claims that its value is in keeping a hard
> > relation between bug's state and the fix in the tree, which precisely
> > is the wrong way to do it for me : I strongly prefer that the bug tracker
> > is never fully up to date regarding the resolved status for a branch than
> > having it believe the branch is fixed because it doesn't know that this
> > branch requires an extra patch. An apparently unresolved bug will be
> > noticed by the next person trying to resolve it. It's how it really
> > works with most developers and bug trackers in real life. I had too
> > quick a look at the other ones for now.
> Please don't opt for some obscure system. The biggest value of a public
> issue tracker to me is that people are actually are able to research
> whether their issue is already known / a duplicate and possible
> workarounds.

I agree and this is why I've been actively looking for such a public
system as well.

> The mail archive is not really accessible.

I know that it's mostly usable by insiders, and occasionally by outsiders,
but it's not convenient to search for an issue if you don't have your local
archives. And the repeated reports for certain old bugs we've seen in the
past obviously indicates that reporters didn't find the previous reports
before posting theirs.

> > With that said at the moment we don't have anything and the situation is
> > not better than having a suboptimal tool.
> I agree.

To be totally transparent, I really think the tool is not well suited and
that its main value is its large user base. But I also know that with you
and Lukas suggesting to use it, you both will deploy a lot of efforts to
build something good to prove me I'm wrong, possibly resulting in a nice
solution in the end. And if some people are willing to invest time
building something, it would be unfair from me to try to steer their
technical choices. Also, Lukas already managed to use the API to develop
some tools, maybe this will be welcome to add some automated state
transitions at some point.

So unless anyone has a better idea for now, and if you're feeling brave
enough, let's give it a try.


Reply via email to