The initial fedora-5.19 branch has been created in kernel-ark. As I mentioned earlier, F37 will branch a 6.0 merge window kernel, but that will be replaced with 5.19 as soon as possible. We will also do stabilization for the 5.19 branch and hope to rebase Fedora 35 and 36 to 5.19 in a timely manner. Test week will be August 14-20 and the rebase will hopefully be shortly after that.
Thanks, Justin
Hi,
On 8/2/22 22:15, Justin Forbes wrote:
The initial fedora-5.19 branch has been created in kernel-ark. As I mentioned earlier, F37 will branch a 6.0 merge window kernel, but that will be replaced with 5.19 as soon as possible.
I'm not sure when F37 branches of, but it would it not be better to keep at F37 on 5.19 and move rawhide to 6.0 once F37 has its own branch ?
My main worry here is how you are going to get F37/rawhide consumers to move back from 5.20 to 5.19. The only way I see to do this is bump the epoch, which we generally try to avoid ?
Regards,
Hans
On Thu, Aug 4, 2022 at 11:35 AM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 8/2/22 22:15, Justin Forbes wrote:
The initial fedora-5.19 branch has been created in kernel-ark. As I mentioned earlier, F37 will branch a 6.0 merge window kernel, but that will be replaced with 5.19 as soon as possible.
I'm not sure when F37 branches of, but it would it not be better to keep at F37 on 5.19 and move rawhide to 6.0 once F37 has its own branch ?
My main worry here is how you are going to get F37/rawhide consumers to move back from 5.20 to 5.19. The only way I see to do this is bump the epoch, which we generally try to avoid ?
dnf distro-sync will also downgrade but I two have concerns.
I wonder if not doing something similar to what we do when stabilising kernels would work, push 5.19 to that and build there while keeping rawhide branch as 5.20 rc and doing builds for it but not tagging it into the rawhide release until branching. There might need to be a special branch process there too. Messy for dev side but probably less messy for uses.
Peter
On Thu, Aug 4, 2022 at 5:44 AM Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Aug 4, 2022 at 11:35 AM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 8/2/22 22:15, Justin Forbes wrote:
The initial fedora-5.19 branch has been created in kernel-ark. As I mentioned earlier, F37 will branch a 6.0 merge window kernel, but that will be replaced with 5.19 as soon as possible.
I'm not sure when F37 branches of, but it would it not be better to keep at F37 on 5.19 and move rawhide to 6.0 once F37 has its own branch ?
My main worry here is how you are going to get F37/rawhide consumers to move back from 5.20 to 5.19. The only way I see to do this is bump the epoch, which we generally try to avoid ?
dnf distro-sync will also downgrade but I two have concerns.
I suppose I was rather counting on people to just do it by hand if they were concerned. F37 branches next Tuesday, so it will still be in the merge window. I somewhat figured users that are willing to run merge window kernels are probably a bit more capable of managing an rpm downgrade if necessary.
I wonder if not doing something similar to what we do when stabilising kernels would work, push 5.19 to that and build there while keeping rawhide branch as 5.20 rc and doing builds for it but not tagging it into the rawhide release until branching. There might need to be a special branch process there too. Messy for dev side but probably less messy for uses.
I suppose I could have them untagged with each build (yesterday's failed as I need filter updates). That does get a bit problematic though, as it would likely subject those kernels to deletion after some time, and make it harder for people using them for a "koji bisect". Not really sure the right answer there.
Justin
Peter _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@lists.fedoraproject.org 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/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, Aug 4, 2022 at 9:04 AM Justin Forbes jforbes@redhat.com wrote:
On Thu, Aug 4, 2022 at 5:44 AM Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Aug 4, 2022 at 11:35 AM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 8/2/22 22:15, Justin Forbes wrote:
The initial fedora-5.19 branch has been created in kernel-ark. As I mentioned earlier, F37 will branch a 6.0 merge window kernel, but that will be replaced with 5.19 as soon as possible.
I'm not sure when F37 branches of, but it would it not be better to keep at F37 on 5.19 and move rawhide to 6.0 once F37 has its own branch ?
My main worry here is how you are going to get F37/rawhide consumers to move back from 5.20 to 5.19. The only way I see to do this is bump the epoch, which we generally try to avoid ?
dnf distro-sync will also downgrade but I two have concerns.
I suppose I was rather counting on people to just do it by hand if they were concerned. F37 branches next Tuesday, so it will still be in the merge window. I somewhat figured users that are willing to run merge window kernels are probably a bit more capable of managing an rpm downgrade if necessary.
I wonder if not doing something similar to what we do when stabilising kernels would work, push 5.19 to that and build there while keeping rawhide branch as 5.20 rc and doing builds for it but not tagging it into the rawhide release until branching. There might need to be a special branch process there too. Messy for dev side but probably less messy for uses.
I suppose I could have them untagged with each build (yesterday's failed as I need filter updates). That does get a bit problematic though, as it would likely subject those kernels to deletion after some time, and make it harder for people using them for a "koji bisect". Not really sure the right answer there.
Turns out there are some build issues due to kunit. Multiple ways to work around them, but trying to figure out the best path going forward. so at this point I have done source commits, but won't do a proper 6.0 build until after the branch.
Justin
Peter _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@lists.fedoraproject.org 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/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi,
On 8/8/22 02:02, Justin Forbes wrote:
On Thu, Aug 4, 2022 at 9:04 AM Justin Forbes jforbes@redhat.com wrote:
On Thu, Aug 4, 2022 at 5:44 AM Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Aug 4, 2022 at 11:35 AM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 8/2/22 22:15, Justin Forbes wrote:
The initial fedora-5.19 branch has been created in kernel-ark. As I mentioned earlier, F37 will branch a 6.0 merge window kernel, but that will be replaced with 5.19 as soon as possible.
I'm not sure when F37 branches of, but it would it not be better to keep at F37 on 5.19 and move rawhide to 6.0 once F37 has its own branch ?
My main worry here is how you are going to get F37/rawhide consumers to move back from 5.20 to 5.19. The only way I see to do this is bump the epoch, which we generally try to avoid ?
dnf distro-sync will also downgrade but I two have concerns.
I suppose I was rather counting on people to just do it by hand if they were concerned. F37 branches next Tuesday, so it will still be in the merge window. I somewhat figured users that are willing to run merge window kernels are probably a bit more capable of managing an rpm downgrade if necessary.
I wonder if not doing something similar to what we do when stabilising kernels would work, push 5.19 to that and build there while keeping rawhide branch as 5.20 rc and doing builds for it but not tagging it into the rawhide release until branching. There might need to be a special branch process there too. Messy for dev side but probably less messy for uses.
I suppose I could have them untagged with each build (yesterday's failed as I need filter updates). That does get a bit problematic though, as it would likely subject those kernels to deletion after some time, and make it harder for people using them for a "koji bisect". Not really sure the right answer there.
Turns out there are some build issues due to kunit. Multiple ways to work around them, but trying to figure out the best path going forward. so at this point I have done source commits, but won't do a proper 6.0 build until after the branch.
Ok, the build issues are unfortunate, but this does nicely solve the downgrade issue.
Regards,
Hans
Will help out
On Tue, Aug 2, 2022 at 10:16 PM Justin Forbes jmforbes@linuxtx.org wrote:
The initial fedora-5.19 branch has been created in kernel-ark. As I mentioned earlier, F37 will branch a 6.0 merge window kernel, but that will be replaced with 5.19 as soon as possible. We will also do stabilization for the 5.19 branch and hope to rebase Fedora 35 and 36 to 5.19 in a timely manner. Test week will be August 14-20 and the rebase will hopefully be shortly after that.
Thanks, Justin _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@lists.fedoraproject.org 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/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hey!
The kernel 5.19 test week has started, firing up the testing on my older HP 655 laptop and a Virtualbox VM as we speak :)
On Tue, Aug 2, 2022 at 10:16 PM Justin Forbes jmforbes@linuxtx.org wrote:
The initial fedora-5.19 branch has been created in kernel-ark. As I mentioned earlier, F37 will branch a 6.0 merge window kernel, but that will be replaced with 5.19 as soon as possible. We will also do stabilization for the 5.19 branch and hope to rebase Fedora 35 and 36 to 5.19 in a timely manner. Test week will be August 14-20 and the rebase will hopefully be shortly after that.
Thanks, Justin _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@lists.fedoraproject.org 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/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
kernel@lists.fedoraproject.org
-
Hans de Goede -
Justin Forbes -
Justin Forbes -
Luna Jernberg -
Peter Robinson