<div dir="ltr">Hi<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 9:52 AM, Christian Schaller <span dir="ltr"><<a href="mailto:cschalle@redhat.com" target="_blank">cschalle@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
The software will come with a warning in the installer that this is not software provided by the Fedora project and that users need to contact<br>
the relevant upstream for support. We will also make it clear that this is not free software and users will be presented with a need to 'opt-in'<br>
to use said non-free software for that reason.<br></blockquote><div><br></div><div>[I am not sure I agree with the overall goal but setting that aside for the moment]<br><br></div><div>Others have covered the idealogically side of the argument very well so let me focus on a more practical problem:<br>
</div><div><br></div><div>It is good that you are willing to clearly differentiate free/non-free software on user searches and make a statement about support but if we are enabling easy access, I think, the user experience isn't going to be much better if the user updates the kernel (as Fedora updates to the upstream kernel often) and breaks the Nvidia driver (which seems plausible atleast, if not pretty likely) and we say hey, we told you that stuff is unsupported. The user will be mightily pissed by this attitude. If we enable access to non-free software, we will be on the hook to atleast try and make that combination work but we can't do that without fairly deep changes on how we have structured our project. Enabling easy access is only a small part of it. The real problem will be QA especially given our fairly aggressive set of updates (do we change our kernel update policy? have the resources to backport fixes instead?) but even otherwise, this is a problem<br>
<br></div><div>To take a real life example,<br></div><div><br><a href="https://fedoraproject.org/wiki/Common_F20_bugs#Eclipse_crashes_with_Google_Talk_plugin_installed">https://fedoraproject.org/wiki/Common_F20_bugs#Eclipse_crashes_with_Google_Talk_plugin_installed</a><br>
</div><div> <br></div><div>There is no good way for a Fedora user to know that installing something seemingly unrelated can cause this problem and I ran into just a day before. If we know about this problem before a release and we are enabling access to Google Talk which I think your proposal will do, do we say, not our problem? We will not test it and we will not care about it even if somebody reports it? Do we enable the workaround that makes Eclipse not crash but degrades the experience by default just in case Google Talk is installed by the user? I would like your proposal to address such issues. <br>
<br></div><div>Rahul<br></div></div></div></div></div>