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
