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
