RFC - Downgrade BlueZ to v4.101 in Fedora 20

David Sommerseth 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.
> 
> https://fedoraproject.org/wiki/Changes/Bluez5

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."
> 
> And…
> 
> "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
to happen.

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
predictability.


--
kind regards,

David Sommerseth



More information about the devel mailing list