Le 14/06/2023 à 23:00, Robie Basak a écrit :
On Wed, Jun 14, 2023 at 09:31:42AM +0200, Didier Roche wrote:
Unfortunately, like many projects, there is a constant tension between the
request for new features backport (adsys, as being an enterprise product,
only really makes sense in a LTS context) and bug fixes. Most of the new
features are developed due to industry requirements, which are:
- evolution of their own security practices (for instance, certificates
support)
- request for other platform supports (winbind in addition to
already-existing sssd)
So on one hand, enterprise users want to use the LTS because they don't
want feature changes. On the other hand, they demand new features so
they do want change.
How does this fit with our stable release policies with respect to
adsys? Is it possible that one enterprise wants to use the current
version of adsys in a stable release and doesn't want it to change
because that's what they validated, and another enterprise wants a new
feature and requires it to be updated in a stable release?
If that conflict does arise, how are we to resolve it, keeping in mind
the need to maintain the reputation of our LTS as a stable platform that
generally and very deliberately doesn't do feature changes?
We are handling that with our extensive testsuite and very high standard
coding process, as you saw on my previous answer. We have a backward
compability promise, and we don’t change existing features, but go the
hard way which is to ensure we have transition plan for everything.
Indeed, this has a cost in term of developing, but I think this is the
standard that not enough OSS projects follow. However, if this was
followed more carefully, I think the industry wouldn’t be afraid to use
newer versions of softwares. For instance, we are already doing this
with our the default browser we are shipping and this list
https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases,
we would not be the first one to handle that. You can argue that for
application handling server infrastructure, like juju, docker.io this is
even more crucial. So why docker.io would go to this exception and not
adsys, for instance?
Could these cases, for example, be served better by a snap, the
backports pocket or a PPA instead?
The issue with backports pockets/PPA is that there is no official stamp
of ubuntu support on this, and this was already dismissed by customers.
The snap approach is something we are considering, but you need to
understand what’s the scope of adsys is: it’s touching a lot of system
wide components, creating configuration files, running apparmor/dconf
commands, and scripts on the end user machine. This part makes the
existing snap confinement very challenging, and it’s probably something
that we can revisit for next cycle. Unfortunately, that won’t solve the
immediate problem.
So, in summary: I have two questions - does this exceed SRU authority, and
need Tech Board approval, and what level of justification is there for
wide ranging vendored code updates in the SRU?.
IMHO, it does exceed SRU team authority. For example, in the case of new
upstream *micro*releases, our SRU policy, that was written by the TB
(prior to my time on the TB), says:
In other cases where such upstream automatic testing is not
available, exceptions must still be approved by at least one member of
the Ubuntu Technical Board.
If the TB is being that specific about *micro*-releases, then surely
the TB intends for more major changes to also require TB approval.
But this is the right place to be talking about it. Let's reach
consensus on how to handle this case, document a proposal, and then the
TB should be able to straightfowardly greenlight it. But I also would
like us to be open to the idea that we might decide that upstream major
bumps aren't appropriate for the updates pocket in this case, and find a
different solution.
In your quote, you mention "where such upstream automatic testing is not
available", so I don’t see how much relevant this is for adsys? I think
I made quite clear that our testing story is more than robust.
I think one way forward is for adsys to file up the Special documented cases
with all the information above and enter the list where we trust and ensure
that upstream is accountable for the SRU?
https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases
Indeed - *if* this is approved as a special case, then that's where we
should document it :)
In
https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases,
it’s written "Submit it to the SRU team for approval. This can be done
to any individual member of the SRU team directly, or you can send it to
ubuntu-release@lists.ubuntu.com for review.", so it seems this is more
SRU-team domain?
Cheers,
Didier
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
