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/
slangasek@ubuntu.com vorlon@debian.org
