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 could decide themselves under that third bullet point. The TB-written requirement is in full: > For Long Term Support releases we sometimes want to introduce new > features. They must not change the behaviour on existing installations > (e. g. entirely new packages are usually fine). 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. To avoid > regressions on upgrade, any such feature must then also be added to any > newer supported Ubuntu release. Once a new feature/package has been > introduced, subsequent changes to it are subject to the usual > requirements of SRUs to avoid regressions. Note that the current upload doesn't meet this criteria - the upload is in Jammy only, and missing for Lunar, resulting in the version number going backwards. If you can't meet the criteria in full to the satisfaction of the SRU team, then I think it needs to be a TB decision since they clearly didn't delegate that sort of choice to the SRU team. The "unintrusive" requirement might be in contention here! All of this nuance could be changed by agreement between the TB and the SRU team. Perhaps the TB would like to delegate more decisions to the SRU team. Perhaps the TB would like to clarify what types of decisions it reserves for itself. But none of this should matter to uploaders. I suggest just leaving this to the SRU team and TB to figure this out between themselves. It shouldn't matter who we need to ask. We're all here and we all want Ubuntu to be successful. Let's just figure out what we want as a project, make sure all options and relevant pros and cons are raised and discussed, and then leave it between the SRU and TB to decide. 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
