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
