Re: Draft Product Description for Fedora Workstation
On Wed, Nov 06, 2013 at 02:45:46PM -0500, Rahul Sundaram wrote: I don't really have a problem in believing that but it would be useful to know in more detail how the initial proposals came to be (who were involved? what problems are we trying to solve? what are failures of the current model? did it go through Red Hat management internally before being proposed and is more headcount being allotted? Was Fedora Board and FESCo members aware that a proposal were coming through and what was their rationale for choosing to go forward? etc) Did you see my message in July before Flock, and my talk there? http://www.youtube.com/watch?v=K4dNP9DiaXc - if this link is broken it's because I'm on the train and yourube is blocked https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html http://mattdm.org/fedora/next/ And I think that answers most of your questions, or at least provides a starting point for them. Overall, the process is basically what you see in public and I've tried to make this as transparent as possible. I did discuss the idea with my manager (Denise Dumas, Director of Platform Engineering) to make sure she would support me in spending time developing it. She has promised (including to everyone at Flock) to provide resources where we can make a good case for them (and I think we can!). I also talked with a few people both inside and outside of Red Hat to help adjust the initial presentation and message, and I presented it to get feedback from a handful of groups internally before Flock. Mostly, though, there was very little that you can't see on this and other mailing lists and in Fedora IRC logs. The part about three products came from Stephen Gallagher at Flock, and he can take both credit and blame for that :). To me, that provides a practical answer to how do we deliver something out of these policy rings I proposed, which was kind of a missing piece so I went with it. If you have solutions to other missing pieces I'll back those too. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Hi On Sat, Nov 9, 2013 at 3:36 PM, Matthew Miller wrote: I did discuss the idea with my manager (Denise Dumas, Director of Platform Engineering) to make sure she would support me in spending time developing it. She has promised (including to everyone at Flock) to provide resources where we can make a good case for them (and I think we can!). I also talked with a few people both inside and outside of Red Hat to help adjust the initial presentation and message, and I presented it to get feedback from a handful of groups internally before Flock. Mostly, though, there was very little that you can't see on this and other mailing lists and in Fedora IRC logs. These are the key parts that I wanted to confirm. Thanks. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
tor 2013-11-07 klockan 09:14 + skrev Peter Robinson: I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. Just so that my silence is not counted as approval. I disapprove. Mattias smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote: On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote: Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Well, the most relevant bit is that they use apparmor for sandboxing. Nobody else uses that. Are the packages expected to ship their own apparmor policy? That would appear to be at odds with the idea of protecting against malicious packages. If they aren't expected to ship their own, could we implement the same sandboxing policy using SELinux? (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu will be using some higher-level profile format, not raw AppArmor.) The whole plan is here : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement Looking at : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest I would say no. From a quick look, some abstraction are quite apparmor specific, see the concept of read_path, which is something we can hardly translate to selinux ( since apparmor use path, while selinux use a 2 tier system with label assigned to path, and then privileges assigned based on label ). What we could do is to have a better abstraction that would be apparmor and selinux comptaible. Since despites what Lennart claim, AppArmor is also used by Opensuse. And I am sure people using smackd ( such as intel people ) would be delighted to not be left in the cold. SELinux is still pretty RH/Fedora specific, even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to support it that well ). And I don't think it is a good idea to use .deb as an image format. .deb is just an ar archive; if this were the only difference, it would not be worth fragmenting the ecosystem over IMHO. (Especially if the GNOME apps alternative is a compressed disk image, which saves disk space and costs extra CPU time and memory, making exactly the wrong tradeoff in most situations AFAICS.) While I do not see any obvious problem into using deb, I do not think it will bring much gain. It will matter for people managing the low level format, ie few people. Reusing the manifests ( if it was doable ) would have yield much more gain. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Michael scherer wrote: SELinux is still pretty RH/Fedora specific, even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to support it that well ). Millions of Android devices now have SELinux. Android 4.3 enabled SELinux and defaults to Permissive. Android 4.4 defaults to Enforcing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 06, 2013 at 02:45:46PM -0500, Rahul Sundaram wrote: Hi On Wed, Nov 6, 2013 at 2:38 PM, Adam Williamson wrote: I'm still slightly out of sync with the fedora.next stuff (REALLY picked a bad time to go on vacation), but it does seem to me that a decent amount of 'mature reflection' was done on it before it was approved, at least. I don't really have a problem in believing that but it would be useful to know in more detail how the initial proposals came to be (who were involved? what problems are we trying to solve? what are failures of the current model? did it go through Red Hat management internally before being proposed and is more headcount being allotted? Was Fedora Board and FESCo members aware that a proposal were coming through and what was their rationale for choosing to go forward? etc) I suspect Mattew discussed this around him before, as anything anyone would propose. Would chatting with Spot on IRC count as going with Red Hat management, or just 2 community member talking together ? Because the outcome would be the same. But the The proposal was discussed IRL during Flock, the proposal was discussed here before[1] and got lot of feedback, the proposal was checked by Board[3] , by FESCO[2]. And I think this was in line with the discussion on the whole product or platform on the Board mailling list, who was started by the user base discussion initiated by Robyn [4]. So it all boil down to thing have changed, and so we think we should also do some changes, for all those reasons. [1] https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html [2] https://fedorahosted.org/fesco/ticket/1158 [3] https://fedoraproject.org/wiki/Fedora.next/boardproposal [4] http://wordshack.wordpress.com/2013/04/04/board-meeting-topic-for-the-day-user-base-aka-target-audience/ -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Fri, 2013-11-08 at 08:37 -0600, Michael Cronenworth wrote: Michael scherer wrote: SELinux is still pretty RH/Fedora specific, even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to support it that well ). Millions of Android devices now have SELinux. Android 4.3 enabled SELinux and defaults to Permissive. Android 4.4 defaults to Enforcing. *can't quite believe this is the first he's read about this* -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Fri, Nov 8, 2013 at 2:31 PM, Michael scherer m...@zarb.org wrote: On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote: On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote: Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Well, the most relevant bit is that they use apparmor for sandboxing. Nobody else uses that. Are the packages expected to ship their own apparmor policy? That would appear to be at odds with the idea of protecting against malicious packages. If they aren't expected to ship their own, could we implement the same sandboxing policy using SELinux? (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu will be using some higher-level profile format, not raw AppArmor.) The whole plan is here : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement Looking at : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest I would say no. From a quick look, some abstraction are quite apparmor specific, see the concept of read_path, which is something we can hardly translate to selinux ( since apparmor use path, while selinux use a 2 tier system with label assigned to path, and then privileges assigned based on label ). Yes, that's one thing that we cannot (and shouldn't) support, but read_path is listed in the Red-flagged for manual review (use should actively be discouraged with updates made to policy groups and templates) section; is it likely to be frequently used? Mirek What we could do is to have a better abstraction that would be apparmor and selinux comptaible. Since despites what Lennart claim, AppArmor is also used by Opensuse. And I am sure people using smackd ( such as intel people ) would be delighted to not be left in the cold. SELinux is still pretty RH/Fedora specific, even if Debian and gentoo support it in theory ( in practice, Debian didn't seems to support it that well ). And I don't think it is a good idea to use .deb as an image format. .deb is just an ar archive; if this were the only difference, it would not be worth fragmenting the ecosystem over IMHO. (Especially if the GNOME apps alternative is a compressed disk image, which saves disk space and costs extra CPU time and memory, making exactly the wrong tradeoff in most situations AFAICS.) While I do not see any obvious problem into using deb, I do not think it will bring much gain. It will matter for people managing the low level format, ie few people. Reusing the manifests ( if it was doable ) would have yield much more gain. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le vendredi 08 novembre 2013 à 21:24 +0100, Miloslav Trmač a écrit : On Fri, Nov 8, 2013 at 2:31 PM, Michael scherer m...@zarb.org wrote: On Thu, Nov 07, 2013 at 09:55:12PM +0100, Miloslav Trmač wrote: On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote: Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Well, the most relevant bit is that they use apparmor for sandboxing. Nobody else uses that. Are the packages expected to ship their own apparmor policy? That would appear to be at odds with the idea of protecting against malicious packages. If they aren't expected to ship their own, could we implement the same sandboxing policy using SELinux? (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu will be using some higher-level profile format, not raw AppArmor.) The whole plan is here : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement Looking at : https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest I would say no. From a quick look, some abstraction are quite apparmor specific, see the concept of read_path, which is something we can hardly translate to selinux ( since apparmor use path, while selinux use a 2 tier system with label assigned to path, and then privileges assigned based on label ). Yes, that's one thing that we cannot (and shouldn't) support, but read_path is listed in the Red-flagged for manual review (use should actively be discouraged with updates made to policy groups and templates) section; is it likely to be frequently used? I can imagine that for any application having some kind of private database ( like a list of music file, save for games, or scoreboard, etc ), this would be used. So yeah, not much, but not that uncommon either IMHO. But even on the others fields, there will be some issues like the need to keep the policy in sync ( for policy_groups ), and the need to keep the template in sync (as the system work by taking template to generate the policy). Keep in sync the content and the name. It could be doable to adapt, but I am quite sure that sooner or later, we will face problem to keep the SElinux and AppArmor policies in sync, due to the difference of approach. I also expect that a conversion wouldn't be straightforward due to different stacks, etc. I do not really see that as a sustainable approach. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 7, 2013 at 3:41 AM, Kevin Kofler kevin.kof...@chello.at wrote: Olav Vitters wrote: The definition given by Frank Murphy is totally different and doesn't align with above. Above also doesn't relate to developers. These align a lot with what I wrote though. :-) http://en.wiktionary.org/wiki/power_user http://en.wikipedia.org/wiki/Power_user No it doesn't if you go by them a developer is not a power user and neither of those really match your definition either. So you all proved that is a meaningless term (i.e buzzword). So can we go back to use proper use case definitions? I need X because I am a power user makes no sense at all. I need X because it helps me do . is way better to work with. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On 7 Nov 2013 03:05, Kevin Kofler kevin.kof...@chello.at wrote: Josh Boyer wrote: What you say makes some sense. It also makes me very tired thinking about the threads coming when the details start getting presented by the WGs :). I guess that's what we've signed up for though. Well yes, each time you try to force a change through which actually makes things worse, there WILL be resistance. In fact, this is already what is happening in this thread, the app proposal coming from (parts of) the Workstation WG. I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. There's certainly no proof that it'll make anything worse. That doesn't mean its going to be perfect or without teething problems as the changes are made and things settle down. The fact that you don't like change or don't understand it means that you shouldn't try and project your opinion as that of the general community. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On 7 Nov 2013 03:20, Kevin Kofler kevin.kof...@chello.at wrote: Olav Vitters wrote: On Wed, Nov 06, 2013 at 01:00:16AM +0100, Kevin Kofler wrote: Bastien Nocera wrote: Might not want to put answers in people's mouths. Did you read up on the various bundling techniques that were explored and the API/ABI guarantees we want to offer? I'll stop short of paraphrasing you. The fact that bundling is even being explored as a technique at all makes me puke! That's offtopic. How is pointing out a fundamental unfixable flaw in the approach you are advocating off topic? Just because you can't see a way to fix it doesn't mean its either unfixable or that there aren't people willing to step up to do so. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Fri, 01 Nov 2013 10:24:20 -0400 Christian Fredrik Kalager Schaller cscha...@redhat.com wrote: Will the other DE's still exist after workstation Will a dev be able to use Xfce, Lxde as graphical choice. What would encourage say an xubuntu dev //* devs are still users */ working on foo, to switch to Fedora Workstation? -- Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. If you want to discuss GNOME, we also have a development list, see https://mail.gnome.org/mailman/listinfo/desktop-devel-list. A bit more logical to include people who actually work on this and less annoying to people who don't want to discuss other distributions on the Fedora mailing list. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 04:01:09AM +0100, Kevin Kofler wrote: Well yes, each time you try to force a change through which actually makes things worse, there WILL be resistance. In fact, this is already what is happening in this thread, the app proposal coming from (parts of) the Workstation WG. That you see a proposal as forcing things through is unfortunate. But I don't see much resistance, there are concerns and sometimes voiced in a strange way, but that's pretty much it. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 03:50:59AM +0100, Kevin Kofler wrote: Olav Vitters wrote: On Wed, Nov 06, 2013 at 01:00:16AM +0100, Kevin Kofler wrote: Bastien Nocera wrote: Might not want to put answers in people's mouths. Did you read up on the various bundling techniques that were explored and the API/ABI guarantees we want to offer? I'll stop short of paraphrasing you. The fact that bundling is even being explored as a technique at all makes me puke! That's offtopic. How is pointing out a fundamental unfixable flaw in the approach you are advocating off topic? You're pointing out that you want to puke. That's offtopic for this mailing list. I rather not know the amount of detail that you're displaying. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
2013/11/7 Olav Vitters o...@vitters.nl On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. I fail to see the point of discussing a feature that is meant to allow upstreams to provide installable bundles that work in all linuxes if it is only to work in Fedora. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, 7 Nov 2013 11:17:28 +0100 Olav Vitters o...@vitters.nl wrote: On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. If you want to discuss GNOME, we also have a development list, see https://mail.gnome.org/mailman/listinfo/desktop-devel-list. To be fair you introduced Guadec, aka Gnome developemt. (I'm not pro\anti Gnome) A bit more logical to include people who actually work on this and less annoying to people who don't want to discuss other distributions on the Fedora mailing list. May it be loosely to cover target audience, Why are they using distro X, is what the wg is doing going to win them over? -- Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Kevin, On Thu, 2013-11-07 at 04:12 +0100, Kevin Kofler wrote: So where's the strawman? please stop with this. Simo wrote a rather long email post and argued he's view on users' freedom and all you did in reply was to nitpick on a footnote. Or in Simo's words again: On Tue, 2013-11-05 at 23:12 -0500, Simo Sorce wrote: If this is all you have to say about what I wrote (strawman on a note and ignore completely the rest) you have nothing valid to say in this discussion. Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On 11/06/2013 11:30 PM, Olav Vitters wrote: On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote: Has this sanboxed-bundled-from-upstream proposal been discussed with other distributions? If the final result is that the Universal Linux Package only works in Fedora we are not gaining anything. A lot of this is being based on technology that's not really available yet such as kdbus, Wayland, systemd bits. This has been discussed at GUADEC (GNOME conference): http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome Wayland and systemd strongly suggest no Ubuntu interoperability whatsoever. Shouldn't this be a top priority for bundled applications? -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
- Original Message - On 11/06/2013 11:30 PM, Olav Vitters wrote: On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote: Has this sanboxed-bundled-from-upstream proposal been discussed with other distributions? If the final result is that the Universal Linux Package only works in Fedora we are not gaining anything. A lot of this is being based on technology that's not really available yet such as kdbus, Wayland, systemd bits. This has been discussed at GUADEC (GNOME conference): http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome Wayland and systemd strongly suggest no Ubuntu interoperability whatsoever. Shouldn't this be a top priority for bundled applications? If we get any traction on this, their customers/users will ask them for it themselves. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le Mer 6 novembre 2013 19:24, Josh Boyer a écrit : I'm just having trouble wrapping my head around the intense focus on a new app packaging technology when the entire distro is making massive changes to how it's produced. Because all distributions can and do ship the same software and the main thing that differences distributions is attention to packaging. What build the Fedora brand is in huge part the hard work of packagers over the years and careful definition of packaging guidelines. There have been many people that claimed this process was awful in the past and their alternatives all sank. Mainly because they were addressing developer problems (freedom to take all the shortcuts that make integration hard and users miserable) and thought they would win marketshare this way (hint: you do not win marketshare by solving developer problems you win marketshare by solving user problems. Users always voted with their feet and rejected the developer-friendly solutions that made their own life harder). So what makes this initiative different? I guess that's because it promotes itself as making it possible to get software in Fedora, competing with and disparaging the work of packagers while hijacking the brand they helped building. Get this thing its own name. Let it win or lose user confidence on its own merit, and don't confuse users with in Fedora claims when you're absolutely *not* offering the same thing in Fedora means now. Right now this proposal has the potential to ruin user trust and become the same thorn nvidia drivers are for xorg and kernel people now. Of course people who build this trust do not like it. Is that clearer? Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le Jeu 7 novembre 2013 11:17, Olav Vitters a écrit : On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. If you want to discuss GNOME, we also have a development list, see https://mail.gnome.org/mailman/listinfo/desktop-devel-list. A bit more logical to include people who actually work on this and less annoying to people who don't want to discuss other distributions on the Fedora mailing list. I fail to see the point of discussing non-GNOME-specific problems on a GNOME development list. A bit more logical to include people who actually work on non-GNOME software and don't want to discuss non-GNOME app distribution on a GNOME list. Really, why do I have to write this at all? Fedora Workstation is not GNOME, that has already bee written in this thread. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 11:33:57AM +0100, Sergio Pascual wrote: 2013/11/7 Olav Vitters o...@vitters.nl On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. I fail to see the point of discussing a feature that is meant to allow upstreams to provide installable bundles that work in all linuxes if it is only to work in Fedora. I already talked about other distributions so your concern has been addressed already. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 02:28:09PM +0100, Nicolas Mailhot wrote: I fail to see the point of discussing non-GNOME-specific problems on a GNOME development list. A bit more logical to include people who actually work on non-GNOME software and don't want to discuss non-GNOME app distribution on a GNOME list. As mentioned, I said the interested people are on that mailing list. Anyway, if you want to discuss another distribution on Fedora mailing list, I think it is stupid and pointless, but that is just my opinion. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 10:45:29AM +, Frank Murphy wrote: On Thu, 7 Nov 2013 11:17:28 +0100 Olav Vitters o...@vitters.nl wrote: On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. If you want to discuss GNOME, we also have a development list, see https://mail.gnome.org/mailman/listinfo/desktop-devel-list. To be fair you introduced Guadec, aka Gnome developemt. (I'm not pro\anti Gnome) I explained that this thought has been discussed and introduced at a conference. If people cannot the mention of GNOME: not my problem. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 12:58:37PM +0100, Florian Weimer wrote: On 11/06/2013 11:30 PM, Olav Vitters wrote: On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote: Has this sanboxed-bundled-from-upstream proposal been discussed with other distributions? If the final result is that the Universal Linux Package only works in Fedora we are not gaining anything. A lot of this is being based on technology that's not really available yet such as kdbus, Wayland, systemd bits. This has been discussed at GUADEC (GNOME conference): http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome Wayland and systemd strongly suggest no Ubuntu interoperability whatsoever. Shouldn't this be a top priority for bundled applications? Canonical does what Canonical wants to do. They already have their own solution for something like this. It is just very distribution specific and not as secure as what this is proposing AFAIK. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 7, 2013 at 8:20 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Mer 6 novembre 2013 19:24, Josh Boyer a écrit : I'm just having trouble wrapping my head around the intense focus on a new app packaging technology when the entire distro is making massive changes to how it's produced. Because all distributions can and do ship the same software and the main thing that differences distributions is attention to packaging. What build the Fedora brand is in huge part the hard work of packagers over the years and careful definition of packaging guidelines. I think you missed the point of my question. It might have been too subtle. It wasn't what is wrong with sandboxed/containerized apps?. See the follow ups. There have been many people that claimed this process was awful in the past and their alternatives all sank. Mainly because they were addressing developer problems (freedom to take all the shortcuts that make integration hard and users miserable) and thought they would win marketshare this way (hint: you do not win marketshare by solving developer problems you win marketshare by solving user problems. Users always voted with their feet and rejected the developer-friendly solutions that made their own life harder). Users want apps. Developers are increasingly not caring at all about distros. I think there's a middle ground to be had here. As I've said before, just saying this is bad without even thinking about if it has some positives and how it could work just seems shortsighted. So what makes this initiative different? I guess that's because it promotes itself as making it possible to get software in Fedora, competing with and disparaging the work of packagers while hijacking the brand they helped building. Get this thing its own name. Let it win or lose user confidence on its own merit, and don't confuse users with in Fedora claims when you're absolutely *not* offering the same thing in Fedora means now. And yet, now we have Coprs. Which lets people easily upload unreviewed, possibly bundled application SRPMs for easy distribution outside of the main Fedora repos. Everyone seems to think Coprs are awesome, but they can be used for the same things you deride containerized apps for. Right now this proposal has the potential to ruin user trust and become the same thorn nvidia drivers are for xorg and kernel people now. Of course people who build this trust do not like it. Is that clearer? No. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le Jeu 7 novembre 2013 14:57, Josh Boyer a écrit : And yet, now we have Coprs. Which lets people easily upload unreviewed, possibly bundled application SRPMs for easy distribution outside of the main Fedora repos. Everyone seems to think Coprs are awesome, but they can be used for the same things you deride containerized apps for. And Coprs have their own name. So they're doing exactly what I proposed. You didn't read my message -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 7, 2013 at 9:10 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Jeu 7 novembre 2013 14:57, Josh Boyer a écrit : And yet, now we have Coprs. Which lets people easily upload unreviewed, possibly bundled application SRPMs for easy distribution outside of the main Fedora repos. Everyone seems to think Coprs are awesome, but they can be used for the same things you deride containerized apps for. And Coprs have their own name. So they're doing exactly what I proposed. You didn't read my message Oh, I read it. I find it odd that we can have a tool with a name (Copr) that is officially part of the Fedora project and a tool without a name (containerized apps) that doesn't even exit yet that both solve similar issues and can be used in similar ways and somehow have the name being the only thing that makes it acceptable. So if we call containerized apps Appers and host it somewhere on Fedora infrastructure and tell people about it, you'd be totally OK with that? People seem to already be jumping to conclusions that Appers are going to somehow magically be THE WAY we deliver software, but yet nobody had the same thoughts around Coprs. The blinders involved here are pretty large. These things are tools. They aren't the end-all-be-all solution to software delivery. I just wish people would calm down and stop wasting so much energy fighting against something on grounds that aren't even with existing tools and before anyone even sees what it looks like. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le Jeu 7 novembre 2013 15:19, Josh Boyer a écrit : So if we call containerized apps Appers and host it somewhere on Fedora infrastructure and tell people about it, you'd be totally OK with that? I think that would remove a lot of the emotion in this thread. People seem to already be jumping to conclusions that Appers are going to somehow magically be THE WAY we deliver software, but yet nobody had the same thoughts around Coprs. Maybe that's because Coprs were never announced with huge rants about market-share and how Fedora packaging sucked and was irrelevant? The blinders involved here are pretty large. It's not blinders it's the natural reaction of people to tactless pronouncements and dismissals. I do wish the people complaining about this list focused more on technical aspects and less on hype or we-ll-decide-somewhere-else-even-though-it-concerns-you. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Peter Robinson wrote: I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. There's certainly no proof that it'll make anything worse. That doesn't mean its going to be perfect or without teething problems as the changes are made and things settle down. There's plenty of reasons why you haven't seen any negative feedback. I'll share my views on this subject since I'm in the not sure ballpark of this new process. Where's the benefit of creating a handful of workgroups that now have some sort of power over the distribution? After reading all of the emails in the past week I have yet to see any benefits of this Fedora.next process. I agree Fedora needs to continue to evolve, but this process appears to shake the foundations of Fedora. Specifics: Different kernels per product, app sandboxing (lib bundling). Will the DVD/Live ISOs currently created cease to exist F21+? Fragmentation of Fedora into Cloud/Workstation/Server products? I'm just randomly spitting out ideas in my head that come to mind, but you cannot expect that silence equates to agreement in your favor. It strikes me as odd at the large number of @redhat accounts and small number of non-@redhat accounts in favor of this new process. Who is in charge of evolving Fedora at this point? I do value Red Hat involvement, but I don't want the common myth of Fedora = Red Hat beta to become a fact. I'm still going to keep my ears open and attempt at digesting what this new idea is bringing to the table, but it hasn't sit well on my stomach so far. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Peter Robinson wrote: Just because you can't see a way to fix it doesn't mean its either unfixable or that there aren't people willing to step up to do so. It's not that I can't see a way to fix it, it's that I can see that there is no way! The whole system relies on bundling, so it is provably impossible to implement it without getting the nasty drawbacks of bundling. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Hi Frank, They will, although in some sense I am the wrong person to ask this question as it will be up to the people developing and packaging these DE's just like it is now. The difference from today here though will be that there will be some requirements for being available for the workstation as the PRD states. The main one here that I foresee is that you can't conflict in terms of library requirements or binary names with the standard desktop of the workstation. I don't think that has been a big problem historically so it will likely have minimal impact, but it is now going to be a formal requirement as the PRD currently stands. I expect there will be other requirements defined too, but I want to make it clear that the goals of these requirements is not to make it impossible or even hard to package alternative DEs for the workstation. But what it will mean is that for instance it will be 100% clear that the responsibility to stay available rests on the alternative DEs packagers and developers and not on the core product developers. Of course with this also comes extra responsibility of the Workstation working group to ensure that development plans are shared as early as possible, to give everyone a chance to port over in time (ref. the recent Bluez discussion). But it all comes back to what I mentioned in an earlier email. The 3 products is a attempt at moving from primarily packaging upstream projects, to having concrete independent development targets for each product and to have engineers work on those independently of upstream priorities. So in some sense when people install alternative DEs that will to some degree mean that they are no longer using the Workstation as at least a subset of the features developed and announced as the big new features of a given release will not be available simply because they where features implemented or bugs fixed in the primary desktop. That is of course not specific to the Workstation product. Christian - Original Message - From: Frank Murphy frankl...@gmail.com To: devel@lists.fedoraproject.org Sent: Thursday, November 7, 2013 4:16:58 AM Subject: Re: Draft Product Description for Fedora Workstation On Fri, 01 Nov 2013 10:24:20 -0400 Christian Fredrik Kalager Schaller cscha...@redhat.com wrote: Will the other DE's still exist after workstation Will a dev be able to use Xfce, Lxde as graphical choice. What would encourage say an xubuntu dev //* devs are still users */ working on foo, to switch to Fedora Workstation? -- Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Peter Robinson wrote: I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. Ah, the silent majority hypothesis, always a fun argument to bring (with no evidence whatsoever) when one is clearly losing a discussion. Can't you just admit that the consensus is AGAINST Apple-like apps? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Josh Boyer wrote: Everyone seems to think Coprs are awesome, but they can be used for the same things you deride containerized apps for. Please don't count me as everyone. How is Coprs a benefit? -Allows easy Fedora fragmentation. Why bother with package reviews ever again? Were Ubuntu's PPAs seen as such an advantage because they allowed every John Doe and Jane Smith to release packages put together with duct tape? I highly value Fedora's packaging guidelines and now to provide a service that does away with them is insulting. -Who is going to police it? People will attempt at uploading binary packages. (steam, NVIDIA, skype, etc) -What's this do over running mock on your local system? Anyone can generate RPMs on their own system the same way Koji/Coprs do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Hi On Thu, Nov 7, 2013 at 10:06 AM, Kevin Kofler wrote: Peter Robinson wrote: I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. Ah, the silent majority hypothesis, always a fun argument to bring (with no evidence whatsoever) when one is clearly losing a discussion. Can't you just admit that the consensus is AGAINST Apple-like apps? You haven't established any such consensus at all. On the contrary, I see a number of people on both sides. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kof...@chello.at) wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. If you are referring to Ubuntu, then yes. But then again, they already have their own app packaging format based around .debs and AppArmor. So yeah, we might be dicks by not supporting non-systemd systems, but they were dicks first, by not supporting non-Ubuntu systems for their app images. And that's quite some consolation, no? ;-) Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Olav Vitters wrote: On Thu, Nov 07, 2013 at 11:33:57AM +0100, Sergio Pascual wrote: 2013/11/7 Olav Vitters o...@vitters.nl On Thu, Nov 07, 2013 at 03:53:48AM +0100, Kevin Kofler wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. I fail to see the point of discussing non-Fedora distributions on Fedora devel mailing list. I fail to see the point of discussing a feature that is meant to allow upstreams to provide installable bundles that work in all linuxes if it is only to work in Fedora. I already talked about other distributions so your concern has been addressed already. But I pointed out that you are leaving out the most popular one, and you responded by labeling me as off-topic when actually YOU were the one who started talking about other distributions. You advertise distribution-independent packages, so your packages really need to work on ALL distributions. Assuming systemd is already a non- starter. IMHO, trying to support cross-distro packages is a failed endeavour from the outstart, Fedora RPMs are the way to go. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, 7 Nov 2013 15:45:13 +0100 Nicolas Mailhot nicolas.mail...@laposte.net wrote: ...snip... It's not blinders it's the natural reaction of people to tactless pronouncements and dismissals. I do wish the people complaining about this list focused more on technical aspects and less on hype or we-ll-decide-somewhere-else-even-though-it-concerns-you. Thats one thing that puzzles me about this thread... this is all from: Work towards a system where applications can be installed inside a container to improve security and simplify compatibility through library bundling Which basically says that the working group is going to work on that. There's actually 0 technical details on how the implemetation will work out, or even if it will. Perhaps we could move this back to productive and suggest that the working group amend their PRD to have something like: Investigate the implementation and usage for application containers and then we can discuss details when there actually are some? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, 07 Nov 2013 09:06:43 -0600 Michael Cronenworth m...@cchtml.com wrote: Josh Boyer wrote: Everyone seems to think Coprs are awesome, but they can be used for the same things you deride containerized apps for. Please don't count me as everyone. How is Coprs a benefit? -Allows easy Fedora fragmentation. Why bother with package reviews ever again? Were Ubuntu's PPAs seen as such an advantage because they allowed every John Doe and Jane Smith to release packages put together with duct tape? I highly value Fedora's packaging guidelines and now to provide a service that does away with them is insulting. Like repos.fedorapeople.org ? How on earth do you get to 'does away with them' ? -Who is going to police it? People will attempt at uploading binary packages. (steam, NVIDIA, skype, etc) The copr maintainers? along with anyone who looks at them who wishes to report something non distributable. Just like repos.fedorapeople.org -What's this do over running mock on your local system? Anyone can generate RPMs on their own system the same way Koji/Coprs do. Sure they can. This just allows them a place to publish them and not use local computing resources to build them. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Bastien Nocera wrote: - [Florian Weimer wrote:] - Wayland and systemd strongly suggest no Ubuntu interoperability whatsoever. Shouldn't this be a top priority for bundled applications? If we get any traction on this, their customers/users will ask them for it themselves. Hahaha, you really think you can force Canonical into adopting your technologies that way? LOL! This is going to backfire spectacularly! (My guess: Canonical will come up with their own Ubuntu App model requiring Ubuntu technologies and all the third-party developers you are trying to attract will target only that one.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 7, 2013 at 4:58 PM, Kevin Kofler kevin.kof...@chello.at wrote: (My guess: Canonical will come up with their own Ubuntu App model requiring Ubuntu technologies If you had read Lennart's previous reply to this thread, you'd be aware that they already did. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Josh Boyer wrote: So if we call containerized apps Appers The name Apper is already taken! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 7, 2013 at 4:15 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kof...@chello.at) wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. If you are referring to Ubuntu, then yes. But then again, they already have their own app packaging format based around .debs and AppArmor. So yeah, we might be dicks by not supporting non-systemd systems, but they were dicks first, by not supporting non-Ubuntu systems for their app images. And that's quite some consolation, no? ;-) No, calling each other dicks is overall not at all consoling. Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On 11/05/2013 10:33 PM, Adam Williamson wrote: On Tue, 2013-11-05 at 16:32 -0500, Josh Boyer wrote: On Tue, Nov 5, 2013 at 4:29 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2013-11-05 at 15:23 -0500, Josh Boyer wrote: On Tue, Nov 5, 2013 at 2:58 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-11-01 at 14:22 -0400, Josh Boyer wrote: - What about watching films, listening to music? I think it is a basic requirement for students (at least for me). Maybe we should add a that a student should be able to play videos and listen to music. It should be easy to install required codes (free/nonfree/patente) if they are available in the repositories (yes, I mean rpmfusion) This would require approval beyond the WG, as it goes against Fedora's policies. Note, I am not saying you are incorrect, just that it's a conversation to be had elsewhere first. Ensuring that it's possible/easy to install plugins from third party repositories when appropriate if those third party repositories are defined is not, I don't believe, against any policies, or we could not have the automatic codec installation mechanisms in Totem and Rhythmbox. (Which, as I read it, is the kind of thing this comment was about). The codec search only works if you have repositories configured that have packages that match the Provides (as far as I understand). Fedora policy says that we do not promote or install such repositories. This is the don't talk about RPMFusion rule. So sure, we can have software that will pull things in if the user has done some manual intervention. We just cant, currently, do that thing for them. Right, that's exactly what I was saying. I just think this is all the _original poster_ was talking about, not any kind of automatic configuration of such repositories. (Or at least, you can read it that way). OK. I guess that's fine, but it seems like a non-goal to me. I mean, it already works that way. All adding it to the PRD would do would make an easy thing to check off the list as met. I suppose we should go back to the OP and ask for clarification of exactly what the idea was, at this point :) All I was asking for is the status quo. 3rd party repositories must be installed manually, but once they are installed automated codec installation should work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Kevin Fenzi wrote: Like repos.fedorapeople.org ? I don't have a beef with r.f.o. They're no different from hosting a repo on a personal server. The top of the root page even contains a disclaimer. How on earth do you get to 'does away with them' ? It's a Fedora infrastructure server building non-Fedora packages. Why is it considered part of Fedora? Plus there is no disclaimer. The copr maintainers? along with anyone who looks at them who wishes to report something non distributable. Just like repos.fedorapeople.org Good. I see that feature. Sure they can. This just allows them a place to publish them and not use local computing resources to build them. I don't have anything wrong with creating a useful service if it respects Fedora's principles. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 08:57:06AM -0700, Kevin Fenzi wrote: Which basically says that the working group is going to work on that. There's actually 0 technical details on how the implemetation will work out, or even if it will. http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome So there have been lots of thought and work going into this. But maybe more needs to be written down in the proposal as you mentioned. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 04:06:04PM +0100, Kevin Kofler wrote: Peter Robinson wrote: I don't see many people forcing things through, I believe that the vast majority of contributors either like the change or aren't bothered by it. Ah, the silent majority hypothesis, always a fun argument to bring (with no evidence whatsoever) when one is clearly losing a discussion. Ok, you're against silent majority hypothesis Can't you just admit that the consensus is AGAINST Apple-like apps? Wait, I thought you were against silent majority hypothesis? -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 07, 2013 at 03:45:13PM +0100, Nicolas Mailhot wrote: Maybe that's because Coprs were never announced with huge rants about market-share and how Fedora packaging sucked and was irrelevant? I'm pretty sure you're misunderstanding what people are saying if you think above. What I wrote might be understood like above, but that's not what I meant at all. Suggest to reread what people wrote. A few comments to make it easier: I was talking about the *review process*. That can take *ages*. Secondly, this is not meant to replace packages, no packages are not at all irrelevant. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, 7 Nov 2013 20:50:28 +0100 Olav Vitters o...@vitters.nl wrote: On Thu, Nov 07, 2013 at 08:57:06AM -0700, Kevin Fenzi wrote: Which basically says that the working group is going to work on that. There's actually 0 technical details on how the implemetation will work out, or even if it will. http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome So there have been lots of thought and work going into this. But maybe more needs to be written down in the proposal as you mentioned. Thats one possible implementation sure. Yeah, ideally a write up with pros/cons, work outstanding that needs to still be done, what things are acceptable for shipping this way and what isn't, how they are exposed to users, how users can manage them, how they interact with other containers that the other working groups might be working on to meet their needs for server applications, etc. I think it's premature to yell about something where there's not even a detailed proposal to look at. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote: On Thu, Nov 7, 2013 at 4:15 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kof...@chello.at) wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. If you are referring to Ubuntu, then yes. But then again, they already have their own app packaging format based around .debs and AppArmor. So yeah, we might be dicks by not supporting non-systemd systems, but they were dicks first, by not supporting non-Ubuntu systems for their app images. And that's quite some consolation, no? ;-) No, calling each other dicks is overall not at all consoling. Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Well, the most relevant bit is that they use apparmor for sandboxing. Nobody else uses that. And I don't think it is a good idea to use .deb as an image format. So if the format on disk, and the execution runtime is totally different for us and for them, there's little to share. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, Nov 7, 2013 at 9:48 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Thu, 07.11.13 20:09, Miloslav Trmač (m...@volny.cz) wrote: Is there a technical reason why we can't use their packaging format, interpreting it with our technologies but staying compatible? Well, the most relevant bit is that they use apparmor for sandboxing. Nobody else uses that. Are the packages expected to ship their own apparmor policy? That would appear to be at odds with the idea of protecting against malicious packages. If they aren't expected to ship their own, could we implement the same sandboxing policy using SELinux? (https://wiki.ubuntu.com/AppDevUploadProcess seems to suggest Ubuntu will be using some higher-level profile format, not raw AppArmor.) And I don't think it is a good idea to use .deb as an image format. .deb is just an ar archive; if this were the only difference, it would not be worth fragmenting the ecosystem over IMHO. (Especially if the GNOME apps alternative is a compressed disk image, which saves disk space and costs extra CPU time and memory, making exactly the wrong tradeoff in most situations AFAICS.) Mire -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, 2013-11-07 at 16:15 +0100, Lennart Poettering wrote: On Thu, 07.11.13 03:53, Kevin Kofler (kevin.kof...@chello.at) wrote: Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. If you are referring to Ubuntu, then yes. But then again, they already have their own app packaging format based around .debs and AppArmor. So yeah, we might be dicks by not supporting non-systemd systems, but they were dicks first, by not supporting non-Ubuntu systems for their app images. And that's quite some consolation, no? ;-) The implementation of some kind of 'app level packaging system' divorced from distros' historic package formats seems like a fairly valuable opportunity to finally improve the level of interoperability between Debian-derived and non-Debian-derived distros. If, instead, we turn it into an opportunity to argue about who was being a dick first and then cheerfully prolong the existing, needless divides without even making a serious attempt at working together, that...seems like something of a waste. And an invitation to a system that _does_ work across distros, like OH SAY STEAM, to eat everyone's lunch. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Thu, 2013-11-07 at 16:58 +0100, Kevin Kofler wrote: Bastien Nocera wrote: - [Florian Weimer wrote:] - Wayland and systemd strongly suggest no Ubuntu interoperability whatsoever. Shouldn't this be a top priority for bundled applications? If we get any traction on this, their customers/users will ask them for it themselves. Hahaha, you really think you can force Canonical into adopting your technologies that way? LOL! This is going to backfire spectacularly! (My guess: Canonical will come up with their own Ubuntu App model requiring Ubuntu technologies and all the third-party developers you are trying to attract will target only that one.) They already *have* one: http://shop.canonical.com/index.php?cPath=19 I have no idea how it works or where it's documented, but it exists. Given that it's there and working and people are using it, the obligation would seem to be on any group that comes along later to try and implement something similar to: i) evaluate Ubuntu's system for its potential to be used outside of Ubuntu ii) If it's not ready to be used outside of Ubuntu as-is, propose a future development path which would result in interoperability and ask the developers of the Ubuntu system if they're willing to work down such lines, and make a genuine effort to have that come about, even at the cost of short-term inconvenience in development iii) If that proves impossible, communicate the situation and the attempts that were made clearly and publicly I'd therefore suggest anyone trying to invent a new app-level distribution mechanism go and look at and produce a formal evaluation of all the existing efforts in the space, including this one, before inventing something else new. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
- Original Message - Bastien Nocera wrote: Might not want to put answers in people's mouths. Did you read up on the various bundling techniques that were explored and the API/ABI guarantees we want to offer? I'll stop short of paraphrasing you. The fact that bundling is even being explored as a technique at all makes me puke! *plonk* Can we remove that boy from the mailing-list? The level of discussion is worse than 10 levels deep in a slashdot thread. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Am 06.11.2013 10:56, schrieb Bastien Nocera: - Original Message - Bastien Nocera wrote: Might not want to put answers in people's mouths. Did you read up on the various bundling techniques that were explored and the API/ABI guarantees we want to offer? I'll stop short of paraphrasing you. The fact that bundling is even being explored as a technique at all makes me puke! *plonk* Can we remove that boy from the mailing-list? The level of discussion is worse than 10 levels deep in a slashdot thread. besides that it looks like you suggested to remove yourself due wrong quoting that boy does a lot of hard work as packager and tries to do it in a clean way without sloppy compromises for the sake of future mainainment maybe you do not care about KDE, but he as packager and many other does http://koji.fedoraproject.org/koji/userinfo?userID=362 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
- Original Message - Am 06.11.2013 10:56, schrieb Bastien Nocera: - Original Message - Bastien Nocera wrote: Might not want to put answers in people's mouths. Did you read up on the various bundling techniques that were explored and the API/ABI guarantees we want to offer? I'll stop short of paraphrasing you. The fact that bundling is even being explored as a technique at all makes me puke! *plonk* Can we remove that boy from the mailing-list? The level of discussion is worse than 10 levels deep in a slashdot thread. besides that it looks like you suggested to remove yourself due wrong quoting that boy You'll have to blame the company provided Zimbra webmail for that. does a lot of hard work as packager and tries to do it in a clean way without sloppy compromises for the sake of future mainainment maybe you do not care about KDE, but he as packager and many other does I'm sure we'd get another maintainer who doesn't feel entitled to reply to emails with absurdities, flame baits and trolling. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 06, 2013 at 12:59:00AM +0100, Kevin Kofler wrote: In short: Make the defaults as sane as possible, but still allow the user to change them if they disagree with you on what is sane. The more options, the better. The definition given by Frank Murphy is totally different and doesn't align with above. Above also doesn't relate to developers. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 06, 2013 at 01:00:16AM +0100, Kevin Kofler wrote: Bastien Nocera wrote: Might not want to put answers in people's mouths. Did you read up on the various bundling techniques that were explored and the API/ABI guarantees we want to offer? I'll stop short of paraphrasing you. The fact that bundling is even being explored as a technique at all makes me puke! That's offtopic. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Tue, Nov 05, 2013 at 01:23:01PM -0800, Adam Williamson wrote: So let me step into my handy Tardis and bring back a vignette from the Real World after Fedora and other distributions bless upstream app distribution as a preferred channel: Could you give some practical programs which are impacted by this? From what I can see, loads of programs are not packaged by a distribution. They might have a package for one distribution, but then not for another. For a manager/techy type situation, I fail to understand practical programs which would be impacted. Usually manager/techy means proprietary, in which case you usually have packages for a few distributions, but not all. Really popular applications already provide packages for a few distributions (but again not all). The intention of these apps are to give an app for a distribution before it's included within the distribution itself. If the distribution method is really that more inconvenient, then this should be addressed. But IMO the app thing is happening anyway. I really dislike these artificial roadblocks for proprietary software. The conversation IMO goes more like this: - Manager: Hey can we provide something on this Linux thing? - Techy: 20min of tech talk - Manager looking at his phone 10 secs into the conversation - Manager: maybe we go for something less complicated vs Techy: 1st quick n dirty (app), then improve on that (distributions) -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 06, 2013 at 01:25:29AM +0100, Kevin Kofler wrote: But many of those concerns are inherent to the concept of sandboxed applications or the methods of delivery they'd enable and cannot possibly be addressed, ever. The whole concept is fatally flawed. I'd suggest trying a different hat than just black. http://en.wikipedia.org/wiki/Six_Thinking_Hats Suggest to also think of how to address concerns. At the moment, it seems you want to bribe programs to accept a complicated and long process (distributions) because the alternative might be too easy (apps). This highlights a concern, not a fatal flaw. The flaw IMO is within the distribution method. It takes a long time and currently there is nothing that makes it easy. Luckily there is no other method at the moment to archive that. Say you have this new application and you want to provide it to (most) Linux users *now* (not 6+ months later). There should be an answer for that. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 06, 2013 at 12:35:59AM +0100, Kevin Kofler wrote: I think users will not understand why all the vendor repositories with non- free crap are there and the stuff they are actually looking for is not. Whether or not proprietary is crap or not is offtopic. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
SNIP So sure, we can have software that will pull things in if the user has done some manual intervention. We just cant, currently, do that thing for them. Right, that's exactly what I was saying. I just think this is all the _original poster_ was talking about, not any kind of automatic configuration of such repositories. (Or at least, you can read it that way). OK. I guess that's fine, but it seems like a non-goal to me. I mean, it already works that way. All adding it to the PRD would do would make an easy thing to check off the list as met. I suppose we should go back to the OP and ask for clarification of exactly what the idea was, at this point :) So there are 3 different cases here 1) Packaging non-free/semi-free software in Fedora - I don't think anyone is advocating that - ref recent openh264 thread 2) Enabling 3rd party repositories with packages that have an unclear legal status is major jurisdictions - This is not what the PRD was referring too, and we have a solution for that already 3) Easily enabling 3rd party repositories containing software that is without any legal uncertainty, but which contains software which might not meet the Fedora guidelines for stuff we would include. So it is item 3 that the PRD is addressing. An example here would be Google Chrome. Google provides a yum repo for Google Chrome for Fedora and Google stands behind Chrome legally, so if they also do the work of putting in an appdata file there we should figure out a simple way for users to install Chrome from the GNOME Software application. The exact details of how we do that enablement can and should be discussed, but it should be something simpler than how we currently enable the (2) option, yet at the same time we probably don't want to give them equal billing to the Fedora packaged and 100% open source stuff we make available in the Fedora repository. As a sidenote, as we delve into the details a bit more here maybe it is time to move these discussions to the product specific mailing list to not spam the general devel list? Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
SNIP I would actually like to go a little further, and make it easy to enable 'clean' third-party repositories. If we imagine a future where e.g. valve is hosting a repository with their steam client, or say, the chromium web browser is available from the a fedora people page, I would really like it if searching for 'steam' or 'chromium' in gnome-software would bring up a text that said something like: The software you are looking for is available from a third-party repository. Do you want to enable it ? That was how I understood the original proposal. And that's the conversation that needs to happen at a higher level outside of the WG before it can really be a reality. I don't think we need to push these decisions to be Fedora generic. There is no reason why the 3 products can't have different rule sets. Just because a policy would work for the cloud image for instance doesn't mean it is the right one for the Workstation and vice versa. Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 6, 2013 at 10:19 AM, Christian Schaller cscha...@redhat.com wrote: SNIP I would actually like to go a little further, and make it easy to enable 'clean' third-party repositories. If we imagine a future where e.g. valve is hosting a repository with their steam client, or say, the chromium web browser is available from the a fedora people page, I would really like it if searching for 'steam' or 'chromium' in gnome-software would bring up a text that said something like: The software you are looking for is available from a third-party repository. Do you want to enable it ? That was how I understood the original proposal. And that's the conversation that needs to happen at a higher level outside of the WG before it can really be a reality. I don't think we need to push these decisions to be Fedora generic. There is no reason why the 3 products can't have different rule sets. Just because a policy would work for the cloud image for instance doesn't mean it is the right one for the Workstation and vice versa. I don't think we need to force the same policy across all 3 products. I DO think we need to discuss adjusting the policy with the people that set the current policy though. That would be FESCo and the Board. I'm going to guess they have reasons for not allowing third party repositories to be automatically installed/enabled for reasons and they oversee the WGs, so bringing it up with them is the correct thing to do. I'd be happy to open a FESCo ticket to discuss this. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 6, 2013 at 10:26 AM, Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Nov 6, 2013 at 10:19 AM, Christian Schaller cscha...@redhat.com wrote: SNIP I would actually like to go a little further, and make it easy to enable 'clean' third-party repositories. If we imagine a future where e.g. valve is hosting a repository with their steam client, or say, the chromium web browser is available from the a fedora people page, I would really like it if searching for 'steam' or 'chromium' in gnome-software would bring up a text that said something like: The software you are looking for is available from a third-party repository. Do you want to enable it ? That was how I understood the original proposal. And that's the conversation that needs to happen at a higher level outside of the WG before it can really be a reality. I don't think we need to push these decisions to be Fedora generic. There is no reason why the 3 products can't have different rule sets. Just because a policy would work for the cloud image for instance doesn't mean it is the right one for the Workstation and vice versa. I don't think we need to force the same policy across all 3 products. I DO think we need to discuss adjusting the policy with the people that set the current policy though. That would be FESCo and the Board. I'm going to guess they have reasons for not allowing third party repositories to be automatically installed/enabled for reasons and they oversee the WGs, so bringing it up with them is the correct thing to do. I'd be happy to open a FESCo ticket to discuss this. https://fedorahosted.org/fesco/ticket/1195 josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Tue, Nov 05, 2013 at 01:23:01PM -0800, Adam Williamson wrote: On Mon, 2013-11-04 at 23:50 +0100, Michael Scherer wrote: Le lundi 04 novembre 2013 à 21:02 +0100, Reindl Harald a écrit : Am 04.11.2013 20:56, schrieb drago01: On Mon, Nov 4, 2013 at 8:49 PM, Reindl Harald h.rei...@thelounge.net wrote: that's all true but you can be pretty sure if a app-store with bundeled applications exists *nobody* would package and maintain them as RPM - everybody would point with his finger to the app No because RPM packages apps *do* have benifits .. otherwise we wouldn't have this discussion. if it goes in that direction, and it starts faster than anybody likes you do a dramatical harm to the userbase which likes the consistent package managment and *really used* conecpt of shared libraries Again those are NOT MUTUALLY EXCLUSIVE. You can have sandboxed *and* rpm packaged apps at the same time. the most imporant word in your answer is *CAN* but you will not, nobody will package whatever application as RPM if he is fine with the app-store, so you *could* have both but i doubt at the end of the day it will happen If no one think that using a rpm is bringing any value, then indeed, no one will do the job. Now, if someone think this is better for whatever reasons, then this someone will do the job. It seems that your fear is that if people are not forced to make rpm, they will not see the value of doing so, and so would not do it. So if that's the problem, then the solution is to demonstrate the value of packaging and rpm rather than restricting all others alternatives. So to me this is the nub of the debate, and it's both fantastically interesting and fantastically difficult to work out in advance. In an ideal world things would work the way Michael describes, and also, the stock market would behave precisely as neat theories based on rational actors predict, and no-one would have any difficulty solving the three door problem, and healthcare.gov would never have been launched in a state in which it could not possibly work... And in the real world, well, it's the real world. :) Excuse me to remove your bnice piece of anticipation, and excuse me to not answer in the same way as I do not have a good idea for now. While what you show is likely true, there is just 1 single problem, this is not the future. This is the present. Currently, if you do not have the big button of your story, you still have a few choice as a ISV or upstream ( free or non free, the problem are the same for both, except that in the case of free software, people will complain to you for stuff that you didn't decide to do ): 1) you just distribute nothing, besides a tarball with source code. Or maybe just a gem or similar. This seems to satisfy perfectly some people who are quite happy of the sisyphean tasks that is the integration of a always growing pack of line of code, but strangely enough, it doesn't suit that well some end-users. And the choice of version shipped by the distribution is a choice that the distribution do. So far, this model served us quite well, and frankly, it satisfy most of my needs, because I have several years of experience. But besides some end-users, that's also not satisfying for some upstream, since they want to have their code sent to users fast for various reasons, like having feedback on new features ( the faster, the better, if possible the day of release ), sometime, they want to distribute bugfixes or proposed bugfixes. Sometimes they also want to have a supported version, potentially older. For every policy decided by a distro, you can find one reason to do thing differently. In the end, it all boils down on who decide the version, between the upstream, the end users and distribution. And while of course, with enough ressources, everybody can choose what he want, there is no one here with a unlimited amount of ressources. SO in the end, that's just distribution using their power to decide for others,; because others either do not have the ressource (users), or spend their ressources on making software (upstream). In order to take/give back some choice to upstream and/or end users, people tried various systems : 2) compile stuff in static That's ugly. And yet, that work enough well for distributing games on Linux since a few years (earliest personal example I can find would be Unreal tournament), for distributing software used in industry or even plugin. Some upstream do this for now. Despites us saying don't do that, it kill kittens, ulrich drepper said it. 2bis) use some magical system, like autoinstall, zeroinstall, etc. They didn't work that well. Potentially for chicken and eggs problem, potentially because some problem were left unsolved. However, since company like Microsoft and Apple ( or Google ) managed to make it work fine
Re: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 3:56 PM, Adam Williamson awill...@redhat.com wrote: In this situation what we should do is carefully consider the relative possibilities of the good, bad and mixed outcomes with as much precision as we can, and try to come up with a path forward which makes the likelihood of a good outcome as high as possible and the likelihood of a bad outcome as low as possible. Let's just try it and see what happens! is not a mature approach to risk management. I'm asking this question genuinely and not sarcastically. Isn't that very let's try it and see what happens! approach exactly what we're doing with Fedora.next? It seems to me we've forged ahead with good ideas around what we'd like to see, but it's a hell of a lot more risk than just having a new way to package applications. I mean, we don't even have resource requirements identified for Fedora.next, much less acquired. Yet, here we are doing it and doing it with the expectation that we'll work through it. I'm just having trouble wrapping my head around the intense focus on a new app packaging technology when the entire distro is making massive changes to how it's produced. It seems like we collectively aren't seeing the forest because of the trees here. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 6, 2013 at 3:04 PM, Olav Vitters o...@vitters.nl wrote: This highlights a concern, not a fatal flaw. The flaw IMO is within the distribution method. No, the fatal flaw is that we don't really have an OS one can build applications on: the ABI is unstable and insufficient. So the choices are either constantly rebuilding and patching (what distributions do) or bundling (what non-distribution mechanisms do). Say you have this new application and you want to provide it to (most) Linux users *now* (not 6+ months later). There should be an answer for that. Letting developers provide a custom application format is not actually solving this: the difficult part is not making something available on the internet, but making it reachable by the users. This, in practice, always ends up as one or a very small number of centralized places - _the_ distribution, _the_ app store, _the_ amazon.com. And the difficulty of getting a set of bits to amazon.com / an app store / a RPM is very similar. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 6, 2013 at 7:24 PM, Josh Boyer jwbo...@fedoraproject.org wrote: I'm just having trouble wrapping my head around the intense focus on a new app packaging technology when the entire distro is making massive changes to how it's produced. I think the trouble here is that the Linux Apps proposal (which is being implicitly referred to) uses a single term to mix three completely different problems, each of them difficult, and gives us a single package deal: * Sandboxing as a protection mechanism (technically difficult - to design, to migrate to, lots of work to implement) * Bundling as a way to solve API/ABI breakage (not technically right yet done and requested in practice, security concerns) * Non-distribution mechanisms to get software from developers to users (losing control/ability to integrate, making it easier for proprietary software) With the 2^3 possible combinations of likes/dislikes, almost everyone has something to be intensely unhappy about. On the other hand, the move to WGs has so far not resulted in any drastic proposals to change what we are doing; it's easy to view this as different kinds of spins with more voting bodies. I expect this to change eventually, but not just now. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Fri, Nov 01, 2013 at 10:24:20AM -0400, Christian Fredrik Kalager Schaller wrote: Hi everyone, Attached is the draft PRD for the Workstation working group. The proposal tries to be relatively high level and focus on goals and principles, but I have included some concrete examples at times to try to provide some clarity on how the goals and principles could play out in practice. I hope the community at large will take the time to read through it and provide feedback so that when the working group meet next we can use that feedback to start tuning in on the final form of the PRD. Here's a statement we may need to better clarify on p. 3: The working group will also specify policies in terms of branding, themeing and desktop graphics. I think we should be clear that any branding efforts need to fit into the overall branding framework of Fedora. We should be careful to avoid having branding diverge between the products to an extent that makes it harder for us to identify them as part of a family of Fedora products. In my time as an FPL, I worked extensively with Fedora folks on trademark and brand guidelines. I suspect Robyn has done quite the same wherever possible. It would be a step backward to make it harder for people to readily identify any of the Fedora products with Fedora. This is really a suggestion for all the working groups, so I'm cc'ing server@ and cloud@ lists too. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 6, 2013 at 1:34 PM, Miloslav Trmač m...@volny.cz wrote: On Wed, Nov 6, 2013 at 7:24 PM, Josh Boyer jwbo...@fedoraproject.org wrote: I'm just having trouble wrapping my head around the intense focus on a new app packaging technology when the entire distro is making massive changes to how it's produced. I think the trouble here is that the Linux Apps proposal (which is being implicitly referred to) uses a single term to mix three completely different problems, each of them difficult, and gives us a single package deal: * Sandboxing as a protection mechanism (technically difficult - to design, to migrate to, lots of work to implement) * Bundling as a way to solve API/ABI breakage (not technically right yet done and requested in practice, security concerns) * Non-distribution mechanisms to get software from developers to users (losing control/ability to integrate, making it easier for proprietary software) With the 2^3 possible combinations of likes/dislikes, almost everyone has something to be intensely unhappy about. Sure, but that's kind of my point. If we can't realize that it's possible to do some kind of combination that makes sense with something this small, what are we going to do when the entire distro is up for change? While I dislike buzzwords, the stop energy here is pretty daunting. On the other hand, the move to WGs has so far not resulted in any drastic proposals to change what we are doing; it's easy to view this as different kinds of spins with more voting bodies. I expect this to change eventually, but not just now. What you say makes some sense. It also makes me very tired thinking about the threads coming when the details start getting presented by the WGs :). I guess that's what we've signed up for though. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, 2013-11-06 at 13:24 -0500, Josh Boyer wrote: On Tue, Nov 5, 2013 at 3:56 PM, Adam Williamson awill...@redhat.com wrote: In this situation what we should do is carefully consider the relative possibilities of the good, bad and mixed outcomes with as much precision as we can, and try to come up with a path forward which makes the likelihood of a good outcome as high as possible and the likelihood of a bad outcome as low as possible. Let's just try it and see what happens! is not a mature approach to risk management. I'm asking this question genuinely and not sarcastically. Isn't that very let's try it and see what happens! approach exactly what we're doing with Fedora.next? It seems to me we've forged ahead Hoo boy, just when the thread was quieting down... I'm still slightly out of sync with the fedora.next stuff (REALLY picked a bad time to go on vacation), but it does seem to me that a decent amount of 'mature reflection' was done on it before it was approved, at least. And it does not appear to be irreversible at this point: we are still only at the point where a bunch of WGs are going away to come up with proposals for FESCo's review, yes? FESCo could ultimately still decide to shoot down the whole thing, or demand major changes, or delay it for any given amount of time? As I read the process, we are not irreversibly committed to any practical changes to any Fedora product at this point. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Hi On Wed, Nov 6, 2013 at 2:38 PM, Adam Williamson wrote: I'm still slightly out of sync with the fedora.next stuff (REALLY picked a bad time to go on vacation), but it does seem to me that a decent amount of 'mature reflection' was done on it before it was approved, at least. I don't really have a problem in believing that but it would be useful to know in more detail how the initial proposals came to be (who were involved? what problems are we trying to solve? what are failures of the current model? did it go through Red Hat management internally before being proposed and is more headcount being allotted? Was Fedora Board and FESCo members aware that a proposal were coming through and what was their rationale for choosing to go forward? etc) Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, 2013-11-06 at 19:10 +0100, Michael scherer wrote: So if that's the problem, then the solution is to demonstrate the value of packaging and rpm rather than restricting all others alternatives. So to me this is the nub of the debate, and it's both fantastically interesting and fantastically difficult to work out in advance. In an ideal world things would work the way Michael describes, and also, the stock market would behave precisely as neat theories based on rational actors predict, and no-one would have any difficulty solving the three door problem, and healthcare.gov would never have been launched in a state in which it could not possibly work... And in the real world, well, it's the real world. :) Excuse me to remove your bnice piece of anticipation, and excuse me to not answer in the same way as I do not have a good idea for now. While what you show is likely true, there is just 1 single problem, this is not the future. This is the present. Various people replied along these lines (you can't be sure it'll happen that way, and anyway, it's already the case that lots of parties don't bother with distro packaging). I'd agree with both of those points. To summarize my response to that general line of reasoning: I don't disagree. As the first two lines of my reply said: So to me this is the nub of the debate, and it's both fantastically interesting and fantastically difficult to work out in advance. It's not a clear calculation _at all_, and it's a pure counterfactual, so more or less impossible to determine with any certainty. An equally possible result is that fewer parties _relatively speaking_ have a strong interest in aiding distro packaging but more parties _absolutely speaking_ become interested in making software available for Linux at all, and the upshot of that is that we get more software available both through the 'third party' mechanism _and_ through distro packaging, and all is sweetness and rainbows. That's certainly a plausible outcome. I'm not suggesting I or anyone can be certain exactly what would happen, jus that this is a sensitive and risk-prone area. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 6, 2013 at 2:38 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2013-11-06 at 13:24 -0500, Josh Boyer wrote: On Tue, Nov 5, 2013 at 3:56 PM, Adam Williamson awill...@redhat.com wrote: In this situation what we should do is carefully consider the relative possibilities of the good, bad and mixed outcomes with as much precision as we can, and try to come up with a path forward which makes the likelihood of a good outcome as high as possible and the likelihood of a bad outcome as low as possible. Let's just try it and see what happens! is not a mature approach to risk management. I'm asking this question genuinely and not sarcastically. Isn't that very let's try it and see what happens! approach exactly what we're doing with Fedora.next? It seems to me we've forged ahead Hoo boy, just when the thread was quieting down... I'm still slightly out of sync with the fedora.next stuff (REALLY picked a bad time to go on vacation), but it does seem to me that a decent amount of 'mature reflection' was done on it before it was approved, at least. And it does not appear to be irreversible at this point: we are still only at the point where a bunch of WGs are going away to come up with proposals for FESCo's review, yes? FESCo could ultimately still decide to shoot down the whole thing, or demand major changes, or delay it for any given amount of time? As I read the process, we are not irreversibly committed to any practical changes to any Fedora product at this point. Sure. That doesn't change that the risk is still there and that there are lots of unknowns and will be ever after FESCo approves (or rejects) the governance and PDRs for the WGs. I suppose the point of little return is Jan. That doesn't mean that it's _not_ a somewhat cavalier approach. My point is, we're seriously considering changing Fedora as a whole because it allows us to make certain things better. So do app containers, or containers in general. So do a lot of other technical things that could _possibly_ lead to some downsides. I'm just imploring people to stop screaming NO on these technical items before they even get started. I think we need a bit more of a bold approach or we're going to be stuck where we are with other projects doing the innovation people find interesting and useful. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On 6 November 2013 15:14, Christian Schaller cscha...@redhat.com wrote: so if they also do the work of putting in an appdata file there... Note, we can easily ship a google-chrome.appdata.xml file in the fedora-appstream project. This has a quite a few appdata files for important applications that are awaiting upstream releases. If you want me to add one that points to a specific HTML page [how to enable the repo] when clicked on, just yell. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, 2013-11-06 at 16:33 +0100, Alberto Ruiz wrote: On Tue, 2013-11-05 at 12:44 -0800, Adam Williamson wrote: Haven't read the whole thread yet, but in case it hasn't been said: Build a way would be great. I've said a few times that it'd be nice for there to be a cross-distro framework for third-party app distribution. Promote as the Proper Way To Get Apps On GNOME / Fedora Desktop would NOT be great. Having spent a lot of time thinking about both sides of the debate I'm still firmly in the 'coherent distribution is the ideal state' camp. And I pretty much agree, read my comments below: Upstream distribution is probably never going to go away entirely, and it'd be good to make it as painless and reliable as possible _where it's really necessary to use it_. But it should never be the primary/preferred method of software distribution on Fedora, in my opinion. It should always be an exception. Application sandboxing/bundling is not mutually exclusive with a coherent system and with keeping control, it's just not an RPM as we know it. What we need to acknowledge is that delivering integral parts of the operating system and delivering third party apps are fundamentally two different things. So once we have sandboxing we can (and should) propose an end user application delivery channel for those apps so we will keep control still. The key here is that the mechanisms to deliver an OS component and an end user should be different. The cadence _is_ different, as an example, at the LibreOffice team we have a hell of a time because people complain about bugs that we already fixed and released on an ongoing basis. In some cases, people are stuck with a specific version of Fedora and they simply can't get the latest version of a given app eventhough the new version doesn't require anything that is provided. The other problem is that the upstreams don't have a channel to deploy beta versions, or versions with a specific patch, that you can't install concurrently because the distributions won't let you. So all in all, the key here is to acknowledge that a system level component (systemd, libjpeg, Qt, NetworkManager) has a completely different nature than an end user application. The upstream has a different focus, development cadence, nature and intent, and it is against the interest of the upstreams and the users to keep delivering those apps as integral parts of the _operating system_. That doesn't mean that there shouldn't be any sort of integration or gatkeeping, we must have a centralized Fedora/FOSS app bundle channel that upstreams can use to certify' their apps against Fedora, if we use scriptless rpms and yum repositories as a transport layer, in a different rpmdb than the system wide one, that is an implementation detail. But the relationship with the upstream and the cadence should be completely different than a system level rpm. Excellent summary Alberto, I recently felt on my skin what it means to be locked in a buggy version of LiberOffice. Making it simple for user to install the upstream version instead of our bundled one would help *a lot* all free software users. Also from an engineering pov it will make our work in Fedora less heavy allowing us to improve the core OS. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 06, 2013 at 07:26:48PM +0100, Miloslav Trmač wrote: places - _the_ distribution, _the_ app store, _the_ amazon.com. And the difficulty of getting a set of bits to amazon.com / an app store / a RPM is very similar. If one will immediately solve it for multiple distributions, then the gain is immensely higher. An IMO, it is not about RPM vs another packaging format. To get into Fedora, you need an account, reviews, etc. It is a pretty long process. This hopefully is much quicker with greater results. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
2013/11/6 Olav Vitters o...@vitters.nl If one will immediately solve it for multiple distributions, then the gain is immensely higher. An IMO, it is not about RPM vs another packaging format. To get into Fedora, you need an account, reviews, etc. It is a pretty long process. Has this sanboxed-bundled-from-upstream proposal been discussed with other distributions? If the final result is that the Universal Linux Package only works in Fedora we are not gaining anything. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Wed, Nov 06, 2013 at 10:55:30PM +0100, Sergio Pascual wrote: Has this sanboxed-bundled-from-upstream proposal been discussed with other distributions? If the final result is that the Universal Linux Package only works in Fedora we are not gaining anything. A lot of this is being based on technology that's not really available yet such as kdbus, Wayland, systemd bits. This has been discussed at GUADEC (GNOME conference): http://www.superlectures.com/guadec2013/sandboxed-applications-for-gnome AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. I assume Lennart will talk about it at various conferences. For e.g. Mageia, the focus is currently on releasing Mageia 4. Features for Mageia 5 is later, so probably discuss it at FOSDEM (beginning of Feb). -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Christian Schaller wrote: So it is item 3 that the PRD is addressing. An example here would be Google Chrome. Google provides a yum repo for Google Chrome for Fedora and Google stands behind Chrome legally, so if they also do the work of putting in an appdata file there we should figure out a simple way for users to install Chrome from the GNOME Software application. The exact details of how we do that enablement can and should be discussed, but it should be something simpler than how we currently enable the (2) option, Why? IMHO, getting proprietary crap (3) should definitely NOT be easier than getting Free stuff we won't ship (2). I understand why we don't make (2) any easier, but that just means (3) should not get any easier either. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Josh Boyer wrote: I don't think we need to force the same policy across all 3 products. I DO think we need to discuss adjusting the policy with the people that set the current policy though. That would be FESCo and the Board. I'm going to guess they have reasons for not allowing third party repositories to be automatically installed/enabled for reasons and they oversee the WGs, so bringing it up with them is the correct thing to do. Having a list of third-party repositories which does not include RPM Fusion is just a really bad joke, beyond useless. If we can't include RPM Fusion (and Livna) in the list, it's better to not have such a list at all and let users find the real, complete list on their own. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Alberto Ruiz wrote: Application sandboxing/bundling is not mutually exclusive with a coherent system and with keeping control, it's just not an RPM as we know it. What we need to acknowledge is that delivering integral parts of the operating system and delivering third party apps are fundamentally two different things. Big -1 to that! The fact that we have no such artificial distinction has always been one of the biggest strengths of GNU/Linux. So once we have sandboxing we can (and should) propose an end user application delivery channel for those apps so we will keep control still. The key here is that the mechanisms to deliver an OS component and an end user should be different. The cadence _is_ different, as an example, at the LibreOffice team we have a hell of a time because people complain about bugs that we already fixed and released on an ongoing basis. In some cases, people are stuck with a specific version of Fedora and they simply can't get the latest version of a given app eventhough the new version doesn't require anything that is provided. We should just push the new version as an update. The other problem is that the upstreams don't have a channel to deploy beta versions, or versions with a specific patch, That's what testing repos (COPRs, repos.fedorapeople.org etc.) are for (see also kde-unstable and kde-testing for a working large-scale example). that you can't install concurrently because the distributions won't let you. What's the point of letting them install concurrently? If you want to test a patch because the installed version doesn't work properly for you, you want to REPLACE the installed version with one that works for you. If it is actually worse, you can just yum downgrade/distro-sync to the official version. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Olav Vitters wrote: The definition given by Frank Murphy is totally different and doesn't align with above. Above also doesn't relate to developers. These align a lot with what I wrote though. :-) http://en.wiktionary.org/wiki/power_user http://en.wikipedia.org/wiki/Power_user Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Olav Vitters wrote: AFAIK (not sure), it should come somewhat easy once you the distribution is based upon systemd. That means it will exclude the most popular distribution out there. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Josh Boyer wrote: Isn't that very let's try it and see what happens! approach exactly what we're doing with Fedora.next? I also have strong doubts that what you call Fedora.next is going to be of any benefit to us. The existing system with the Spins and SIGs just worked, what's the point of overthrowing it all with a new parallel structure (Products and Working Groups)? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Josh Boyer wrote: What you say makes some sense. It also makes me very tired thinking about the threads coming when the details start getting presented by the WGs :). I guess that's what we've signed up for though. Well yes, each time you try to force a change through which actually makes things worse, there WILL be resistance. In fact, this is already what is happening in this thread, the app proposal coming from (parts of) the Workstation WG. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Michael scherer wrote: PPA are populars, so does OBS. They are not perfect, but they work good enough for people ( and it seems good enough for us to replicate, despites PPAs being a time bomb, breaking Ubuntu upgrade in various way ). Well, these ARE the way if you really need to ship something that cannot go into the distribution repository. Bypassing the whole packaging system is not. Of course, depending on who makes the PPAs, the packages can be really really crappy, but users know that and do prefer packages from a reviewed repository or at least from a PPA done by a decent packager. (Packages done by upstream tend to be the crappiest of all.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Simo Sorce wrote: On Wed, 2013-11-06 at 01:13 +0100, Kevin Kofler wrote: Simo Sorce wrote: * and *ideally* I mean SELinux sanbdboxed with specific APIs that must be used to interact with the rest of the system, so that the application doesn't have free reign over users files. So you want to remove my freedom to disable SELinux? SARCASMWay to go… /SARCASM If this is all you have to say about what I wrote (strawman on a note and ignore completely the rest) you have nothing valid to say in this discussion. If the system relies on SELinux to sandbox apps, it means that SELinux becomes mandatory to use it, which definitely does remove my freedom to disable it. So where's the strawman? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Olav Vitters wrote: On Wed, Nov 06, 2013 at 01:00:16AM +0100, Kevin Kofler wrote: Bastien Nocera wrote: Might not want to put answers in people's mouths. Did you read up on the various bundling techniques that were explored and the API/ABI guarantees we want to offer? I'll stop short of paraphrasing you. The fact that bundling is even being explored as a technique at all makes me puke! That's offtopic. How is pointing out a fundamental unfixable flaw in the approach you are advocating off topic? Do I need to rehash all the reasons why bundling sucks? https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Adam Williamson wrote: It's not a clear calculation _at all_, and it's a pure counterfactual, so more or less impossible to determine with any certainty. An equally possible result is that fewer parties _relatively speaking_ have a strong interest in aiding distro packaging but more parties _absolutely speaking_ become interested in making software available for Linux at all, and the upshot of that is that we get more software available both through the 'third party' mechanism _and_ through distro packaging, and all is sweetness and rainbows. That's certainly a plausible outcome. I'm not suggesting I or anyone can be certain exactly what would happen, jus that this is a sensitive and risk-prone area. I don't believe in that at all. I think that the Free Software community is happy with the system as it stands now; whom we would attract with an alternative system is developers who develop proprietary software and/or who hate distribution packaging, and so will never get their stuff into our repositories. If a developer is happy with the distro packaging system, why would they care about the app system? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Hi On Wed, Nov 6, 2013 at 10:11 PM, Kevin Kofler wrote: I don't believe in that at all. I think that the Free Software community is happy with the system as it stands now Well you should speak for yourself instead of assuming that a large community has only one view.. I think there is room for improvement and more than one approach and I also think the way you are expressing your disagreement (for example, talking about puking etc) is in pretty distasteful. You talk about freedom so much while not wanting anyone else to be free to use an approach you don't prefer. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Nov 6, 2013, at 8:11 PM, Kevin Kofler kevin.kof...@chello.at wrote: I don't believe in that at all. I think that the Free Software community is happy with the system as it stands now; In my estimation, there's a better statistical chance you know what makes a frog happy, than what the free software community is happy with. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Mon, Nov 04, 2013 at 11:05:21PM +0100, Nicolas Mailhot wrote: As all such schemes it works as long as you ignore the fact that apps process data and communicate with other apps. That's not being overlooked. Probably the presentation already addresses this concern. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Mon, Nov 04, 2013 at 06:19:48PM +0100, Kevin Kofler wrote: I disagree with the premise that to get anywhere, we would need to bend over backwards to the proprietary market and adopt their inferior software distribution strategies. If that were true, we could give up right here, we'd have already lost. [..] If Adobe were to want Photoshop on a linux desktop, I think that would be great news. It would be hugely disruptive. Hugely disruptive to your freedom, indeed… What's wrong with GIMP? I don't get why you want to force your view of freedom onto everyone. These sandboxed applications is not just for proprietary software. I don't think it'll replace the current distribution model. It will generate some competition. IMO competition is good, instead of preventing sandboxed applications, show that the packaged applications are preferred. Now such distribution of applications also easily allow proprietary applications: Awesome, finally! Easy to run Steam, Photoshop, etc. The kernel is GPL and doesn't force this licence on Adobe. You can have whatever license you want as application. These sandboxed applications do suffer from various drawbacks, so better to believe in your solution than to try and block another view IMO. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit : The problem is not to get code in the hands of developers. You don't need distros for that. The problem is to get the code to end-users and developers spend more time fighting the constrains it involves than trying to understand this problem-space. Of course the aim might not be to reach end users but to push code from developpers to other developers. And if that is the case, there is a huge disconnect between GNOME goals and Fedora Workstation goals. GNOME speakers repeat all year round their software is not aimed at power users, but developers are the über power user. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 12:35 PM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit : The problem is not to get code in the hands of developers. You don't need distros for that. The problem is to get the code to end-users and developers spend more time fighting the constrains it involves than trying to understand this problem-space. Of course the aim might not be to reach end users but to push code from developpers to other developers. And if that is the case, there is a huge disconnect between GNOME goals and Fedora Workstation goals. GNOME speakers repeat all year round their software is not aimed at power users, but developers are the über power user. Depends on what you mean by power user (I hate this meaningless term) if it means software developer then yes. If it means someone that spends his whole day in config dialogs then no. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Draft Product Description for Fedora Workstation
On Tue, Nov 5, 2013 at 6:35 AM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 4 novembre 2013 23:02, Nicolas Mailhot a écrit : The problem is not to get code in the hands of developers. You don't need distros for that. The problem is to get the code to end-users and developers spend more time fighting the constrains it involves than trying to understand this problem-space. Of course the aim might not be to reach end users but to push code from developpers to other developers. And if that is the case, there is a huge disconnect between GNOME goals and Fedora Workstation goals. GNOME speakers repeat all year round their software is not aimed at power users, but developers are the über power user. Fortunately, the WG can highlight the areas in whatever software they choose that need to be modified to accomplish the WG's goals. And due to the wonderfulness of open source, Fedora can make those changes. Work with whatever upstream is in question to see if there are changes that can be done in a manner that benefit both. Basically, collaboration and compromise are going to be required. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct