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
