Re: [External] Re: Respins for OEM preloads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux