Message-ID: <2023071341-twitter-apron-e023@gregkh>
Date:   Thu, 13 Jul 2023 17:06:22 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Thorsten Leemhuis <linux@...mhuis.info>
Cc:     stable@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, Sasha Levin <sashal@...nel.org>,
        Jonathan Corbet <corbet@....net>
Subject: Re: [RFC PATCH v1 0/3] docs: stable-kernel-rules: add delayed
 backporting option and a few tweaks

On Thu, Jul 13, 2023 at 10:48:14AM +0200, Thorsten Leemhuis wrote:
> On 12.07.23 21:00, Greg KH wrote:
> > On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
> >> On 12.07.23 17:16, Greg KH wrote:
> > [...]
> >>>>   .. 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.
> > [...]
> >> 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.
> 
> /me first didn't want to reply, as this is not really important, but
> then reconsidered; again, feel free to just ignore this
> 
> FWIW, I do not consider that rebasing to be problem at all; it are those
> rebases "sometimes in intermediate places, before a -rc is released,
> just to give CI systems a chance to test easier" make things this
> slightly annoying bit harder when you want to distribute stable-rc
> releases to users.
> 
> But as I said, I can fully understand why you do those as well. I just
> with there was a way to reliably get a -rc release from git as well.
> Simply tagging them when you do a -rc release would solve all that. Is
> that maybe something that could be easily added to your -rc release scripts?

I can add a tag, but it would have to be a tag that can be rebased, and
git doesn't like that very well :)

> /me looks at https://github.com/gregkh/gregkh-linux/tree/master/stable
> but failed to find the -rc release script :-/

Hah, no github, it's at:
	https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/scripts/quilt-mail

But I don't think tags will help much.  I'll let anyone who actually
runs a CI that uses this to speak up to see if it would before adding
them.

Also, as proof this works, I just got a report of someone testing the
queues and finding a problem at the moment, before we sent anything out
for review.  So this is working well today.

thanks,

greg k-h

Powered by blists - more mailing lists