Hey Robie, thanks for the reply Le 09/03/2019 à 11:03, Robie Basak a écrit : > AIUI, the concern is that a user running an LTS may upgrade up to an > intermediate release, and then face regressions there for known bugs > that have known fixes that we didn't bother to fix in a supposedly > supported release. This seems inappropriate. In my view the likelihood > of needing this upgrade increases the closer we get to the next LTS as > the older LTS falls increasingly out of date.
Well, at the same time, the cycle post LTS is often when we go ahead with big transitions/features that got parked in the previous cycles while we were stabilizing the LTS. The result is that those versions are often quite different/less polished/including changes|regressions compared to the LTS. I don't believe that skipping some SRUs or not is going to change the situation (at least from a desktop perspective, maybe server is in a different position) > expecting that, then we should make the project-wide decision to stop > doing the intermediate releases, rather than pretend that we are > supporting them. Right, that's a complex topic by itself so probably best to keep that aside of the current SRU one. > I don't think this necessarily needs to be a hard rule for every SRU, > but I think it should be the norm, and I'm concerned that removing the > general expectation will leave the intermediate releases effectively > unmaintained. I think it does make sense to try to make an honest effort, and I agree that we should recommend that we do SRU fixed to $current-stable. That said I personally see value doing that for important fixes/early after the new version is out, but at this point of the cycle I start feeling like that Cosmic desktop SRU aren't bringing much values, especially for 'cosmetic' fixes. Disco is likely going to be out before or soon after we do the SRU upload/review/verification dance and if our nonLTS users did manager to stay on a version with $problem until now they can probably waiting until they start using Disco to see it resolved. > However, I can imagine exceptions to always requiring SRUs into > intermediate releases. For example if a bug is difficult to reproduce or > verify, or a complication means that the fix is different and difficult > to verify, or regression risk is higher, then, combined with there being > no users evidently available to verify an intermediate release, I don't > think it would be appropriate to block the publication of an LTS fix. Again that might be more desktop specific, but I think cosmetic/polish fixes should be in that category. Often we do include fixes for minor annoyances in the LTS because users are going to be for years on that version but we don't have the resources to polish the non LTS on the same level. > Every release is "stable", not just LTS releases. If you don't see it > that way, then please let's change the discussion to "let's get rid of > intermediate releases", because it feels to me that this is the > essential reduction of your point. Supporting more releases does take > more effort! But the project has made the commitment to do this work, > and if we want to stop, then we should make it clear to users what the > new deal really is. Well, I think it mostly comes down to available resources at this point. In theory, yes, we would like to fix every single bug reported and every serie, in practice we can't. If we don't have the manpower to keep up with LTS/current stable/new serie, our options are basically 1. reduce the quantity of work we spent on $next-version in favor of stables 2. fix less issues in $stable-series, including the LTS 3. focus on the LTS which is what matters the most and skip $current-stable for some of the fixes I don't think we are going to get sign-up to do 1., so it basically it's either 2. or 3. Letting bugs unfixed in the LTS just because people don't have the capacity to do the $current-stable work sounds wrong to me. I think the consequence of the current SRU team position is that we get less SRUs in the LTS and/or that people do delay they SRUs to workaround the problem (as Steve suggested in his email). Do we have stats on the number of SRUs which end up being unverified and deleted/never rolled out to updates by serie? It's not based on facts but my got feeling is that at this point cosmic SRUs are struggling to get verifications done because most of our active contributors switched to disco and the SRUs we are currently doing are mostly going to be wasted work. Cheers, Sebastien Bacher -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
