Hi folks I feel we've gone backwards since we had a video call on this topic, where my impression was a specific agreement to support LTS enablement provided upgrade breakages were handled. There is a need in any event to deprecate support for hardware in every release, so upgrade blocking is a valuable addition to the system.
Suggesting that Ubuntu resurrect the partner archive wishes the problem away and fragments the platform. Hardware enablement is one of the best things we do for the Ubuntu community, and I think the TB is missing the wood for the trees in reverting to a position it held before we properly discussed it. While we clearly drive partners towards upstream-centric enablement, we do no good by refusing to enable Ubuntu for users of LTS releases where that isn't currently the vendor's practice. I think the team in question should have latitude to enable hardware in existing LTS releases somewhat differently than the policies we apply to applications, for example. Mark On Tue, 19 May 2026 at 17:28, Andreas Hasenack via technical-board < [email protected]> wrote: > Hi, > > On Tue, Feb 24, 2026 at 7:52 PM Robie Basak <[email protected]> wrote: > > (...) > > We appreciate the challenges of the quasi-main-archive situation you are >> in at the moment. To avoid this happening again, let us be clear that >> you must not submit SRUs for hardware enablements that have not been >> already performed in the development release and all releases after the >> target release, and certainly not without making any deviation clear in >> all relevant documentation. This applies equally to kernel packages in >> the main archive. >> > > This topic came up again in the context of another hardware enablement > SRU, and I just wanted to clarify this statement one more time: "and all > releases after the target release". > > That includes interim releases that are still within their support > lifetime. For example, right now, if an HWE SRU is targeting noble, that > means it must also target questing (interim), and resolute (and of course > stonking, the current devel). > > -- > technical-board mailing list > [email protected] > https://lists.ubuntu.com/mailman/listinfo/technical-board >
-- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
