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 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. Cheers, Willy
