tl;dr: I'm still -1 on this proposal. For hardware enablements that cannot meet our existing requirements, some combination of PPAs, resurrecting the partner archive, and shipping specialist images built from outside the archive remain the best and most appropriate options.
My reasoning follows. # Making a decision I don't think I have heard a complete argument in favour of of the proposed change. Suggestions have been made with regard to the current situation on specific points, but I'm still unclear on the details. I think I've asked clearly enough, so given the iterations we've had already as well as meeting discussion[1], it seems reasonable to proceed without as all opportunity has been given. The thread has dragged on long enough; it's time to make a decision. # Specific arguments [I've copied previous argumentation I've made so it's up-to-date and all in one place] Blocking do-release-upgrade isn't enough. Users also upgrade by reinstalling the new version, and will find the regression then. There are two ways of upgrading: 1) the user uses do-release-upgrade (or the GUI equivalent; 2) the user reinstalls and redeploys with the new release. The latter case is much more common in professional developent and production environments. Gating the release upgrader covers the former case but misses the latter. Users have expectations about hardware support and how they relate to Ubuntu releases. If Ubuntu announces that some new hardware is now supported in Ubuntu, users can reasonably expect that the latest release of Ubuntu, as well as the next release of Ubuntu, will also support that hardware. Breaking this assumption therefore has consequences for user expectations, and also has implications to effectively _set_ expectations. How are users then expected to understand what features they can expect to available in the next Ubuntu release, and which features will be missing on release upgrade, to either appear later (when?) or possibly never? It seems to me that we need to be very clear to users about this, and the only reasonable way to do this is to *not* claim that hardware is enabled in Ubuntu until it is enabled in all releases following some target release (eg. the current LTS), as is the current rule. I accept that features do eventually get dropped, but this is quite different from a user perspective. Users understand the distinction between new things being added (in which case they expect the next Ubuntu release to also contain that support) and support for old hardware or technologies being sunset (in which case they expect the next Ubuntu to possibly drop that support). Features eventually getting dropped are therefore an entirely different and distinct case from new feature being added from a user expectation perspective. It doesn't follow that just because we do one, the other is acceptable. It was argued that usability and discoverability of updates would be better from the main archive for these hardware enablements. I don't buy it. For those cases where an image is required, the discoverability of an apt package is moot since a specialist image generated from outside the main archive would already have the appropriate PPAs enabled. Usability is therefore the same in both scenarios. In cases where a regular installer can be used, I don't think it's a big enough burden to point users to PPAs. In fact, that is an entirely appropriate marker to set user expectations of the subpar experience they can expect; namely in this case that a future release upgrade will not work. It was argued that security maintenance would be better if this work in the main archive. But security maintenance can be performed in a PPA. I'm aware that the security team already do so for a number of PPAs. So any argument that using the main archive is better for security is moot. In both cases security maintenance must be performed, and in both cases they can be. It is true that using the main archive means that you only have one thing to security maintain, but by not upstreaming the enablement in the first place, you're already volunteering to do forward porting work multiple times, and security maintenance is a fraction of that in comparison. It was argued that you prefer to be held to a better quality standard by using the main archive. This is a specious argument since we're only discussing this exactly because you want to suspend a specific bar of quality that we already have exactly because you do not want it to apply to you. You talked about wanting clarity on the exception. I agree that we should have clarity on what is and is not acceptable. But let's be clear that there currently is no exception. The only reason we're in the position we are at the moment appears to be due to multiple teams landing SRUs contrary to Ubuntu's longstanding policy to enable the development release first and only then backport. It is common that there is no mention that a hardware enablement hasn't been performed in the development release. Reviewing teams relied on good faith assumptions that this was already done and that you would call out unusual situations, but you did not. When noticed, subsequent requests are sometimes (inappropriately) justified on the basis that some other part has already landed, but this is because policy violation went unnoticed, not because an exception was granted. Most of the bugs you linked do some combination of this, and also usually mark development release bug tasks as "Fix Released" even though the use case presented does not work on the development release at all. Where the facts have not been hidden from the SRU team, reviews have generally consistently upheld longstanding policy. On Jetson users stuck on Jammy: so give them a custom Noble image shipped from a PPA, like (presumably?) you did last time. Or, if at the time you broke the "development release first" rule by bypassing SRU team review and then shipped an image build from the main archive only, you can break the cycle by fixing the development release first now, and then backporting. If you insist that a release upgrade must now work, then surely that demonstrates exactly why you must not break the rule in the future. I don't see how transferring the problem of users being stuck on Jammy to the problem of users being stuck on Noble is really any better given that they still won't be able to move to Resolute when it is released. Instead, we should be honest about this to our users by keeping these subpar enablements out of the main archive until you actually enable the development release and keep it enabled. Generally, the same applies to the other examples you gave where users are "stuck". I see no reason why remaining outside the archive and providing custom images cannot give users the best experience possible. There is only one way to give them a better experience, which is to enable the development release first. There's already tremendous pressure from customers to focus only on LTS releases, sometimes even only the older ones. If enablement efforts focus there, then new releases won't have meaning any more. Users already wait before switching to a new LTS release. It used to be that they would wait until .1. I've recently heard people recommend waiting until .2. If we agree to your proposal then they're going to also have to wait until everything they want is enabled. As a result the reliable two year cadence we have for LTS today will become a lie, since in reality nobody will switch for some undefined period of time until an LTS is actually ready, which won't have a clear point in time any more. All the effort we spend on keeping the stable release stable will be wasted for the early life of an LTS, effectively shortening the effective lifetime of a release. What is a release anyway, if not a point in time that we say that this is the best we offer? By reserving the latest and best hardware enablements from the release, you'd be undermining our release themselves. And interim releases will never get enablements at all, making them increasingly useless. So why are we going to the trouble of making them, releasing them and "supporting" them? So far, they are mostly only second class citizens in respect of lifetime. They still receive security and bugfix* maintenance, and we go to an incredible amount of effort to get them in shape and keep them there. If we continue to push to ignore them, maybe we should just stop the pretence and stop shipping them? I take a different view here. It isn't obvious what the benefit of interim releases and the "development release first" approach is exactly when you look at the sheer number of users who prefer the LTS. But those statistics are not appropriately weighted. The value we get from the next release is heavily weighted by the relatively few users of the previous interim release and users of the development release. Those are the users who are active in both developing upstream code, contributing patches into our ecosystem and also giving us the feedback to make our next release great. If you think about it, these users are the *only* source of our next release! If we continue to undermine those users by witholding features from them, we're only hurting our own ecosystem and thereby our own product. This applies even to rare hardware enablements with few users! # Process implications if in favour What if we were to allow this request? It's easy to say yes, but that opens a can of worms. Yes to what, exactly? How are we going to define what is allowed and what isn't? Are we removing the "must not regress on release upgrades" rule altogether, so we can add any feature or bugfix to any release without thought as to we will break user expectations on a future release? Only for LTS? Only if there's a release upgrader quirk to block, and if so, what will qualify for a release upgrader quirk? What about MOFED, for example? Would you expect to enable MOFED in Noble without fixing Resolute (or a future development release) first? # Conclusion -1 from me. [1] https://irclogs.ubuntu.com/2025/11/18/%23ubuntu-meeting.html#t20:07
signature.asc
Description: PGP signature
-- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
