Hello Willy,

On Mon, Sep 23, 2019 at 7:02 PM Willy Tarreau <w...@1wt.eu> 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

Reply via email to