adsys SRU

[Robie Basak]

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?

Could these cases, for example, be served better by a snap, the
backports pocket or a PPA instead?

> >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.

> 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 :)

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20230614/8a37efe7/attachment.sig>