On Monday, March 13, 2023 11:03:00 AM PDT Dimitri John Ledkov wrote:
> On Mon, 13 Mar 2023 at 17:54, Erich Eickmeyer <eeickmeyer@ubuntu.com> wrote:
> > On Monday, March 13, 2023 10:29:50 AM PDT Dimitri John Ledkov wrote:
> > > Ideally all flavours would be at 6.2 already, but due to various
> > > reasons they are not.
> >
> > This is understandable and perfectly reasonable.
> >
> > > This is not unique to lowlatency flavour, and applies to kvm, azure,
> > > raspi, and many more kernel flavours all of which are still on v5.19
> > > in Lunar.
> >
> > 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. If it's a matter of ISO image space, then you need to be using iso_level=3
per the change I collaborated with to ubuntu-cdimage prior to 22.04's release
which future-proofed all Ubuntu .iso images beyond the 4GB level. Either way,
it sounds like you're either not communicating your needs to the right team(s)
or doing something wrong, because disk space shouldn't be a limitation in this
day and age.
> 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.
> > > We pushed 6.1 out, and migrated, on generic only, to migrate lots of
> > > packages in proposed, specifically nvidia & everything entangled with
> > > it, and thus unblock autopkgtesting of all the userspace packages
> > > which were otherwise failing on v5.19. There is no intention to port
> > > all flavours to 6.1.
> >
> > Again, this is one of the reasons we had do miss testing week among
> > another
>
> it was a mistake to skip testing week. you should have tested ubuntu
> studio during the testing week like all the other flavours did. As
> there are a lot of changes in lunar, that landed and affect ubuntu
> studio. For example, all cloud images which use various cloud kernel
> flavours, based on v5.19 did participate.
>
> Can you explain who made the call to skip testing week? as to me, it
> seemed, it's a requirement to release a flavour. Is studio going to
> skip Lunar release?
That was my call as Ubuntu Studio flavor lead to skip testing week. I found out
two days before the start of testing week (Feature Freeze) that a major
component of our test case (studio-controls) was not going to work properly
with the pipewire setup due to health issues on the part of the lead
developer, so to have users use the ISO tracker without a modified test case,
which needs to happen anyhow, would lead to poor test results. Basically, we
were not ready for testing week.
As far as a requirement to release a flavor? We usually have had testing weeks
after beta release. Honestly, this is between us and the release team.
> > 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.
> >
> > > in Lunar, no further 6.1 builds will be done for any kernel flavour
> > > for the time being. And v6.2 landing, across all flavours, is in
> > > progress.
> >
> > Understandable. I'm just trying to prevent the problem at hand in the
> > future, hence requesting that the decision to split the lowlatency into a
> > lesser flavor be reverted and have it built and treated as if it were the
> > generic kernel since it is installed by default in an official flavor of
> > Ubuntu on desktop systems. It is just clear to me that it truly does not
> > get equal treatment, which confirms my fears, which is why I want the
> > decision that was made reverted so that proper testing can proceed as it
> > was before this change.
> It was not a choice to split it, but necessity.
> We had to split lowlatency into a separate build, as generic &
> lowlatency from a single builder was unable to complete anymore due to
> build-time, disk usage, and upload time.
> It's either split builds, or no builds at all.
> Thus a revert, would just cause generic & lowlatency fail to build
> from source, always.
Then a solution needs to be figured out. It's been a year. If they need to be
built separately with lowlatency given a higher priority, then so be it, but
lowlatency needs to be given higher priority. It's installed with every
installation of Ubuntu Studio. I don't know where you get your metrics from of
low usage, but I guarantee it's off as Ubuntu Studio doesn't report
installation metrics since it's a default with the system and not installed
via command line. We're talking thousands of users per my estimates.
--
Erich Eickmeyer
Project Leader - Ubuntu Studio
Technical Lead - Edubuntu Revival
