пн, 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 >
