| amurray | Rhonda: you would need to follow the https://wiki.ubuntu.com/StableReleaseUpdates process - in which case the general approach would be to find the minimal change needed to fix the bug and include that in the existing version of fastapi in 22.04 rather than backporting a newer version | 02:23 |
|---|---|---|
| Rhonda | Well, extracting the minimal change would be quite a lot of hassle for no real gain there I fear, frankly speaking, for the reason that the sync wasn't done properly in the first place unfortunately. :/ | 10:59 |
| Rhonda | So if it would blocked I rather would go with a backport instead and suggest people to use that instead | 10:59 |
| amurray | Rhonda: my comment above was general advice - I am not on the SRU team, but my understanding is that in general they do not usually approve wholesale new version upgrades - except for in rare circumstances | 11:30 |
| amurray | in this case, since the package seems pretty fundamentally broken, there is no real risk of regression from say introducing a whole new version so perhaps it would be allowed in this case | 11:30 |
| rbasak | Rhonda: it might be acceptable if it can be demonstrated that the package is completely broken and there can be no user happily using it in its current state, taking into account all possible use cases. Otherwise those users risk being regressed. If that's the case it needs to be stated and there's a review burden too - the SRU team need to be able to verify that this is indeed the case. | 12:24 |
| rbasak | Rhonda: you also need to not go beyond the next release so upgrading users don't go "downwards" in version. | 12:26 |
| Rhonda | rbasak: Oh, trust me, I do know how upgrade paths work. :) I'm on the backports team in Debian and regularly had to lecture people on that. | 12:31 |
| rbasak | Rhonda: ah OK. So yeah, basically the SRU team will probably accept it if it's completely broken but please make it very clear in the bug how that is the case so it can be easily reviewed. | 12:33 |
| rbasak | Rhonda: any doubt or ambiguity really holds these things up. IMHO developers tend to overestimate the cost of finding the minimal fixes. | 12:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!