ANN: kernel git branches and process changes

[Bagas Sanjaya]

On 26/10/2023 09:16, Paul Moore wrote:
> On Wed, Oct 25, 2023 at 9:25 PM Bagas Sanjaya <bagasdotme at gmail.com> 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