On Mon, Mar 13, 2023 at 11:21:39AM -0700, Erich Eickmeyer wrote: > > > My point is that lowlatency shouldn't be grouped-in to these flavors, but > > > should be given higher priority and grouped-in with generic since it's > > > still used in desktop systems by default and is directly affecting the > > > testing of an official flavor of Ubuntu. This was one of the reasons we > > > had to miss testing week because we didn't even have kernel parity.
> > Impossible. we run out of disk space and cannot complete the > > lowlatency builds with generic any more. Thus it is now treated > > exactly like all other derivatives. > If you ran out of disk space perhaps you should have requested more disk > space? I'd think that's something that should have been easily > accommodated by IS. This is running out of package space *during package builds*. The Launchpad build instances, for sanity of operability, are all pre-provisioned and one-size-fits-all. There is no capability in Launchpad to request more disk space for a particular package build (the information is not even available at the time the VM is instantiated what build will be done on it). This is a longstanding design decision that the Kernel Team has no power to change and the Launchpad Team has no capacity to address in any sort of near term. Your choices for Lunar are to have the lowlatency kernel flavor as a separate source package or to have it not at all. > because disk space shouldn't be a limitation in this day and age. That is not constructive or realistic. > > We do not invest additional engineering & resource time, to prioritise > > lowlatency flavour, over other flavours, which have more images and > > higher usage. > Well, thanks, that alienates an entire user base and a whole official > flavor of Ubuntu, which basically puts you at odds with the community. > I'm sure that's not your intention, but seeing as how Ubuntu is a > community-driven distribution, you probably should rethink this. All the other community flavors in Ubuntu use the generic kernel flavor. You are asking the Ubuntu Kernel Team to do something which first of all is not possible from an engineering perspective, but secondly would involve them committing to provide additional labor for a specific community flavor which, from a community governance perspective, is not in your power to require. What Dimitri is communicating is that the support the lowlatency kernel flavor receives is the same, no better no worse, as the support provided for all of the kernel flavors that actually provide the funding for the Kernel Team to do that work. If you want to have a conversation about the Ubuntu Studio team taking responsibility for a community-maintained kernel flavor, we could have that conversation. But it's not reasonable to ask that the Kernel Team make a HIGHER committment to the lowlatency kernel in the service of Ubuntu Studio, than they do to the kernels for paying customers. That said, with my Release Team hat on, I will state clearly that I am not happy with the state of kernels in the devel series; either in lunar, or in other series of the recent past. We have a pretty consistent history of kernel security updates being synced from the stable release to devel-proposed and then languishing there for months with insufficient effort to get them migrated to the release pocket, with the result that Ubuntu Developers who dogfood our development releases have the least secure systems out of the box of any Ubuntu users, from the time a new series opens to the time the Kernel Team releases kernels to the devel series based on the new upstream version that's targeted for the next release. Dimitri as one of the few core-devs on the Kernel Team is who I see primarily engaging with the Release Team to get kernels in the devel series unstuck from -proposed. But it's not on him personally to manage this, there's a systemic issue of undercommitment of resources to the devel series. And complaining about the state of where things are now in the lunar release pocket isn't going to change anything. It would be a misinvestment to work on rebasing the other kernel flavors on 6.1 now with a 6.2 upload around the corner. > > > reason (two blockers this round). To not have kernel equality here could > > > cause false positives in kernel-level testing. JACK and the audio stack, > > > in particular, are directly affected by the kernel, and what might work > > > in 6.1 might not work in 5.19 with various devices. This could cause > > > false bug reports and create a lot more problems for triage. I think it's reasonable for you to decide not to invest time in testing against a kernel that is not the final kernel for the release, where you believe that will result in wasted time due to false-positives. But 6.1 is also not the final kernel for the release, so I don't see any reason that being at parity with the generic kernel in the release pocket *right now* would make a material difference to Ubuntu Studio's situation. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel