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
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release