On 01/18/2017 02:18 AM, Hans de Goede wrote:
Hi,
On 17-01-17 21:59, Laura Abbott wrote:
> On 01/17/2017 05:19 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 17-01-17 14:12, Thorsten Leemhuis wrote:
>>> Lo! Three quick question from someone who for some strange reason is
>>> interested in this topic:
>>>
>>> Hans de Goede wrote on 17.01.2017 13:11:
>>>>
>>>> As such I would like to (for starters) add this driver:
>>>>
https://github.com/hadess/rtl8723bs
>>>>
>>>> Which is fully open source and although not ready for
>>>> upstream, actively maintained by the community, to the
>>>> driver/staging directory of the Fedora kernel pkg.
>>>
>>> * wouldn't it make more sense to simply add the driver to the staging
>>> directory upstream?
>>
>> See my answer to Bastien's mail.
>>
>>> * will users somehow made aware they are using drivers of lower quality
>>> which are maintained differently (they for example might vanish suddenly
>>> if maintainers lose interest, which normally doesn't happen with proper
>>> kernel drivers)
>>
>> Other then the standard tainting caused by this being in staging, no.
>>
>>> * while at it: Is
https://fedoraproject.org/wiki/KernelStagingPolicy
>>> still considered policy or is it a page everyone forgot about?
>>
>> I for one had never heard about that page.
>>
>> Regards,
>>
>> Hans
>
>
> Yes, that page should still be accurate wrt to staging policy although
> I think the list of drivers might need to be updated.
>
> In general, I think upstreaming is the right approach to take and
> if you are willing to go through staging, I think that could be
> a good path to work to get the driver out of staging.
I've the feeling this whole discussion has been derailed a bit
by focusing too much on the rtl8723bs example.
Quoting from my original mail, upstreaming was given as
one possible solution:
Yes, and I think it's the best solution and should still be pursued
in parallel.
"d) Get the driver upstreamed. Unfortunately many of
these drivers are vendor code, which often is ported
windows code with lots of ugly glue; and the effort to
get this upstream will take more time then I have
to invest into this. Also if this were easy it would
have been done by now, there are quite a few people
interested in this."
Nothing has changed wrt this, to be specific I would like
to see the following wifi drivers be available in Fedora
kernels:
rtl8723bs
rtl8189es
rtl8189fs
esp8089
xradio
And in the future possible others (rda599x comes to mind)
and I simply do not have the bandwidth to get 1 one of
these let alone all of these into staging, let alone
fully mainlined.
Currently we're crippling our user experience by refusing
to ship drivers support this hardware even though there are
fully open drivers to support these.
And that's the problem. This happens all the time with kernel
drivers, everyone wants the end result of a driver but the
work to actually make it sustainable never gets done. Unless
a driver is actually merged in the upstream kernel, it's not
going to work in the long term. Keeping the driver out of tree
means it loses out on review and updates coming from the
kernel community which is better for the driver in the long
term.
Again quoting from my original email:
"I also believe that this rule goes against Fedora's
basic principles:
-It goes against the First principle, many other distros
are shipping with this driver
-It goes against the Features principle, disallowing
people to have working wifi is a mis-Feature
-It goes against the Freedom principle, if a contributor
is willing to spend time to maintain such a driver
he/she should have the freedom to do so"
I really have to disagree with most of this here.
First doesn't mean just being the very first for everything.
It's possible for features to be available out there somewhere
but not yet ready for distribution. Other distributions have
different requirements and their idea of ready may not be
Fedora's idea. (e.g. BTRFS as default)
From
https://fedoraproject.org/wiki/Foundations
"We also believe that these changes are best developed in
direct concert with the upstream software communities whose
work is part of the Fedora distribution."
I'd rather see Fedora be the first to make an effort to get
the driver upstream.
Finally I really don't see the issue of freedom here. Nobody
is saying you can't maintain the driver yourself in another
repo or take the Fedora tree and distribute it yourself with
extra modules added, several of the options you proposed involved
exactly that. The discussion here is if the driver belongs as part of
the maintained Fedora kernel. I do not believe it is a violation
of free software to have a discussion and say no to a feature,
even if someone is willing to maintain it.
And I still end up at my original unanswered question:
"All I'm asking from the fedora kernel team is permission
to add the driver."
Justin's response there stands but I still firmly believe that
actively working to get the driver upstreamed is in Fedora's
best interest for the long term.
Regards,
Hans
Thanks,
Laura