Re: haproxy issue tracker discussion
Cool, thanks :-) Ursprüngliche Nachricht Von: Lukas Tribus Gesendet: 18. Jänner 2019 14:14:06 MEZ An: Aleksandar Lazic CC: haproxy , Willy Tarreau , "Tim Düsterhus" Betreff: Re: haproxy issue tracker discussion Hello Aleksandar, On Fri, 18 Jan 2019 at 12:54, Aleksandar Lazic wrote: > > Hi. > > As there are now the github templates in the repo can / should we start to > create issues & features on github? Yes, you can go ahead and start filing bugs and features. There's some minor tweaking yet to be done regarding the subsystem labels, but that's not really a blocking issue. Once that is done, I will send out a proper announcement on the list (tomorrow, probably). Lukas
Re: haproxy issue tracker discussion
Hello Aleksandar, On Fri, 18 Jan 2019 at 12:54, Aleksandar Lazic wrote: > > Hi. > > As there are now the github templates in the repo can / should we start to > create issues & features on github? Yes, you can go ahead and start filing bugs and features. There's some minor tweaking yet to be done regarding the subsystem labels, but that's not really a blocking issue. Once that is done, I will send out a proper announcement on the list (tomorrow, probably). Lukas
Re: haproxy issue tracker discussion
Hi. As there are now the github templates in the repo can / should we start to create issues & features on github? Regards Aleks Ursprüngliche Nachricht Von: Willy Tarreau Gesendet: 14. Jänner 2019 04:11:17 MEZ An: "Tim Düsterhus" CC: Lukas Tribus , haproxy Betreff: Re: haproxy issue tracker discussion On Mon, Jan 14, 2019 at 03:06:54AM +0100, Tim Düsterhus wrote: > May I suggest the following to move forward? (...) > That way we can test the process with a small, unimportant, test issue. > The automated closing based on the labels can than be added a few days > later. I don't expect huge numbers of issues right away, so they can be > closed by hand. Sounds good to me. Thanks guys! Willy
Re: haproxy issue tracker discussion
On Mon, Jan 14, 2019 at 03:06:54AM +0100, Tim Düsterhus wrote: > May I suggest the following to move forward? (...) > That way we can test the process with a small, unimportant, test issue. > The automated closing based on the labels can than be added a few days > later. I don't expect huge numbers of issues right away, so they can be > closed by hand. Sounds good to me. Thanks guys! Willy
Re: haproxy issue tracker discussion
Willy, Lukas, Am 14.01.19 um 02:08 schrieb Lukas Tribus: > My simple github script which relays the PR to the mailing list uses > the GH Rest API through the agithub client [1]. I will have a look at > how extensible it is, but extracting labels of closed issues and > reopening it if it contains one of the "affected" labels should be > quite simple. I suggest to not fully rely on the webhooks (they might not be delivered under high load). Also: The automated closing / opening should only happen for type: bug labels. > I added labels based on the previous discussion (and removing and > skipping some of them, as we are already at 30 labels anyway): > > https://github.com/lukastribus/hap-issue-trial/labels?sort=name-asc I suggest to make it less colorful. e.g. use a single color for all the subsystems (they are probably the least interesting label). --- May I suggest the following to move forward? 1. Enable the issue tracker on GitHub. 2. Set up the labels based in the list in Lukas' repository. 3. Prepare a patch that adds the issue templates, with a `see #1` in the commit message body. Ideally Lukas would do this, he did the bulk work of testing with the templates (you can add me as a Co-authored-by: Tim Düsterhus at the bottom). Lukas: You probably need to update the "bug" label to "type: bug" in the Bug.md template. 4. Someone creates a first issue titled "Add issue templates". 5. The patch is merged by Willy. 6. The issue is being closed by Willy. That way we can test the process with a small, unimportant, test issue. The automated closing based on the labels can than be added a few days later. I don't expect huge numbers of issues right away, so they can be closed by hand. Best regards Tim Düsterhus
Re: haproxy issue tracker discussion
Hello, On Sat, 12 Jan 2019 at 13:38, Willy Tarreau wrote: > > The situation on GitHub does not need to mirror the situation on > > haproxy.org. You could still use separated repositories on haproxy.org > > to separate permissions and push the "validated" commits to GitHub. This > > is what the PHP project does. The canonical repositories lives on their > > infrastructure and GitHub is a mirror only. They have a pre-receive hook > > that prevents pushes if files / branches outside one's permission set > > are touched: https://github.com/php/karma/blob/master/hooks/pre-receive Cool, did not know that. > > Just mentioning the issue does not close it! You have to prefix the > > number with a "(Fix(es)?|Closes?)". > > Mentioning the issue comes with the nice property that the commit > > appears in the timeline of the issue, which I consider useful. > > Got it, I didn't think about this, makes sense indeed. I agree that > given that we'll have unique ID numbers across all branches, it would > be sad not to be able to easily reference them. Yes, I agree that ideally we should be able to reference the issue #ID from the commits, and if we can mirror stable branches into the same repository on github, it should just work for all of them. > > > Mind you that I don't have any idea what language this code block uses nor > > > where it has to be stuffed, so I'll trust you :-) > > > > It's the Graph Query Language the v4 API of GitHub uses: > > https://developer.github.com/v4/. You send it as the body of the HTTP > > API request and get back a JSON formatted reply with the data you asked > > for. And if it's non-empty you send a new API request that opens / > > closes the issue in question. > > Where it needs to be stuffed: On some server that runs a cronjob / > > ingests the webhooks. :-) > > Thanks for the explanation. > > > In the long run it can probably be stuffed as a GitHub Action and be > > part of the repository (in the .github folder). They are still a Beta, > > though: https://developer.github.com/actions/ > > Thanks for the link, I wasn't aware of this. Yeah I think there are a lot of possibilities. My simple github script which relays the PR to the mailing list uses the GH Rest API through the agithub client [1]. I will have a look at how extensible it is, but extracting labels of closed issues and reopening it if it contains one of the "affected" labels should be quite simple. I added labels based on the previous discussion (and removing and skipping some of them, as we are already at 30 labels anyway): https://github.com/lukastribus/hap-issue-trial/labels?sort=name-asc Also Tim improved the issue templates. Regards, Lukas [1] https://github.com/mozilla/agithub
Re: haproxy issue tracker discussion
On Sat, Jan 12, 2019 at 01:09:08PM +0100, Tim Düsterhus wrote: > Willy, > > Am 12.01.19 um 12:45 schrieb Willy Tarreau: > >> This example makes me wonder, though: Should the various branches be > >> separate repositories on GitHub like on haproxy.org or should they be > >> actual branches (e.g. 1.8.x in haproxy/haproxy instead of > >> haproxy/haproxy-1.8) for the mirror? > > > > I've been thinking about this for a while in the past, which is the > > reason why we purposely didn't upload the other branches yet. On the > > one hand having all branches at once in a single repository is > > convenient to retrieve everything at once. On the other hand, most > > people cloning the repo are not interested in retrieving maintenance > > versions for old branches. In addition, while at the moment and for > > simplicity reasons, all stable maintainers do have write access to > > the master repository, in the future we could imagine delegating some > > outdated branches to certain contributors who still need to maintain > > them for whatever reason, and in this case we might not feel much at > > ease with granting them a write access to all other repos and have to > > face their occasional mistakes. > > The situation on GitHub does not need to mirror the situation on > haproxy.org. You could still use separated repositories on haproxy.org > to separate permissions and push the "validated" commits to GitHub. This > is what the PHP project does. The canonical repositories lives on their > infrastructure and GitHub is a mirror only. They have a pre-receive hook > that prevents pushes if files / branches outside one's permission set > are touched: https://github.com/php/karma/blob/master/hooks/pre-receive > > The post-receive hook would then do the following for dev: > > git push github master:master > git push github --tags > > And this for 1.8: > > git push github master:1.8.x > git push github --tags Well, maybe indeed. However if a new maintainer comes and wants to follow a different process he will need the permissions to push to GH. But you're making a point that anyway GH is only a mirror so he'll have to have access to haproxy.org and publish the reference there, so that might work anyway. As you see, I'm mentioning use cases, though I'll probably not be the one having the last word on the implementation given that I'll rely on others' help. > Just mentioning the issue does not close it! You have to prefix the > number with a "(Fix(es)?|Closes?)". > Mentioning the issue comes with the nice property that the commit > appears in the timeline of the issue, which I consider useful. Got it, I didn't think about this, makes sense indeed. I agree that given that we'll have unique ID numbers across all branches, it would be sad not to be able to easily reference them. > > Mind you that I don't have any idea what language this code block uses nor > > where it has to be stuffed, so I'll trust you :-) > > It's the Graph Query Language the v4 API of GitHub uses: > https://developer.github.com/v4/. You send it as the body of the HTTP > API request and get back a JSON formatted reply with the data you asked > for. And if it's non-empty you send a new API request that opens / > closes the issue in question. > Where it needs to be stuffed: On some server that runs a cronjob / > ingests the webhooks. :-) Thanks for the explanation. > In the long run it can probably be stuffed as a GitHub Action and be > part of the repository (in the .github folder). They are still a Beta, > though: https://developer.github.com/actions/ Thanks for the link, I wasn't aware of this. > > OK, that's manageable I guess, thanks. I find it a bit annoying that it uses > > the code repository to store the github interface configuration but aside > > this it's probably OK. > > At least you can use the .github/ hidden folder now. In former times > they had to be placed at the root of the repository. Ah so we're seeing the improved version :-) > status: pending-backport > >>> > >>> I think this one is implied by the presence of "affects:" > >> > >> Not necessarily. "affects" without "pending-backport" probably needs > >> more work finding the issue first, while "pending-backport" can be as > >> easy as a cherry-pick. > > > > OK I see your point but in this case the dev branch is fixed, > > "affects: dev" is not there anymore then pending-backport is implied > > by ("affects: 1.x" and not "affects: dev"). This even works for bugs > > that only affect older branches. > > Does it? What if a bug is found that only affects the current stable > branch, but not dev, because some refactoring "accidentally" fixed it? In practice we *always* first try to diagnose the issue in -dev. The only case where dev is not affected but an older branch is affected is when we have diagnosed it enough to know that dev is really not affected. However I'm seeing the problem with -dev : we need to know that a fix is known. It's the "status: resolved" that b
Re: haproxy issue tracker discussion
Willy, Am 12.01.19 um 12:45 schrieb Willy Tarreau: >> This example makes me wonder, though: Should the various branches be >> separate repositories on GitHub like on haproxy.org or should they be >> actual branches (e.g. 1.8.x in haproxy/haproxy instead of >> haproxy/haproxy-1.8) for the mirror? > > I've been thinking about this for a while in the past, which is the > reason why we purposely didn't upload the other branches yet. On the > one hand having all branches at once in a single repository is > convenient to retrieve everything at once. On the other hand, most > people cloning the repo are not interested in retrieving maintenance > versions for old branches. In addition, while at the moment and for > simplicity reasons, all stable maintainers do have write access to > the master repository, in the future we could imagine delegating some > outdated branches to certain contributors who still need to maintain > them for whatever reason, and in this case we might not feel much at > ease with granting them a write access to all other repos and have to > face their occasional mistakes. The situation on GitHub does not need to mirror the situation on haproxy.org. You could still use separated repositories on haproxy.org to separate permissions and push the "validated" commits to GitHub. This is what the PHP project does. The canonical repositories lives on their infrastructure and GitHub is a mirror only. They have a pre-receive hook that prevents pushes if files / branches outside one's permission set are touched: https://github.com/php/karma/blob/master/hooks/pre-receive The post-receive hook would then do the following for dev: git push github master:master git push github --tags And this for 1.8: git push github master:1.8.x git push github --tags > This matches perfectly the situation I've been into with the kernel: > I inherited old ones and other developers didn't have to be scared by > my mistakes because I could only affect the part I was responsible for. > As such it makes me think that it's probably better to only have the > master branch in the main repo, and create separate repos for the > maintenance branches. > >> The former would require referencing issues as haproxy/haproxy#123. The >> latter allows for a more simple #123. > > Given that we'd prefer *not* to see them automatically closed, I don't > see this as a limitation, on the opposite! Just mentioning the issue does not close it! You have to prefix the number with a "(Fix(es)?|Closes?)". Mentioning the issue comes with the nice property that the commit appears in the timeline of the issue, which I consider useful. >> The following GitHub v4 API query pulls issues with >> state == OPEN && (label == "1.6-affected" || label == "enhancement") >> for Lukas' test repository from the API. "enhancement" is to be replaced >> by the other "*-affected" labels. >> >> { >> repository(owner: "lukastribus", name: "hap-issue-trial") { >> issues(states: [OPEN], labels: ["1.6-affected", "enhancement"], >> last: 100) { >> nodes { >> title >> } >> } >> } >> } > > Mind you that I don't have any idea what language this code block uses nor > where it has to be stuffed, so I'll trust you :-) It's the Graph Query Language the v4 API of GitHub uses: https://developer.github.com/v4/. You send it as the body of the HTTP API request and get back a JSON formatted reply with the data you asked for. And if it's non-empty you send a new API request that opens / closes the issue in question. Where it needs to be stuffed: On some server that runs a cronjob / ingests the webhooks. :-) In the long run it can probably be stuffed as a GitHub Action and be part of the repository (in the .github folder). They are still a Beta, though: https://developer.github.com/actions/ - and issue and feature request template >>> >>> For this one I have no idea since I don't know much how it works. >> >> You need to a markdown file to the .github/ISSUE_TEMPLATE folder in the >> repository: >> >> https://github.com/lukastribus/hap-issue-trial/blob/master/.github/ISSUE_TEMPLATE/Bug.md >> >> see: >> https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/ > > OK, that's manageable I guess, thanks. I find it a bit annoying that it uses > the code repository to store the github interface configuration but aside > this it's probably OK. At least you can use the .github/ hidden folder now. In former times they had to be placed at the root of the repository. status: pending-backport >>> >>> I think this one is implied by the presence of "affects:" >> >> Not necessarily. "affects" without "pending-backport" probably needs >> more work finding the issue first, while "pending-backport" can be as >> easy as a cherry-pick. > > OK I see your point but in this case the dev branch is fixed, > "affects: dev" is not there anymore then pending-backport is implied > by ("affects: 1.x" and not "affects: dev").
Re: haproxy issue tracker discussion
Hi Tim, On Sat, Jan 12, 2019 at 12:24:23PM +0100, Tim Düsterhus wrote: > > This one is less of a problem because the likelihood that someone writes > > "fixes haproxy/haproxy/#4" in a commit message is particularly low, unless > > they do it on purpose to annoy us of course. > > It would only close on us, if the person creating the other commit had > the necessary permissions in our issue tracker. OK. > This example makes me wonder, though: Should the various branches be > separate repositories on GitHub like on haproxy.org or should they be > actual branches (e.g. 1.8.x in haproxy/haproxy instead of > haproxy/haproxy-1.8) for the mirror? I've been thinking about this for a while in the past, which is the reason why we purposely didn't upload the other branches yet. On the one hand having all branches at once in a single repository is convenient to retrieve everything at once. On the other hand, most people cloning the repo are not interested in retrieving maintenance versions for old branches. In addition, while at the moment and for simplicity reasons, all stable maintainers do have write access to the master repository, in the future we could imagine delegating some outdated branches to certain contributors who still need to maintain them for whatever reason, and in this case we might not feel much at ease with granting them a write access to all other repos and have to face their occasional mistakes. This matches perfectly the situation I've been into with the kernel: I inherited old ones and other developers didn't have to be scared by my mistakes because I could only affect the part I was responsible for. As such it makes me think that it's probably better to only have the master branch in the main repo, and create separate repos for the maintenance branches. > The former would require referencing issues as haproxy/haproxy#123. The > latter allows for a more simple #123. Given that we'd prefer *not* to see them automatically closed, I don't see this as a limitation, on the opposite! > > I'm wondering if based on the previous work you did on the > > pull requests using the API it would be possible to : > > - reopen closed issues that still have a "*-affected" or "needs triage" > > label > > - close issues that don't have "*-affected" nor "needs triage" > > > > In this case it would mean we just need to use the labels and not care > > about the state at all. > > Yes. You can pull issues with a specific state and a specific label from > the API and you can receive webhooks when an issue is being opened or > closed. Fine! > The following GitHub v4 API query pulls issues with > state == OPEN && (label == "1.6-affected" || label == "enhancement") > for Lukas' test repository from the API. "enhancement" is to be replaced > by the other "*-affected" labels. > > { > repository(owner: "lukastribus", name: "hap-issue-trial") { > issues(states: [OPEN], labels: ["1.6-affected", "enhancement"], > last: 100) { > nodes { > title > } > } > } > } Mind you that I don't have any idea what language this code block uses nor where it has to be stuffed, so I'll trust you :-) > >> - and issue and feature request template > > > > For this one I have no idea since I don't know much how it works. > > You need to a markdown file to the .github/ISSUE_TEMPLATE folder in the > repository: > > https://github.com/lukastribus/hap-issue-trial/blob/master/.github/ISSUE_TEMPLATE/Bug.md > > see: > https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/ OK, that's manageable I guess, thanks. I find it a bit annoying that it uses the code repository to store the github interface configuration but aside this it's probably OK. > >> status: pending-backport > > > > I think this one is implied by the presence of "affects:" > > Not necessarily. "affects" without "pending-backport" probably needs > more work finding the issue first, while "pending-backport" can be as > easy as a cherry-pick. OK I see your point but in this case the dev branch is fixed, "affects: dev" is not there anymore then pending-backport is implied by ("affects: 1.x" and not "affects: dev"). This even works for bugs that only affect older branches. It's even better as we have always implied that a backport to a branch is not welcome until the next branch is fixed. Thus the "backport-pending" for a branch is always deduced from "affects: branch" and not "affects:next branch". Willy
Re: haproxy issue tracker discussion
Willy, Am 12.01.19 um 08:47 schrieb Willy Tarreau: >> The following issue was closed ... : >> https://github.com/lukastribus/hap-issue-trial/issues/3 >> >> from another repository, just because I referenced the issue >> prepending the word "Fix": >> https://github.com/lukastribus/hap-issue-trial-1.8/commit/91a0776fec856766c64b8f3a34a796718c2368c1 > > This one is less of a problem because the likelihood that someone writes > "fixes haproxy/haproxy/#4" in a commit message is particularly low, unless > they do it on purpose to annoy us of course. It would only close on us, if the person creating the other commit had the necessary permissions in our issue tracker. This example makes me wonder, though: Should the various branches be separate repositories on GitHub like on haproxy.org or should they be actual branches (e.g. 1.8.x in haproxy/haproxy instead of haproxy/haproxy-1.8) for the mirror? The former would require referencing issues as haproxy/haproxy#123. The latter allows for a more simple #123. >> As our intention I believe is to keep the issue open until all >> affected branches are fixed, this github feature is a little >> inconvenient. But I guess we can just refer to the issue by prepending >> it with "issue" or "bug", so GH doesn't see "Fix". Still it feels like >> we are working against the system. > > As often yes. I'm wondering if based on the previous work you did on the > pull requests using the API it would be possible to : > - reopen closed issues that still have a "*-affected" or "needs triage" > label > - close issues that don't have "*-affected" nor "needs triage" > > In this case it would mean we just need to use the labels and not care > about the state at all. Yes. You can pull issues with a specific state and a specific label from the API and you can receive webhooks when an issue is being opened or closed. The following GitHub v4 API query pulls issues with state == OPEN && (label == "1.6-affected" || label == "enhancement") for Lukas' test repository from the API. "enhancement" is to be replaced by the other "*-affected" labels. { repository(owner: "lukastribus", name: "hap-issue-trial") { issues(states: [OPEN], labels: ["1.6-affected", "enhancement"], last: 100) { nodes { title } } } } >> - and issue and feature request template > > For this one I have no idea since I don't know much how it works. You need to a markdown file to the .github/ISSUE_TEMPLATE folder in the repository: https://github.com/lukastribus/hap-issue-trial/blob/master/.github/ISSUE_TEMPLATE/Bug.md see: https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/ >> status: pending-backport > > I think this one is implied by the presence of "affects:" Not necessarily. "affects" without "pending-backport" probably needs more work finding the issue first, while "pending-backport" can be as easy as a cherry-pick. Best regards Tim Düsterhus
Re: haproxy issue tracker discussion
Lukas, Am 12.01.19 um 02:53 schrieb Lukas Tribus: > As our intention I believe is to keep the issue open until all > affected branches are fixed, this github feature is a little > inconvenient. But I guess we can just refer to the issue by prepending > it with "issue" or "bug", so GH doesn't see "Fix". Still it feels like > we are working against the system. Simply doing "see #123" / "ref #123" instead of "Fixes #123" probably would work as well. The rest of the message probably makes it clear that it's a fix. > - a rough consensus of the process (like the sequence above) It's looking good. I believe the initial "needs-triage" label can be added using the template: https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/ (step 5). Best regards Tim Düsterhus
Re: haproxy issue tracker discussion
Hi Lukas, On Sat, Jan 12, 2019 at 02:53:45AM +0100, Lukas Tribus wrote: > Hi Tim, Willy, > > apologies for not responding sooner, I always have to force myself to > policy/organizational discussions, when I can also read stack or > straces :) You really don't need to apologize :-) > > So in the end we can live with simply "affects-1.8" etc and remove these > > flags once the fix(es) is/are backported. > > I like that. If it has that branch specific affected label, we know > there is still something to do. We can add and remove a label multiple > times if required (when having backporting issues). > > So for example a new issue is opened and handled in the following sequence? > > - OP opens a new issue > - we assign generic default labels, for example: needs-triage > - first human responder may ask for further information's, adds > status: gathering feedback > - OP responds with additional information's > - triaging occurs, removing status: gathering feedback, needs-triage; > adding bug, dev-affected, 1.8-affected, 1.7-affected, bisected > - assigning for example a MAINTAINER to the bug (would be useful if > MAINTAINERS had github accounts and we document those in the file) > - the bug is fixed in -dev and marked for backport, removing dev-affected > - backported to 1.8, removing 1.8-affected > - backported to 1.7, removing 1.7-affected and closing issue (all > backports completed) > - OP reports the bug is still present in 1.7 (post fix) > - we re-open the issue add 1.7-affected again This last point is exactly what I was thinking as well and I like this. I consider issues a cleaner and more reliable todo-list. It follows exactly the process we're currently living with. In my todo notes it's sometimes written "backport Foo's fix to 1.7". And this can be added at any point in time, even when backporting it to 1.8 because it was only diagnosed as affecting 1.8 and during the backport it was figured that it in fact also affects another one. Another good point is that it can allow us to emit an emergency fix for a previously closed branch if we think it comes with a low cost and is worth it. Then it's trivial to reopen the issue for this unplanned operation. > - after a new fix for 1.7 has been committed, remove the label and > close the issue again Yep. > Just to get a feel for it, I'm playing with a trial repo here: > https://github.com/lukastribus/hap-issue-trial/ > > I added some labels, stole template from another project (restic) with > slight modifications and talked to myself over some issue. Also tried > referencing issues from commits and vice-versa. It's a good idea to have a label the suggested severity level. It doesn't prevent the developer from changing it later (especially increasing it) but it definitely helps. It even allows to lower it when the last backports only are pending and the issue is less important (this is quite common, like crashes in 1.9 but only returns an error in 1.8). > I don't like how github automatically closes issues when commits refer > to a issue prepended with some specific words like Fix or resolves: > https://help.github.com/articles/closing-issues-using-keywords/ It's always been one of my concerns as well. In some projects, contributors provide fixes with their internal bug IDs, and this can automatically close random issues when IDs collide. As usual it shows that the tool focuses more on ease of use and limited effort than accuracy and fine-grained control. > The following issue was closed ... : > https://github.com/lukastribus/hap-issue-trial/issues/3 > > from another repository, just because I referenced the issue > prepending the word "Fix": > https://github.com/lukastribus/hap-issue-trial-1.8/commit/91a0776fec856766c64b8f3a34a796718c2368c1 This one is less of a problem because the likelihood that someone writes "fixes haproxy/haproxy/#4" in a commit message is particularly low, unless they do it on purpose to annoy us of course. > As our intention I believe is to keep the issue open until all > affected branches are fixed, this github feature is a little > inconvenient. But I guess we can just refer to the issue by prepending > it with "issue" or "bug", so GH doesn't see "Fix". Still it feels like > we are working against the system. As often yes. I'm wondering if based on the previous work you did on the pull requests using the API it would be possible to : - reopen closed issues that still have a "*-affected" or "needs triage" label - close issues that don't have "*-affected" nor "needs triage" In this case it would mean we just need to use the labels and not care about the state at all. > So we'd have to define: > > - a rough consensus of the process (like the sequence above) > - the actual set of labels Your proposal below looks reasonably good, probably we can refine them later. > - and issue and feature request template For this one I have no idea since I don't know much how it works. > I like the type and status labels o
Re: haproxy issue tracker discussion
Hi Tim, Willy, apologies for not responding sooner, I always have to force myself to policy/organizational discussions, when I can also read stack or straces :) >> When should the binary "issue open" / "issue closed" property be >> toggled? When the issue is fixed in Dev? When the issue is fixed in the >> lowest affected version? > > [...] > Conclusion : the affected status is only temporary and enough to go > once the backport is done. This simply means we don't need a "fixed-1.9" > or whatever, we just have to remove the "affected" label exactly as it > would have been if the issue had been reported the day after. > > So in the end we can live with simply "affects-1.8" etc and remove these > flags once the fix(es) is/are backported. I like that. If it has that branch specific affected label, we know there is still something to do. We can add and remove a label multiple times if required (when having backporting issues). So for example a new issue is opened and handled in the following sequence? - OP opens a new issue - we assign generic default labels, for example: needs-triage - first human responder may ask for further information's, adds status: gathering feedback - OP responds with additional information's - triaging occurs, removing status: gathering feedback, needs-triage; adding bug, dev-affected, 1.8-affected, 1.7-affected, bisected - assigning for example a MAINTAINER to the bug (would be useful if MAINTAINERS had github accounts and we document those in the file) - the bug is fixed in -dev and marked for backport, removing dev-affected - backported to 1.8, removing 1.8-affected - backported to 1.7, removing 1.7-affected and closing issue (all backports completed) - OP reports the bug is still present in 1.7 (post fix) - we re-open the issue add 1.7-affected again - after a new fix for 1.7 has been committed, remove the label and close the issue again Just to get a feel for it, I'm playing with a trial repo here: https://github.com/lukastribus/hap-issue-trial/ I added some labels, stole template from another project (restic) with slight modifications and talked to myself over some issue. Also tried referencing issues from commits and vice-versa. I don't like how github automatically closes issues when commits refer to a issue prepended with some specific words like Fix or resolves: https://help.github.com/articles/closing-issues-using-keywords/ The following issue was closed ... : https://github.com/lukastribus/hap-issue-trial/issues/3 from another repository, just because I referenced the issue prepending the word "Fix": https://github.com/lukastribus/hap-issue-trial-1.8/commit/91a0776fec856766c64b8f3a34a796718c2368c1 As our intention I believe is to keep the issue open until all affected branches are fixed, this github feature is a little inconvenient. But I guess we can just refer to the issue by prepending it with "issue" or "bug", so GH doesn't see "Fix". Still it feels like we are working against the system. So we'd have to define: - a rough consensus of the process (like the sequence above) - the actual set of labels - and issue and feature request template I like the type and status labels of netbox: https://github.com/digitalocean/netbox/labels How about something like this (status: and type: should be unique): help wanted needs-triage bisected affected/dev affected/1.9 affected/1.8 affected/1.7 affected/1.6 status: accepted status: blocked status: duplicate status: gathering feedback status: rejected status: revisions needed status: pending-backport status: done type: bug type: documentation type: change request type: housekeeping type: major feature type: minor feature and maybe some technical labels like "subsystem: xyz". Maybe needs-triage should be "status: needs-triage". Regards, Lukas
Re: haproxy issue tracker discussion
Willy, Am 10.01.19 um 19:40 schrieb Willy Tarreau: > Conclusion : the affected status is only temporary and enough to go > once the backport is done. This simply means we don't need a "fixed-1.9" > or whatever, we just have to remove the "affected" label exactly as it > would have been if the issue had been reported the day after. > > So in the end we can live with simply "affects-1.8" etc and remove these > flags once the fix(es) is/are backported. Makes sense. > We could decide that bugs for which no "affects-X.Y" label exist anymore > can be closed. That doesn't mean the issue doesn't affect older branch, > it means it's not known to affect them yet, which is similar to before > the bug report (since an issue tracker only tracks known defects and not > hypothetical ones). Ideally the backports would happen more timely to keep the list of "Open" issues clean. Otherwise some of the "Open" issues are completely unfixed, while for others "merely" the backport is missing. > With this model, there is less work for everyone involved, all the info > is concentrated together, users can see that their version remains bogus > because we don't know how to backport the fix but the next one is fixed > so it might be time to upgrade, and there's much less info duplication > leading to the inevitable consistency that comes from it. I guess that will work then. Best regards Tim Düsterhus
Re: haproxy issue tracker discussion
Hi Tim, On Thu, Jan 10, 2019 at 04:12:54PM +0100, Tim Düsterhus wrote: > > I tend to think that if labels already mark the relevance to a branch, > > then they override the status and probably we don't really care about > > the status. The "moby" project above does that by the way, with > > "status/foo" labels. We could possibly have had "v1.8-open" and > > "v1.8x-done". This way instead of searching by status users can > > search by clicking on the labels. I could just be missing something. > > When should the binary "issue open" / "issue closed" property be > toggled? When the issue is fixed in Dev? When the issue is fixed in the > lowest affected version? In fact, I've given some thinking to this and came to the conclusion that a status is only valid at the moment it is consulted. Example : - bug is reported as affecting 1.8 - it is diagnosed - it is figured that 1.9 is affected as well, but for an unkonwn reason, dev is not - it gets marked for 1.9, 1.8, all of which have to be fixed. - in the mean time another backport from dev to 1.9 happens to fix it, so the "affects 1.9" status is not true anymore. - later it is figured that dev was safe and 1.9 became safe thanks to this later commit => in this case both 1.8 and 1.9 were initially marked as affected But now imagine the exact same bug was reported only one day later : - a seemingly unrelated backport from dev to 1.9 protects 1.9 against the bug - bug is reported as affecting 1.8 - it is diagnosed - it is figured that 1.8 is the only one affected, but for an unkonwn reason, 1.9 and dev are not - later it is figured that dev and 1.9 were safe thanks to the former commit => in this case only 1.8 was marked as affected Conclusion : the affected status is only temporary and enough to go once the backport is done. This simply means we don't need a "fixed-1.9" or whatever, we just have to remove the "affected" label exactly as it would have been if the issue had been reported the day after. So in the end we can live with simply "affects-1.8" etc and remove these flags once the fix(es) is/are backported. > Both is not ideal, I guess. Maybe we need to automatically create follow > up issues for the various branches once the fix lands in dev: I really don't like this for the reason I explained : they cut the discussion in the middle most often to restart it in another one for the exact branch the issue was reported for. User reports issue on 1.9, we create it, then create another issue for 1.9, which makes no sense for users' point of view and is extremely confusing from the outside. You look at the bug fixed in dev, it was reported as 1.9 and marked fixed, while 1.9 is still affected. Given that the primary purpose of the public issue tracker is to expose statuses that users can search into, I'd really want to have them all together. There's hardly version-specific discussions, and the rare times it will happen, it doesn't cost much to have them together but it is a huge pain to have them separate. Also, if an issue is met during the backport (while working on the automatically created branch-specific issue), there's no easy way to share the info with the other branches which are covered by different issues. Since the other branches statuses will have to be checked in the primary one anyway, better have all statuses there. > 1. User creates issue #123. > > > Subject: If I foo then haproxy replies with bar instead of baz > > > > If I foo then haproxy replies with bar and this is very bad! > > 2. Developer fixes the issue in dev, noting the branches to backport in > the commit message. Ideal in a machine-parseable format (Backport-To: 1.8) > > > BUG/MINOR: foo: Make haproxy reply with baz > > > > This fixes issue #123. > > > > Backport-To: 1.8 > > Backport-To: 1.7 There is a race here : the diag of affected branches arrives much earlier than the fix, hence the commit message. And very often the whole extent is not known at fix time, and has to be extended afterwards when doing the backports to the other branches. We already have the cherry-picked tracking in the commit messages, so I'd suggest that anyone aware of another affected branch adds the "affects-X.Y" label, and that (once we have it) a bot simply checks for the cherry-picked commits to figure the issue and remove the label. For the rare cases where it doesn't work correctly (because as I said cherry-picking is not rocket science), it's easy to manually remove the label to mark the branch as unaffected at the time of reading. We could decide that bugs for which no "affects-X.Y" label exist anymore can be closed. That doesn't mean the issue doesn't affect older branch, it means it's not known to affect them yet, which is similar to before the bug report (since an issue tracker only tracks known defects and not hypothetical ones). With this model, there is less work for everyone involved, all the info is concentrated together, users can see that their ve
Re: haproxy issue tracker discussion
Aleks, Am 10.01.19 um 15:30 schrieb Aleksandar Lazic: > In general I also see a huge benefit to add a issue tracker I also know > that's a > workflow change for the developers. > > As I also follow the discussion let suggest me the following. > > * add some templates for the different cases e. g.: ISSUE_TEMPLATE.md > https://blog.github.com/2016-02-17-issue-and-pull-request-templates/ Yes. We definitely need one template for "Bug" and another for "Wishlist". > * use some labels, as labels are very flexible and easy to use as selector. > for example: bug, 1.7, backport-1.7, 2.0-dev, fixed_in_1.9.1, ... I disagree here. We should not create too many labels, because one should not need to search for the proper labels. Also once an issue is marked closed it disappears from the view. Labels that make sense: - Affected version: affects/1.7, affects/1.8, ... - Type: Bug, Wishlist - Subsystem: dns, h2, ... - Resolution: fixed, invalid, cannot-reproduce, ... To track whether an issue is fixed in a specific branch Milestones + automated follow-up issues are superior. > * in the commit message(s) can the issue number be added to create a > corelation > to the issue with `#`. > https://help.github.com/articles/basic-writing-and-formatting-syntax/#referencing-issues-and-pull-requests Yes, this should be done. Best regards Tim Düsterhus
Re: haproxy issue tracker discussion
Willy, Am 09.01.19 um 15:22 schrieb Willy Tarreau: >> Here's some more recent projects that probably grew up with GitHub. I >> can't comment how they do the backports, though: >> >> https://github.com/nodejs/node/issues (has LTS / Edge) >> https://github.com/zfsonlinux/zfs/issues (has stable / dev) >> https://github.com/antirez/redis/issues >> https://github.com/moby/moby/issues (tons of automation based on an >> issue template) > > I only knew 3 of them by name and never used any ;-) > > Node is interesting here. the have tags per affected version. E.g. > https://github.com/nodejs/node/issues/25221 Yes, that definitely makes sense. > I tend to think that if labels already mark the relevance to a branch, > then they override the status and probably we don't really care about > the status. The "moby" project above does that by the way, with > "status/foo" labels. We could possibly have had "v1.8-open" and > "v1.8x-done". This way instead of searching by status users can > search by clicking on the labels. I could just be missing something. When should the binary "issue open" / "issue closed" property be toggled? When the issue is fixed in Dev? When the issue is fixed in the lowest affected version? Both is not ideal, I guess. Maybe we need to automatically create follow up issues for the various branches once the fix lands in dev: 1. User creates issue #123. > Subject: If I foo then haproxy replies with bar instead of baz > > If I foo then haproxy replies with bar and this is very bad! 2. Developer fixes the issue in dev, noting the branches to backport in the commit message. Ideal in a machine-parseable format (Backport-To: 1.8) > BUG/MINOR: foo: Make haproxy reply with baz > > This fixes issue #123. > > Backport-To: 1.8 > Backport-To: 1.7 3. A bot automatically creates follow-up issues for each noted branch referring to the initial issue, stating that a backport is needed: > Subject: Backport 1.7: If I foo then haproxy replies with bar instead of baz > > This is a follow-up issue, because #123 is not yet fixed for haproxy 1.7. 4. Developer backports the commit, closing the follow-up issues whenever he did so (this probably can be automated as well. If a Backport-To: 1.7 line appears in the 1.7 branch the matching issue will be closed). Best regards Tim Düsterhus
Re: haproxy issue tracker discussion
Am 09.01.2019 um 15:22 schrieb Willy Tarreau: > Hi Tim, > > On Wed, Jan 09, 2019 at 12:58:30PM +0100, Tim Düsterhus wrote: >> Am 09.01.19 um 05:31 schrieb Willy Tarreau: >>> Except that the "naturally" part here is manually performed by someone, >>> and an issue tracker is nothing more than an organized todo list, which >>> *is* useful to remind that you missed some backports. It regularly happens >>> to us, like when the safety of some fixes is not certain and we prefer to >>> let them run for a while in the most recent versions before backporting >>> them to older branches. This is exactly where an issue tracker is needed, >>> to remind us that these fixes are still needed in older branches. >> >> So the commits are not being cherry-picked in the original order? I >> imagined that the process went like this: >> >> 1. List all the commits since the last cherry-picks >> 2. Look in the commit message to see whether the commit should be >> backported. >> 3. Cherry-pick the commit. > > It's what we *try* to do, but cherry-picking never is rocket science, for > various reasons, some ranging from uncertainty regarding some fixes that > need to cool down later, other because an add-on was made, requiring an > extra patch that are much more convenient to deal with together (think > about bisect for example). That's why I created the git-show-backport > script which gives us significant help in comparing lists of commits from > various branches. > >>> If the issue tracker only tracks issues related to the most recent branch, >> >> I believe you misunderstood me. What I attempted to say is: >> >> The issue tracker tracks which branches the bug affects. But IMO it does >> not need to track whether the backport already happened, because the >> information that the backport needs to happen is in the commit itself >> (see above). > > For me it is important to have the info that the branch is still unfixed > because as I explained, the presence of a given commit is not equivalent > to the issue being fixed. A commit is for a branch. It will often beckport > as a 1-to-1 to the closest branches, but 10% of the time you need to > backport extra stuff as well that is not part of the fix but which the > fix uses, and sometimes you figure that the issue is still not completely > fixed despite the backport being there because it's more subtle. > >>> it will only solve the problem for this branch. For example, Veiko Kukk >>> reported in November that compression in 1.7.11 was broken again. How do >>> I know this ? Just because I've added an entry for this in my TODO file. >>> This bug is apparently a failed backport, so it requires that the original >>> bug is reopened and that any backport attempt to an older version is paused. >> >> Is the failed backport a new bug or is it not? I'd say it's a new bug, >> because the situation changed. It's a new bug (someone messed up the >> backport) that affects haproxy-1.7, but does not affect haproxy-dev. You >> describe it as an old bug that needs to be re-opened. > > For me it's not a new bug at all, it's the same description. Worse, often > it will even be the one the reporter used! For example someone might report > an issue with 1.7, that we diagnose covers 1.7 to 2.0-dev. We finally find > the bug and if it in 2.0-dev then backport it. The backport stops working > when reaching 1.7. It's hard to claim it's a new bug while it exactly is the > bug the person reported! Doing otherwise would make issue lookups very > cumbersome, even more than the mailing list archives where at least you > can sort by threads. Thus for me it's only the status in the old branch > which is not resolved. It's also more convenient for users looking for a > solution to figure that the same bug is already fixed in 1.8 and that > possibly an upgrade would be the path to least pain. > >>> You'll note that for many of them the repository is only a mirror by >>> the way, so that's another hint. >> >> I suspect the reason is simple: The project already had a working issue >> tracker that predated GitHub. Many of these projects are way older than >> GitHub. > > It's possible. > >> Here's some more recent projects that probably grew up with GitHub. I >> can't comment how they do the backports, though: >> >> https://github.com/nodejs/node/issues (has LTS / Edge) >> https://github.com/zfsonlinux/zfs/issues (has stable / dev) >> https://github.com/antirez/redis/issues >> https://github.com/moby/moby/issues (tons of automation based on an >> issue template) > > I only knew 3 of them by name and never used any ;-) > > Node is interesting here. the have tags per affected version. E.g. > https://github.com/nodejs/node/issues/25221 I like this as then you can see all effected Versions for a issue and PR. > I tend to think that if labels already mark the relevance to a branch, > then they override the status and probably we don't really care about > the status. The "moby" project above does that by the way, wit
Re: haproxy issue tracker discussion
Hi Tim, On Wed, Jan 09, 2019 at 12:58:30PM +0100, Tim Düsterhus wrote: > Am 09.01.19 um 05:31 schrieb Willy Tarreau: > > Except that the "naturally" part here is manually performed by someone, > > and an issue tracker is nothing more than an organized todo list, which > > *is* useful to remind that you missed some backports. It regularly happens > > to us, like when the safety of some fixes is not certain and we prefer to > > let them run for a while in the most recent versions before backporting > > them to older branches. This is exactly where an issue tracker is needed, > > to remind us that these fixes are still needed in older branches. > > So the commits are not being cherry-picked in the original order? I > imagined that the process went like this: > > 1. List all the commits since the last cherry-picks > 2. Look in the commit message to see whether the commit should be > backported. > 3. Cherry-pick the commit. It's what we *try* to do, but cherry-picking never is rocket science, for various reasons, some ranging from uncertainty regarding some fixes that need to cool down later, other because an add-on was made, requiring an extra patch that are much more convenient to deal with together (think about bisect for example). That's why I created the git-show-backport script which gives us significant help in comparing lists of commits from various branches. > > If the issue tracker only tracks issues related to the most recent branch, > > I believe you misunderstood me. What I attempted to say is: > > The issue tracker tracks which branches the bug affects. But IMO it does > not need to track whether the backport already happened, because the > information that the backport needs to happen is in the commit itself > (see above). For me it is important to have the info that the branch is still unfixed because as I explained, the presence of a given commit is not equivalent to the issue being fixed. A commit is for a branch. It will often beckport as a 1-to-1 to the closest branches, but 10% of the time you need to backport extra stuff as well that is not part of the fix but which the fix uses, and sometimes you figure that the issue is still not completely fixed despite the backport being there because it's more subtle. > > it will only solve the problem for this branch. For example, Veiko Kukk > > reported in November that compression in 1.7.11 was broken again. How do > > I know this ? Just because I've added an entry for this in my TODO file. > > This bug is apparently a failed backport, so it requires that the original > > bug is reopened and that any backport attempt to an older version is paused. > > Is the failed backport a new bug or is it not? I'd say it's a new bug, > because the situation changed. It's a new bug (someone messed up the > backport) that affects haproxy-1.7, but does not affect haproxy-dev. You > describe it as an old bug that needs to be re-opened. For me it's not a new bug at all, it's the same description. Worse, often it will even be the one the reporter used! For example someone might report an issue with 1.7, that we diagnose covers 1.7 to 2.0-dev. We finally find the bug and if it in 2.0-dev then backport it. The backport stops working when reaching 1.7. It's hard to claim it's a new bug while it exactly is the bug the person reported! Doing otherwise would make issue lookups very cumbersome, even more than the mailing list archives where at least you can sort by threads. Thus for me it's only the status in the old branch which is not resolved. It's also more convenient for users looking for a solution to figure that the same bug is already fixed in 1.8 and that possibly an upgrade would be the path to least pain. > > You'll note that for many of them the repository is only a mirror by > > the way, so that's another hint. > > I suspect the reason is simple: The project already had a working issue > tracker that predated GitHub. Many of these projects are way older than > GitHub. It's possible. > Here's some more recent projects that probably grew up with GitHub. I > can't comment how they do the backports, though: > > https://github.com/nodejs/node/issues (has LTS / Edge) > https://github.com/zfsonlinux/zfs/issues (has stable / dev) > https://github.com/antirez/redis/issues > https://github.com/moby/moby/issues (tons of automation based on an > issue template) I only knew 3 of them by name and never used any ;-) Node is interesting here. the have tags per affected version. E.g. https://github.com/nodejs/node/issues/25221 I tend to think that if labels already mark the relevance to a branch, then they override the status and probably we don't really care about the status. The "moby" project above does that by the way, with "status/foo" labels. We could possibly have had "v1.8-open" and "v1.8x-done". This way instead of searching by status users can search by clicking on the labels. I could just be missing something. > > To be totally transparent, I real
Re: haproxy issue tracker discussion
Willy, Am 09.01.19 um 05:31 schrieb Willy Tarreau: > Except that the "naturally" part here is manually performed by someone, > and an issue tracker is nothing more than an organized todo list, which > *is* useful to remind that you missed some backports. It regularly happens > to us, like when the safety of some fixes is not certain and we prefer to > let them run for a while in the most recent versions before backporting > them to older branches. This is exactly where an issue tracker is needed, > to remind us that these fixes are still needed in older branches. So the commits are not being cherry-picked in the original order? I imagined that the process went like this: 1. List all the commits since the last cherry-picks 2. Look in the commit message to see whether the commit should be backported. 3. Cherry-pick the commit. In the specific case of GitHub's issue tracker: If a issue is referenced in a commit message the commit will automatically appear in the timeline of that issue. This works even across repositories (by using haproxy/haproxy#123 instead of just #123). It only shows when specifically looking at a single issue, though and thus is not available directly in the list of issues. > If the issue tracker only tracks issues related to the most recent branch, I believe you misunderstood me. What I attempted to say is: The issue tracker tracks which branches the bug affects. But IMO it does not need to track whether the backport already happened, because the information that the backport needs to happen is in the commit itself (see above). > it will only solve the problem for this branch. For example, Veiko Kukk > reported in November that compression in 1.7.11 was broken again. How do > I know this ? Just because I've added an entry for this in my TODO file. > This bug is apparently a failed backport, so it requires that the original > bug is reopened and that any backport attempt to an older version is paused. Is the failed backport a new bug or is it not? I'd say it's a new bug, because the situation changed. It's a new bug (someone messed up the backport) that affects haproxy-1.7, but does not affect haproxy-dev. You describe it as an old bug that needs to be re-opened. >> I'd throw my hat into the ring as well. I maintain a few Open Source >> projects myself (though not of the size and importance of haproxy) and >> actually use the GitHub issue tracker. > > Thanks. From what I've been used to see on github, very very few projects > do care about maintenance. Most of them are rolling releases. It actually > took me a very long time to try to figure one project with multiple > maintenance branches to see how they dealt with issues, and the few I > found by then had disabled issues, which could have already been a hint > about its suitability to the task. Just a few examples : > > *snip* > > You'll note that for many of them the repository is only a mirror by > the way, so that's another hint. I suspect the reason is simple: The project already had a working issue tracker that predated GitHub. Many of these projects are way older than GitHub. Here's some more recent projects that probably grew up with GitHub. I can't comment how they do the backports, though: https://github.com/nodejs/node/issues (has LTS / Edge) https://github.com/zfsonlinux/zfs/issues (has stable / dev) https://github.com/antirez/redis/issues https://github.com/moby/moby/issues (tons of automation based on an issue template) >>> With that said at the moment we don't have anything and the situation is >>> not better than having a suboptimal tool. >> >> I agree. > > To be totally transparent, I really think the tool is not well suited and > that its main value is its large user base. But I also know that with you > and Lukas suggesting to use it, you both will deploy a lot of efforts to > build something good to prove me I'm wrong, possibly resulting in a nice > solution in the end. And if some people are willing to invest time > building something, it would be unfair from me to try to steer their Clearly it's important that the developer team / you are able to efficiently work with it as well. > technical choices. Also, Lukas already managed to use the API to develop > some tools, maybe this will be welcome to add some automated state > transitions at some point. > > So unless anyone has a better idea for now, and if you're feeling brave > enough, let's give it a try. > It's probably impossible to build something absolutely perfect without real world data points. If a pain point arises it can be specifically worked on. Currently this discussion is completely hypothetical. Best regards Tim Düsterhus
Re: haproxy issue tracker discussion
On Tue, Jan 08, 2019 at 07:18:07PM +0100, Tim Düsterhus wrote: > Willy, > > Am 08.01.19 um 18:30 schrieb Willy Tarreau: > > I totally agree. This is the tool I'm missing the most currently. I'm > > not aware of a *good* and manageable issue tracker. Having a status for > > a bug per branch most likely eliminates most of them... > > I'm not sure this is required. The bugfixes naturally land in the > current development repository and have the affected branches in their > commit message. They naturally "trickle down" to the maintained > branches. So if the issue is marked as fixed the fix will *eventually* > appear in the stable branch of the reporter. Except that the "naturally" part here is manually performed by someone, and an issue tracker is nothing more than an organized todo list, which *is* useful to remind that you missed some backports. It regularly happens to us, like when the safety of some fixes is not certain and we prefer to let them run for a while in the most recent versions before backporting them to older branches. This is exactly where an issue tracker is needed, to remind us that these fixes are still needed in older branches. If the issue tracker only tracks issues related to the most recent branch, it will only solve the problem for this branch. For example, Veiko Kukk reported in November that compression in 1.7.11 was broken again. How do I know this ? Just because I've added an entry for this in my TODO file. This bug is apparently a failed backport, so it requires that the original bug is reopened and that any backport attempt to an older version is paused. Without having cross-branches indications, you can't reliably do this. There is a significant risk that the faulty fix gets backported to 1.6 before anyone qualifies the issue. This can possibly be dealt with using labels, I'm not sure how convenient it will be. > In my experience non-issues (a.k.a. RTFM) are usually easy to detect > when reading through the explanation. As long as there is manpower to clear them up it's OK, but this means that some of us will count on you guys for this. With e-mails I don't even need to do anything to stop reading a faulty bug report. The mail is marked read once I glance over it, and I don't see it anymore. I can also mark a whole thread as read when I see that any of the people I trust here on the list start to respond. When reading an issue tracker, the same issues pop up until I've done something with them. This makes a huge difference. This is why I've always been highly concerned with the risk of pollution. > >> What you are describing basically is a unmaintained issue tracker, > >> which is of course useless. > >> > >> But keeping people from filing new issues is the wrong approach to > >> this, imho. Proper templating, triaging and correct labeling of the > >> issues is the difference between a useless and a useful issue tracker > >> from my point of view. > > > > I do have strong doubts but I'm open to trying :-) > > I have to agree with Lukas here. Proper triaging is key here. And this > is no different to email. You have to read email to decide what to do. Yes but you don't have to act on them to stop seeing them ;-) > And you have to read the issue to decide what to do. Most of the time many of us will conclude they have nothing to do because they're not the best people for this. When you have 10 people responsible for different areas, on average 10% of the issues will be of interest to them, and I want to be sure that we will not end up with developers looking at the issue tracker and constantly seeing stuff that's not for them without an easy way to definitely skip it and focus on their stuff. Again with e-mail it's easy because without doing anything you don't see the same e-mail again. Here if you have to label or ack all the stuff that's not for you just in order not to see it again, it's inefficient. But it can likely be improved with proper triaging. > Labels in the issue tracker are like folders in your mailbox and the > issue tracker itself is like a public mailbox. That's exactly the problem. With e-mails, there's one state per reader, here there's a single state that everyone has to share. > I'd throw my hat into the ring as well. I maintain a few Open Source > projects myself (though not of the size and importance of haproxy) and > actually use the GitHub issue tracker. Thanks. From what I've been used to see on github, very very few projects do care about maintenance. Most of them are rolling releases. It actually took me a very long time to try to figure one project with multiple maintenance branches to see how they dealt with issues, and the few I found by then had disabled issues, which could have already been a hint about its suitability to the task. Just a few examples : Apache : https://github.com/apache/httpd Squid : https://github.com/squid-cache/squid Nginx : https://github.com/nginx/nginx Linux : https://github.com/torvald
Re: haproxy issue tracker discussion
Willy, Am 08.01.19 um 18:30 schrieb Willy Tarreau: > I totally agree. This is the tool I'm missing the most currently. I'm > not aware of a *good* and manageable issue tracker. Having a status for > a bug per branch most likely eliminates most of them... I'm not sure this is required. The bugfixes naturally land in the current development repository and have the affected branches in their commit message. They naturally "trickle down" to the maintained branches. So if the issue is marked as fixed the fix will *eventually* appear in the stable branch of the reporter. The "first responder" will try to reproduce the issue both in the current dev version (to see if appears in bleeding edge) as well as the most recent version of the branch the reporter uses (in case it was accidentally fixed during a refactor). If possible the first responder creates a reg-test showing the issue. > I'm really not convinced it would change anything. We've put prominently > on the previous repo an indication that it was not the official project > and that issues / PRs were not accepted, despite this your automatic bot > was needed to close them. My goal is contributors efficiency. Several of > us are on the critical path and every minute they waste slows someone > else down. So if it becomes more annoying for everyone to create a new > issue just for the purpose of discouraging wanderers from trying to > create them, it will only have a globally negative effect. In my experience non-issues (a.k.a. RTFM) are usually easy to detect when reading through the explanation. >> >> What you are describing basically is a unmaintained issue tracker, >> which is of course useless. >> >> But keeping people from filing new issues is the wrong approach to >> this, imho. Proper templating, triaging and correct labeling of the >> issues is the difference between a useless and a useful issue tracker >> from my point of view. > > I do have strong doubts but I'm open to trying :-) I have to agree with Lukas here. Proper triaging is key here. And this is no different to email. You have to read email to decide what to do. And you have to read the issue to decide what to do. Labels in the issue tracker are like folders in your mailbox and the issue tracker itself is like a public mailbox. >> I'm in favor of the former, because I believe triage will be required >> for both and I don't think the amount of bogus issues will be >> unmanageable. I'd also volunteer to triage incoming issues - not that >> it's much different from what's currently done discourse anyway - as >> Tim already said. > > Oh yes! I just want to be sure we don't burn you out! This is also why > I'm open to trying what those doing the work propose. If I'm imposing > a painful or inefficient process for those doing the work, it will not > work either. I'd throw my hat into the ring as well. I maintain a few Open Source projects myself (though not of the size and importance of haproxy) and actually use the GitHub issue tracker. >> Regarding what tool to use, in the "open to everyone" case I'd opt for >> github simply because it has the lowest barrier of entry for everyone, >> as well as me being mildly familiar with it personally. Pre-existing >> github labels would have to be replaced by useful ones and a issue >> template would have to be created. I would suggest using GitHub's issue tracker as well. It works fairly well in my experience. > I'd say that we managed to close the issues there when we discovered > them. It took a huge amount of efforts, sure, but eventually it was > done. So if we figure later that it was a wrong choice, we know it can > be done again. In this regard I think it's the lowest cost to *try*. > > However I'd like that we spend some time thinking about what can be > done to properly route the bugs to the various branches. Bugs in dev > are useless, we want them to be fixed in stable branches. So we have See the very top of my email. > Thanks a lot for these links, they are very informative. This utility > doesn't "yet" support cross-branches, but it's said that bugseverywhere > does. But bugseverywhere claims that its value is in keeping a hard > relation between bug's state and the fix in the tree, which precisely > is the wrong way to do it for me : I strongly prefer that the bug tracker > is never fully up to date regarding the resolved status for a branch than > having it believe the branch is fixed because it doesn't know that this > branch requires an extra patch. An apparently unresolved bug will be > noticed by the next person trying to resolve it. It's how it really > works with most developers and bug trackers in real life. I had too > quick a look at the other ones for now. Please don't opt for some obscure system. The biggest value of a public issue tracker to me is that people are actually are able to research whether their issue is already known / a duplicate and possible workarounds. The mail archive is not really accessible. >
Re: haproxy issue tracker discussion
On Sun, Jan 06, 2019 at 07:41:08PM +0300, Alexey Elymanov wrote: > Ansible, for example (https://github.com/ansible/ansible/issues), uses some > advanced automation and templates to manage their enormous issues stream. > Issue are checked against conforming rules/tests/codestyle checks or, for > example, automatically closed due inactivity > I believe most if not all soluitons they use are opensource. Thank you for this link Alexey, it definitely brings some value to this discussion! Willy
Re: haproxy issue tracker discussion
Hi guys, sorry for the long delay, it was not the best week for me to restart all of this discussion, but now it's OK, I'm catching up! On Sun, Jan 06, 2019 at 05:29:43PM +0100, Lukas Tribus wrote: > Hello everyone, > > > as per Tim's suggestion I'm restarting the discussion about the issue > tracker, started in "haproxy 1.9 status update" (2018-05-25), > Message-ID 20180525161044.ga6...@1wt.eu: > https://www.mail-archive.com/haproxy@formilux.org/msg30139.html > > > > It would be nice to show what's pending or being worked on, and > > to sometimes add extra info regarding a given task. > > Yes, we are in need of an issue tracker, not only to handle open bugs, > but even more so to handle feature/change requests that often need > more time. Those do get lost on the mailing list, even when everyone > already agreed it's needed. I totally agree. This is the tool I'm missing the most currently. I'm not aware of a *good* and manageable issue tracker. Having a status for a bug per branch most likely eliminates most of them... > > The problem we've faced in the past with GitHub's issue tracker > > is that it's impossible to restrict the creation of new issues to > > participants. Given that haproxy is a complex component, the boundary > > between human error, misunderstanding and bug is extremely thin. > > It is, but I don't like restricting the creation of new issues to > participants. > > Issue templates need to be clear that the issue tracker is not a > support forum. I'm really not convinced it would change anything. We've put prominently on the previous repo an indication that it was not the official project and that issues / PRs were not accepted, despite this your automatic bot was needed to close them. My goal is contributors efficiency. Several of us are on the critical path and every minute they waste slows someone else down. So if it becomes more annoying for everyone to create a new issue just for the purpose of discouraging wanderers from trying to create them, it will only have a globally negative effect. Based on your experience dealing with all these reports on discourse, what is the approximate ratio between valid and invalid reports ? > Triaging new issues will be needed anyway, and that > also includes closing misdirected support request. Sure, and any support / issue reporting chain requires this since you only know what it was once the issue is fixed (and sometimes even after it's fixed you discover new impacts). > To be clear: I think developers should not receive an email > notifications for new or untriaged issues - only when specifically > assigned to the issue or if they commented previously on it. Instead, > maybe an automated weekly report or something like that (similar to > what we have now for the stable-queue) could go out to the mailing > list with a summary of the open issues, grouped by it's labels. Maybe. But right now issues reported here are dealt with because all of us presume that "someone will surely look at this one", and if we see a long unresponded e-mail, we try to assign more time to it (and sometimes we miss it, of course). And what is nice is that actually a large number of people respond, some with links to a similar previous report, others suggesting to adapt the config to narrow the issue down, etc. So there is a huge value in having the community participate to issue resolution and not just some developers. The problem with batches is that when you get 20 new bugs at once that you hadn't had the time to look at previously, well, you don't know where to start and you simply prefer to pretend you didn't see them. So possibly that having the triaged issues being forwarded here in real time with a visible tag would maintain the same level of participation with a higher accuracy and less losses. > > It resulted in the issue tracker being filled with wrong bugs, 100% of > > which were in fact requests for help. It makes the utility totally > > useless for development and bug fixing as it requires more time to > > maintain in a clean state than it takes to put issues in a mailbox. > > What you are describing basically is a unmaintained issue tracker, > which is of course useless. > > But keeping people from filing new issues is the wrong approach to > this, imho. Proper templating, triaging and correct labeling of the > issues is the difference between a useless and a useful issue tracker > from my point of view. I do have strong doubts but I'm open to trying :-) > So I guess we ultimately have to decide between: > > - an issue tracker open to everyone, however requiring some > volunteers to triage incoming bugs (and close invalid ones) > - an issue tracker that is open to "previous participants", with the > expectation to require less manpower for triage > > > I'm in favor of the former, because I believe triage will be required > for both and I don't think the amount of bogus issues will be > unmanageable. I'd also volunteer to triage in
Re: haproxy issue tracker discussion
Ansible, for example (https://github.com/ansible/ansible/issues), uses some advanced automation and templates to manage their enormous issues stream. Issue are checked against conforming rules/tests/codestyle checks or, for example, automatically closed due inactivity I believe most if not all soluitons they use are opensource. On Sun, Jan 6, 2019 at 7:32 PM Lukas Tribus wrote: > Hello everyone, > > > as per Tim's suggestion I'm restarting the discussion about the issue > tracker, started in "haproxy 1.9 status update" (2018-05-25), > Message-ID 20180525161044.ga6...@1wt.eu: > https://www.mail-archive.com/haproxy@formilux.org/msg30139.html > > > > It would be nice to show what's pending or being worked on, and > > to sometimes add extra info regarding a given task. > > Yes, we are in need of an issue tracker, not only to handle open bugs, > but even more so to handle feature/change requests that often need > more time. Those do get lost on the mailing list, even when everyone > already agreed it's needed. > > > > The problem we've faced in the past with GitHub's issue tracker > > is that it's impossible to restrict the creation of new issues to > > participants. Given that haproxy is a complex component, the boundary > > between human error, misunderstanding and bug is extremely thin. > > It is, but I don't like restricting the creation of new issues to > participants. > > Issue templates need to be clear that the issue tracker is not a > support forum. Triaging new issues will be needed anyway, and that > also includes closing misdirected support request. > > > To be clear: I think developers should not receive an email > notifications for new or untriaged issues - only when specifically > assigned to the issue or if they commented previously on it. Instead, > maybe an automated weekly report or something like that (similar to > what we have now for the stable-queue) could go out to the mailing > list with a summary of the open issues, grouped by it's labels. > > > > It resulted in the issue tracker being filled with wrong bugs, 100% of > > which were in fact requests for help. It makes the utility totally > > useless for development and bug fixing as it requires more time to > > maintain in a clean state than it takes to put issues in a mailbox. > > What you are describing basically is a unmaintained issue tracker, > which is of course useless. > > But keeping people from filing new issues is the wrong approach to > this, imho. Proper templating, triaging and correct labeling of the > issues is the difference between a useless and a useful issue tracker > from my point of view. > > > So I guess we ultimately have to decide between: > > - an issue tracker open to everyone, however requiring some > volunteers to triage incoming bugs (and close invalid ones) > - an issue tracker that is open to "previous participants", with the > expectation to require less manpower for triage > > > I'm in favor of the former, because I believe triage will be required > for both and I don't think the amount of bogus issues will be > unmanageable. I'd also volunteer to triage incoming issues - not that > it's much different from what's currently done discourse anyway - as > Tim already said. > > Regarding what tool to use, in the "open to everyone" case I'd opt for > github simply because it has the lowest barrier of entry for everyone, > as well as me being mildly familiar with it personally. Pre-existing > github labels would have to be replaced by useful ones and a issue > template would have to be created. > > > > A limitation that isn't addressed by any of them is that an issue has > > a single status and not one per maintenance branch. Some will say that > > labels replace this but I'd say that this isn't true, it just vaguely > > emulates this. Anyway if we don't have better we can go with this. I > > often dream of the day someone pissed of by using prehistoric issue > > trackers writes a modern one, just like when Linus created Git... > > There are some niche tools allowing a "distributed issue tracking > system" within git, but they seem very fragmented, none of it gets a > lot of traction and it would certainly over complicate things for a > lot of people, including myself. See git-bug [1] and it's HN > discussion [2], containing a log of other references [3-7]. > > Well I guess we would certainly not have many bogus issues reported on > those systems ;) > > > > Regards, > Lukas > > > [1] https://github.com/MichaelMure/git-bug > [2] https://news.ycombinator.com/item?id=17782121 > [3] http://bugseverywhere.org/ > [4] http://mrzv.org/software/artemis/ > [5] https://github.com/sit-fyi/issue-tracking > [6} https://github.com/dspinellis/git-issue > [7] http://travisbrown.ca/projects/nitpick/docs/nitpick.html > >
haproxy issue tracker discussion
Hello everyone, as per Tim's suggestion I'm restarting the discussion about the issue tracker, started in "haproxy 1.9 status update" (2018-05-25), Message-ID 20180525161044.ga6...@1wt.eu: https://www.mail-archive.com/haproxy@formilux.org/msg30139.html > It would be nice to show what's pending or being worked on, and > to sometimes add extra info regarding a given task. Yes, we are in need of an issue tracker, not only to handle open bugs, but even more so to handle feature/change requests that often need more time. Those do get lost on the mailing list, even when everyone already agreed it's needed. > The problem we've faced in the past with GitHub's issue tracker > is that it's impossible to restrict the creation of new issues to > participants. Given that haproxy is a complex component, the boundary > between human error, misunderstanding and bug is extremely thin. It is, but I don't like restricting the creation of new issues to participants. Issue templates need to be clear that the issue tracker is not a support forum. Triaging new issues will be needed anyway, and that also includes closing misdirected support request. To be clear: I think developers should not receive an email notifications for new or untriaged issues - only when specifically assigned to the issue or if they commented previously on it. Instead, maybe an automated weekly report or something like that (similar to what we have now for the stable-queue) could go out to the mailing list with a summary of the open issues, grouped by it's labels. > It resulted in the issue tracker being filled with wrong bugs, 100% of > which were in fact requests for help. It makes the utility totally > useless for development and bug fixing as it requires more time to > maintain in a clean state than it takes to put issues in a mailbox. What you are describing basically is a unmaintained issue tracker, which is of course useless. But keeping people from filing new issues is the wrong approach to this, imho. Proper templating, triaging and correct labeling of the issues is the difference between a useless and a useful issue tracker from my point of view. So I guess we ultimately have to decide between: - an issue tracker open to everyone, however requiring some volunteers to triage incoming bugs (and close invalid ones) - an issue tracker that is open to "previous participants", with the expectation to require less manpower for triage I'm in favor of the former, because I believe triage will be required for both and I don't think the amount of bogus issues will be unmanageable. I'd also volunteer to triage incoming issues - not that it's much different from what's currently done discourse anyway - as Tim already said. Regarding what tool to use, in the "open to everyone" case I'd opt for github simply because it has the lowest barrier of entry for everyone, as well as me being mildly familiar with it personally. Pre-existing github labels would have to be replaced by useful ones and a issue template would have to be created. > A limitation that isn't addressed by any of them is that an issue has > a single status and not one per maintenance branch. Some will say that > labels replace this but I'd say that this isn't true, it just vaguely > emulates this. Anyway if we don't have better we can go with this. I > often dream of the day someone pissed of by using prehistoric issue > trackers writes a modern one, just like when Linus created Git... There are some niche tools allowing a "distributed issue tracking system" within git, but they seem very fragmented, none of it gets a lot of traction and it would certainly over complicate things for a lot of people, including myself. See git-bug [1] and it's HN discussion [2], containing a log of other references [3-7]. Well I guess we would certainly not have many bogus issues reported on those systems ;) Regards, Lukas [1] https://github.com/MichaelMure/git-bug [2] https://news.ycombinator.com/item?id=17782121 [3] http://bugseverywhere.org/ [4] http://mrzv.org/software/artemis/ [5] https://github.com/sit-fyi/issue-tracking [6} https://github.com/dspinellis/git-issue [7] http://travisbrown.ca/projects/nitpick/docs/nitpick.html