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

[Robie Basak]

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