пн, 23 сент. 2019 г. в 22:02, Willy Tarreau <w...@1wt.eu>:

> 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.

I'm ok with that.

> 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

Reply via email to