On Sat, May 18, 2019 at 11:41 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > What would you prefer to happen in such situations? Commit summaries > > > modified enough to confuse CI tools into *NOT* noticing that those > > > are versions of the same patch? Some kind of metadata telling the > > > same tools that such-and-such commits got folded in (and they might > > > have been split in process, with parts folded into different spots > > > in the series, at that)? > > > > > > Because "never fold in, never reorder, just accumulate patches in > > > the end of the series" is not going to fly. For a lot of reasons. > > > > As far as I'm concerned, this is the tools problem; I don't think it's > > worth it for developers to feel they need to twist themselves into > > knots just to try to make the CI tools' life easier. > > FWIW, what _is_ the underlying problem? It looks like the basic issue > is with rebase/cherry-pick of a commit; it seems to be trying to > handle two things: > 1) report X' in commit C' is similar to report X in commit C, > with C' apparently being a rebase/cherry-pick/whatnot of C; don't > want to lose that information > 2) reports X, Y and Z in commit C don't seem to be reoccuring > on the current tree, without any claimed fix in it. Want to keep > an eye on those. > > ... and getting screwed by a mix of those two: reports X, Y and Z in > commit C don't seem to be reoccuring on the current tree, even though > it does contain a commit C' that seems to be a rebase of C. A fix for > C is *not* present as an identifiable commit in the current tree. > Was it lost or was it renamed/merged with other commits/replaced by > another fix? > > What I don't quite understand is why does the tool care. Suppose > we have a buggy commit + clearly marked fix. And see a report > very similar to the original ones, on the tree with alleged fix > clearly present. IME the earlier reports are often quite relevant - > the fix might have been incomplete/racy/etc., and in that case > the old reports (*AND* pointer to the commit that was supposed to > have fixed those) are very useful. > > What's the problem these reminders are trying to solve? Computational > resources eaten by comparisons? syzbot, as any bug tracking system has notion of "open" and "closed" bugs. This is useful for 2 main reasons: - being able to see what are the currently open bugs (on our plate) to not go over already closed bugs again and again and to not lose still relevant bugs (for upstream linux https://syzkaller.appspot.com/upstream#open) - to be able to understand when a new similarly looking crash is actually a new bug (either not completely fixed old one, or completely new does not matter much) and report it again (because it's not a good idea to send an email for every crash as is (hundreds of thousands a day)) In order to do this tracking syzbot needs the association between reports and fixing commits. Merely saying "it's fixed" is not enough because consider you say "it's fixed", but it's fixed only in mm, but not in net-next. So next second syzbot sees this crash again in net-next and sends a new bug report as it now thinks the old one is fixed, so this must be a new one. Only the commit allows it to precisely understand when the fix is in all trees, and not just in all trees but in all currently tested builds for these trees. Above you say "on the tree with alleged fix clearly present". To understand that syzbot needs to know the commit.
