On Mon, 2014-04-07 at 08:29 -0400, Bastien Nocera wrote:
----- Original Message -----
Hi,
After listening to the Fedora.Next discussion @ FOSDEM2014 I have been looking forward to a more stable Fedora workstation that we can actually use reliably.
I've read up about it and it would be nice to have working development tools but one of the things I haven't heard people talking about is how Fedora.next will enable people to actually use it for work.
Currently I have been bit by removal of the bluetooth HSP/HFP Profile (https://bugzilla.redhat.com/show_bug.cgi?id=1045548). I just purchased all new plantronics headsets for our developers that used to work perfectly in Fedora 18 and now I can just throw them away.
Answers like these make me wonder if running Fedora will be sustainable, we have to work on these systems and if I have to dual boot Windows to make a skype call; it would be better to run ubuntu.
From: Adam Williamson <awilliam <at> redhat.com> Subject: Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20 Newsgroups: gmane.linux.redhat.fedora.devel Date: 2014-01-23 23:16:09 GMT (10 weeks, 3 days, 10 hours and 37 minutes ago) On Thu, 2014-01-23 at 16:56 -0500, Brian J. Murrell 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. I'm somewhat cheered that our product has apparently reached the quality level where people consider a Bluetooth audio profile to be a 'key feature', but so far as our QA standards are concerned, it ain't. This didn't really 'pass unnoticed' through QA. I noticed it, and was supremely unconcerned. Yes, if you depend on this specific feature it sucks, but it's hardly unusual for some specific feature of something or other to break between Fedora releases. It's a thing that happens, and as I'm on record as arguing in more extensive and generic terms, the nature of Fedora as a project would need to change quite a lot before we decided we were a project where stuff like this didn't sometimes break. -- Adam Williamson Fedora QA Community Monkey
I don't want to be bashing anyone and we would like to help out with Fedora workstation testing things through. But is there any point in investing a lot of time when the QA people don't care about an OS that you can actually use.
Except that this problem has nothing to do with testing. We're still missing DUN support in NetworkManager and HSP/HFP support in PulseAudio following the removal of those profiles directly in BlueZ 5.x by the upstream developers.
I'm pretty much the only person doing work on BlueZ, and even so I'm only updating packages to the latest upstream versions to pick up bug fixes.
If we didn't go with BlueZ 5, we'd have been stuck for nearly a year with a completely unmaintained BlueZ 4.x stack. By the time Fedora 20 would have been EOL, we'd have been shipping a Bluetooth stack that would have been unmaintained for 3 years.
Put pressure on those projects (NM and PA) to implement and ship BlueZ 5.x support. Pointing fingers at QE or at Fedora will not help get those problems solved, either now or in the future.
Right. I could have worded my post more clearly, I suppose, but it was intended for the audience that was reading at the time, and there's an implicit assumption behind it: this is really not a Fedora-level issue, it's an upstream ecosystem one. Both the choices Fedora had were bad ones: stick with a rapidly decaying and ancient Bluetooth stack, or update it and lose some useful features. Those were literally Fedora's only choices. Either would have made someone unhappy.
I'm hopeful we can get the necessary buy-in from various folks to have slightly higher basic functionality requirements for Fedora Workstation than we did for the desktop under the ancien regime, but "working high bitrate Bluetooth audio" is probably beyond the level of 'things we're likely to block the release on' still. I recognize that it's somewhat annoying if you've just bet the farm on it, but we have practical considerations to bear in mind too - we don't have infinite development resources we can throw around to fix upstream problems.