Not requiring SRU changes to be in $current-stable to go in the LTS

Sat Mar 9 20:26:25 UTC 2019

Hi all,

I broadly agree with Robie.  To add a little further color, I'd say that the
one hard rule is that we need to make sure the bug is (on track to be) fixed
in the devel series before we land an SRU.  We should *default* to SRUing
into later non-LTS releases whenever we SRU into the LTS release, but it's
counterproductive to make this a hard rule because the SRUer can always just
wait it out until the interim release in question has EOLed, submit the same
SRU, and have it demonstrably fixed in all later supported releases without
doing any more work - but having deprived their LTS users of the fix for
some months, which benefits no one.

So I will always ask an uploader to also SRU the fixes to the interim
releases if I see that they haven't been, because as Robie says, we also
have made a committment to support these releases.  But I also am unlikely
to reject the LTS-only SRU if the uploader is unwilling to do the SRU to
non-LTS on the basis of their cost-benefit analysis.

On Sat, Mar 09, 2019 at 10:03:41AM +0000, Robie Basak wrote:
> Hi Sebastian,
> 
> Thank you for bringing this up. I always prefer to have decisions like
> this made explicitly and then documented so that everyone is clear and
> that SRUs don't get held up due to confusion about expectations. It'd be
> useful to get this case clarified.
> 
> What follows is just my personal opinion of course. I'm interested to
> hear what others think.
> 
> On Fri, Mar 08, 2019 at 05:47:34PM +0000, Sebastien Bacher wrote:
> > From my experience, it's common practice from the SRU team to require
> > for a bug to be fixed in $current-stable to be SRUed to the LTS (e.g
> > to need a cosmic SRU first to be able to have a SRU for bionic).
> 
> 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.
> 
> IMHO, as long as the Ubuntu project makes the intermediate releases, in
> the general case I don't think it's acceptable for an Ubuntu development
> team committed to maintaining some set of packages to push SRUs to the
> LTS but not bother with the intermediate releases. If we want to stop
> expecting that, then we should make the project-wide decision to stop
> doing the intermediate releases, rather than pretend that we are
> supporting them. I don't think such a decision would be appropriate.
> Therefore I consider maintenance of the intermediate releases to be
> mandatory for committed teams.
> 
> 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 realise that vastly more Ubuntu users use the LTS than the
> intermediate releases. However I believe that the success of the LTS
> feeds from the intermediate releases and that abolishing them (or
> effectively abandoning them by not supporting them) will harm the
> success of the LTS releases too.
> 
> 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.
> 
> I'm also concerned not to turn away volunteer contributors from making
> Ubuntu incrementally better; a fix in the LTS but not intermediate
> releases is better than no fix at all. It might be better to
> pragmatically not hold a hard line in this case. I don't think this
> applies to your team, though, since your team has already made a
> commitment to maintain desktop packages in Ubuntu.
> 
> To address your original points directly:
> 
> > I would like to ask if we could revisit that requirement, which I
> > believe is resource expensive and bring us little benefit.
> 
> In the general case, the benefit is to support the intermediate releases
> that we have already committed to supporting, and if we don't want to do
> that, then the argument should be that it is the intermediate releases
> that bring us little benefit and should be abolished (this would be a
> separate discussion).
> 
> > Some arguments
> > - our team members are usually either using the current devel version
> > or the current LTS, which means in practice the current-stable SRUs
> > get tested in a VM or not tested at all before upload
> 
> I think it's reasonable to require that a team committed to maintain
> some package in Ubuntu does test SRUs to that package to all supported
> releases during SRU verification, in the case that affected users
> haven't stepped up to do so. I accept this is harder for desktop, but it
> seems like an essential part of "support" that we have already committed
> to as a project.
> 
> > - we often get no feedback at all on the nonLTS version of the SRU, those
> > tend to sit longer in proposed by lack of verification
> 
> In these cases the maintaining team can step in and perform the
> verification. This is what the server team does currently, for example.
> 
> > - the previous items leads us to often validate the LTS update before the
> > non LTS one so we can't really argue that the nonLTS upload helps to get
> > more testing and reduce risks on the LTS one
> 
> I think we're generally in agreement here. I'm not sure I agree exactly
> with your line of argument, but I don't think there's enough to try and
> claim that intermediate release SRUs significantly help quality in LTS
> release SRUs in the general case.
> 
> > - the non LTS/newer series are often less polished so we can't really
> > argue that users upgrading from e.g bionic to cosmic shouldn't be
> > exposed to problems that were resolved while they were on the LTS
> 
> I don't think that's a reason to make intermediate releases worse. One
> main reason I see that the LTS versions are more "polished" is that more
> users use them for longer, so more bugs get found and fixed over time.
> Why shouldn't we also fix these found bugs in the other releases that we
> support?
> 
> > - it makes sense to put the extra polish effort for a LTS serie
> 
> Sure. But it doesn't make sense to skip maintenance of intermediate
> releases. If we're going to do that, it would make more sense to stop
> pretending the we support them and stop making the intermediate releases
> altogether.
> 
> > - we should trust the maintainer's judgement, often it makes sense to fix
> > important issues in current-stable, especially after release, but as we get
> > closer from the next stable those SRU makes less sense
> 
> 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.
> 
> Robie

-- 
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/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20190309/e9114f80/attachment.sig>