On Sat, 13 Dec 2025, Linus Torvalds wrote:
> On Fri, 12 Dec 2025 at 05:56, Mikulas Patocka <[email protected]> wrote:
> >
> > I rebased it just before sending it because the kernel test robot found
> > grammatical errors in two commit messages.
>
> That really isn't a strong enough reason to then rebase things late.
>
> Rebasing is for *important* things, or for early development. Not for
> the merge window, or at least not without explaining why the tree
> contains a lot of very recent changes.
>
> > What's your preferred time frame for submitting the device mapper pull
> > request? One week since the merge window starts? Or less than one week?
>
> The code should be ready *BEFORE* the merge window starts. Not "one
> week after". Not one *HOUR* after.
>
> Lots of people send me their pull requests the week before. This time
> around I had something like 35 pull requests ready to go for the merge
> window in my inbox when I released 3.18.
>
> Other people wait for the actual release, so then on the first Monday
> of the merge window that number had roughly doubled, and that's fairly
> normal.
>
> Does it *have* to come in that early? No. We have two weeks partly to
> be able to be flexible. But those two weeks are *not* for development.
>
> They are for me and "it takes time to merge", and they are for other
> developers for "my goldfish ate my favorite stick bug, and now I'm
> devastated and an emotional wreck, and it took me some time to get
> over it".
>
> So people have other things going on in their lives than just kernel
> development, and two weeks gives some buffer for that.
>
> And sometimes there's some trees that have dependencies where there's
> a few "I need to go after that other tree" kinds of things, and the
> two weeks gives some flexibility in that sense.
>
> That last case used to be particularly true back when Andrew Morton
> didn't use git, so his series depended on other peoples git trees and
> couldn't use stable git branches where two or more trees shared some
> common history.
>
> But even with all those reasons for two weeks, the merge window is for
> things that were ready *before* the merge window started.
>
> Sure, late commits happen because maybe there were fixes that still
> came in and people notice them and want to deal with fixes asap, and
> there might be a "one more thing" there, but the merge window is NOT
> for new development.
>
> And not for random late rebases that aren't explained. When I see lots
> of recent commits, that just makes me go "what the heck happened
> here?" exactly because that should *not* be happening. It should have
> been ready to go.
>
> And as always - you can *explain* things. The merge message should
> have explanations for what the pull contains, but there can also be
> notes about why something was slightly off. Like explaining why some
> unusual late rebase happened.
>
> But note the "unusual". It shouldn't be the pattern.
>
> Basically, if a pull request comes in during the second week, you
> should have a *reason* for it that you also explain. If it's too
> personal to explain in public, feel free to just send me a separate
> private email.
>
> Things happen. We have rules, but at the same time very few rules are
> black and white. Kernel development is supposed to be pretty flexible
> - outside of the "no regression" rules, pretty much all other rules
> can be bent.
>
> But when the rules are bent, they should at least be explained.
>
> Linus
OK.
I will send the pull request sooner next time and I'll defer patches that
come during the merge window.
Mikulas
