Hi guys,
On Fri, Sep 20, 2019 at 03:47:17PM +0200, Lukas Tribus wrote:
> Hello Patrick,
>
>
> > I dunno, I've personally never been fond of it when bug reporters are
> > blindly asked to upgrade to the latest version.
>
> Everything you are saying is relevant for a support environment, like
> the mailing list or discourse. However the bug tracker is not a
> support forum, it's a bug tracker only. We need factual data,
> everything else belongs to the support channels. We needed this to
> file known bugs and features requests so we stop forgetting about them
> in the stream of emails and to coordinate fixes of known, confirmed
> bugs.
>
> Nobody is saying that problems need to be reported on Github. People
> seeking help ought to report their issues to the mailing list. If on
> the other hand those people are willing to file a bug report - and
> this implies some groundwork for them - then that's great, because it
> helps us.
>
> 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*. Patrick is right regarding the difficulty to upgrade
in some environments, I've worked in such environments and sometimes
you get a very strange behavior, you collect traces as fast as you can
and you want to archive your report in a safe place, shared by others,
knowing that it's incomplete but that it may help in the future when
it's confronted to another apparently similar one, coming from someone
with much less traces. In this regard the issue tracker is convenient
to keep some warm issues available and not forgotten even if we consider
them incomplete but credible.
Similarly some issues which trigger very late can by definition never
happen on the latest version. For example, just remove 3 lines in the
scheduler to allow to loop at the end of the tree back to the beginning
and suddenly all haproxy code deployed will fail after 49.7 days. And
we do want to get such reports that are extremely rare and valuable by
nature.
My hope is that we can encourage good faith among the reporters. I'd
suggest changing the question to something like this instead :
[ ] 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.
It doesn't necessarily *have* to be a check box, it just needs to be
prominent so that it's well understood.
With all this said, we're starting to see more bugs with multiple
participants and this is encouraging because that's exactly what is
needed to help narrow down an issue. Thus I'm not for really filtering
at the door, but rather making sure that the reporter thinks twice and
decides.
Typically those who install their fresh new PC with a default distro,
start the default haproxy (without updating the distro) and report an
issue should be reminded about trying again and upgrading first. But
those who have been chasing a bug for a month (like Veiko in the other
thread) an finally been hit by it with subtantial information (not
necessarily traces/conf, sometimes context explanations) should be
able to post if they think it does provide some value.
> > In corporate environments, it can be difficult to perform such upgrades.
> > Sometimes these issues are only reproducible in production environments.
>
> I know that. But that's not a bug report, it's a support request
Not necessarily. Regarding the example about the time looping at 49.7 days,
I actually experienced it with other products long ago. It definitely is a
bug. Just like I've seen some equipements get their VRRP desynchronized
progressively over time, the amount of desync grew by a few seconds in sine
waves of something like 24 days. The initially observable issue was that
sometimes there would be a quick failover and a switch back, and that over
a long period that would happen more often then less often. It's quite
difficult to qualify such a think but it definitely is a bug an not someone
asking for help. Sharing elements as they come can be useful, provided the
person accepts that this issue will not be handled for a while.
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.
Just my two cents,
Willy
