On Wed, Jan 26, 2022 at 3:38 AM Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: > > Lo! > > On 20.01.22 09:38, Sumantro Mukherjee wrote: > > > > I would like to invite all of you to participate in the Kernel 5.16 > > Test week is happening from 2022-01-23 to 2022-01-29. It's > > fairly simple, head over to the wiki [0] and read in detail about the > > test week and simply run the test case mentioned in[1] and enter your > > results. > > [...] > > [0] https://fedoraproject.org/wiki/Test_Day:2022-01-23_Kernel_5.16_Test_Week > > [1] https://testdays.fedoraproject.org/events/126 > > [2] https://badges.fedoraproject.org/badge/science-kernel-tester-i > > Wouldn't it be better for everyone if stable pre-releases would be > offered for testing in these test weeks, *if* they are available at that > time? I was just wondering that, as according to your [0] it seems that > 5.16.2 is still being tested currently, but 5.16.3 is up for review > already since Monday -- with more that 1000 changes: > https://lore.kernel.org/stable/20220124184125.121143506@xxxxxxxxxxxxxxxxxxx/ > > [note, there are newer pre-releases for 5.16.3 already] > > These changes might fix a few bugs testers otherwise might run into > without need -- or introduce new bugs that thus can be found and fixed > before 5.16.y hits updates-testing. I do create test builds for stable rc kernels usually, but they are scratch builds and not secure boot signed. With the time it takes for full kernel builds, and then the time to spin new ISOs, etc. I would never get feedback in time for a stablerc before the kernel is released. And with 5.15 and 5.16, the early stable's often have more than 1 rc release. For most of the 5.15 test week, we were iterating over rcs to get 5.15.3 out because of an issue that would impact many/most users, which was a regression from 5.15.2. We knew about this issue, but having it as a test week kernel would have lost a lot of meaningful feedback because many testers would hit the known bug and stop testing. > I bring this up, as situations like happened a few times already, as > Greg often merges a big bunch of changes in the first two weeks after a > mainline rc1 is out (see https://lwn.net/Articles/863505/ ) -- and > that's usually the time when the kernel test week happens. > > Ciao, Thorsten > > P.S.: kernel.spec until a few years had some code that made building > stable rcs easy, but it was removed (and likely won't work well the the > ask based kernel.spec anyway). There are still a couple of ways to go about it. If you just want to deal with dist-git and the stable-queue quilt trees, it is pretty simple to cat the patches (in series order) to a patch file and apply that patch before the redhat patch. For kernel ark with the source tree, there are still some issues with the scripts that I need to fix up to handle a stable rc. Right now, the logic expects either an rc or a stable. I will try to get that done as we get further in the 5.17 cycle. It is still possible, and pretty easy to build a stable rc with a caveat. An example workflow for building the 5.16.3-rc2 stable kernel (this expects you have local branches for both stable/linux-5.16.y and stablerc/linux-5.16.y as linux-5.16.y-rc). 1) Update linux-5.16.y, linux-5.16.y-rc, and fedora-5.16 branches 2) In fedora-5.16 'git merge linux-5.16.y-rc' and fix any merge issues if they appear 3) git revert Greg's latest commit which actually changes the version to 5.16.3-rc2 (this chokes up our scripts). >From there you can build as you typically would. The kernel is still versioned as 5.16.2, so I tend to specify the release to match the rc number, but that is personal preference. Once I get the scripts fixed, we won't need to revert the version patch, and the spec should be versioned correctly. Justin _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
