LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Steve French <smfrench@gmail.com>
Cc: CIFS <linux-cifs@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] CIFS/SMB3 fixes
Date: Wed, 8 May 2019 13:37:07 -0700	[thread overview]
Message-ID: <CAHk-=wiKoePP_9CM0fn_Vv1bYom7iB5N=ULaLLz7yOST3K+k5g@mail.gmail.com> (raw)
In-Reply-To: <CAH2r5mv=4JsaF-8v=U4JR3jrOyPfhtUsJPogNudLejDh09xGSA@mail.gmail.com>

On Wed, May 8, 2019 at 11:32 AM Steve French <smfrench@gmail.com> 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

  reply	other threads:[~2019-05-08 20:37 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-08 18:32 Steve French
2019-05-08 20:37 ` Linus Torvalds [this message]
2019-05-08 20:46   ` Linus Torvalds
2019-05-08 21:47   ` Steve French
2019-05-08 20:45 ` pr-tracker-bot
  -- strict thread matches above, loose matches on Subject: below --
2022-01-17  3:04 [GIT PULL] cifs/smb3 fixes Steve French
2022-01-17  7:59 ` pr-tracker-bot
2021-11-25  4:31 Steve French
2021-11-25 19:12 ` pr-tracker-bot
2021-11-19 22:45 Steve French
2021-11-20 19:20 ` pr-tracker-bot
2021-08-13 21:41 [GIT PULL] CIFS/SMB3 Fixes Steve French
2021-08-14  1:12 ` pr-tracker-bot
2021-07-30 21:09 [GIT PULL] CIFS/SMB3 fixes Steve French
2021-07-31 16:32 ` pr-tracker-bot
2021-07-17  0:17 [GIT PULL] CIFS/SMB3 Fixes Steve French
2021-07-17 20:13 ` pr-tracker-bot
2021-06-28 23:52 Steve French
2021-06-30  3:35 ` pr-tracker-bot
2021-05-05 14:22 Steve French
2021-05-05 20:49 ` pr-tracker-bot
2021-03-28  0:07 Steve French
2021-03-28 19:11 ` pr-tracker-bot
2021-03-20 16:18 Steve French
2021-03-20 18:06 ` pr-tracker-bot
2021-03-20 16:17 Steve French
2021-02-26  6:24 Steve French
2021-02-26 22:24 ` pr-tracker-bot
2020-12-20 19:47 Steve French
2020-12-21  4:45 ` pr-tracker-bot
2020-08-03 22:45 Steve French
2020-08-07  2:39 ` pr-tracker-bot
2020-07-04  3:44 Steve French
2020-07-04  7:00 ` pr-tracker-bot
2020-06-13 20:37 Steve French
2020-06-13 20:50 ` pr-tracker-bot
2020-04-26 14:23 Steve French
2020-04-26 19:20 ` pr-tracker-bot
2020-04-12  2:26 [GIT PULL] cifs/smb3 fixes Steve French
2020-04-12 17:25 ` pr-tracker-bot
2020-03-31 19:14 [GIT PULL] CIFS/SMB3 fixes Steve French
2020-03-31 21:50 ` pr-tracker-bot
2020-03-19  4:51 Steve French
2020-03-19 17:03 ` Linus Torvalds
2020-03-19 17:15   ` Steve French
2020-03-19 17:25 ` pr-tracker-bot
2020-02-16  2:58 [GIT PULL] CIFS/SMB3 Fixes Steve French
2020-02-16 19:50 ` pr-tracker-bot
2020-02-09  1:45 Steve French
2020-02-09 21:30 ` pr-tracker-bot
2019-11-27 23:49 Steve French
2019-11-30 19:13 ` Linus Torvalds
2019-11-30 21:20   ` Steve French
2019-11-30 19:40 ` pr-tracker-bot
2019-10-27  2:40 Steve French
2019-10-27 11:30 ` pr-tracker-bot
2014-10-03 19:56 Steve French

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wiKoePP_9CM0fn_Vv1bYom7iB5N=ULaLLz7yOST3K+k5g@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smfrench@gmail.com \
    --subject='Re: [GIT PULL] CIFS/SMB3 fixes' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).