On 13.07.23 17:39, Conor Dooley wrote:
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 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 :)
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?
Yup, exactly, that's what I meant, as that makes it possible to get the same state as the tarball by simply doing a "git checkout v6.4.4-rc1", even if the linux-6.4.y branch in the stable-rc repo changed.
And CI systems should not care.
/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...
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
My scripts instead wait for the tarballs to show up on kernel.org. :-D
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 :)
Yeah, CI systems likely don't care much, but I distribute the proper stable-rc releases to ordinary users for simple testing in the wild; and it afaics would be good if they'd match the tarball in case a users runs into problems and reports them, as I fear people otherwise might quickly talk past each other...
Ciao, Thorsten