Hello Willy,
On Mon, Sep 23, 2019 at 7:02 PM Willy Tarreau <[email protected]> wrote: > > However it needs to be clear that the issue tracker in Github is not a > > support forum, and that filing a report will needs some ground work. > > It is also *always* a good idea to discuss an issue on the ML first, > > before filing an issue. > > I'm a bit torn between you two on this actually. There are several > reasons. The first one is that nobody is running the latest version > since a latest exists after a commit is pushed, and that at this game > it can circle forever. Some would say "but not released doesn't count" > and I'd argue that *new* bugs affecting -dev are even more important > to me than older ones since they are regressions, which is also why we > now have the CI running. > > However I also agree that it's important to encourage users to upgrade > *when they can*. > [...] > My hope is that we can encourage good faith among the reporters. 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. People can spend 3 minutes thinking about an issue, not reading the documentation or doing some basic due diligence and still fill out the template properly (including flagging whatever checkboxes we throw at them obviously). 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. 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; which is one additional round-trip as a consequence for a "false-positive" and at the same time, we may reduce the noise a lot. Templates and the rules implied in it don't apply to responses in issues (from other people), so nobody willing to provide additional infos to existing issues is impacted anyway. > [ ] 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. > 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. 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. I just think the bar can be a little bit higher without negative impact. Lukas
