Hi Cyril,
On Sun, Jul 19, 2020 at 11:59:14PM +0200, Cyril Bonté wrote:
> Hi all,
> If I remember well, Lukas maintains the github issues tempplate.
>
> Because of lack of time, I'm not able to read all emails since I receive
> github issues notifications. Time to time, I try to read them all but the
> current template makes the operation quite difficult because all issues
> first start with "haproxy -vv" output, hiding the important informations.
Actually I've encountered the same difficulty many times of finding
what the problem is, and figured that some users even forget to clearly
describe it. The purpose of having the version at the beginning is to make
sure users do not forget to post the versions. But maybe we can add a
mention about it in the template instead, such as "don't forget to append
the requested dumps at the end". This would also help request users to
also post haproxy's panics and run gdb on a core file and issue
"t a a bt full".
> (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
2) more detailed description matching the subject above: "when I
do this, haproxy does that"
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 ...)
Thanks,
Willy
