Hi, On 8/8/22 02:02, Justin Forbes wrote: > On Thu, Aug 4, 2022 at 9:04 AM Justin Forbes <jforbes@xxxxxxxxxx> wrote: >> >> On Thu, Aug 4, 2022 at 5:44 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: >>> >>> On Thu, Aug 4, 2022 at 11:35 AM Hans de Goede <hdegoede@xxxxxxxxxx> 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 _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-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/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
