----- 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. Cheers -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
