Hi Lukas, On Tue, Aug 11, 2020 at 11:25:02PM +0200, Lukas Tribus wrote: > On Mon, 20 Jul 2020 at 06:35, Willy Tarreau <[email protected]> wrote: > > > (Another case is when I try to follow the issue reports during vacation) > > > > > > I think it could be easier and quicker by only changing the sections order > > > like this : > > > 1. Expected behavior > > > 2. Actual behavior > > > 3. Steps to reproduce the behavior > > > 4. Do you have any idea what may have caused this? > > > 5. Do you have an idea how to solve the issue? > > > 6. What's the configuration? > > > 7. Output of haproxy -vv and uname -a > > > > > > What do you think about it ? > > > > Actually I'm wondering whether we should merge points 1 and 2 above into > > "detailed description of the problem": sometimes it's easier to mention > > "I'm seeing this which I find strange" without knowing exactly what the > > expected behavior should be. We could indicate in the comments for this > > section "please clearly describe the whole problem, preferably starting > > with the expected behavior and followed by the actual behavior". > > > > And even then, I'm now thinking that most users would probably more > > naturally first describe what they observed then explain what they > > would have expected. This would flow more naturally: > > > > 1) subject of the bug report > > Not sure whether you are just referring to the title of the issue > (which actually is the subject already) or whether you are proposing > to add a new section: I feel like that's redundant and would advise > against it.
I was indeed speaking about the current title. > > 2) more detailed description matching the subject above: "when I > > do this, haproxy does that" > > That's what "Actual behavior" is. Are you suggesting we rephrase? I think that "Detailed description of the problem" can be more natural than just the actual behavior in that for some people providing a multi- step description, it could cover both the current and expected behavior. Quite often the expected behavior is something like "not crash :-)" which is definitely obvious, and implies that the current behavior is wrong. Sometimes it's more nuanced and it can be "does this while I'd expect that". And if the reporter has tested several workarounds, it's harder to place them under "actual behavior" than "detailed description". > I agree it should be at the beginning, before "expected behavior". > > > > 3) expected behavior: explain why what's described above is > > considered as wrong and what was expected instead (probably > > a mismatch with the doc, can be skipped if it's about a crash) > > 4, 5, 6, 7) unchanged > > 8) haproxy's last output if it crashed, gdb output if a core was > > produced > > 9) any additional info that may help (local patches, environment > > specificities, unusual workload, observations, coincidences > > with events on other components ...) > > Agreed. > > Features.md need's something similar (moving all the boring stuff below). Yes, probably indeed! By the way, I was a bit worried that the features entry would serve as unordered wish lists for some groups hoping to use them to vote for certain things, but for now it remains very reasonable and that's great. > Let me know about 1) and 2) above, and I will send a patch. You now get the idea, maybe my wording is not perfect and something is more suitable, so feel free to propose anything along these lines :-) Thanks! Willy
