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 : https://github.com/openssl/openssl/issues 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. Cheers, Willy
