Re: adsys SRU
Hey Chris, let me chime in. Le 14/06/2023 à 08:26, Christopher James Halse Rogers a écrit : There's an Jammy/Lunar adsys SRU¹ in the queue at the moment, and I think it needs bringing to up to the list for discussion. The changelog looks like approximately 9 months of normal feature development. The diff against Jammy is >3MB in size (due largely to significant vendored-dependency churn it seems). The relevant part of SRU policy - “Other safe cases”² - allowing feature addition, says “If existing software needs to be modified to make use of the new feature, it must be demonstrated that these changes are unintrusive, have a minimal regression potential, and have been tested properly”. It looks like adsys is well tested, but I'm not sure about these being minimal changes or with minimal regression potential ☺. It's true that we've done a wholesale backport of adsys 0.9.2³ to Jammy in the past; however, in that case the changes were mostly listed bugfixes or FTBFS fixes, and the feature addition was shipping a *Windows* binary. I'm writing this to ubuntu-release@ for two main reasons: 1. It seems valuable to include adsys updates in LTS releases; however, I'm not sure that the scope of changes (and seeming criticality of the system - “failures might prevent users from logging in” seems pretty bad) falls under the existing delegation of power from the Tech Board to the SRU team. 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) Due to our very limited team capacity, already max-ed out and being split between many projects on different themes, our only way to have a good adsys support, while answering the two previous requirements is to support only one single code base version, meaning, shipping the same code base in all supported releases. As most of the dependencies are vendored (apart from some limited dynamic C linking or dep on samba/sssd for instance), we are in control of what we ship and know exactly what’s our quality base is on it (more details on that in the next paragraphs). 2. There's a *lot* of vendored code churn, and from the SRU perspective I have no information as to whether that's appropriate. I understand that the Go ecosystem does not follow our ideas of stable releases and there's a real tension here - it's a huge amount of work to vet dependency updates, and such updates are *likely* to include bug fixes. I don't think “we just update all our vendored dependencies each SRU to whatever upstream is most recently shipping” is an appropriate standard, though. I'm not sure what *is* the right balance, though. Right, but also, you need to take into consideration the following: - as we are vendoring dependencies, accepted as part of the MIR process, it means that we, as upstream, takes the responsibility in front of the security team to handle security fixes inside those dependencies. Most of the security fixes in the various dependencies comes only with new upstream "release" (even if in the Go ecosystem, this is mostly a tag). FYI, the Rust ecosystem is following the same pattern and the vendoring exception is allowed for it too. - as we took that responsability of vendoring, and updating them, it means that we need to do that work as part of the SRU process too. - however, due to the very, very, limited team capacity mentioned above, we need to pick our battle and supporting a "single code base" (including vendored dependencies) is the only way we can go. So, with that amount of diff, how do we ensure we can ship something we trust and that we are not impacted by any kind of regressions? 1. This can only be done by automated tests. As of today, I count 1557 automated tests on the adsys repository alone. Those are unit/package/integration tests, using golden files to project exactly the desired expected for each tests on the file system: https://github.com/ubuntu/adsys/tree/main/cmd/adsysd/integration_tests/testdata/TestPolicyUpdate/golden/current_user%2C_first_time. All those are run against the exact same versions of vendored dependencies and Go version that is going to be built against in the distro on our CI, even when we automatically update one of the vendored dependency: https://github.com/ubuntu/adsys/actions/runs/5257398861 We run those tests with **and** without built-in Go race detector. Also, we are testing untrusted inputs (like the Windows Active Directory GPO utf16 little-endian input) with fuzz testing, and we already fixed some crashes with it, like https://github.com/ubuntu/adsys/pull/333. 2. All th
Re: adsys SRU
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
Re: adsys SRU
On Wed, Jun 14, 2023 at 10:00:44PM +0100, Robie Basak wrote: > 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? Let me propose another way to limit issues: Backport the adsys in the latest stable release to LTS series, and keep that as a release series, while developing new stuff in stable. Basically that's what I'm trying to do with grub too (except we currently binary copy the grub binaries rather than do rebuilds per series, but different story). You can also split this up further and have an adsys that just receives security updates, and an "hwe" like rolling adsys, think like kernels. I think the backports pocket could work, but it may be easier to use an adsys-rolling package or something so users don't have to enable "scary" repositories. Also backports and PPAs don't really have the same guarantees as -updates, when that is something that customers want. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en 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
Re: adsys SRU
On Thu, Jun 15, 2023 at 09:00:09AM +0200, Didier Roche wrote: > >>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'm not suggesting that adsys doesn't meet the TB's QA criteria for (micro)release updates. I haven't looked into that. But that statement is relevant on the question of what the TB has delegated to the SRU team to decide. The policy refers back the TB if the criteria are not met. In adsys' case, if relevant criteria set by the TB aren't met then similarly I think the intent is for the TB to consider it, not the SRU team. > >>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@lists.ubuntu.com for review.", so it seems this is more > SRU-team domain? IIRC I wrote this text myself, wearing my SRU team hat. When the TB delegated microrelease update reviews to the SRU team, they were considered to no longer be exceptions. The SRU team would handle them on a case-by-case basis, and so the previous list of TB-granted exceptions was removed. This caused confusion within the SRU team and frustration to uploaders because we were not able to be consistent within ourselves. We wanted documentation so that we could make decisions on requirements for a package as a whole, set our own expectations of the process and QA that would be appropriate on a package-by-package basis, and this way uploaders could also have more confidence and consistency in that what was documented already approved would not be questioned or bikeshedded. Otherwise we'd end up with one upload being approved and the next one asking for some additional test steps or something like that, causing frustration all round. This led to some confusion as to how uploaders should ask for such a thing, because it used to be a question for the TB, but then the TB said it was no longer required, but then the SRU team wanted it anyway. So to clear that up, I wrote that text. I intended it to apply only to what is within the scope of the SRU team to agree though, and for the SRU team to refer to the TB if it is asked for something that it doesn't have the authority to approve. I thought it'd be more straightforward to leave the scope of the statement out of it, since those details are generally not understood by uploaders anyway. In summary, my view is: * The SRU team cannot deliberately choose to introduce functional behavioural changes in the updates pocket. Of course pratically there are close calls when fixing bugs which the SRU team traditionally decides for itself. As an example, not too long ago I asked the TB to consider a Thunderbird major version bump that would presumably have included behavioural changes in the UI and (IIRC) broke some extensions, which they/we approved. So when it's a grey area the SRU team makes a call. When it's clearly out of scope, it's not the SRU team's decision. * The SRU team can accept an upstream microrelease release subject to their own review and opinion but only if meets the QA requirements set by the TB (since that's exactly what the TB wrote). We can do this as a one-off or on a recurring basis. The SRU team strongly prefers to document recurring instances of these for consistency of review decisions. * The SRU team can accept new features in LTS releases subject to their own review, but only if it does not change behaviour for existing features as well as other specific requirements (since that's exactly what the TB wrote). I didn't realise you were claiming that the adsys Jammy upload didn't change behaviour for existing features. If that's the case, then the SRU team cou
Re: adsys SRU
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@lists.ubuntu.com for review.", so it seems this is more SRU-team domain? Cheers, Didier -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mail
Re: adsys SRU
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 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
Re: adsys SRU
On Wed, Jun 14, 2023 at 11:01 PM Robie Basak wrote: > On Wed, Jun 14, 2023 at 09:31:42AM +0200, Didier Roche wrote: > > > > 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 :) > > This special case is now documented on https://wiki.ubuntu.com/AdsysUpdates . Can you please review this exception? Thanks. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: adsys SRU
On Wed, Jun 21, 2023 at 2:48 PM Robie Basak 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 > -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: adsys SRU
On Thu, Jun 22, 2023 at 02:59:39PM +0200, Jean-Baptiste Lallement wrote: > Can you please be concise and provide a list of bullet points that must be > addressed to move forward? Question 1. Do you want: a) an exception that allows you to change behaviour on existing installations when users upgrade to new versions of adsys that provide new features within an LTS release? or b) an exception in which you commit to never making changes that change behaviour on existing installations when users upgrade to new versions of adsys that provide new features within an LTS release? If you answer (a), then this will require an exception to be granted by the Technical Board, since that would contradict their existing documented policy. > The target audience of ADSys is users of LTS releases, so we want to > skip short-lived releases. This directly contradicts the Technical Board's existing documented policy. If you insist then you will require an exception to be granted by the Technical Board. This will take time, and in the end I think such an exception is unlikely to be granted. Users upgrading from an LTS to a newer interim release is currently a supported path, and users using adsys who upgrade would be regressed if you skip the interim releases. Question 2: Do you wish to insist on skipping interim releases regardless? 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
Re: adsys SRU
On Fri, Jun 23, 2023 at 4:43 PM Robie Basak wrote: > On Thu, Jun 22, 2023 at 02:59:39PM +0200, Jean-Baptiste Lallement wrote: > > Can you please be concise and provide a list of bullet points that must > be > > addressed to move forward? > > Question 1. Do you want: > > a) an exception that allows you to change behaviour on existing > installations when users upgrade to new versions of adsys that provide > new features within an LTS release? > > or b) an exception in which you commit to never making changes > that change behaviour on existing installations when users upgrade to > new versions of adsys that provide new features within an LTS release? > > If you answer (a), then this will require an exception to be granted by > the Technical Board, since that would contradict their existing > documented policy. > This is b) we will only provide new features, not change existing ones. > > > The target audience of ADSys is users of LTS releases, so we want to > > skip short-lived releases. > > This directly contradicts the Technical Board's existing documented > policy. If you insist then you will require an exception to be granted > by the Technical Board. This will take time, and in the end I think such > an exception is unlikely to be granted. Users upgrading from an LTS to a > newer interim release is currently a supported path, and users using > adsys who upgrade would be regressed if you skip the interim releases. > > Question 2: Do you wish to insist on skipping interim releases > regardless? > We are okay with porting to interim releases even if it is not where this software is consumed. Cheers, JB -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: adsys SRU
Hi, I know discussions are still ongoing about the adsys 0.12.0 SRU, but I have a user who wishes to have LP #2020834 [1] fixed, which high priority. [1] https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020834 Would it be possible to potentially reject 0.12.0 from jammy -unapproved, we get LP #2020834 sponsored and uploaded, verified and released, before we start discussing 0.12.0 again for Jammy and Lunar? I was planning on just letting 0.12.0 happen since the fix is present in 0.10.0, but my user has time restrictions and would like to be able to use dashes '-' in their domain names. Thanks, Matthew -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: adsys SRU
Hi JB, I too would like to go forward with the entire backport too, but time is running short. This user has a SLA deadline of 2023-07-09. I submitted patches to the LP bug one month ago on 2023-05-26 and was subsequently blocked by the 0.12.0 upload in -unapproved on 2023-06-06. The impact for the user isn't too bad, they would like to consume the fixed adsys so they can run their testsuites internally, and they see the bug as a blocker to onboard other new users to the platform as it breaks a widely deployed use case of '-' in domain names. So low priority, apart from SLA deadlines. Thanks, Matthew On Mon, 3 Jul 2023 at 19:29, Jean-Baptiste Lallement wrote: > > Hey Matthew, > > We are still waiting for a go/no-go from the SRU team, but the discussion > seems to have stalled. I'd rather move forward with the entire backport since > it fixes much more than just this bug. > What is the priority for this customer, any deadline? > > Thanks. > > JB > > On Mon, Jul 3, 2023 at 9:03 AM Matthew Ruffell > wrote: >> >> Hi, >> >> I know discussions are still ongoing about the adsys 0.12.0 SRU, but I >> have a user who wishes to have LP #2020834 [1] fixed, which high >> priority. >> >> [1] https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020834 >> >> Would it be possible to potentially reject 0.12.0 from jammy >> -unapproved, we get LP #2020834 sponsored and uploaded, verified and >> released, before we start discussing 0.12.0 again for Jammy and Lunar? >> >> I was planning on just letting 0.12.0 happen since the fix is present >> in 0.10.0, but my user has time restrictions and would like to be able >> to use dashes '-' in their domain names. >> >> Thanks, >> Matthew -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: adsys SRU
On Mon, Jul 03, 2023 at 10:34:22PM +1200, Matthew Ruffell wrote: > Hi JB, > I too would like to go forward with the entire backport too, but time > is running short. This user has a SLA deadline of 2023-07-09. I > submitted patches to the LP bug one month ago on 2023-05-26 and was > subsequently blocked by the 0.12.0 upload in -unapproved on > 2023-06-06. The impact for the user isn't too bad, they would like to > consume the fixed adsys so they can run their testsuites internally, > and they see the bug as a blocker to onboard other new users to the > platform as it breaks a widely deployed use case of '-' in domain > names. So low priority, apart from SLA deadlines. To be clear, no version of adsys has been accepted into -proposed from the unapproved queue for this; so any blocking is on the uploader side, not on the SRU team side. > On Mon, 3 Jul 2023 at 19:29, Jean-Baptiste Lallement > wrote: > > > > Hey Matthew, > > > > We are still waiting for a go/no-go from the SRU team, but the discussion > > seems to have stalled. I'd rather move forward with the entire backport > > since it fixes much more than just this bug. > > What is the priority for this customer, any deadline? > > > > Thanks. > > > > JB > > > > On Mon, Jul 3, 2023 at 9:03 AM Matthew Ruffell > > wrote: > >> > >> Hi, > >> > >> I know discussions are still ongoing about the adsys 0.12.0 SRU, but I > >> have a user who wishes to have LP #2020834 [1] fixed, which high > >> priority. > >> > >> [1] https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020834 > >> > >> Would it be possible to potentially reject 0.12.0 from jammy > >> -unapproved, we get LP #2020834 sponsored and uploaded, verified and > >> released, before we start discussing 0.12.0 again for Jammy and Lunar? > >> > >> I was planning on just letting 0.12.0 happen since the fix is present > >> in 0.10.0, but my user has time restrictions and would like to be able > >> to use dashes '-' in their domain names. > >> > >> Thanks, > >> Matthew > > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org 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
Re: adsys SRU
The exception - https://wiki.ubuntu.com/AdsysUpdates - has been updated to limit the scope to the implementation of new GPO. New features that are not new GPO will need explicit approval from the SRU team. I hope it makes the exception acceptable. Thanks for considering this exception. Cheers, JB On Mon, Jun 26, 2023 at 12:56 PM Jean-Baptiste Lallement < jean-baptiste.lallem...@canonical.com> wrote: > > > On Fri, Jun 23, 2023 at 4:43 PM Robie Basak > wrote: > >> On Thu, Jun 22, 2023 at 02:59:39PM +0200, Jean-Baptiste Lallement wrote: >> > Can you please be concise and provide a list of bullet points that must >> be >> > addressed to move forward? >> >> Question 1. Do you want: >> >> a) an exception that allows you to change behaviour on existing >> installations when users upgrade to new versions of adsys that provide >> new features within an LTS release? >> >> or b) an exception in which you commit to never making changes >> that change behaviour on existing installations when users upgrade to >> new versions of adsys that provide new features within an LTS release? >> >> If you answer (a), then this will require an exception to be granted by >> the Technical Board, since that would contradict their existing >> documented policy. >> > > This is b) we will only provide new features, not change existing ones. > > >> >> > The target audience of ADSys is users of LTS releases, so we want to >> > skip short-lived releases. >> >> This directly contradicts the Technical Board's existing documented >> policy. If you insist then you will require an exception to be granted >> by the Technical Board. This will take time, and in the end I think such >> an exception is unlikely to be granted. Users upgrading from an LTS to a >> newer interim release is currently a supported path, and users using >> adsys who upgrade would be regressed if you skip the interim releases. >> >> Question 2: Do you wish to insist on skipping interim releases >> regardless? >> > > We are okay with porting to interim releases even if it is not where this > software is consumed. > > > Cheers, > JB > > -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
