On Wed, Jan 10, 2024 at 9:51 AM Jens Axboe <axboe@xxxxxxxxx> 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
