On Wed, Jan 20, 2021 at 1:04 PM Mark Pearson <markpearson@xxxxxxxxxx> wrote: > > > On 20/01/2021 11:11, Kamil Paral wrote: > > On Tue, Jan 19, 2021 at 6:44 PM Mark Pearson <markpearson@xxxxxxxxxx > > <mailto:markpearson@xxxxxxxxxx>> wrote: > > > > Release cadence is once. We just can't update our preload images that > > often - there's a long test cycle, and energy certification that goes > > with that image. It's one of the reasons the X1C8 is still shipping with > > Fedora32, and P1G3 and P15 (soon!) will be with F33 for a long time. The > > only reason to update would be a critical bug that couldn't be fixed > > with an update once the platform was received. > > > > > > If the cadence is once in a long time (related to new hardware > > introductions, so possibly once a year or similar), I think the best > > approach here is to have releng manually trigger an F33 Workstation Live > > image compose using the current updates repo. Assuming it's not a > > problem for them. We (the QA) can then trigger an OpenQA test run on it, > > create the release validation test matrices for it, and even ask the > > community in large to perform some manual tests if they have time. I > > believe some of us would devote some time to make sure at least the > > basics work correctly. I'm not sure if all the plumbing for this one-off > > compose is ready (in fedfind, relval, openqa and wherever else needed), > > but Adam will know more. > > > > I don't want to just repeat Adam's words, but I'd like to stress out > > that from the security perspective, such a compose should really be > > created using the proper Fedora Infra tooling (or Lenovo itself using > > official Fedora bits). I don't want to belittle the people standing > > behind the unofficial Live respins, they are doing a great and useful > > work, but if this is going to be shipped preinstalled to thousands of > > customers, the whole process should be as verifiable as with our > > official releases. > > > > Thanks Kamil, > > My preference would be to have a build that comes from Fedora with > Fedora's blessing rather than something we put together :) Partly so we > don't screw it up but also as part of the "we don't mess with the Fedora > image" thing - if we get the image from you then it reinforces that. > > I know our timelines right now are quite tight - I'd like to get the > image into test before Chinese New Year happens - though I'm looking at > the calendar and wondering how optimistic I'm being.... How big a deal > is creating an official compose? Is it days/weeks/months? At the moment > I'd like it by start of Feb (with a bit of wriggle room) > > As Matthew mentioned - 5.10.8 is coming out soon and whether that ties > into this too? Any recommendations from the community as to which fixes > are important etc happy to take on board. The HW testing we've done so > far looks good - but that's not the whole story. > While there are hardware fixes, the main reason for 5.10.8 being important is that the Btrfs performance regression introduced in 5.10.0 was fixed in that release. With this release, Btrfs I/O performance is at least 50% higher than 5.9 across virtually all workloads. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-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/test@xxxxxxxxxxxxxxxxxxxxxxx
