[Drbd-dev] [GIT PULL] DRBD fixes for Linux 5.18
Jens Axboe
axboe at kernel.dk
Wed Apr 6 14:35:40 CEST 2022
On 4/6/22 2:06 AM, Christoph B?hmwalder wrote:
> Hi Jens,
>
> this is the first batch of DRBD updates, catching up from the last few
> years. These fixes are a bit more substantial, so it would be great if
> they could still go into 5.18.
Thanks for sending these, but you based the repo on my 5.19 branch,
which won't work as pulling your tree will then result in me getting
your 5.18 changes with my 5.19 as well.
As it happens, this is also a problem for your 5.19 based changes. My
for-next branch is not stable, just like linux-next isn't stable. In
terms of shas, not how it runs...
In general, for the block tree, here's what you want to base the changes
on, using 5.18/5.19 as examples as current/next tree.
- If they are bound for 5.18, base them on block-5.18. That branch may
not exist if nothing is queued up yet, in which case just base them on
the last -rc1 tag for that series. That'd be 5.18-rc1 in this case.
- If they are bound for 5.19, usually I will have a 5.19 driver and core
block branch. Base them against for-5.19/drivers. If it doesn't exist,
previous -rc is a good choice again.
Usually post -rc2 all of the above branches will exist, during merge
window and right after things are a bit more influx and haven't really
settled down yet.
Now, there's also the fact that you're using a non kernel.org git tree.
That's fine, but ideally we'd like you to use signed tags in that case.
But not sure your key has been signed by anyone in the korg ring of
trust? Since I've already seen these patches this isn't a huge concern
for now, but something to get sorted out going forward.
Can you rebase your two pull requests and send them in again? Either
that, or just git send-email the two series, that'll work too. I'm fine
applying series from maintainers like that, it doesn't have to be a git
pull request.
--
Jens Axboe
More information about the drbd-dev
mailing list