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 of netbox: > https://github.com/digitalocean/netbox/labels Indeed, looks like they came to similar conclusions based on similar needs! It's reassuring to see that we're not reinventing the wheel. > How about something like this (status: and type: should be unique): > > help wanted > needs-triage This one should be a status and the first one. > bisected > > affected/dev > affected/1.9 > affected/1.8 > affected/1.7 > affected/1.6 Maybe "affects: x.y" then, to follow the next ones ? > status: accepted > status: blocked I'm not sure what "blocked" corresponds to in the workflow. > status: duplicate > status: gathering feedback > status: rejected > status: revisions needed Sme for this one. > status: pending-backport I think this one is implied by the presence of "affects:" > 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". Definitely, so that maintainers can look at bugs affecting their areas, and so that when someone believes he finds a bug somewhere he can quickly check if it was already found or not. > Maybe needs-triage should be "status: needs-triage". Yes, agreed. Last point is that ideally we should try to keep these names short so that bugs are still readable when holding multiple labels. For example we can have "status: feedback", "type: doc", "type: cleanup" and shorten a few like this. Thanks! Willy
