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
