Hi everyone, So as most of you might know the Fedora board voted against the proposal to allow 3rd party repos in the App installer last night. While unfortunate I don't see it as the end of the road neither for the working group or the proposal itself. We should continue with step 2 of the development process which is writing up a technical specification of the product. I will send out my a template/skeleton for what I think needs to be included in the specification and we can take it from there, because regardless of what will be the long term outcome of the boards current decision, we will need that specification.
Christian
On 24 January 2014 10:18, Christian Schaller cschalle@redhat.com wrote:
...writing up a technical specification of the product...
I think this is going to be hard until we know more about the legal side of things and what we're allowed to do. From my point of view, if we can ship a google-chrome.repo file that's disabled and some pre-prepared appstream metadata, it makes building the required functionality in gnome-software quite easy. We can show the non-free applications, and if the user clicks install we just need to show some kind of agreement, download the metadata and then install the application.
If we can't ship the AppStream metadata or the disabled repo file then we need some way of querying for search terms, for instance calling out to a webservice on apps.fedoraproject.org that returns results for a search term of "chrome" -- this will also need to return icons, perhaps screenshots, and also some repo parameters and possible EULA text. This would be possible to implement in a gnome-software plugin and a chunk of new functionality in PackageKit, and would also need a new webservice. So again, possible, just a little harder to implement.
Richard.
Yeah, for the installer it will be a bit hard to proceed atm, but there are of course a lot of other aspects to the PRD we can flesh out.
I will check with legal if there are any implications in turning the software app into a application that searches the web for Fedora sofware as opposed to a front-end to specific repositories. It could be a work around as it lets the purist stay pure as we don't ship any data pointing to anything non-free and at the same time it would make any software available for Fedora easier to find. Hopefully it would be fine as the software app at that point is essentially just a web browser tailored to search for software.
Christian
----- Original Message -----
From: "Richard Hughes" hughsient@gmail.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, January 24, 2014 11:32:41 AM Subject: Re: Fedora board vote and way forward
On 24 January 2014 10:18, Christian Schaller cschalle@redhat.com wrote:
...writing up a technical specification of the product...
I think this is going to be hard until we know more about the legal side of things and what we're allowed to do. From my point of view, if we can ship a google-chrome.repo file that's disabled and some pre-prepared appstream metadata, it makes building the required functionality in gnome-software quite easy. We can show the non-free applications, and if the user clicks install we just need to show some kind of agreement, download the metadata and then install the application.
If we can't ship the AppStream metadata or the disabled repo file then we need some way of querying for search terms, for instance calling out to a webservice on apps.fedoraproject.org that returns results for a search term of "chrome" -- this will also need to return icons, perhaps screenshots, and also some repo parameters and possible EULA text. This would be possible to implement in a gnome-software plugin and a chunk of new functionality in PackageKit, and would also need a new webservice. So again, possible, just a little harder to implement.
Richard.
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On 24 January 2014 10:39, Christian Schaller cschalle@redhat.com wrote:
Yeah, for the installer it will be a bit hard to proceed atm, but there are of course a lot of other aspects to the PRD we can flesh out.
Sure. Given we're so close to the UI freeze for F21 we'll have to either punt this to F22, but I think that's fine unless F21 turns out to be a long time coming.
I will check with legal if there are any implications in turning the software app into a application that searches the web for Fedora sofware as opposed to a front-end to specific repositories.
It might be as simple as just getting the software center to download something like this at runtime: https://github.com/hughsie/fedora-appstream/blob/master/appstream-extra/twit... -- i.e. it's metadata, but metadata that's downloaded at runtime rather than shipped with the package. That example is a web-app, so no repo configuration is present, but it would be fairly easy to add a EULA text and some repo parameters to that XML format.
Richard
My take away from the discussion so far is that the current board would not accept anything that 'automates' access to such external software. Doesn't matter if we ship the metadata on the ISO or not.
The only thing that I can see flying with the current board is a system that is 'blind' to what it is offering, just like a web browser.
Christian
----- Original Message -----
From: "Richard Hughes" hughsient@gmail.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, January 24, 2014 11:48:59 AM Subject: Re: Fedora board vote and way forward
On 24 January 2014 10:39, Christian Schaller cschalle@redhat.com wrote:
Yeah, for the installer it will be a bit hard to proceed atm, but there are of course a lot of other aspects to the PRD we can flesh out.
Sure. Given we're so close to the UI freeze for F21 we'll have to either punt this to F22, but I think that's fine unless F21 turns out to be a long time coming.
I will check with legal if there are any implications in turning the software app into a application that searches the web for Fedora sofware as opposed to a front-end to specific repositories.
It might be as simple as just getting the software center to download something like this at runtime: https://github.com/hughsie/fedora-appstream/blob/master/appstream-extra/twit... -- i.e. it's metadata, but metadata that's downloaded at runtime rather than shipped with the package. That example is a web-app, so no repo configuration is present, but it would be fairly easy to add a EULA text and some repo parameters to that XML format.
Richard
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On 24 January 2014 10:54, Christian Schaller cschalle@redhat.com wrote:
My take away from the discussion so far is that the current board would not accept anything that 'automates' access to such external software. Doesn't matter if we ship the metadata on the ISO or not.
Did they define 'automates'? Is there a required level of pain that we have to make the user go through? At the moment it's just "type chrome into google; click an rpm; input your password". I don't see how that's any harder than "type a chrome into the software center; click install; agree to the EULA; input your password".
The only thing that I can see flying with the current board is a system that is 'blind' to what it is offering, just like a web browser.
So perhaps when the user clicks install, it just opens the browser to something like https://www.google.com/intl/en/chrome/browser/ ? -- that's perfectly doable right now, but the UX would be pretty, well, unusual.
Richard.
On Fri, Jan 24, 2014 at 6:00 AM, Richard Hughes hughsient@gmail.com wrote:
On 24 January 2014 10:54, Christian Schaller cschalle@redhat.com wrote:
My take away from the discussion so far is that the current board would not accept anything that 'automates' access to such external software. Doesn't matter if we ship the metadata on the ISO or not.
Did they define 'automates'? Is there a required level of pain that we have to make the user go through? At the moment it's just "type chrome into google; click an rpm; input your password". I don't see how that's any harder than "type a chrome into the software center; click install; agree to the EULA; input your password".
As long as software center doesn't know to go directly to the site containing the chrome repo, that is possible.
The only thing that I can see flying with the current board is a system that is 'blind' to what it is offering, just like a web browser.
So perhaps when the user clicks install, it just opens the browser to something like https://www.google.com/intl/en/chrome/browser/ ? -- that's perfectly doable right now, but the UX would be pretty, well, unusual.
Possibly. I believe the Board would like some informative messaging around 3rd party software, it's lack of support from Fedora, etc.
josh
----- Original Message -----
My take away from the discussion so far is that the current board would not accept anything that 'automates' access to such external software. Doesn't matter if we ship the metadata on the ISO or not.
The only thing that I can see flying with the current board is a system that is 'blind' to what it is offering, just like a web browser.
How is that a better solution than making it easier to add new repositories through the web browser? Or through a URL copy/paste in the software center?
My naive approach would be to: - allow repositories to be defined by a single URL (this is what third-party repositories for Synology, iOS jailbreak, Cyanogen, etc. use) - use a custom scheme in the software center to pass those URLs, eg. gnome-software://rpmrepos.org/my-stable-repo or even defining multiple repos with a single URL: gnome-software://rpmrepos.org The software center can now show you the list of repositories offered by this URL - Convince repo maintainers to add those URLs to web pages
One-click in the web browser, confirm in Software center. It also works for both proprietary repos and free software restricted ones. The user can find out about the repos through the existing page, that could be linked from the Software center as well: https://fedoraproject.org/wiki/Third_party_repositories
Having said that, I don't think this is the blocker problem for most users. They know how to find the repositories they need ("fedora rpm nvidia" in Google?), the problem is providing making it easy for developers to package their wares for Fedora.
Have you recently tried to install Skype or Spotify on a Fedora machine? It's all about running alien (in the same way that Debian users ran alien 10 years ago to convert proprietary RPMs to debs).
Hashing out application bundles and making sure that whatever gets selected also works on Ubuntu would be the best way to convince the makers of those products to ship them in a format that Fedora can understand and install.
Haven't tried spotify in a long while, but yes I do seem to remember they only ship a deb currently. Skype are shipping an RPM still. Of course we have no guarantee they will continue doing so, which was part of what we where hoping to do here. By offering the inclusion in the software center we could have used that to try to ensure vedors keep supporting Fedora or start supporting Fedora.
As for making it easy to package software, isn't that what the LinuxApps plan is all about?
Christian
----- Original Message -----
From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, January 24, 2014 12:15:50 PM Subject: Re: Fedora board vote and way forward
----- Original Message -----
My take away from the discussion so far is that the current board would not accept anything that 'automates' access to such external software. Doesn't matter if we ship the metadata on the ISO or not.
The only thing that I can see flying with the current board is a system that is 'blind' to what it is offering, just like a web browser.
How is that a better solution than making it easier to add new repositories through the web browser? Or through a URL copy/paste in the software center?
My naive approach would be to:
- allow repositories to be defined by a single URL (this is what third-party
repositories for Synology, iOS jailbreak, Cyanogen, etc. use)
- use a custom scheme in the software center to pass those URLs, eg. gnome-software://rpmrepos.org/my-stable-repo or even defining multiple repos with a single URL: gnome-software://rpmrepos.org The software center can now show you the list of repositories offered by this URL
- Convince repo maintainers to add those URLs to web pages
One-click in the web browser, confirm in Software center. It also works for both proprietary repos and free software restricted ones. The user can find out about the repos through the existing page, that could be linked from the Software center as well: https://fedoraproject.org/wiki/Third_party_repositories
Having said that, I don't think this is the blocker problem for most users. They know how to find the repositories they need ("fedora rpm nvidia" in Google?), the problem is providing making it easy for developers to package their wares for Fedora.
Have you recently tried to install Skype or Spotify on a Fedora machine? It's all about running alien (in the same way that Debian users ran alien 10 years ago to convert proprietary RPMs to debs).
Hashing out application bundles and making sure that whatever gets selected also works on Ubuntu would be the best way to convince the makers of those products to ship them in a format that Fedora can understand and install. -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
----- Original Message -----
Haven't tried spotify in a long while, but yes I do seem to remember they only ship a deb currently. Skype are shipping an RPM still. Of course we have no guarantee they will continue doing so, which was part of what we where hoping to do here. By offering the inclusion in the software center we could have used that to try to ensure vedors keep supporting Fedora or start supporting Fedora.
As for making it easy to package software, isn't that what the LinuxApps plan is all about?
Yes. So for which vendors are we expanding all this energy to integrate proprietary repos into the Software Center?
Currently none as we didn't get the go ahead from the board to do so.
----- Original Message ----- From: "Bastien Nocera" bnocera@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, January 24, 2014 12:55:55 PM Subject: Re: Fedora board vote and way forward
----- Original Message -----
Haven't tried spotify in a long while, but yes I do seem to remember they only ship a deb currently. Skype are shipping an RPM still. Of course we have no guarantee they will continue doing so, which was part of what we where hoping to do here. By offering the inclusion in the software center we could have used that to try to ensure vedors keep supporting Fedora or start supporting Fedora.
As for making it easy to package software, isn't that what the LinuxApps plan is all about?
Yes. So for which vendors are we expanding all this energy to integrate proprietary repos into the Software Center?
On Fri, Jan 24, 2014 at 12:15 PM, Bastien Nocera bnocera@redhat.com wrote:
----- Original Message -----
My take away from the discussion so far is that the current board would not accept anything that 'automates' access to such external software. Doesn't matter if we ship the metadata on the ISO or not.
The only thing that I can see flying with the current board is a system that is 'blind' to what it is offering, just like a web browser.
How is that a better solution than making it easier to add new repositories through the web browser? Or through a URL copy/paste in the software center?
My naive approach would be to:
- allow repositories to be defined by a single URL (this is what third-party repositories for Synology, iOS jailbreak, Cyanogen, etc. use)
- use a custom scheme in the software center to pass those URLs, eg. gnome-software://rpmrepos.org/my-stable-repo or even defining multiple repos with a single URL: gnome-software://rpmrepos.org The software center can now show you the list of repositories offered by this URL
- Convince repo maintainers to add those URLs to web pages
One-click in the web browser, confirm in Software center. It also works for both proprietary repos and free software restricted ones. The user can find out about the repos through the existing page, that could be linked from the Software center as well: https://fedoraproject.org/wiki/Third_party_repositories
Having said that, I don't think this is the blocker problem for most users. They know how to find the repositories they need ("fedora rpm nvidia" in Google?), the problem is providing making it easy for developers to package their wares for Fedora.
Have you recently tried to install Skype or Spotify on a Fedora machine?
Skype offers an RPM.
On Fri, Jan 24, 2014 at 06:15:50AM -0500, Bastien Nocera wrote:
My naive approach would be to:
- allow repositories to be defined by a single URL (this is what third-party repositories for Synology, iOS jailbreak, Cyanogen, etc. use)
- use a custom scheme in the software center to pass those URLs, eg. gnome-software://rpmrepos.org/my-stable-repo or even defining multiple repos with a single URL: gnome-software://rpmrepos.org The software center can now show you the list of repositories offered by this URL
- Convince repo maintainers to add those URLs to web pages
This, however, I think *would* be in line with the board's position - it's effectively a better integrated version of the status quo.
Hi
On Fri, Jan 24, 2014 at 9:00 AM, Matthew Garrett wrote:
On Fri, Jan 24, 2014 at 06:15:50AM -0500, Bastien Nocera wrote:
My naive approach would be to:
- allow repositories to be defined by a single URL (this is what
third-party repositories
for Synology, iOS jailbreak, Cyanogen, etc. use)
- use a custom scheme in the software center to pass those URLs, eg. gnome-software://rpmrepos.org/my-stable-repo or even defining multiple repos with a single URL: gnome-software://rpmrepos.org The software center can now show you the list of repositories offered
by this URL
- Convince repo maintainers to add those URLs to web pages
This, however, I think *would* be in line with the board's position - it's effectively a better integrated version of the status quo.
I would however suggest that you use more generic url's similar to apt url's
yum://rpmrepos.org
So that command line users (via a plugin maybe) or other frontends can access the same functionality without being led into thinking this interface is specific to GNOME software
Rahul
On Fri, Jan 24, 2014 at 06:15:50AM -0500, Bastien Nocera wrote:
- use a custom scheme in the software center to pass those URLs, eg. gnome-software://rpmrepos.org/my-stable-repo or even defining multiple repos with a single URL: gnome-software://rpmrepos.org The software center can now show you the list of repositories offered by this URL
- Convince repo maintainers to add those URLs to web pages
This really looks ok. It would be useful to anyone offering software for Fedora instead of only to a small list of proprietary vendors.
Maybe in some cases those URLs can even point to something that's not necessarily specific to a single distribution. For now, it could be just different sections for RPM and Debian repos with Gnome Software choosing depending on what kind of system it's running on.
This also seems to be approximately what openSUSE's One Click Install does: http://en.opensuse.org/openSUSE:One_Click_Install_Developer
On Fri, Jan 24, 2014 at 03:59:29PM +0100, Lars Seipel wrote:
This also seems to be approximately what openSUSE's One Click Install does: http://en.opensuse.org/openSUSE:One_Click_Install_Developer
It seems like it may be a little over-complex (especially compared to the idea of a URL defining the repo), but I also notice that it is intended to be distro-independent and the web site at least seems keen on standardization. Maybe collaboration would be productive?
http://en.opensuse.org/openSUSE:One_Click_Install_Developer#Distribution_ind...
On 24 January 2014 15:13, Matthew Miller mattdm@fedoraproject.org wrote:
It seems like it may be a little over-complex (especially compared to the idea of a URL defining the repo), but I also notice that it is intended to be distro-independent and the web site at least seems keen on standardization. Maybe collaboration would be productive?
Yes, I've worked with the Suse people closely when I was involved in the AppStream design. My concerns about security were never really addressed, hence my reticence to support it in PackageKit.
Richard.
On Fri, Jan 24, 2014 at 5:54 AM, Christian Schaller cschalle@redhat.com wrote:
My take away from the discussion so far is that the current board would not accept anything that 'automates' access to such external software. Doesn't matter if we ship the metadata on the ISO or not.
Correct. It cannot know the location of where to grab external metadata from, etc.
The only thing that I can see flying with the current board is a system that is 'blind' to what it is offering, just like a web browser.
Fairly close, yes. I think there was also an idea to perhaps make metadata an explicit filetype so that if a user searches for "nvidia linux driver" and lands on the nivida website, they can click a link and PK (or similar) will know what to do. That would also go for other 3rd party repositories. There is the bit about "informed decision", so some messaging before it's installed might be necessary.
josh
On Fri, 2014-01-24 at 05:54 -0500, Christian Schaller wrote:
My take away from the discussion so far is that the current board would not accept anything that 'automates' access to such external software. Doesn't matter if we ship the metadata on the ISO or not.
The only thing that I can see flying with the current board is a system that is 'blind' to what it is offering, just like a web browser.
I can see this thread goes on for miles, but I really wanted to say this.
Christian: This is not a question of being tricksy with technical implementation details. It is a question of principle. The Board is not attempting to give you oblique hints as to how you can achieve your initial goal without infringing on some technicality or other. The Board has made a clear statement that the substance of your proposal conflicts with Fedora's foundations. I wish you would respect that, rather than trying to fiddle with the implementation details to try and argue that you're complying with the letter of the Board's statement; as someone at the Board meeting told me when I suggested rewording the latter agreement to make it more clear you should not do *precisely* what you're trying to do now, this is not a court of law and we are not playing a game of "that depends on what the meaning of the word 'is' is".
From my reading of the Board meeting and my conversation with Board
members, the consensus was broadly what I suggested during the meeting: there needs to be a 'bright line' between Fedora and not-Fedora, and there needs to be an active and informed decision on the user/sysadmin's part to cross that line. What you are now proposing violates that principle even more than your original proposal.
When the board talked about 'reducing technical barriers' it wasn't talking about this: it was acknowledging the broader debate about whether the perceived difficulty of using third party software in Fedora is *really* about the poor infrastructure for the building and distribution of such software, rather than any problem with the process of hopping the 'bright line' itself, which as others have pointed out, really isn't that onerous: clicking on a package that contains a .repo definition and saying 'yes' a couple of times is not rocket science. So the Board was endorsing the idea of looking at the *real* pain points for third party software use instead of trying to subvert the fundamental principles of the project in a way that doesn't even address the correct problem.
Adam, the problem is that it's extremely un-intuative for a user when it's "download a pacakge with the .repo in it you found on a random search on google, and THEN use Software to search for the app you wanted to install". People unfamiliar with the underlying architecture will not understand that easily. If we could make it so that a package could both install a repository file AND software from that repository (also known as "one click install") that would solve that problem, but will still introduce a problem of security, because it will encourage users to download random software from the web, essentially invalidating all the security benefits of a package management system.
On Fri, 2014-01-24 at 19:21 +0200, Elad Alfassa wrote:
Adam, the problem is that it's extremely un-intuative for a user when it's "download a pacakge with the .repo in it you found on a random search on google, and THEN use Software to search for the app you wanted to install". People unfamiliar with the underlying architecture will not understand that easily. If we could make it so that a package could both install a repository file AND software from that repository (also known as "one click install") that would solve that problem, but will still introduce a problem of security, because it will encourage users to download random software from the web, essentially invalidating all the security benefits of a package management system.
All this seems to be covered in a competing sub-thread, so let's not confuse the issue any further.
On Fri, Jan 24, 2014 at 19:21:23 +0200, Elad Alfassa elad@fedoraproject.org wrote:
Adam, the problem is that it's extremely un-intuative for a user when it's "download a pacakge with the .repo in it you found on a random search on google, and THEN use Software to search for the app you wanted to install". People unfamiliar with the underlying architecture will not understand that easily. If we could make it so that a package could both install a repository file AND software from that repository (also known as "one click install") that would solve that problem, but will still introduce a problem of security, because it will encourage users to download random software from the web, essentially invalidating all the security benefits of a package management system.
Downloading commercial software is a security problem in the first place. I wouldn't expect downloading random software to be much worse. I suppose that would depend on the space you are selecting from, but for at least some ways about hearing about software, I would expect the commercial stuff to be much more likely to have anti-user features and bundled libraries with known security problems than some small open source project.
Hi Adam, It is not really a question of trying to be tricky here. I understand that us trying to find a solution both sides can live with here feels frustrating to you, as it constantly butts head against where you feel the boundary should be, but trust me the situation is frustrating for us too.
But I agree that a tenable solution is not likely to be found in this direction, so I think what we need is to take a step back and some timeout to try think outside the box about this problem. Your idea from yesterday to enable features such as this in a differently branded product has some obvious issues to me, but at least it was a good example of someone trying to come up with a solution to the disagreement by not getting locked into the the context of the current debate, and thus maybe something we should at least think about. Anyway maybe some brainstorming is what is needed here.
Christian
----- Original Message ----- From: "Adam Williamson" awilliam@redhat.com To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, January 24, 2014 6:11:03 PM Subject: Re: Fedora board vote and way forward
On Fri, 2014-01-24 at 05:54 -0500, Christian Schaller wrote:
My take away from the discussion so far is that the current board would not accept anything that 'automates' access to such external software. Doesn't matter if we ship the metadata on the ISO or not.
The only thing that I can see flying with the current board is a system that is 'blind' to what it is offering, just like a web browser.
I can see this thread goes on for miles, but I really wanted to say this.
Christian: This is not a question of being tricksy with technical implementation details. It is a question of principle. The Board is not attempting to give you oblique hints as to how you can achieve your initial goal without infringing on some technicality or other. The Board has made a clear statement that the substance of your proposal conflicts with Fedora's foundations. I wish you would respect that, rather than trying to fiddle with the implementation details to try and argue that you're complying with the letter of the Board's statement; as someone at the Board meeting told me when I suggested rewording the latter agreement to make it more clear you should not do *precisely* what you're trying to do now, this is not a court of law and we are not playing a game of "that depends on what the meaning of the word 'is' is".
From my reading of the Board meeting and my conversation with Board
members, the consensus was broadly what I suggested during the meeting: there needs to be a 'bright line' between Fedora and not-Fedora, and there needs to be an active and informed decision on the user/sysadmin's part to cross that line. What you are now proposing violates that principle even more than your original proposal.
When the board talked about 'reducing technical barriers' it wasn't talking about this: it was acknowledging the broader debate about whether the perceived difficulty of using third party software in Fedora is *really* about the poor infrastructure for the building and distribution of such software, rather than any problem with the process of hopping the 'bright line' itself, which as others have pointed out, really isn't that onerous: clicking on a package that contains a .repo definition and saying 'yes' a couple of times is not rocket science. So the Board was endorsing the idea of looking at the *real* pain points for third party software use instead of trying to subvert the fundamental principles of the project in a way that doesn't even address the correct problem.
On Fri, 2014-01-24 at 13:23 -0500, Christian Schaller wrote:
Hi Adam, It is not really a question of trying to be tricky here. I understand that us trying to find a solution both sides can live with here feels frustrating to you, as it constantly butts head against where you feel the boundary should be, but trust me the situation is frustrating for us too.
But I agree that a tenable solution is not likely to be found in this direction, so I think what we need is to take a step back and some timeout to try think outside the box about this problem. Your idea from yesterday to enable features such as this in a differently branded product has some obvious issues to me, but at least it was a good example of someone trying to come up with a solution to the disagreement by not getting locked into the the context of the current debate, and thus maybe something we should at least think about. Anyway maybe some brainstorming is what is needed here.
Yeah, sorry, I think I got it out of my system now. :)
I didn't really bring up differently-branded products as a concrete suggestion for what the Fedora Desktop team should do, just as a useful reference point for the wider debate: it's a way of reinforcing the point that the really problematic issue here is the 'Fedora/not-Fedora' distinction. It's absolutely fine for Korora etc to do whatever they want because it's very clear that doesn't come with the endorsement of the Fedora project/distribution. But I expect people who use Korora have an explicit or implicit understanding that Korora, to some degree, is standing behind the stuff they're including: if they install Korora and then install a couple of updates and Flash breaks, they're going to complain to Korora, right? They see it as a piece of Korora.
The practical suggestion I find most interesting is a *cross-distribution* infrastructure/platform for the provision and distribution of third-party software, quite simply. My take is that the fact there's nothing like this that all or at least most of the major vendors agree on is much more of a problem for both users and distributors of third party stuff than any single distro's exact perspective on how far it should isolate itself from third-party bits. As we've already gone over, I don't think the degree of isolation from third-party bits that Fedora currently insists on is so great as to form a major barrier *in itself*.
It's also worth noting that Chrome/Flash etc and NVIDIA are kind of different problems. NVIDIA is a very tricky case much more because of the technical details of that particular case than just because it's third party software. I haven't really seen anyone who had much of a problem with the *theory* of how to install NVIDIA, which is more or less 'enable the magic repo and then install a couple of packages'. The problems people have in that case really are technical implementation issues: specifically, getting nouveau out of the way of nvidia is kind of tricky and the details seem to change from release to release, and then Fedora is rather ahead of NVIDIA in its kernel schedule - so quite often we bump a stable Fedora release to a kernel version which NVIDIA isn't ready for yet, so even if you have the akmod for NVIDIA rather than the kmod installed, everything goes sideways.
My point there is that we should probably think harder about the Chrome/Flash/whatever case - the case of things that are basically 'apps' sitting quite lightly on top of the distribution 'platform' - than the tricky NVIDIA case, which is kind of a special one and requires special handling. For the 'app' case, I really think that having a *single* distribution platform for all the major distros would make everyone's life a lot easier, and would not be hard at all to reconcile with Fedora's fundamental principles - we just have to isolate access to that platform to whatever degree is agreed to meet our principles, and I think we're all agreed that that degree doesn't need to be *excessively* onerous, just enough to keep Fedora's principles clear and the separation of responsibility clear.
Of course, this requires both building the infrastructure/framework and the distributions committing to *some* kind of platform that the third party distributors can rely on - even if it's as basic as 'we'll give you glibc and an input layer and ALSA/PulseAudio and maybe we'll commit to a couple of toolkits being available, anything else you can bundle yourself or manage the cross-distro compatibility some other way'. But, at least IMHO, that's the approach that provides the best payback. It's already what happens, in effect - most third party distributors don't build tweaked and tested packages for all distros, they just build a huge static bundle on top of glibc and ship it in a tarball (or a 'dumb' RPM/DEB package which doesn't really use any distro dependencies, it's just being used as a container). But we don't have a nice neat distribution platform for their tarballs/dumb RPM or DEB packages, so users have to go out and find them in a dozen different locations, and there's lots of silliness in how they work probably because all the distros aren't getting together and providing some simple groundwork and rules.
If we just had a nice Software/Steam-ish platform where you'd know all the major third-party stuff was available, with a decent interface and screenshots and reviews and all that gumph that's the current vogue, it'd be a much nicer experience, even if ultimately what you got was the same big static bundle you get from a tarball/dumb package today.
On Fri, Jan 24, 2014 at 1:49 PM, Adam Williamson awilliam@redhat.com wrote:
The practical suggestion I find most interesting is a *cross-distribution* infrastructure/platform for the provision and distribution of third-party software, quite simply. My take is that the fact there's nothing like this that all or at least most of the major vendors agree on is much more of a problem for both users and distributors of third party stuff than any single distro's exact perspective on how far it should isolate itself from third-party bits. As we've already gone over, I don't think the degree of isolation from third-party bits that Fedora currently insists on is so great as to form a major barrier *in itself*.
<snip NVIDIA>
My point there is that we should probably think harder about the Chrome/Flash/whatever case - the case of things that are basically 'apps' sitting quite lightly on top of the distribution 'platform' - than the tricky NVIDIA case, which is kind of a special one and requires special handling. For the 'app' case, I really think that having a *single* distribution platform for all the major distros would make everyone's life a lot easier, and would not be hard at all to reconcile with Fedora's fundamental principles - we just have to isolate access to that platform to whatever degree is agreed to meet our principles, and I think we're all agreed that that degree doesn't need to be *excessively* onerous, just enough to keep Fedora's principles clear and the separation of responsibility clear.
Of course, this requires both building the infrastructure/framework and the distributions committing to *some* kind of platform that the third party distributors can rely on - even if it's as basic as 'we'll give you glibc and an input layer and ALSA/PulseAudio and maybe we'll commit to a couple of toolkits being available, anything else you can bundle yourself or manage the cross-distro compatibility some other way'. But, at least IMHO, that's the approach that provides the best payback. It's already what happens, in effect - most third party distributors don't build tweaked and tested packages for all distros, they just build a huge static bundle on top of glibc and ship it in a tarball (or a 'dumb' RPM/DEB package which doesn't really use any distro dependencies, it's just being used as a container). But we don't have a nice neat distribution platform for their tarballs/dumb RPM or DEB packages, so users have to go out and find them in a dozen different locations, and there's lots of silliness in how they work probably because all the distros aren't getting together and providing some simple groundwork and rules.
If we just had a nice Software/Steam-ish platform where you'd know all the major third-party stuff was available, with a decent interface and screenshots and reviews and all that gumph that's the current vogue, it'd be a much nicer experience, even if ultimately what you got was the same big static bundle you get from a tarball/dumb package today.
So if one were to go to all of the infrastructure work and cross-distro collaboration and get vendor buy-in, would you view that single "platform" (or AppStore or whatever) as something that a Fedora software installer could point to and include in searches done in the software installer?
josh
On Fri, 2014-01-24 at 14:03 -0500, Josh Boyer wrote:
If we just had a nice Software/Steam-ish platform where you'd know all the major third-party stuff was available, with a decent interface and screenshots and reviews and all that gumph that's the current vogue, it'd be a much nicer experience, even if ultimately what you got was the same big static bundle you get from a tarball/dumb package today.
So if one were to go to all of the infrastructure work and cross-distro collaboration and get vendor buy-in, would you view that single "platform" (or AppStore or whatever) as something that a Fedora software installer could point to and include in searches done in the software installer?
Like I said I don't view the degree of isolation of the platform from the distro as a hugely key issue, and it's something we could figure out later, but I guess my personal answer would probably be 'yes, as long as it was sufficiently clear what was going on'. We already have various mechanisms like this in the distro, so it'd be kind of inconsistent to zap it for this purpose - though I think all the similar mechanisms that are currently allowed (I'm thinking of pip / rubygems / Wordpress plugin store and similar things) are for access to 'repositories' that have similar freedom / patent encumbrance policies to ours, which is kind of a notable difference.
On Fri, Jan 24, 2014 at 2:23 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2014-01-24 at 14:03 -0500, Josh Boyer wrote:
If we just had a nice Software/Steam-ish platform where you'd know all the major third-party stuff was available, with a decent interface and screenshots and reviews and all that gumph that's the current vogue, it'd be a much nicer experience, even if ultimately what you got was the same big static bundle you get from a tarball/dumb package today.
So if one were to go to all of the infrastructure work and cross-distro collaboration and get vendor buy-in, would you view that single "platform" (or AppStore or whatever) as something that a Fedora software installer could point to and include in searches done in the software installer?
Like I said I don't view the degree of isolation of the platform from the distro as a hugely key issue, and it's something we could figure out later, but I guess my personal answer would probably be 'yes, as long as it was sufficiently clear what was going on'. We already have various mechanisms like this in the distro, so it'd be kind of inconsistent to zap it for this purpose - though I think all the similar mechanisms that are currently allowed (I'm thinking of pip / rubygems / Wordpress plugin store and similar things) are for access to 'repositories' that have similar freedom / patent encumbrance policies to ours, which is kind of a notable difference.
I understand the preference for one nice, consistent location and I agree it would be nice. But so as to be clear, the real key differences you see here are:
"as long as it was sufficiently clear what was going on"
and
"existing mechanisms have similar policies to Fedora's".
Is that correct?
If so, the existing scattered but specific repos could still have it be clear as to what was going on, and we don't really control the pip/rubygems/wordpress policies. Those mechanisms could include something Fedora considers unacceptable, and we likely wouldn't even know. Would we then patch out that functionality from their respective languages if we found out?
I'm not trying to argue. I don't even think I really disagree with the sentiment you're trying to convey. I'm trying to understand where your bright line is though, because it's very dim to me at the moment.
josh
On Fri, 2014-01-24 at 14:47 -0500, Josh Boyer wrote:
On Fri, Jan 24, 2014 at 2:23 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2014-01-24 at 14:03 -0500, Josh Boyer wrote:
If we just had a nice Software/Steam-ish platform where you'd know all the major third-party stuff was available, with a decent interface and screenshots and reviews and all that gumph that's the current vogue, it'd be a much nicer experience, even if ultimately what you got was the same big static bundle you get from a tarball/dumb package today.
So if one were to go to all of the infrastructure work and cross-distro collaboration and get vendor buy-in, would you view that single "platform" (or AppStore or whatever) as something that a Fedora software installer could point to and include in searches done in the software installer?
Like I said I don't view the degree of isolation of the platform from the distro as a hugely key issue, and it's something we could figure out later, but I guess my personal answer would probably be 'yes, as long as it was sufficiently clear what was going on'. We already have various mechanisms like this in the distro, so it'd be kind of inconsistent to zap it for this purpose - though I think all the similar mechanisms that are currently allowed (I'm thinking of pip / rubygems / Wordpress plugin store and similar things) are for access to 'repositories' that have similar freedom / patent encumbrance policies to ours, which is kind of a notable difference.
I understand the preference for one nice, consistent location and I agree it would be nice. But so as to be clear, the real key differences you see here are:
"as long as it was sufficiently clear what was going on"
and
"existing mechanisms have similar policies to Fedora's".
Is that correct?
No, not entirely, because there's a significant difference in this approach. You'd install the platform from Fedora's repos - which would have the implication that we are responsible for the platform working on Fedora, which seems like a reasonable commitment on our part - and you'd then install the software from the platform.
When someone runs Steam on Fedora and then installs a game, it's pretty clear that the game came from Steam, not Fedora. If it doesn't work, they're probably not going to blame Fedora. If it's a non-free game, it's fairly clear that doesn't mean Fedora endorses non-free software.
Ditto with the pip, gems etc examples - you install pip from Fedora, and then you run 'pip install foo' (not 'yum install foo') to install foo. It's embedded right there in the command that you're installing something *from pip*, not from Fedora.
Any mechanism which results in the actual software being accessed through the same interface as Fedora's own packages does not have this clarity baked in, so it has to communicate it in some other way. Right now the hoop-jumping you have to go through in order to enable an external repo or install an external package *also* has the effect of making this clear - I think that's one reason this debate is so fuzzy: from one perspective the difficulty sucks, but from another perspective it's performing a valuable function for us. I don't mind losing the aspect that sucks, but I don't want to lose the valuable function.
If so, the existing scattered but specific repos could still have it be clear as to what was going on, and we don't really control the pip/rubygems/wordpress policies.
I don't have sufficient background on this - I haven't read through the fesco/board considerations of those mechanisms, if they were considered - so I'm hesitant to debate it. But I suspect that if it suddenly became the case that you could deploy non-free software through these mechanisms, there'd at least be a question about whether we should continue to provide them in the way we currently do.
I'm not trying to argue. I don't even think I really disagree with the sentiment you're trying to convey. I'm trying to understand where your bright line is though, because it's very dim to me at the moment.
Sure, I understand where you're coming from - I think this is one of those areas where everyone has a take on it that makes sense to them as long as they don't examine it too closely, and everyone's take is slightly different, and when we all start really examining our takes and comparing them to each other and to what's actually there in the software, everything gets squishier...
On Fri, Jan 24, 2014 at 3:05 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2014-01-24 at 14:47 -0500, Josh Boyer wrote:
On Fri, Jan 24, 2014 at 2:23 PM, Adam Williamson awilliam@redhat.com wrote:
On Fri, 2014-01-24 at 14:03 -0500, Josh Boyer wrote:
If we just had a nice Software/Steam-ish platform where you'd know all the major third-party stuff was available, with a decent interface and screenshots and reviews and all that gumph that's the current vogue, it'd be a much nicer experience, even if ultimately what you got was the same big static bundle you get from a tarball/dumb package today.
So if one were to go to all of the infrastructure work and cross-distro collaboration and get vendor buy-in, would you view that single "platform" (or AppStore or whatever) as something that a Fedora software installer could point to and include in searches done in the software installer?
Like I said I don't view the degree of isolation of the platform from the distro as a hugely key issue, and it's something we could figure out later, but I guess my personal answer would probably be 'yes, as long as it was sufficiently clear what was going on'. We already have various mechanisms like this in the distro, so it'd be kind of inconsistent to zap it for this purpose - though I think all the similar mechanisms that are currently allowed (I'm thinking of pip / rubygems / Wordpress plugin store and similar things) are for access to 'repositories' that have similar freedom / patent encumbrance policies to ours, which is kind of a notable difference.
I understand the preference for one nice, consistent location and I agree it would be nice. But so as to be clear, the real key differences you see here are:
"as long as it was sufficiently clear what was going on"
and
"existing mechanisms have similar policies to Fedora's".
Is that correct?
No, not entirely, because there's a significant difference in this approach. You'd install the platform from Fedora's repos - which would have the implication that we are responsible for the platform working on Fedora, which seems like a reasonable commitment on our part - and you'd then install the software from the platform.
I see. So you install "AppStore" from some website, and then open that up and it has whatever. OK, that's a bit different than what I thought you were describing. Thanks, that helps me understand where you're coming from better.
When someone runs Steam on Fedora and then installs a game, it's pretty clear that the game came from Steam, not Fedora. If it doesn't work, they're probably not going to blame Fedora. If it's a non-free game, it's fairly clear that doesn't mean Fedora endorses non-free software.
They'll likely still blame Fedora for having deficient driver support our media codecs, but sure ;). (Games are a horrible example, but I'm just having fun there not seriously debating.)
Any mechanism which results in the actual software being accessed through the same interface as Fedora's own packages does not have this clarity baked in, so it has to communicate it in some other way. Right now the hoop-jumping you have to go through in order to enable an external repo or install an external package *also* has the effect of making this clear - I think that's one reason this debate is so fuzzy: from one perspective the difficulty sucks, but from another perspective it's performing a valuable function for us. I don't mind losing the aspect that sucks, but I don't want to lose the valuable function.
OK.
josh
On Fri, 2014-01-24 at 15:14 -0500, Josh Boyer wrote:
No, not entirely, because there's a significant difference in this approach. You'd install the platform from Fedora's repos - which would have the implication that we are responsible for the platform working on Fedora, which seems like a reasonable commitment on our part - and you'd then install the software from the platform.
I see. So you install "AppStore" from some website, and then open that up and it has whatever. OK, that's a bit different than what I thought you were describing. Thanks, that helps me understand where you're coming from better.
More or less - actually there can be an 'appstore' Fedora package as long as the appstore itself is F/OSS and so forth (complies with the Fedora packaging guidelines).
I guess in my head I've always conceived this as a separate platform, because that seems like the design most likely to get cross-platform buy-in. Trying to implement it as some sort of consensus metadata format for repositories for each distro's package manager seems like a very difficult approach, to me - what I think third parties and users *both* really want is the ability to deploy the _same_ bundle via the _same_ channel on multiple distributions. Like I said, very simply, something like Steam, or pip. The distributors don't want to have to build packages for Fedora and Ubuntu and Arch and distro-flavour-of-the-week, and the users are probably better served if this experience is the same across distributions - it's kind of much better, in a way, for the Official Way To Install Chrome On Linux to just be 'set up 3rdPartyPlatform however your distro chooses to do that, then follow these common instructions that are the same for everyone', rather than having different instructions for every distro.
So the fact that I've always conceived this as a cross-distro secondary distribution platform had the effect, in my head, of solving the 'bright line' problem, and so it didn't really become an issue.
On Fri, Jan 24, 2014 at 1:49 PM, Adam Williamson awilliam@redhat.com wrote:
The practical suggestion I find most interesting is a *cross-distribution* infrastructure/platform for the provision and distribution of third-party software, quite simply. My take is that the fact there's nothing like this that all or at least most of the major vendors agree on is much more of a problem for both users and distributors of third party stuff than any single distro's exact perspective on how far it should isolate itself from third-party bits. As we've already gone over, I don't think the degree of isolation from third-party bits that Fedora currently insists on is so great as to form a major barrier *in itself*.
<snip NVIDIA>
My point there is that we should probably think harder about the Chrome/Flash/whatever case - the case of things that are basically 'apps' sitting quite lightly on top of the distribution 'platform' - than the tricky NVIDIA case, which is kind of a special one and requires special handling. For the 'app' case, I really think that having a *single* distribution platform for all the major distros would make everyone's life a lot easier, and would not be hard at all to reconcile with Fedora's fundamental principles - we just have to isolate access to that platform to whatever degree is agreed to meet our principles, and I think we're all agreed that that degree doesn't need to be *excessively* onerous, just enough to keep Fedora's principles clear and the separation of responsibility clear.
Of course, this requires both building the infrastructure/framework and the distributions committing to *some* kind of platform that the third party distributors can rely on - even if it's as basic as 'we'll give you glibc and an input layer and ALSA/PulseAudio and maybe we'll commit to a couple of toolkits being available, anything else you can bundle yourself or manage the cross-distro compatibility some other way'. But, at least IMHO, that's the approach that provides the best payback. It's already what happens, in effect - most third party distributors don't build tweaked and tested packages for all distros, they just build a huge static bundle on top of glibc and ship it in a tarball (or a 'dumb' RPM/DEB package which doesn't really use any distro dependencies, it's just being used as a container). But we don't have a nice neat distribution platform for their tarballs/dumb RPM or DEB packages, so users have to go out and find them in a dozen different locations, and there's lots of silliness in how they work probably because all the distros aren't getting together and providing some simple groundwork and rules.
If we just had a nice Software/Steam-ish platform where you'd know all the major third-party stuff was available, with a decent interface and screenshots and reviews and all that gumph that's the current vogue, it'd be a much nicer experience, even if ultimately what you got was the same big static bundle you get from a tarball/dumb package today.
So if one were to go to all of the infrastructure work and cross-distro collaboration and get vendor buy-in, would you view that single "platform" (or AppStore or whatever) as something that a Fedora software installer could point to and include in searches done in the software installer?
josh
On Fri, Jan 24, 2014 at 11:48 AM, Richard Hughes hughsient@gmail.com wrote:
On 24 January 2014 10:39, Christian Schaller cschalle@redhat.com wrote:
Yeah, for the installer it will be a bit hard to proceed atm, but there are of course a lot of other aspects to the PRD we can flesh out.
Sure. Given we're so close to the UI freeze for F21 [...]
Are we? We don't even have a schedule. Anyway as I understand the board any such tool should not be specifically designed to find non free software but be more generic "find software we do not ship".
On 24 January 2014 10:58, drago01 drago01@gmail.com wrote:
Are we? We don't even have a schedule.
Sorry, I was under the impression we were shipping GNOME 3.12 in Fedora 21 and following the pattern. If that's not the case, apologies.
Anyway as I understand the board any such tool should not be specifically designed to find non free software but be more generic "find software we do not ship".
I don't understand that at all. Shouldn't a software center be designed to install software, no matter what the origin? If we're making the user jump through hoops because of some Fedora policy, it's probably a good idea to state that explicitly, as I'm really confused by all the subtle meanings in the above sentence.
Richard.
On Fri, Jan 24, 2014 at 6:04 AM, Richard Hughes hughsient@gmail.com wrote:
On 24 January 2014 10:58, drago01 drago01@gmail.com wrote:
Are we? We don't even have a schedule.
Sorry, I was under the impression we were shipping GNOME 3.12 in Fedora 21 and following the pattern. If that's not the case, apologies.
For lack of any other plan, that might as well be the target at the moment. The only thing we know about schedule is that F21 will not ship before August.
Anyway as I understand the board any such tool should not be specifically designed to find non free software but be more generic "find software we do not ship".
I don't understand that at all. Shouldn't a software center be designed to install software, no matter what the origin? If we're
Yes. Which is what the Board is saying. It's saying you cannot know where to look for, or display by default, non-free software. So no links or .repo files to e.g. flash-plugin. It's also saying that if a user explicitly searches for something, then it's possible to have the installer make it easier for them to get after they've made an informed choice. Call that informed choice a "3rd party warning splash screen" or something.
making the user jump through hoops because of some Fedora policy, it's probably a good idea to state that explicitly, as I'm really confused by all the subtle meanings in the above sentence.
In short: no known locations/links/repo files to 3rd party software, informative messaging before allowing installation if a search is done.
Hopefully that clears things up. If not, please email the advisory-board list for further clarification.
josh
----- Original Message -----
From: "Josh Boyer" jwboyer@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, January 24, 2014 1:30:52 PM Subject: Re: Fedora board vote and way forward
On Fri, Jan 24, 2014 at 6:04 AM, Richard Hughes hughsient@gmail.com wrote:
On 24 January 2014 10:58, drago01 drago01@gmail.com wrote:
Are we? We don't even have a schedule.
Sorry, I was under the impression we were shipping GNOME 3.12 in Fedora 21 and following the pattern. If that's not the case, apologies.
For lack of any other plan, that might as well be the target at the moment. The only thing we know about schedule is that F21 will not ship before August.
Anyway as I understand the board any such tool should not be specifically designed to find non free software but be more generic "find software we do not ship".
I don't understand that at all. Shouldn't a software center be designed to install software, no matter what the origin? If we're
Yes. Which is what the Board is saying. It's saying you cannot know where to look for, or display by default, non-free software. So no links or .repo files to e.g. flash-plugin. It's also saying that if a user explicitly searches for something, then it's possible to have the installer make it easier for them to get after they've made an informed choice. Call that informed choice a "3rd party warning splash screen" or something.
Well we have never done that before so I don't see any point in starting now. Educating users as part of an integrated install is one thing, but starting to pop up educational messages when people download software through the browser is getting beyond crazy.
The way I see it is that once we have 'outsourced' access to 3rd party software to said 3rd parties and their websites it is no longer our business what messaging comes along with that software. It is not like we display warning messages today when you do 'yum update' from 3rd party repostories.
Christian
On Fri, Jan 24, 2014 at 8:12 AM, Christian Schaller cschalle@redhat.com wrote:
----- Original Message -----
From: "Josh Boyer" jwboyer@fedoraproject.org To: "Discussions about development for the Fedora desktop" desktop@lists.fedoraproject.org Sent: Friday, January 24, 2014 1:30:52 PM Subject: Re: Fedora board vote and way forward
On Fri, Jan 24, 2014 at 6:04 AM, Richard Hughes hughsient@gmail.com wrote:
On 24 January 2014 10:58, drago01 drago01@gmail.com wrote:
Are we? We don't even have a schedule.
Sorry, I was under the impression we were shipping GNOME 3.12 in Fedora 21 and following the pattern. If that's not the case, apologies.
For lack of any other plan, that might as well be the target at the moment. The only thing we know about schedule is that F21 will not ship before August.
Anyway as I understand the board any such tool should not be specifically designed to find non free software but be more generic "find software we do not ship".
I don't understand that at all. Shouldn't a software center be designed to install software, no matter what the origin? If we're
Yes. Which is what the Board is saying. It's saying you cannot know where to look for, or display by default, non-free software. So no links or .repo files to e.g. flash-plugin. It's also saying that if a user explicitly searches for something, then it's possible to have the installer make it easier for them to get after they've made an informed choice. Call that informed choice a "3rd party warning splash screen" or something.
Well we have never done that before so I don't see any point in starting now. Educating users as part of an integrated install is one thing, but starting to pop up educational messages when people download software through the browser is getting beyond crazy.
I was thinking software-center, not browser, but as you've pointed out the difference between them in this specific instance is rather small.
The way I see it is that once we have 'outsourced' access to 3rd party software to said 3rd parties and their websites it is no longer our business what messaging comes along with that software. It is not like we display warning messages today when you do 'yum update' from 3rd party repostories.
True. And looking over the second item passed by the Board about reducing technical barriers, I see that the "informed" part was removed. I had forgotten that, so my apologies. It was a long meeting.
josh
On 24 January 2014 12:30, Josh Boyer jwboyer@fedoraproject.org wrote:
In short: no known locations/links/repo files to 3rd party software, informative messaging before allowing installation if a search is done. Hopefully that clears things up.
That's not clear at all. So if the user searches for "chrome" in the software center, are we allowed to show them a link to the Google Chrome website? If so, how do we know what the website URL is if we can't store it somewhere?
This sounds more and more like installing non-free software is going to be impossible unless some compromises are made.
Richard.
On Fri, Jan 24, 2014 at 02:03:18PM +0000, Richard Hughes wrote:
On 24 January 2014 12:30, Josh Boyer jwboyer@fedoraproject.org wrote:
In short: no known locations/links/repo files to 3rd party software, informative messaging before allowing installation if a search is done. Hopefully that clears things up.
That's not clear at all. So if the user searches for "chrome" in the software center, are we allowed to show them a link to the Google Chrome website?
Not unless the user has already added the Chrome repository.
On 24 January 2014 14:28, Matthew Garrett mjg59@srcf.ucam.org wrote:
Not unless the user has already added the Chrome repository.
So if gnome-software supported YMP files http://en.opensuse.org/openSUSE:One_Click_Install_ISV that would be okay for FESCo? Of course, that would mean convincing all the non-free upstreams to add an extra file, as well as the traditional semi-static-binary-plus-repo.rpm file.
I'm not sure it makes it any easier from an end user point of view, and I'm sure it makes it a lot less safe. Imagine some random person posting a malicious ymp file in fedoraforum.org which gets picked up by google for some common search words and users haplessly click on it without reading the XML or verifying the URL. In that case it might just be safer for users to search for chrome on google, get directed to http://www.google.com/chrome and then they can click the .rpm file there.
Which is the point we're at now. What FESCo has effectively said is "what we have now is fine", and we have a declining userbase that says otherwise.
Richard.
On Fri, Jan 24, 2014 at 02:38:44PM +0000, Richard Hughes wrote:
On 24 January 2014 14:28, Matthew Garrett mjg59@srcf.ucam.org wrote:
Not unless the user has already added the Chrome repository.
So if gnome-software supported YMP files http://en.opensuse.org/openSUSE:One_Click_Install_ISV that would be okay for FESCo? Of course, that would mean convincing all the non-free upstreams to add an extra file, as well as the traditional semi-static-binary-plus-repo.rpm file.
That would seem fine, yes.
I'm not sure it makes it any easier from an end user point of view, and I'm sure it makes it a lot less safe. Imagine some random person posting a malicious ymp file in fedoraforum.org which gets picked up by google for some common search words and users haplessly click on it without reading the XML or verifying the URL. In that case it might just be safer for users to search for chrome on google, get directed to http://www.google.com/chrome and then they can click the .rpm file there.
We can't curate a list of "safe" repositories in any meaningful way - we simply don't have the infrastructure to do so. There are existing mechanisms that could be used (require the XML to be signed with an EV certificate, for instance) which would act as significant impediments to random people spoofing genuine repositories.
Which is the point we're at now. What FESCo has effectively said is "what we have now is fine", and we have a declining userbase that says otherwise.
The example you've used is Chrome. Chrome is not present in the Windows Store. Chrome is not present in the Mac App Store. Users are forced to manually download it from Google. This doesn't seem to be hurting their popularity.
There are multiple issues with Fedora. The degree of technical churn means it's difficult for us to apply polish to certain aspects of the system. We do things like push stable updates that break systems. We fail to follow through on development efforts that distinguish us from the competition. We're bad at making a product. Ascribing any decline in userbase to "It's difficult for users to install Chrome or Skype" isn't helpful - maybe it's true, but there's so many other things that could also be turning users away that it's impossible to tell.
When we're faced with a bunch of problems, let's concentrate on the problems that don't require us to compromise our pinciples. This longer release cycle gives us the opportunity to fix a lot of the things that are fundamentally wrong with Fedora. It'd be a shame to see that opportunity wasted because we're fixated on one issue.
On Fri, Jan 24, 2014 at 02:38:44PM +0000, Richard Hughes wrote:
okay for FESCo? Of course, that would mean convincing all the non-free upstreams to add an extra file, as well as the traditional semi-static-binary-plus-repo.rpm file.
Well, hopefully any work in that direction is not solely targeted at making life better for proprietary vendors but also be useful to anyone else trying to ship software for Fedora.
Which is the point we're at now. What FESCo has effectively said is "what we have now is fine", and we have a declining userbase that says otherwise.
Do we have any data that shows that the declining number of users has anything to do with less-then-perfect accessibility of proprietary software?
On Fri, 2014-01-24 at 14:03 +0000, Richard Hughes wrote:
On 24 January 2014 12:30, Josh Boyer jwboyer@fedoraproject.org wrote:
In short: no known locations/links/repo files to 3rd party software, informative messaging before allowing installation if a search is done. Hopefully that clears things up.
That's not clear at all. So if the user searches for "chrome" in the software center, are we allowed to show them a link to the Google Chrome website? If so, how do we know what the website URL is if we can't store it somewhere?
This sounds more and more like installing non-free software is going to be impossible unless some compromises are made.
There is a fundamental difference between the user searching for the software *in the Fedora software center* and having it offered to them and them searching for it *on the internet* and finding it.
The former comes with a clear implication that 'this content is Fedora-approved'. It's come from a Fedora application, after all. This principle is, so far as I can tell, universally recognized: every software vendor that offers an app store of some kind has implicitly acknowledged that they 'stand behind' said app store to some extent, by tending it. Apple tends its app store notoriously heavily - and, of course, Apple is right up there at the top of the charts in terms of knowing what its users consider it 'responsible' for and what they don't - but even Google tends the Android app store more than many people realize, partly for purely selfish reasons but also partly for 'self-defense' reasons, because it recognizes this principle that by making software accessible from something which it is clearly responsible for, it becomes responsible for that software. I'm not suggesting you're not willing to do this 'tending', I'm making a larger point: by making software available through our 'app store' we send a message that we stand behind that software, and Fedora does *not* stand behind non-free software.
I keep seeing the idea of 'search for software in Software' and 'search for software on the web' discussed as if they were almost identical, but they absolutely are not.
To make it crystal clear: I see a huge difference both in principle and practice between 'user searches for Chrome in Software, finds Chrome, maybe clicks through a disclaimer they entirely ignore, installs Chrome' and 'user searches for "Chrome Linux" or "Chrome Fedora" on the Web, finds a page not maintained by Fedora, clicks a link, and Chrome is now available through the packaging system'.
On Fri, 2014-01-24 at 09:24 -0800, Adam Williamson wrote:
To make it crystal clear: I see a huge difference both in principle and practice between 'user searches for Chrome in Software, finds Chrome, maybe clicks through a disclaimer they entirely ignore, installs Chrome' and 'user searches for "Chrome Linux" or "Chrome Fedora" on the Web, finds a page not maintained by Fedora, clicks a link, and Chrome is now available through the packaging system'.
*sigh* and to clarify further - I'm not saying in my opinion the user always has to go through some kind of random web search process to find stuff, I'm just saying that one of those approaches clearly maintains the Fedora/not-Fedora distinction, while the other doesn't. Any approach that clearly maintains that distinction is fine for me.
Adam Williamson (awilliam@redhat.com) said:
suggesting you're not willing to do this 'tending', I'm making a larger point: by making software available through our 'app store' we send a message that we stand behind that software, and Fedora does *not* stand behind non-free software.
s/non-free/third-party/.
When it comes to installing Stuff From The Greater Interwebs, I don't see the difference in how we deal with a user who installed the nVidia driver and their system exploded vs. a user who installed a Python3 RPM with python3 as /usr/bin/python and their system exploded.
Bill
On Fri, 2014-01-24 at 17:06 -0500, Bill Nottingham wrote:
Adam Williamson (awilliam@redhat.com) said:
suggesting you're not willing to do this 'tending', I'm making a larger point: by making software available through our 'app store' we send a message that we stand behind that software, and Fedora does *not* stand behind non-free software.
s/non-free/third-party/.
When it comes to installing Stuff From The Greater Interwebs, I don't see the difference in how we deal with a user who installed the nVidia driver and their system exploded vs. a user who installed a Python3 RPM with python3 as /usr/bin/python and their system exploded.
True, in that instance you can make the substitution.
----- Original Message -----
On Fri, Jan 24, 2014 at 6:04 AM, Richard Hughes hughsient@gmail.com wrote:
On 24 January 2014 10:58, drago01 drago01@gmail.com wrote:
Are we? We don't even have a schedule.
Sorry, I was under the impression we were shipping GNOME 3.12 in Fedora 21 and following the pattern. If that's not the case, apologies.
For lack of any other plan, that might as well be the target at the moment. The only thing we know about schedule is that F21 will not ship before August.
Anyway as I understand the board any such tool should not be specifically designed to find non free software but be more generic "find software we do not ship".
I don't understand that at all. Shouldn't a software center be designed to install software, no matter what the origin? If we're
Yes. Which is what the Board is saying. It's saying you cannot know where to look for, or display by default, non-free software. So no links or .repo files to e.g. flash-plugin. It's also saying that if a user explicitly searches for something, then it's possible to have the installer make it easier for them to get after they've made an informed choice. Call that informed choice a "3rd party warning splash screen" or something.
making the user jump through hoops because of some Fedora policy, it's probably a good idea to state that explicitly, as I'm really confused by all the subtle meanings in the above sentence.
In short: no known locations/links/repo files to 3rd party software, informative messaging before allowing installation if a search is done.
For me, search before acceptance is offending thing and on the other hand with user's consent I'd be ok with locations/links and repo files.
That's why I voted -1 as I think there is space compromise... Without playing with words ;-), inventing services to rule the world etc.
Same was Rex. We both want opt-in - you as users allows 3rd party sources (with strong messaging why you should not do it), then searches, installation works out of box. I think it goes with our values - let user choose his way but does not taint search results with proprietary software if they don't want.
It could be one checkbox (install time, initial setup time, first run of app, np).
But from discussion it seems like the Board and GNOME team do not like it at all (mjg and mclasen expressed it's no go).
Jaroslav
Hopefully that clears things up. If not, please email the advisory-board list for further clarification.
josh
desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Fri, Jan 24, 2014 at 11:04:42AM +0000, Richard Hughes wrote:
Are we? We don't even have a schedule.
Sorry, I was under the impression we were shipping GNOME 3.12 in Fedora 21 and following the pattern. If that's not the case, apologies.
We've promised QA and Rel Eng that August is earliest. I don't know if that means we'll skip a Gnome release entirely or what. Post F21, getting back to better alignment with the Gnome schedule seems useful. We had been kind of drifting away from that anyway.
In the future, this might mean that cloud/server/workstation end up on different schedules, but that's going to take a lot of coordinated planning.
On Fri, 2014-01-24 at 09:57 -0500, Matthew Miller wrote:
We've promised QA and Rel Eng that August is earliest. I don't know if that means we'll skip a Gnome release entirely or what. Post F21, getting back to better alignment with the Gnome schedule seems useful. We had been kind of drifting away from that anyway.
Why wait until after F21 to get back in sync with GNOME? Let's target F21 Workstation for late October and ship GNOME 3.14.
----- Original Message -----
On Fri, Jan 24, 2014 at 11:04:42AM +0000, Richard Hughes wrote:
Are we? We don't even have a schedule.
Sorry, I was under the impression we were shipping GNOME 3.12 in Fedora 21 and following the pattern. If that's not the case, apologies.
We've promised QA and Rel Eng that August is earliest. I don't know if that means we'll skip a Gnome release entirely or what. Post F21, getting back to better alignment with the Gnome schedule seems useful. We had been kind of drifting away from that anyway.
Btw. any input on scheduling from WGs appreciated - we need to know how much time is needed but for F21, it's going to be compromise based on WGs and other teams needs. GNOME schedule was always part of initial schedule but not the only part - especially with the way how we try to plan releases some flexibility is needed.
In the future, this might mean that cloud/server/workstation end up on different schedules, but that's going to take a lot of coordinated planning.
Yes, with products, Fedora at itself is not GNOME only thing and this could let WGs to adjust schedules. But it's not only about coordination but also tooling and automation to allow multiple release out of sync. It's pain to release two pretty much well-defined releases now.
Could you please draft the schedule overlap with GNOME release for F21, as an initial point we can take a look? I can't promise anything but...
Jaroslav
-- Matthew Miller -- Fedora Project -- mattdm@fedoraproject.org -- desktop mailing list desktop@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/desktop
On Fri, Jan 24, 2014 at 5:32 AM, Richard Hughes hughsient@gmail.com wrote:
On 24 January 2014 10:18, Christian Schaller cschalle@redhat.com wrote:
...writing up a technical specification of the product...
I think this is going to be hard until we know more about the legal side of things and what we're allowed to do. From my point of view, if we can ship a google-chrome.repo file that's disabled and some pre-prepared appstream metadata, it makes building the required functionality in gnome-software quite easy. We can show the non-free applications, and if the user clicks install we just need to show some kind of agreement, download the metadata and then install the application.
The Board decision disallows this.
If we can't ship the AppStream metadata or the disabled repo file then we need some way of querying for search terms, for instance calling out to a webservice on apps.fedoraproject.org that returns results for a search term of "chrome" -- this will also need to return icons, perhaps screenshots, and also some repo parameters and possible EULA text. This would be possible to implement in a gnome-software plugin and a chunk of new functionality in PackageKit, and would also need a new webservice. So again, possible, just a little harder to implement.
This is something that could be allowable, yes. Bill Nottingham came up with a similar cross-distro style service idea that is of course much broader, but might be easier to get vendors to participate in.
josh
On Fri, Jan 24, 2014 at 10:32:41AM +0000, Richard Hughes wrote:
If we can't ship the AppStream metadata or the disabled repo file then we need some way of querying for search terms, for instance calling out to a webservice on apps.fedoraproject.org that returns results for a search term of "chrome" -- this will also need to return icons, perhaps screenshots, and also some repo parameters and possible EULA text. This would be possible to implement in a gnome-software plugin and a chunk of new functionality in PackageKit, and would also need a new webservice. So again, possible, just a little harder to implement.
I don't believe that this would be in line with the spirit of the board's decision.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Bastien Nocera -
Bill Nottingham -
Bruno Wolff III -
Christian Schaller -
drago01 -
Elad Alfassa -
Jaroslav Reznik -
Josh Boyer -
Lars Seipel -
Matthew Garrett -
Matthew Miller -
Michael Catanzaro -
Rahul Sundaram -
Richard Hughes