Changes in md branch management

Changes in md branch management

[Song Liu]

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.

Thanks,
Song

Re: Changes in md branch management

[Jens Axboe]

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

Re: Changes in md branch management

[Song Liu]

On Wed, Jan 10, 2024 at 9:51 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> 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?

Yeah, this is a great idea.

>
> 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.

Yes, we shouldn't need to rebase any patches for the md-6.9 branch.

Thanks for the feedback!
Song