Re: github template
Lukas, Am 16.08.20 um 22:27 schrieb Lukas Tribus: > The changes can be seen here: > > https://github.com/lukastribus/hap-issue-trial/issues/new/choose > > If you agree, I will send the patches. > I created a pull request for each of the three templates. If you are happy with those then please add the following to the squashed commit: Co-authored-by: Tim Duesterhus Best regards Tim Düsterhus
Re: github template
Hi Lukas, On Sun, Aug 16, 2020 at 10:27:24PM +0200, Lukas Tribus wrote: > The changes can be seen here: > > https://github.com/lukastribus/hap-issue-trial/issues/new/choose > > If you agree, I will send the patches. Looks perfect to me, many thanks! Willy
Re: github template
Hi, I prepared: - changes to Bug.md as per this discussion - changes to Features.md (just different sequence here) - added a new label "type: code-report" and a new issue template for those as well The changes can be seen here: https://github.com/lukastribus/hap-issue-trial/issues/new/choose If you agree, I will send the patches. Lukas
Re: github template
Hi again, On Wed, Aug 12, 2020 at 04:54:17AM +0200, Willy Tarreau wrote: > > 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 :-) Regarding a potential patch, I think we should really consider having new type, which is not exactly a bug but not a feature request either. The ones I'm having in mind are the valgrind and coverity reports, most of which are in fact 100% harmless but still potential bugs or "unclean" stuff, I don't really know how to qualify them. Maybe just "automated reports", which could even cover future tools. The issue is that it already happened to me twice to miss a real bug in the list when there were a burst of such reports occupying the main issues page. By nature they don't work the same way as bugs. They don't require the formalism of a real bug report, there are less round trips (i.e. I don't expect to see a "feedback required" status that often), they generally have no known impact so should be taken with less precedence than prod-blocking bugs, and can be handled by more people (especially the coverity reports). In addition, the valgrind reports present the risk to introduce real bugs when trying to fix them, just because the person looking at them may not necessarily know the affected area in deepest details, and it would be much safer to involve a knowledgeable maintainer. Also some of them will not be backported so there's an incentive to quickly act and close them, which is good because none should be seen rotting for a long time there. Having a special status will ease their listing and encourage eliminating them more regularly. Maybe we could add that as "test bot" (but some are really done by hand using a tool so that doesn't match). Actually I'm aware there's a slight difference between the coverity reports and valgrind reports, in that in the case of coverity it's a suspected issue while with valgrind it's a detected one. In the former case almost anyone can sort that out. In the second case, almost only the code's author knows and even sometimes it's hard, and a mistake done there becomes dramatic for stability. So maybe they're not exactly the same but in both cases they have no short term impact and some of them ought even not to be backported (which is why many of them are expected to be short lived). I'm open to ideas and suggestions. Cheers, Willy
Re: github template
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 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
Re: github template
Hello, On Mon, 20 Jul 2020 at 06:35, Willy Tarreau 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. >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 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). Let me know about 1) and 2) above, and I will send a patch. Lukas
Re: github template
I will comment next week, but I generally agree that we should move the version output to the end, as I noticed the same issue. expected/actual behaviour sections are painful in the obvious cases (dont crash/crash), but oftentimes users just assume their itent is obvious when it's really not. lukas
Re: github template
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
github template
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. (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 ? -- Cyril Bonté
