RFC - Downgrade BlueZ to v4.101 in Fedora 20
davids at redhat.com
Fri Jan 24 11:47:46 UTC 2014
On 23/01/14 23:16, Chris Murphy wrote:
> On Jan 23, 2014, at 2:56 PM, "Brian J. Murrell" <brian at interlinx.bc.ca> wrote:
>> On Thu, 2014-01-23 at 19:53 +0100, David Sommerseth wrote:
>>> As a side note, it also needs to be discussed how such a key feature of
>>> the bluetooth stack could go unnoticed through QA, and how to avoid this
>>> from happening again.
>> Indeed. I wondered the same myself.
> As far as I know there isn't an explicit test case or release
> criteria that covers this functionality, or it would have been discovered. Why
> it's not a test case is a valid question, but simply put there are only
> so many QA people, much of it is voluntary so not everything important
> gets tested.
Fair enough. However, in this case it seems this was even noticed. Why
that was never looked into more thoroughly is a mystery for me.
By all means, software does and needs to evolve, and it can break. I
have full understanding for this. But not alerting that basic
functionality of things you would expect breaks, that's the key point
here. That puts users into a difficult situation, especially when the
dependencies are so tricky.
> Seemingly critical features that shouldn't have major regressions
> are exactly where testing should be done in advance of release. People who
> care about such functionality need to alpha and beta test, and review
> feature proposals that affect things they care about. You don't have to
> test for a week or month or the whole cycle. But had there been more
> discovery, and criticism of the loss of features at the right time, then
> it seems plausible the change would have been pushed back to F21.
I'll admit I noticed the Bluez5 threads on this list, and thought this
was fairly straight forward. Packages needed to be adopted to a new API
is kind of normal. And I took it for granted that the HSP/HFP
functionality would be tested. I cannot understand this functionality
is not considered an important feature. I mean, does people only use
bluetooth for the A2DP profile?
> "Major functionality should keep working without regressions,
> compared to BlueZ 4 in Fedora 19."
> "If the release blocking desktops have major bluetooth related
> regressions by the time of the Fedora 20 Beta Change Deadline, then
> FESCo and the proposal owners may enact a contingency plan to revert the
> BlueZ 5 related changes and go back to BlueZ 4."
> This thread is suggesting a major regression, and if that's the case
> then the contingency should have been employed. But the first red flag
> for that should have been at the latest prior to beta freeze.
During the F20 beta, I was soaked into other work to be able to test
this. But knowing we have a Fedora QA group and a plan for rolling
things back, I had a trust that the Fedora community wouldn't allow this
But trust me, I will check things far more closely in the coming
releases ... unless I simply switch to RHEL instead to have some better
More information about the devel