adsys SRU

[Jean-Baptiste Lallement]

On Wed, Jun 21, 2023 at 2:48 PM Robie Basak <robie.basak at ubuntu.com> wrote:

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

Our main request is to add new features to existing releases in LTS. The
justification is requirements from customers.
The target audience of ADSys is users of LTS releases, so we want to skip
short-lived releases.

This is all becoming very confusing. We followed the instruction on [1] and
did a wiki page like the one on that page.
Can you please be concise and provide a list of bullet points that must be
addressed to move forward?

Thanks.

JB.

[1]


> > 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20230622/c3e8430c/attachment.html>