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. 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 "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. Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
