Hi Simon, Thank you for working to make users' experience of LXD better for Ubuntu users!
On Thu, Oct 24, 2024 at 01:07:29AM +0000, Simon Déziel wrote: > I would like to request an SRU exception [1] for the lxd-agent-loader > and lxd-installer packages in all supported Ubuntu releases. I have > created a wiki page [2] that outlines everything I believe is relevant > to this SRU exception. I agree that some changes to the lxd experience probably should fit under our "For Long Term Support releases we sometimes want to introduce new features" justification for SRUs to stable Ubuntu releases[1]. Note though that this isn't an "exception" as such since existing SRU policy permits this. We do need to ensure the condition "They must not change the behaviour on existing installations". I would further extend this to ensure that we do not change behaviour of *redeployments* since this is also a common use case for server users (eg. CI that uses LXD). I note that both lxd-agent-loader and lxd-installer are pretty minimal "3.0 (native)" packages. Changes should be easy to review. The easiest way to ensure the above constraints would be a full review of the changes being applied during both sponsorship and upload, and SRU review for the same thing. To that end, I'm not sure any kind of routine process that skips a full code review makes sense. Can we instead review requested changes in SRUs on a case-by-case basis? This wouldn't preclude you from maintaining (essentially) the same source tree of these packages across all supported Ubuntu releases. You'd need to ensure no changes to behaviour for existing Ubuntu users whichever way you do it. I'm just saying that case-by-case review is probably the easiest and smoothest way of achieving that. Normally other packages bound to a regular SRU cadence but without changing existing user behaviour (eg. cloud-init) have to be very careful to maintain this in every upstream change they make. This does compromise engineering velocity when developing new features and new behaviours. Either way, you'd need to be making the same commitment. I would question though if this is really necessary given that engineering burden. For example, I see a change[2] in lxd-installer that changes some default behaviour to failure instead of falling back to the default snap channel for lxd. It may be the case that in practice this won't result in behaviour change to users, but that's the kind of thing that we need to be careful about, and therefore needs reviewing carefully. Ideally the code change would be written in a way that makes it easier to validate that there really will be no change to user behaviour. To proceed, I suggest that you start by reviewing to consider if all the changes to both lxd-installer and lxd-agent-loader would be acceptable to SRU for each Ubuntu release in terms of (the lack of) changes to behaviour. This might involve making some code changes to make it easier to demonstrate that this is the case. If after careful review you think that this is the case and demonstrable by code review, then the SRU team could also review to confirm that, and then we'd be able to update both packages in all stable releases as a one-off exercise. Next time, we'll have a baseline to review against then. If this becomes annoyingly repetitive then we could consider some kind of standing agreement to skip some parts of the review at that point. None of this precludes us having some documentation that explains this plan, of course. Does this work for you? Robie [1] https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#other-safe-cases [2] https://git.launchpad.net/ubuntu/+source/lxd-installer/diff/lxd-installer-service?id=b9a2b3c3461eaf73976c069432782329465f579d
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
