On 26/10/2023 09:16, Paul Moore wrote: > On Wed, Oct 25, 2023 at 9:25 PM Bagas Sanjaya <bagasdotme@xxxxxxxxx> wrote: >> On Wed, Oct 25, 2023 at 05:11:51PM -0400, Paul Moore wrote: >>> #### stable-X.Y branch >>> >>> The stable-X.Y branch is intended for stable kernel patches and is based on >>> Linus' X.Y-rc1 tag, or a later X.Y.Z stable kernel release tag as needed. >>> If serious problems are identified and a patch is developed during the kernel's >>> release candidate cycle, it may be a candidate for stable kernel marking and >>> inclusion into the stable-X.Y branch. The main Linux kernel's documentation >>> on stable kernel patches has more information both on what patches may be >>> stable kernel candidates, and how to mark those patches appropriately; upstream >>> mailing list discussions on the merits of marking the patch for stable can also >>> be expected. Once a patch has been merged into the stable-X.Y branch and spent >>> a day or two in the next branch (see the next branch notes), it will be sent to >>> Linus for merging into the next release candidate or final kernel release (see >>> the notes on pull requests in this document). If the patch has been properly >>> marked for stable, the other stable kernel trees will attempt to backport the >>> patch as soon as it is present in Linus' tree, see the main Linux kernel >>> documentation for more details. >>> >>> Unless specifically requested, developers should not base their patches on the >>> stable-X.Y branch. Any merge conflicts that arise from merging patches >>> submitted upstream will be handled by the maintainer, although help and/or may >>> be requested in extreme cases. >>> >>> #### dev branch >>> >>> The dev branch is intended for development patches targeting the upcoming merge >>> window, and is based on Linus' latest X.Y-rc1 tag, or a later rc tag as needed >>> to avoid serious bugs, merge conflicts, or other significant problems. This >>> branch is the primary development branch where the majority of patches are >>> merged during the normal kernel development cycle. Patches merged into the >>> dev branch will be present in the next branch (see the next branch notes) and >>> will be sent to Linus during the next merge window. >>> >>> Developers should use the dev branch a stable basis for their own development >>> work, only under extreme circumstances will the dev branch be rebased during >>> the X.Y-rc cycle and the maintainer will be responsible for resolving any >>> merge conflicts, although help and/or may be requested in extreme cases. >>> >> >> If I have patches targetting current (not next) release cycle, either for >> stabilizing that cycle or for stable backports, I have to base it on dev >> branch (not stable-X.Y), right? >> >> Confused... > > I would prefer that yes. I know it sounds a little odd, but I'd > rather see folks develop and test against what we believe to be the > latest subsystem code, which is what lives in the dev branch. If > there are merge conflicts, I'd rather we see them when merging the fix > into the stable-X.Y branch so we are aware of the conflict at > development/submission time rather than waiting for the next merge > window. Having done this for a number of years at this point, I've > learned to appreciate seeing merge conflicts as early in the > development cycle as possible and I've also learned that they are > often not as scary in practice as we imagine. > > Of course all of this is a general rule since you can't specify every > single situation in guidance like the above; if there is something > that you believe is particularly ugly you can always write the mailing > list, or me directly if the issue is sensitive, and we can sort it > out. If after a few months (year?) this proves to be too painful we > can always revisit this and update the policy, it's definitely not set > in stone. > > Hopefully you are less confused now? > OK, thanks for clarification! -- An old man doll... just what I always wanted! - Clara
