Re: [RFC PATCH v1 0/3] docs: stable-kernel-rules: add delayed backporting option and a few tweaks

[Greg KH <gregkh@linuxfoundation.org>]

On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
> On 12.07.23 17:16, Greg KH wrote:
> > On Wed, Jul 12, 2023 at 11:30:30AM +0200, Thorsten Leemhuis wrote:
> >> While working on the latter I noticed one more thing:
> >>
> >> ```
> >>     .. warning::
> >>        The -stable-rc tree is a snapshot in time of the stable-queue
> >> tree and
> >>        will change frequently, hence will be rebased often. It should
> >> only be
> >>        used for testing purposes (e.g. to be consumed by CI systems).
> >> ```
> > [...]
> >> I'll thus likely
> >> change the text to something like this,
> >> unless I'm missing something or someone has a better idea:
> >> ```
> >>   .. warning::
> >>      The branches in the -stable-rc tree are rebased each time a new -rc
> >>      is released, as they are created by taking the latest release and
> >>      applying the patches from the stable-queue on top.
> > 
> > Yes, that is true, but they are also rebased sometimes in intermediate
> > places, before a -rc is released, just to give CI systems a chance to
> > test easier.
> > 
> > These are ONLY for CI systems to use, nothing else should be touching
> > them.  So I think the current text is correct, what am I missing?
> 
> That I misunderstood things and forgot about the "rebased sometimes in
> intermediate places" aspect I once knew about. Sorry. I'll leave the
> text as it is then.
> 
> Nevertheless makes me wonder: is that strategy wise in times when some
> ordinary users and some distributions are building kernels straight from
> git repos instead of tarballs? I'm one of those, as I distribute
> stable-rc packages for Fedora here:
> https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/

As we keep the patches in quilt, not git, it's the best we can do.  The
-rc releases are never a straight-line if we have to do multiple ones,
we remove patches in the middle, add them at the end or beginning, and
sometimes even change existing ones.

All of this is stuff that a linear history tool like git can't really
model well, so we keep a quilt series of the patches in git for anyone
that want to generate the tree themselves, and we provide the -rc git
tree for those that don't want to generate it and can live with the
constant rebasing.

thanks,

greg k-h