adsys SRU

[Didier Roche]

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 at lists.ubuntu.com for review.", so it seems this is more 
SRU-team domain?

Cheers,
Didier