adsys SRU

[Robie Basak]

On Wed, Jun 21, 2023 at 11:43:12AM +0200, Jean-Baptiste Lallement wrote:
> This special case is now documented on https://wiki.ubuntu.com/AdsysUpdates
> . Can you please review this exception?

Thank you for putting this together!

From that text:
> The scope of this exception excludes major changes to existing
> features.

Current SRU policy distinguishes "They must not change the behaviour on
existing installations". Is this what you mean, or are you asking for
further flexbility than that, *allowing* (non-major[1]) behaviour
changes in existing releases instead?

> Since Adsys interacts directly with Active Directory, the package must
> stay up-to-date with the latest changes and improvements in Active
> Directory features, bug fixes, security patches and business
> requirements.

Current SRU policy allows for changes in order to maintain compatibility
due to protocol-related changes on the other side. So changes made for this
purpose alone doesn't need any further justification.

However, the text here is much wider than that. I think we should
explicitly document the justification for making changes that aren't
strictly required for protocol compatiblity.

For example, I could claim that glibc must receive major changes to stay
up-to-date with the latest changes and improvements in POSIX features,
bug fixes, security patches and business requirements. Of course we
aren't going to do that, but the quoted text above doesn't distinguish
why the adsys case is different, and therefore from my perpsective is
insufficient documented justification.

To be clear, as one member of the SRU team and TB, I've not clear on the
justifications yet, so I am undecided as to what is required here. I'd
like to get the justification clear first, and then we can move forward.

Some further questions to keep the ball rolling, but on the assumption
that you'll get approval on the basis of expanded justification:

On SRU process: during unapproved queue review, are you suggesting that
the SRU team take all upstream changes without further review? And for
SRU verification, are you saying that apart from autopkgtests (as we do
that anyway for all SRUs), the only other verification that will be
performed will be an upgrade test? You won't be smoke testing the
package at all?

For example, "New and existing features will be tested in a real Active
Directory environment" is something that I think you're describing will
take place upstream only, and not as part of the SRU process with the
proposed package builds. Am I correct? If so, how can we ensure that
differences between those environments won't cause an issue?

The current adsys upload is for Jammy only. What are your plans for
Lunar? In general the planned relationship between LTS and interim
releases should probably be documented on the same page, so we don't get
stuck on that question[2] (as well as possible feature regressions)
during SRU review.

Thanks,

Robie


[1] I think "major" really needs defining too if that term stays,
please.
[2] https://wiki.ubuntu.com/StableReleaseUpdates#Newer_Releases
-------------- 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/20230621/b40161be/attachment.sig>