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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 13 Jul 2023 10:48:14 +0200
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Greg KH <gregkh@...uxfoundation.org>
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 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?

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

Whatever, as I said, not really important. :-D Have a nice day everyone!

Ciao, Thorsten