Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 13 Jul 2023 16:39:52 +0100
From:   Conor Dooley <conor@kernel.org>
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     Thorsten Leemhuis <linux@leemhuis.info>, stable@vger.kernel.org,
        linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
        Sasha Levin <sashal@kernel.org>,
        Jonathan Corbet <corbet@lwn.net>
Subject: Re: [RFC PATCH v1 0/3] docs: stable-kernel-rules: add delayed
 backporting option and a few tweaks
Message-ID: <20230713-irritant-rarity-5f7b424fe43e@spud>
References: <cover.1689008220.git.linux@leemhuis.info>
 <2023071002-phrasing-tranquil-49d6@gregkh>
 <a97a37bf-86b5-cd8e-a8ce-00e38720cee4@leemhuis.info>
 <2023071221-blade-reactive-0707@gregkh>
 <d8403c45-3561-4759-f6c2-d18afa5e323a@leemhuis.info>
 <2023071215-able-mushy-c889@gregkh>
 <18238769-39c3-2b40-7725-367aa0e5c50b@leemhuis.info>
 <2023071341-twitter-apron-e023@gregkh>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="5zCBt+dSDALTpKvC"
Content-Disposition: inline
In-Reply-To: <2023071341-twitter-apron-e023@gregkh>
Precedence: bulk


--5zCBt+dSDALTpKvC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 13, 2023 at 05:06:22PM +0200, Greg KH wrote:
> 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 n=
ew -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 intermedi=
ate
> > >>> 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 so=
me
> > >> ordinary users and some distributions are building kernels straight =
=66rom
> > >> 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/
> > >=20
> > > As we keep the patches in quilt, not git, it's the best we can do.  T=
he
> > > -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.
> > >=20
> > > 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.
> >=20
> > /me first didn't want to reply, as this is not really important, but
> > then reconsidered; again, feel free to just ignore this
> >=20
> > 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.
> >=20
> > 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 scr=
ipts?
>=20
> 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 :)

I figure the desired tagging behaviour is that you do it when the email
is sent out for a corresponding version & so the tag "should" not need to
be rebased?

> > /me looks at https://github.com/gregkh/gregkh-linux/tree/master/stable
> > but failed to find the -rc release script :-/
>=20
> Hah, no github, it's at:
> 	https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/=
tree/scripts/quilt-mail
>=20
> 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.

I'm not sure that it is particularly valuable to the usual flow of
testing what is about to come down the tracks, at least in my simple
case where I trigger it based on the -rc emails or whenever something
else interesting happens, like a patch being dropped that breaks the
build.

I suppose it may be useful if an issue presents itself but disappears
when a backport is dropped from the queue & some developers are
interested in figuring out why the backport went awry?

Other than that, I'm not sure what the value is in "I just with [sic]
there was a way to reliably get a -rc release from git as well", in
_my_ CI use case I don't care about the superseded stable -rc versions,
just whatever is about to be released.

Others with more complex CI infrastructure, like Linaro etc, might feel
differently :)

> 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.
>=20
> thanks,
>=20
> greg k-h

--5zCBt+dSDALTpKvC
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZLAaxQAKCRB4tDGHoIJi
0ufnAPoDpPrRw9iwibvmWTaKWO72V+pyNZUp7/9FmQCwxMfs0QEAgV1zbDgb6hIu
J1txvI3y+DExvTq+h1xUqgdvVZduRA8=
=X8n3
-----END PGP SIGNATURE-----

--5zCBt+dSDALTpKvC--