On 23/01/14 23:16, Chris Murphy wrote: > On Jan 23, 2014, at 2:56 PM, "Brian J. Murrell" <brian@xxxxxxxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
