Re: Changes in md branch management

[Jens Axboe <axboe@kernel.dk>]

On 1/10/24 10:42 AM, Song Liu wrote:
> In the past, we managed the md patches in two branches: md-next and md-fixes.
> This approach has a few issues:
> 1. It is not very clear which upstream version a patch will land in;
> 2. Around the merge window, there is no good base for md-next.
> 
> We will try to solve these issues with a new approach:
> 1. We will use numbered branches like md-6.9. Patches applied to the numbered
>    branches are planned to land in the numbered upstream release. Git commit
>    hash in these numbered branches should be the same as their final hash.
> 2. When there is no good base for the next numbered branch, which is usually
>    after previous rc7 and before the next rc2, accepted patches will
> be applied to
>    md-tmp branch. These patches are expected to be cherry-picked later to a
>    numbered branch, so the git commit hash may change.
> 
> Please let me know if you have comments and suggestions with this approach.

Sounds pretty reasonable, maybe name md-tmp md-tmp-6.10 or whatever the
case may be?

Outside of that, I like the idea of just having an md-6.9 branch. This
can continue to roll forward post the merge window, as there really
should only be md changes in there. Eg I can pull from that for both
before-merge-window times and for fixes post the merge window. That one
should never get rebased, you should just keep piling patches and fixes
on top.

-- 
Jens Axboe