ANN: kernel git branches and process changes

[Paul Moore]

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?

-- 
paul-moore.com