On Fri, Nov 13, 2020 at 09:37:34AM -0000, Sebastien Bacher wrote:
>@Matthieu, @Dave, thanks for the comments and details.
>
>I'm not blocking work to land, the 20.10 SRU could be accepted now and I didn't revert in that serie.
>The SRU team tries to ensure the fix is in the new serie so it doesn't get forgotten/regress when next version is out but I think it's pretty clear we are going to sort out the review details, that's not a blocker and SRU team has been happy in the past to let things in with the understand than $newserie is being sorted out
Ah, my apologies - I had mis-interpreted the reversion as applying to
the SRU. I've no issue with a reversion in hirsute, provided it doesn't
delay existing users from using their Bluetooth hardware.
>> If upstream say "yes" to the patches, without further discussion: that's
>> great, but there'd presumably still be some delay before another version
>> makes its way down to us, so we'd be applying *some* patch to make it work in the interim.
>
>Again I'm not asking for the patches to be reviewed or accepted upstream
>before they are uploaded to Ubuntu, I'm just asking for them to be sent
>upstream and the reference to the email/report/merge request to be added
>to the patches. It would probably have been less work to just do it
>rather than type a long explanation here on why we need to distro patch
>in any case (which I never disagreed with)
I estimate, as I think several others do judging by various comments,
that the patches in their current state don't stand much chance of
passing muster upstream, and I have no desire to waste their time with a
premature submission. At the very least, some justification needs adding
to the 1 second sleep: either a datasheet reference, which I've so far
failed to find, or some empirical measurements that it's actually
required (which I'm in the process of gathering; I've verified *a* delay
is required but not the minimum, or whether it can be combined with the
post-load nanosleep), along with evidence it doesn't break any existing
platforms (I've found a datasheet reference to back that bit up, but
tests are good too).
Anyway, sorry I mis-interpreted the release your action applied to; I
look forward to seeing the SRU land.
In the meantime, rest assured a submission will be made upstream as soon
as I think I've got a faint hope of it passing!
On Fri, Nov 13, 2020 at 09:37:34AM -0000, Sebastien Bacher wrote:
>@Matthieu, @Dave, thanks for the comments and details.
>
>I'm not blocking work to land, the 20.10 SRU could be accepted now and I didn't revert in that serie.
>The SRU team tries to ensure the fix is in the new serie so it doesn't get forgotten/regress when next version is out but I think it's pretty clear we are going to sort out the review details, that's not a blocker and SRU team has been happy in the past to let things in with the understand than $newserie is being sorted out
Ah, my apologies - I had mis-interpreted the reversion as applying to
the SRU. I've no issue with a reversion in hirsute, provided it doesn't
delay existing users from using their Bluetooth hardware.
>> If upstream say "yes" to the patches, without further discussion: that's
>> great, but there'd presumably still be some delay before another version
>> makes its way down to us, so we'd be applying *some* patch to make it work in the interim.
>
>Again I'm not asking for the patches to be reviewed or accepted upstream
>before they are uploaded to Ubuntu, I'm just asking for them to be sent
>upstream and the reference to the email/report/merge request to be added
>to the patches. It would probably have been less work to just do it
>rather than type a long explanation here on why we need to distro patch
>in any case (which I never disagreed with)
I estimate, as I think several others do judging by various comments,
that the patches in their current state don't stand much chance of
passing muster upstream, and I have no desire to waste their time with a
premature submission. At the very least, some justification needs adding
to the 1 second sleep: either a datasheet reference, which I've so far
failed to find, or some empirical measurements that it's actually
required (which I'm in the process of gathering; I've verified *a* delay
is required but not the minimum, or whether it can be combined with the
post-load nanosleep), along with evidence it doesn't break any existing
platforms (I've found a datasheet reference to back that bit up, but
tests are good too).
Anyway, sorry I mis-interpreted the release your action applied to; I
look forward to seeing the SRU land.
In the meantime, rest assured a submission will be made upstream as soon
as I think I've got a faint hope of it passing!