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

=> 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.


Reply via email to