Hi Lukas, On Tue, Sep 24, 2019 at 01:22:38AM +0200, Lukas Tribus wrote: > I realize I did not explain my point very well. I have to emphasize > that there is an important distinction between what we suggest in the > bug reporting template and what we actually *enforce*. Enforcements > happen considering the context, and that context is often more > important than actual rules. I believe we have done a good job > understanding and considering that context in the nearly 300 issue's > so far.
I think so as well. If you remember, initially I was the one who wanted that only a few of people could create issues, in order to avoid the issue tracker becoming a horrible mess. You and Tim suggested that it would work fine the way it works now and I accepted to test without being much convinced. As you can see you were right and I was wrong, because I think we mainly have a good quality in the bug reports (and the template does help a lot, just like the periodic cleanup you do there by chasing duplicates or closing those already fixed). My focus remains on limiting the overhead for people who can be a bottleneck, like the core developers and those sorting all these bugs like you do. Thus I always balance the savings on one side and the extra cost that could happen on the other side. And here I think that *right now* with users being autonomous enough to post their reports we don't have to do it ourselves, and keeping such a good balance while watching for risks of overloading the central people seems optimal. > On the other hand, important reports come in with > good informations in older release and are *clearly* relevant. But if > we have a report in 2.0.4 it is obvious that the OP did not install > haproxy from a CentOs repository, so asking for an upgrade is not some > far fetched fantasy. Sure but the primary purpose for which I initially wanted an issue tracker was for the hard reproducers that we were used to forget and that I was keeping enumerated in my own "TODO" e-mail. And where this issue tracker really helps is by helping to collect such information. When these rare reproducers happen, they rarely are on the latest version and this equation is hard to solve for users waiting for the next core, watchdog, deadlock, or strange issue to happen again. Despite this, developers seeing these reports can often judge whether this bug sounds totally new or not. I've see some excellent quality reports from William Dauchy and from Patrik there, I don't even remember if they were always on the last one but definitely they were insane bugs that I wanted to understand. > Context is key to understanding whether or not to > apply a rule (or whether to ask to reproduce in the latest release). > > I did not mean we should reject all issues that are not reproduced in > the latest release. However I do not feel like raising barriers to > file new issues is detrimental because in the absolute worst case, > people will ask about their problem on the mailing list or on > discourse as opposed to directly filing the issue; This was my initial expectation and based on how it works now I've figured I was wrong. Do you think we have that many bugs reported on too old versions that it is causing an issue (and possibly too much work on your side, because I know that I'm only seeing what remains from your cleanups) ? > > [ ] I confirm that I did my best to upgrade to the latest version > > before reporting this bug and I am also conscious that developers > > tend to be much less reactive on older versions. > > Frankly I'd not use this particular statement, because this wording > sounds vague to me and I feel like people can read into it whatever > they want to hear, including support for the 1.2 branch given enough > patience on their end. Also people fill out annoying forms every day, > a checkbox that begins with the words "I can confirm that I did my > best ..." is just a psychological NOP, personally I'm not sure I'd > actually read further than those words, immediately hitting that > checkbox. That's true. Thus maybe we can simply add this information (not a checkbox) : Bugs are expected to be reported on the latest version only. Beware that issues not respecting this expectation may simply be ignored or closed without explanation if developers think they match an already fixed issue. If you're facing constraints making it difficult for you to report on the latest version, you're highly encouraged to discuss your issue on the mailing list or discourse. This way we instruct the user while keeping the door open. > > Just thinking (not sure it's a good idea as it could attract too many > > reports), maybe we could have a check box that automatically sets an > > "incomplete" status for a bug report. This allows reporters to stick to > > facts and share them with others, this is convenient for rare bugs. > > We will have to check whether it's possible to map checkboxes to > labels, but yes, I'd be fine with that. Or we can have another button for this, but I fear that it would be randomly misused. > I'm actually also fine with maintaining the current template as-is and > I agree the issue tracker needs to be used to collect informations on > unkown bugs, which is especially useful if there are multiple > reporters. This definitely is one of the most important value it has brought so far. > I just think the bar can be a little bit higher without > negative impact. Unless you feel that it's starting to cause too much work on your side, from my developer's perspective at least it's still manageable as it is right now, with a positive balance, so I'd also be all for keeping it as it is, possibly just rewording a little bit or so if needed. Cheers, Willy
