Hi! [moving to ubuntu-devel@ for wider discussion]
I think the appropriate answer here depends on careful policy decisions that would apply to both the development and to stable releases. I discussed this briefly with some other SRU team members earlier, and also with Seb. Subject to further consultation, I suggest that if we recommend that users switch to the snap, then that should require explicit user opt-in (eg. via a debconf prompt) regardless of whether it's in Lunar or in a stable release. This means that the current implementation in Lunar should also be changed. For an SRU, if the current deb is unusable, nobody is stepping up to maintain it and this is causing users harm, then either we ship a transitional deb without a binary with the same explicit opt-in requirement, or we do that but also keep the deb-built binary available in case the user selects "no". The decision should depend on exactly what is wrong with the current deb. We shouldn't bother users unless there's something seriously wrong with it. In both cases, the notice associated with the choice should be crafted carefully to make it clear that if the user selects "yes", then they would be installing telegram-desktop directly as shipped by a third party and not from Ubuntu, and that further maintanance of the package would come from upstream, subject to upstream and no longer Ubuntu process and policies. Here's my reasoning. Regardless of whether we do this in the next release or also in existing stable releases, there are some key user expectations that we should be thinking about: 1) That users expect Ubuntu releases to be stable in the sense that they won't change behaviour once released (with some exceptions). 2) That policy, builds, quality control, package publication and similar processes are under the control of Ubuntu governance. This is required in order for us to be in a position to deliver on user expectations generally, including on the previous point. Moving to snaps published by third parties would break these expectations, unless we take further action. In some cases, moving to a snap makes sense. For example, given that the telegram-desktop deb continues to have no volunteers to fix the outstanding issues with it, it sounds like users are better served by the snap right now. But how does that fit in with user expectations I described above? Within the Technical Board I've been working on defining policy in this area. The draft isn't quite ready yet so this is unfortunate timing. But based on the current state of our deliberations, I think we're at the following in relation to telegram-desktop: If users make a deliberate choice to opt-in to a third party software source, then no further policy applies. Users understand that they are no longer consuming the software "from Ubuntu", so expectations on quality from Ubuntu no longer apply. Otherwise, user expectations such as "no change in behaviour" generally remain, and we should maintain that. So packages installed by default in Ubuntu, or through automation such as a transitional deb, should not change in behaviour even when the package ultimately being delivered is a snap. There are exceptions. For example, Firefox already had an exception as a deb, so it makes sense to carry that through to the snap. It is probably appropriate to apply our usual Internet protocol change exception to telegram-desktop, but I'm not sure it's appropriate to give it a blanket exception for all behavioural changes when protocol changes do not require them. There are also other requirements on such snaps in our draft, such as a dedicated snap track, which aren't currently implemented in the telegram-desktop transitional deb that's in Lunar right now. Some would require commitments from upstream. It seems to me that in the case of Telegram, it makes more sense to leave upstream free to do what they want in respect of the snap, rather than for us to ask them for their agreement in implementing our "stable" policies. This would preclude us from installing telegram-desktop by default, or pulling it in automatically via a deb, but that doesn't seem like much of an issue to me given that in the past the only way for a user to install it was by requiring explicit user action anyway. Feedback appreciated. Feedback from non Ubuntu developers should go to ubuntu-devel-discuss@ please[1]. Thanks, Robie [1] https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
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
