----- Original Message ----- > From: "Christian Schaller" <cschalle@xxxxxxxxxx> > To: "Fedora community advisory board" <advisory-board@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, January 22, 2014 2:20:07 AM > Subject: Re: Proposal: Revision of policy surrounding 3rd party and non-free software > > Ok, I seen this issue raised a few times now about the NVidia driver and the > Fedora kernel update policy. > > We are well aware that there are challenges here, Josh Boyer who is the lead > Fedora kernel developer > is part of the Fedora Workstation Working Group and inside Red Hat I manage > among other things the graphics team > who maintains and develops things like Nouveau, but at the same time the same > team works with Nvidia dealing > with issues encountered by common customers of Red Hat and NVidia. So between > Josh and Red Hat graphics team > I hope you can trust that we have the right people on board to find a > solution if a solution is possible. > > The goal of the Workstation Working group, and I am sure that is something we > share with the other working groups, is > to make a high quality product. That includes identifying potential issues > and figuring out how to solve them. Figuring > out the binary driver issue is one of the harder ones and I can easily see it > taking a long time to resolve, or maybe we > will never find a solution. But please lets not make 'Its to hard, lets not > even try' the new Fedora slogan. I'm certainly not of the opinion that we shouldn't ever change anything. The three-products proposal is change; I also suspect some policies may change in line with each working group's preferences, workflow, etc. I think it's an important step for Fedora, and one that will result in providing a more tailored experience for each use case. And it's also going to be hard - so I think to say that "everyone is saying no because they're scared it's too hard," is unfair. I am pretty sure that that work, along with the infrastructure changes we'll need to support the new workflow, and the automation/testing work that many are putting significant and amazing effort into will be incredibly difficult - but is absolutely key to our ability to actually deliver 3 things that are at the same level of quality as the one product we have now, and I really believe that, done right and over time, will result in far higher levels of quality, far better testing coverage, than the "one product" world we just started the journey away from with the release of F20. Some people in this thread are point-blank saying "no,"; others may be saying "no," or "no, it's too hard (or impossible)" with regards to some of the technical details here. Many responses are some combination of both, though I suspect some may be presenting the combo as "no on principle, and just in case anyone wants to argue with that, here's technical reasons why it is hard or impossible, which render any arguing about the principle as pointless effort anyway." Those arguing on principle - that Fedora's foundation of Freedom simply prohibits this - are generally not naive. I don't think anyone believes that "Freedom" is easy; many of the "Features, First" things that we do as part of Fedora development that *increase freedom" by providing open source alternatives are technically difficult, and sometimes even controversial, but we do them *precisely* because Freedom, the advancement of free software, is something we believe in as a project. So I don't think it's a matter of people saying it's too hard. If nothing else - I think it can probably be construed that those saying "no" are actually saying, "I'd rather do things the hard way." But when you say, "please lets not make 'Its to hard, lets not even try' the new Fedora slogan" - I think that slogan is exactly how people are perceiving this proposal. "Freedom is too hard, so let's not even try." As I stated previously - I'm not against change. I'm not even against finding a reasonable workaround to this particular issue or against debating it, I'm open to many things. But I do feel as though this solution in particular is a bit of "giving up" in some way on its own. In other mails in this thread, other solutions for enabling a better experience for the workstation user were cited by Bill and others; as I pointed out, some of these didn't directly impact the project's core principles as written today. Some of these, as mentioned, require more effort than others. You kindly pointed out your ability as a manager to redirect/reallocate resources; has the working group considered, rather than selecting by "effort required," which improvements/changes might have the most impact in terms of improving things to the ends of gaining users? And then redirecting work efforts done by those whom you can redirect towards solving those problems? For example: While I completely love and appreciate the efforts of those working in Fedora's QA team - I think we always have room to continuously improve the quality of the distribution. Effort in improving our automation, build system, moving towards gating changes and updates based on passing tests, and automating the testing of as much of our release criteria as possible not only frees up QA time to further test things which can't be as easily automated, and reduces their resource strain in the face of a 3-way product split - but can also improve the overall quality of the product(s), resulting in a better experience for those who *already* use Fedora, a better reputation, a better experience for those trying it out and whom we would love to keep on Fedora. Giving up Freedom feels like a solution of "the last resort." While I get that this solution is easier to *implement* than others on the table - I don't know that "it's the easiest" should necessitate a rewrite of everything that defines the Fedora Project before seeing how other, at least net-neutral changes can impact the usage of Fedora. I really would prefer to implement other solutions first that are more along the lines of "it can only stay the same or go up from here" instead of those which may gain users at the expense of existing users, contributors, reputation, branding. (Or find a solution to this particular problem that is more in line with our existing values.) -robyn > > Christian > > > > ----- Original Message ----- > > From: "Rahul Sundaram" <metherid@xxxxxxxxx> > > To: "Fedora community advisory board" > > <advisory-board@xxxxxxxxxxxxxxxxxxxxxxx> > > Sent: Wednesday, January 22, 2014 4:37:35 AM > > Subject: Re: Proposal: Revision of policy surrounding 3rd party and > > non-free software > > > > Hi > > > > > > On Tue, Jan 21, 2014 at 9:52 AM, Christian Schaller < cschalle@xxxxxxxxxx > > > wrote: > > > > > > > > > > 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 > > 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' > > to use said non-free software for that reason. > > > > [I am not sure I agree with the overall goal but setting that aside for the > > moment] > > > > Others have covered the idealogically side of the argument very well so let > > me focus on a more practical problem: > > > > 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 > > > > To take a real life example, > > > > https://fedoraproject.org/wiki/Common_F20_bugs#Eclipse_crashes_with_Google_Talk_plugin_installed > > > > 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. > > > > Rahul > > > > _______________________________________________ > > advisory-board mailing list > > advisory-board@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/advisory-board > _______________________________________________ > advisory-board mailing list > advisory-board@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/advisory-board _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
