On Thu, 4 Jun 2020, Joe Perches wrote: > On Thu, 2020-06-04 at 12:33 +0200, Julia Lawall wrote: > > > > On Thu, 4 Jun 2020, Joe Perches wrote: > > > > > On Thu, 2020-06-04 at 11:52 +0200, Julia Lawall wrote: > > > > Should Fixes also be used when the change will make it hard to port other > > > > fixes over it? > > > > > > If it's a logic defect or regression that's being fixed, > > > shouldn't the logic defect or regression be fixed as > > > reasonably soon as possible? > > > > Sure, but I recall seeing some patches that mentioned that the problem had > > existed since the beginning of git. Of course, it should be rare. > > git history goes back 15 years already. > There are scant few bugs that old. > > There is a tree with even older history that Rob Landley > still has here: https://landley.net/kdocs/fullhist/ > > It does make git blame research a bit easier for those > rare and extremely old defects. > > > > The nature of the fix should ideally be optimal for > > > backporting, but I believe that should not stop any > > > consideration for the standalone fix itself. > > > > I'm not sure to follow this. > > I think it comes down to defects in current need to be > fixed. Describing > the base commit that is being fixed > is useful for backporting. > > I believe it's not reasonable to ask the author of a > fix to research how it could or should be backported. > > > Sometimes non-bug fixes that block > > backporting a bug fix have to be backported as well. So the fixes would > > again highlight the range of versions affected by the issue. > > Sure, but the non-bug fixes that may also need backporting > to enable easy backports of the actual fix should not be > described in the Fixes: <commit> as those are generally > easily researched from a command like: > > $ git log <commit>.. <files in fix> > > by whoever needs to backport. OK, I recall a discussion with Dan where he suggested that some things that were not actually bug fixes could also merit a Fixes tag. But it's probably better if he weighs in directly. It would be unfortunate if someone doesn't submit a fix because they can't figure out how to make the Fixes tag properly, though. For example, when there is a lot of concurrency involved, some of the bugs reported by syzkaller can be hard to fully understand. In the case of a NULL pointer dereference can a patch only be submitted if it is known where the NULL comes from, and at what time the reason for producing the NULL was introduced into the kernel? Adding a NULL test without fully understanding how the NULL can arise could reasonably be seen as papering over a real problem. But sometimes it could be better to paper over the problem than incur the problem in a critical situation. But I agree that these are corner cases. Hopefully if such a NULL test was submitted with an explanation on why the submitter was not able to find the source of the problem and why the problem is important, then the maintainer could provide some guidance that would resolve the situation. julia
