On Wed, May 8, 2019 at 11:32 AM Steve French <smfrench@xxxxxxxxx> wrote: > > [..] Our > build verification tests passed (and continue to be extended to > include more tests). See e.g. our 'buildbot' results at: > http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/199 Still, is there any reason for that very late rebase? Why are all the commits so recent? And perhaps even more importantly, why is the base for that rebase is some completely random and inappropriate commit in the middle of the merge window? That's *INSANE*. And it's against everything I've always told people to do: DO NOT BASE YOUR DEVELOPMENT WORK ON SOME RANDOM "KERNEL OF THE DAY" DURING THE MERGE WINDOW !! who knows what horrendous bugs we've introduced at that random point in the merge window, and you now based all your work on that unstable random commit. There is *no* excuse for this kind of crazy development. Even if you use something else than git to develop (some patch-queue based inferior system or whatever) and even if you then import it into git later PICK A SANE AND STABLE IMPORT POINT and if you *do* use git for development, but you have to rebase because you've made some silly mistake and need to undo something PICK A SANE AND STABLE REBASE POINT I don't know how much clearer I can be about this, and I do not understand why this keeps on happening. We've been using git for just about 15 years now, and I've said this for pretty much all that time. Some random googling found this lwn article based on some random old email of mine from ten years ago: https://lwn.net/Articles/328436/ and while it is about general rebasing and merging issues, it does talk about how to "allow development to be based on a (hopefully) relatively stable point where the issues are known". That is as important for a rebase point as it is for a merge point. Rebasing on top of random kernel versions should not be done. EVER. And if you did it to avoid some merge conflict, DON'T. I'd much rather get a pull request for something that is *STABLE* and *WELL-TESTED*, than get a pull request that has been syntactically cleaned up, but is based on something that might not work at all under certain circumstances. Even if *your* code were to be perfect, that doesn't matter if the thing you based your code on is a quicksand of memory corruption and general flakiness. So don't do the whole "rebase the day before" in the first place, but *DEFINITELY* don't do it when you then pick a random and bad point to rebase things on top of! Linus
