Comment 15 for bug 1732703

On Wed, Dec 13, 2017 at 10:34:25PM -0000, Andres Rodriguez wrote:
> FWIW, this is currently affecting customers who are running MAAS and
> require livepatch.

It's been affecting users since January, no? Why the sudden urgency?
What difference will a week or two make?

> Comments #11 and #12 above confirm that the patch is enough for the MAAS
> needs. Whichever way MAAS decides to check for systemd is up to MAAS and
> that is not a reason to block an SRU provided that it does not impact
> any other piece of software. That said, this patch does not does not
> introduce a regression to MAAS nor any other software.

I think that's quite a brave claim to make. I'm sure "does not
introduce a regression" was a claim that might have been made in the
systemd SRU that regressed this too, and yet here we are.

> Lastly, this patch is *only* for 1.9 as this code path is only available
> in Trusty, so upgrades to later Ubuntu releases will yield on using a
> newer version of MAAS that doesn't rely on this code path.

If we did decide to SRU an emergency fix as a stopgap for MAAS' use
case, and it's for Trusty only, then why have a test at all? Can we just
return 'upstart' without a test?

To be clear, I'm not demanding or even requesting anything specific
right now. I don't feel that a case for urgency has yet been made, given
the currently known regression timeline. In the meantime I think it's
worth understanding how we want to fix this properly, because requiring
multiple SRUs while we swing back and forth is bad for everyone, and
equally I don't want to see us locked into a suboptimal solution.

If a case is accepted on the basis of urgency, or another SRU team
member disagrees with my assessment, I wouldn't want to block that. Feel
free to land what you think is appropriate.