'No bundling' policy details (was Re: F21 Self Contained Change: Playground repository)
On Tue, 2014-04-08 at 13:59 -0400, Stephen Gallagher wrote: On 04/08/2014 01:32 PM, Richard Shaw wrote: On Tue, Apr 8, 2014 at 12:23 PM, Rex Dieter rdie...@math.unl.edu mailto:rdie...@math.unl.edu wrote: Stephen Gallagher wrote: Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. Offering users a slightly-less stringent repository such as this makes sense. Adding repos definitely should not be taken lightly. Frankly, if 2 is really something worth doing, then perhaps also the (overly?) stringent policies need rethinking. I freely admit there's definitely some gray area here, and maybe another repo is indeed the right (ie, least-bad) approach. I agree. I'm working on several review requests from the same developer that bundle the same code across his projects (an xmlrpc implementation so each program can talk to each other). He doesn't want to split it out into an independent library because he doesn't want to support its use outside of his own programs, that said I've been working with him to clean it up but it's a long slow process and the software is perfectly usable as is. It's probably not feasible, but If there was a way to track downloads/installs so I would know how many people are using the software it would give me an idea if it's worth the trouble to fix the package to the guidelines or leave it in this repository. In that specific case, my recommendation would be for him to have one of his packages create a subpackage that dropped that library in a non-system location (/usr/lib[64]/myproject-shared/mylib.foo) and then the other packages can link to that library directly. Putting a library in a private location is a clear sign that other projects shouldn't attemp to use it (and that you make no claims whatsoever about its suitability for any other purpose). Sorry for the thread necro, but I just wanted to point out that even without Stephen's approach, I don't think the code in question violates any policies. The policy against bundling reads as follows: https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. At least as I read it, that prohibits the bundling of *previously packaged, system-wide* shared resources. (The following text which elaborates upon the guideline seems to confirm this, for me). I don't believe it prohibits, nor is it intended to prohibit, the packaging of *new* code along the lines described by Richard. Unless one of the packages introduces the code as a system-wide library, and then the other packages include their own 'bundled' copies of that library, I don't think the packages in question would be against the guidelines. It'd be interesting if you could link to the relevant review requests, and anywhere someone has raised the contention that the bundling guideline comes into play. -- 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: 'No bundling' policy details (was Re: F21 Self Contained Change: Playground repository)
On Thu, May 8, 2014 at 2:38 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2014-04-08 at 13:59 -0400, Stephen Gallagher wrote: On 04/08/2014 01:32 PM, Richard Shaw wrote: On Tue, Apr 8, 2014 at 12:23 PM, Rex Dieter rdie...@math.unl.edu mailto:rdie...@math.unl.edu wrote: Stephen Gallagher wrote: Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. Offering users a slightly-less stringent repository such as this makes sense. Adding repos definitely should not be taken lightly. Frankly, if 2 is really something worth doing, then perhaps also the (overly?) stringent policies need rethinking. I freely admit there's definitely some gray area here, and maybe another repo is indeed the right (ie, least-bad) approach. I agree. I'm working on several review requests from the same developer that bundle the same code across his projects (an xmlrpc implementation so each program can talk to each other). He doesn't want to split it out into an independent library because he doesn't want to support its use outside of his own programs, that said I've been working with him to clean it up but it's a long slow process and the software is perfectly usable as is. It's probably not feasible, but If there was a way to track downloads/installs so I would know how many people are using the software it would give me an idea if it's worth the trouble to fix the package to the guidelines or leave it in this repository. In that specific case, my recommendation would be for him to have one of his packages create a subpackage that dropped that library in a non-system location (/usr/lib[64]/myproject-shared/mylib.foo) and then the other packages can link to that library directly. Putting a library in a private location is a clear sign that other projects shouldn't attemp to use it (and that you make no claims whatsoever about its suitability for any other purpose). Sorry for the thread necro, but I just wanted to point out that even without Stephen's approach, I don't think the code in question violates any policies. The policy against bundling reads as follows: https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. At least as I read it, that prohibits the bundling of *previously packaged, system-wide* shared resources. (The following text which elaborates upon the guideline seems to confirm this, for me). I don't believe it prohibits, nor is it intended to prohibit, the packaging of *new* code along the lines described by Richard. Unless one of the packages introduces the code as a system-wide library, and then the other packages include their own 'bundled' copies of that library, I don't think the packages in question would be against the guidelines. It'd be interesting if you could link to the relevant review requests, and anywhere someone has raised the contention that the bundling guideline comes into play. Thank you. That makes sense to me. If he was just bundling the system xmlrpcpp then we would need to do something about it, but it's heavily modified and upstream seems to be dead anyhow. Thanks, 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: F21 Self Contained Change: Playground repository
On 04/15/2014 05:58 PM, Kevin Fenzi wrote: ...snip... Packages for the repository are built in COPR. The COPR owner can propose the repository as a whole for inclusion into the Playground repository by marking it as such in COPR. Repositories/packages successfully built and satisfying the Playground repository's Policies are copied into the Playgroud repository. The one Playground repository includes many Copr repositories. I'm a bit confused here. Is there another repo that all playground packages are copied to? Or are they just seperate copr repos? Ok, on further reading there is a seperate repo. This would be mirrored? No copying, there is not so much space on Copr. It's not a real repository, but set of Copr projects marked as Playground. They will be installed by dnf plugin, I recommend to look how the plugin works: http://dnf.baseurl.org/2014/03/19/copr-plugin/ It will be almost the same for Playground plugin. How is is composed? Just a simple pull all packages from these copr's and createrepo? Will it support multilib, signing, drpms or updateinfo? I see mention that multilib isn't planned at first and that you want to use obs-signd to sign packages. Wouldn't it make sense to look at just using mash (which we use for all other composes). If you did that we could look at signing with sigul and you could get multilib/drpms/etc along for the ride? No compose either, there is nothing to compose, when it stays on Copr. At this point I don't think multilib is possible because Copr repos have to be somehow regenerated and we have to force users to run rebuild for both x86_64 and i686. I'd like to see signing of packages, but our proposal to use obs-signd wasn't accepted well as I heard and sigul is according to his author not nice and should be improved. It was already discussed on devel list before, when Mirek asked about signing packages. Let's do it easy and use only repository of repositories. We can create a real repository with automatic checks for F22, when Taskotron is ready. I guess automatic control and disc space would limit a real repository and I don't believe we could finish it until F21. To avoid any potential confusion, we want to make it clear that the Playground repository will not host packages that have bad licenses, include proprietary software or include patented software. Might change this to all packages advertised in the playground must meet the same legal guidelines as packages in Fedora proper. Some software we ship does have patents, just ones that have patent grants attached. Fine by me, I'll change it. Can you expand on: The repository's repodata is continuously regenerated. All the builds in the COPR repositories that are selected to feed the Playground repository are composed once a day and pushed to the Playground repository and its mirrors. Is the repo composed once a day? Or everytime there is a new build? Hm, I should remove this. The plugin was finished after we discussed these things :) It doesn't make any sense now, I'll update the content. Thanks for review, kevin Marcela -- 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: F21 Self Contained Change: Playground repository
On Thu, Apr 17, 2014 at 3:03 AM, Marcela Mašláňová mmasl...@redhat.com wrote: On 04/15/2014 05:58 PM, Kevin Fenzi wrote: ...snip... Packages for the repository are built in COPR. The COPR owner can propose the repository as a whole for inclusion into the Playground repository by marking it as such in COPR. Repositories/packages successfully built and satisfying the Playground repository's Policies are copied into the Playgroud repository. The one Playground repository includes many Copr repositories. I'm a bit confused here. Is there another repo that all playground packages are copied to? Or are they just seperate copr repos? Ok, on further reading there is a seperate repo. This would be mirrored? No copying, there is not so much space on Copr. It's not a real repository, but set of Copr projects marked as Playground. They will be installed by dnf plugin, I recommend to look how the plugin works: http://dnf.baseurl.org/2014/03/19/copr-plugin/ It will be almost the same for Playground plugin. This reminds me of something else that wasn't clear to some FESCo members yesterday. The wording around dnf being required can seem to imply that you require dnf to replace yum across the entire system. From my understanding, that isn't required and people only need to use dnf if they wish to use the playground plugin. Is that correct? If so you might want to clarify the wording in the requirements section. 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: F21 Self Contained Change: Playground repository
On 04/17/2014 02:34 PM, Josh Boyer wrote: On Thu, Apr 17, 2014 at 3:03 AM, Marcela Mašláňová mmasl...@redhat.com wrote: On 04/15/2014 05:58 PM, Kevin Fenzi wrote: ...snip... Packages for the repository are built in COPR. The COPR owner can propose the repository as a whole for inclusion into the Playground repository by marking it as such in COPR. Repositories/packages successfully built and satisfying the Playground repository's Policies are copied into the Playgroud repository. The one Playground repository includes many Copr repositories. I'm a bit confused here. Is there another repo that all playground packages are copied to? Or are they just seperate copr repos? Ok, on further reading there is a seperate repo. This would be mirrored? No copying, there is not so much space on Copr. It's not a real repository, but set of Copr projects marked as Playground. They will be installed by dnf plugin, I recommend to look how the plugin works: http://dnf.baseurl.org/2014/03/19/copr-plugin/ It will be almost the same for Playground plugin. This reminds me of something else that wasn't clear to some FESCo members yesterday. The wording around dnf being required can seem to imply that you require dnf to replace yum across the entire system. From my understanding, that isn't required and people only need to use dnf if they wish to use the playground plugin. Is that correct? If so you might want to clarify the wording in the requirements section. josh My bad, I thought everyone is testing dnf heavily these days :) You can install yum and dnf without conflicts. Dnf must be used for installation and management of Playground repo, rest of the system can be still handled by yum. Marcela -- 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: F21 Self Contained Change: Playground repository
On 04/08/2014 06:17 PM, Jaroslav Reznik wrote: The Playground repository gives contributors a place to host packages that are not up to the standards of the main Fedora repository but may still be useful to other users. For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and packages that are never going to make it there. Users of the repository should be willing to endure a certain amount of instability when using packages from there. Are there any restrictions on obsoletes/provides between the base Fedora repositories and these playground repositories, (undeclared) file conflicts, paths that can be touched, or restrictions on RPM scripts? -- 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: F21 Self Contained Change: Playground repository
On 04/17/2014 03:03 PM, Florian Weimer wrote: On 04/08/2014 06:17 PM, Jaroslav Reznik wrote: The Playground repository gives contributors a place to host packages that are not up to the standards of the main Fedora repository but may still be useful to other users. For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and packages that are never going to make it there. Users of the repository should be willing to endure a certain amount of instability when using packages from there. Are there any restrictions on obsoletes/provides between the base Fedora repositories and these playground repositories, (undeclared) file conflicts, paths that can be touched, or restrictions on RPM scripts? In fact, it's still an open question [1]. I guess only experienced users will allow Playground, so no worries. But I can be persuaded both ways with good arguments. [1] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29#Open_Questions Marcela -- 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: F21 Self Contained Change: Playground repository
On 04/08/2014 08:23 PM, Kevin Fenzi wrote: So, I need to fully read the change before making more comments, but I thought I would mention Chromium since it seems to come up a lot. Yes, it has a number of bundled things that cannot be easily unbundled. And I would expect that every library bundled by Chromium has already been bundled by something else in Fedora. :-) So it can't be just bundling that blocks Chromium. -- 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: F21 Self Contained Change: Playground repository
On Thu, 17 Apr 2014 09:03:20 +0200 Marcela Mašláňová mmasl...@redhat.com wrote: On 04/15/2014 05:58 PM, Kevin Fenzi wrote: ...snip... Packages for the repository are built in COPR. The COPR owner can propose the repository as a whole for inclusion into the Playground repository by marking it as such in COPR. Repositories/packages successfully built and satisfying the Playground repository's Policies are copied into the Playgroud repository. The one Playground repository includes many Copr repositories. I'm a bit confused here. Is there another repo that all playground packages are copied to? Or are they just seperate copr repos? Ok, on further reading there is a seperate repo. This would be mirrored? No copying, there is not so much space on Copr. It's not a real repository, but set of Copr projects marked as Playground. They will be installed by dnf plugin, I recommend to look how the plugin works: http://dnf.baseurl.org/2014/03/19/copr-plugin/ It will be almost the same for Playground plugin. ok, then you might rephrase the parts of the change that have copied into the playground repository. Perhaps: Repositories/packages successfully built and satisfying the playground repositories policies are made available to users via the dnf playground plugin. 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: F21 Self Contained Change: Playground repository
On 04/17/2014 06:14 PM, Kevin Fenzi wrote: On Thu, 17 Apr 2014 09:03:20 +0200 Marcela Mašláňová mmasl...@redhat.com wrote: On 04/15/2014 05:58 PM, Kevin Fenzi wrote: ...snip... Packages for the repository are built in COPR. The COPR owner can propose the repository as a whole for inclusion into the Playground repository by marking it as such in COPR. Repositories/packages successfully built and satisfying the Playground repository's Policies are copied into the Playgroud repository. The one Playground repository includes many Copr repositories. I'm a bit confused here. Is there another repo that all playground packages are copied to? Or are they just seperate copr repos? Ok, on further reading there is a seperate repo. This would be mirrored? No copying, there is not so much space on Copr. It's not a real repository, but set of Copr projects marked as Playground. They will be installed by dnf plugin, I recommend to look how the plugin works: http://dnf.baseurl.org/2014/03/19/copr-plugin/ It will be almost the same for Playground plugin. ok, then you might rephrase the parts of the change that have copied into the playground repository. Perhaps: Repositories/packages successfully built and satisfying the playground repositories policies are made available to users via the dnf playground plugin. kevin Thanks, fixed too. Marcela -- 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: F21 Self Contained Change: Playground repository
Hi, sorry for being a bit late to the discussion. On Tue, 2014-04-08 at 12:23 -0500, Rex Dieter wrote: Adding repos definitely should not be taken lightly. Frankly, if 2 is really something worth doing, then perhaps also the (overly?) stringent policies need rethinking. The initial idea for the Playground repository came up as a frequently encountered need for something between the current Fedora's main repository and the COPRs. The former is comprised of very high-quality peer-review packages adhering to the Packaging Guidelines and the latter are just user-contributed RPMs which have almost no restrictions (besides being buildable by Copr and complying with the Fedora Licensing guidelines), so they could be of very high quality, very low quality or anything in between. I think this Change brings some cool new opportunities, where Fedora can research some new concepts and innovate: 1) This will be the first more generally-targeted repository that will came out entirely from Copr so we'll be able to see how Copr handles that. 2) Packages destined to the Playground repository will go through automatic testing/gating to ensure that they are up to some basic level of quality. As the tests will be automatic, they could also be repeated on every package update to provide some sort of continuous integration at the package level. If this proves to be successful, we could look at porting this to the main repository. 3) After the Playground sets off and we learn the process of spinning another repository, we could look at creating Playground++, a more stable Ring 2 repository around the main repository. 4) This could also spur some new thoughts on the current Packaging Guidelines and review process (e.g. Which parts are too strict? Which parts take the longest?), and as a consequence, help in improving it. 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: F21 Self Contained Change: Playground repository
...snip... Packages for the repository are built in COPR. The COPR owner can propose the repository as a whole for inclusion into the Playground repository by marking it as such in COPR. Repositories/packages successfully built and satisfying the Playground repository's Policies are copied into the Playgroud repository. The one Playground repository includes many Copr repositories. I'm a bit confused here. Is there another repo that all playground packages are copied to? Or are they just seperate copr repos? Ok, on further reading there is a seperate repo. This would be mirrored? How is is composed? Just a simple pull all packages from these copr's and createrepo? Will it support multilib, signing, drpms or updateinfo? I see mention that multilib isn't planned at first and that you want to use obs-signd to sign packages. Wouldn't it make sense to look at just using mash (which we use for all other composes). If you did that we could look at signing with sigul and you could get multilib/drpms/etc along for the ride? To avoid any potential confusion, we want to make it clear that the Playground repository will not host packages that have bad licenses, include proprietary software or include patented software. Might change this to all packages advertised in the playground must meet the same legal guidelines as packages in Fedora proper. Some software we ship does have patents, just ones that have patent grants attached. Can you expand on: The repository's repodata is continuously regenerated. All the builds in the COPR repositories that are selected to feed the Playground repository are composed once a day and pushed to the Playground repository and its mirrors. Is the repo composed once a day? Or everytime there is a new build? 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: F21 Self Contained Change: Playground repository
On 04/08/2014 10:46 PM, drago01 wrote: On Tue, Apr 8, 2014 at 6:17 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: Playground repository = https://fedoraproject.org/wiki/Changes/Playground_repository Change owner(s): Marcela Mašláňová mmasl...@redhat.com, Mirek Suchý msu...@redhat.com Responsible WG: Env and Stacks WG The Playground repository gives contributors a place to host packages that are not up to the standards of the main Fedora repository but may still be useful to other users. For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and packages that are never going to make it there. Users of the repository should be willing to endure a certain amount of instability when using packages from there. To avoid any potential confusion, we want to make it clear that the Playground repository will not host packages that have bad licenses, include proprietary software or include patented software. What's the point of this feature? I mean if we think we are to strict we might want to rethink the guidelines. And how is that different from other coprs repos where poeple already can host that stuff on? It even uses COPR (and thus shares the same problems like lack of multilib and thus dependecy problems). Is this going to be enabled by default? If yes how it is different from just adding the packages in fedora proper if not why is it a feature at all? It is just yet another external repo. No, it won't be enabled by default. All Coprs acceptable by Playground will be on one place with at least some rules. On our yesterday meeting we spoke to tflink about using taskotron at least for some general tests. We have higher standards on packages going into Playground, but not too high. Marcela -- 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: F21 Self Contained Change: Playground repository
To chime in here, we have been doing something like this in GStreamer for a long while. There is 'plugins-base' and 'plugins-good' plugins which is comparable to the current core Fedora repository. Any plugin going into base or good need to conform to certain coding standards, licensing standards and documentation standards. Then there is 'plugins-ugly' which is more like rpmfusion. It still has the coding and documentation standards, but licensing can be of a wider variety. (Not just 'non-free' as GStreamer do not accept GPL plugins into the base or good repositories either due to being a LGPL toolkit). Finally there is plugins-bad, which is a bit more like what I think Playground will be. It is a repository with plugins which for a variety of reasons are not ready for any of the other ones yet. This could be that they are not of a high enough coding quality yet or lack documentation, but they still 'work'. And what we found over the years, is that while it is good to have high standards for these plugins to stretch towards in order to get included in one of the other modules, having 'bad' available is crucial as a way to get access to plugins that might be critical to their usecase even if they are not up to our technical standards yet. So while it can be frustrating that some plugins end up lingering in bad for a long time, it is still a much better scenario than people deciding GStreamer is useless for them and move somewhere else. Christian - Original Message - From: Stephen Gallagher sgall...@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, April 8, 2014 7:04:54 PM Subject: Re: F21 Self Contained Change: Playground repository -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2014 12:24 PM, Michael Cronenworth wrote: Jaroslav Reznik wrote: For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and *packages that are never going to make it there.* This sounds like a problem and not a feature. Why would packages never make it to Fedora, yet be available in this new repository? My intent here is to be constructive so my question is genuine. I don't believe Fedora should start down the path of a fragmented repository structure. It makes sense for RHEL and its software channels it can sell support for, but Fedora is different. RPMFusion being an exception as it is a legal necessity. My interpretation here is that there exists plenty of genuinely open-source software out there for which it will likely never be possible to package fully according to Fedora's packaging guidelines due to bundling or similar issues (the obvious example being the oft-requested Chromium). Similarly, there are a great many useful Ruby libraries and applications out there for which unbundling them would be an exercise in futility. Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. Offering users a slightly-less stringent repository such as this makes sense. Also packages that are never going to make it there should probably have been phrased more politically: Even if the reality of the situation is that perfect adherence to the Fedora packaging guidelines is infeasible. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNELDYACgkQeiVVYja6o6MoCACggkj5lqoAtzbDxboz94/bxXma wH4AoI33Q7n/z2W+q6+9baU1ohhR7iXg =IzBI -END 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 Self Contained Change: Playground repository
= Proposed Self Contained Change: Playground repository = https://fedoraproject.org/wiki/Changes/Playground_repository Change owner(s): Marcela Mašláňová mmasl...@redhat.com, Mirek Suchý msu...@redhat.com Responsible WG: Env and Stacks WG The Playground repository gives contributors a place to host packages that are not up to the standards of the main Fedora repository but may still be useful to other users. For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and packages that are never going to make it there. Users of the repository should be willing to endure a certain amount of instability when using packages from there. To avoid any potential confusion, we want to make it clear that the Playground repository will not host packages that have bad licenses, include proprietary software or include patented software. == Detailed Description == We are still working on details but the main ideas are finished and described in the [1]. Packages for the repository are built in COPR. The COPR owner can propose the repository as a whole for inclusion into the Playground repository by marking it as such in COPR. Repositories/packages successfully built and satisfying the Playground repository's Policies are copied into the Playgroud repository. The one Playground repository includes many Copr repositories. Playground repository is only meant to provide packages for Fedora 21 and later versions. Initially, the repository will be provided as a Beta for a limited number of packagers and testers, so we'll be able to incrementally define the remaining details of the workings of the repository. To enable the repository, testers will need to use DNF along with its Copr plugin. == Scope == * Proposal owners: ** Document process, setting, guidelines (if any) ** Communicate with Copr developers * Other developers: ** Copr devs *** Ability to mark an individual COPR for inclusion in the Playground repository. *** Copr deployment that's considered reliable enough to build packages for this repo * Policies and guidelines: ** Packages must follow the Legal Guidelines. In particular, the license for all packages must be approved in the Legal Guidelines. ** Packages may violate other Fedora Packaging Guidelines. [1] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_(draft) ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: F21 Self Contained Change: Playground repository
Jaroslav Reznik wrote: For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and *packages that are never going to make it there.* This sounds like a problem and not a feature. Why would packages never make it to Fedora, yet be available in this new repository? My intent here is to be constructive so my question is genuine. I don't believe Fedora should start down the path of a fragmented repository structure. It makes sense for RHEL and its software channels it can sell support for, but Fedora is different. RPMFusion being an exception as it is a legal necessity. -- 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: F21 Self Contained Change: Playground repository
On 08/04/14 18:24, Michael Cronenworth wrote: Jaroslav Reznik wrote: For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and *packages that are never going to make it there.* This sounds like a problem and not a feature. Why would packages never make it to Fedora, yet be available in this new repository? My intent here is to be constructive so my question is genuine. I don't believe Fedora should start down the path of a fragmented repository structure. It makes sense for RHEL and its software channels it can sell support for, but Fedora is different. RPMFusion being an exception as it is a legal necessity. There are other packages hard to package properly, which could rotten in Package Reviews. Mostly it's about bundling, but there is also stuff like Chromium. Marcela -- 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: F21 Self Contained Change: Playground repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2014 12:24 PM, Michael Cronenworth wrote: Jaroslav Reznik wrote: For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and *packages that are never going to make it there.* This sounds like a problem and not a feature. Why would packages never make it to Fedora, yet be available in this new repository? My intent here is to be constructive so my question is genuine. I don't believe Fedora should start down the path of a fragmented repository structure. It makes sense for RHEL and its software channels it can sell support for, but Fedora is different. RPMFusion being an exception as it is a legal necessity. My interpretation here is that there exists plenty of genuinely open-source software out there for which it will likely never be possible to package fully according to Fedora's packaging guidelines due to bundling or similar issues (the obvious example being the oft-requested Chromium). Similarly, there are a great many useful Ruby libraries and applications out there for which unbundling them would be an exercise in futility. Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. Offering users a slightly-less stringent repository such as this makes sense. Also packages that are never going to make it there should probably have been phrased more politically: Even if the reality of the situation is that perfect adherence to the Fedora packaging guidelines is infeasible. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNELDYACgkQeiVVYja6o6MoCACggkj5lqoAtzbDxboz94/bxXma wH4AoI33Q7n/z2W+q6+9baU1ohhR7iXg =IzBI -END 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: F21 Self Contained Change: Playground repository
Stephen Gallagher wrote: Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. Offering users a slightly-less stringent repository such as this makes sense. Adding repos definitely should not be taken lightly. Frankly, if 2 is really something worth doing, then perhaps also the (overly?) stringent policies need rethinking. I freely admit there's definitely some gray area here, and maybe another repo is indeed the right (ie, least-bad) approach. -- Rex -- 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: F21 Self Contained Change: Playground repository
On Tue, Apr 8, 2014 at 12:23 PM, Rex Dieter rdie...@math.unl.edu wrote: Stephen Gallagher wrote: Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. Offering users a slightly-less stringent repository such as this makes sense. Adding repos definitely should not be taken lightly. Frankly, if 2 is really something worth doing, then perhaps also the (overly?) stringent policies need rethinking. I freely admit there's definitely some gray area here, and maybe another repo is indeed the right (ie, least-bad) approach. I agree. I'm working on several review requests from the same developer that bundle the same code across his projects (an xmlrpc implementation so each program can talk to each other). He doesn't want to split it out into an independent library because he doesn't want to support its use outside of his own programs, that said I've been working with him to clean it up but it's a long slow process and the software is perfectly usable as is. It's probably not feasible, but If there was a way to track downloads/installs so I would know how many people are using the software it would give me an idea if it's worth the trouble to fix the package to the guidelines or leave it in this repository. Thanks, 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: F21 Self Contained Change: Playground repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2014 01:32 PM, Richard Shaw wrote: On Tue, Apr 8, 2014 at 12:23 PM, Rex Dieter rdie...@math.unl.edu mailto:rdie...@math.unl.edu wrote: Stephen Gallagher wrote: Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. Offering users a slightly-less stringent repository such as this makes sense. Adding repos definitely should not be taken lightly. Frankly, if 2 is really something worth doing, then perhaps also the (overly?) stringent policies need rethinking. I freely admit there's definitely some gray area here, and maybe another repo is indeed the right (ie, least-bad) approach. I agree. I'm working on several review requests from the same developer that bundle the same code across his projects (an xmlrpc implementation so each program can talk to each other). He doesn't want to split it out into an independent library because he doesn't want to support its use outside of his own programs, that said I've been working with him to clean it up but it's a long slow process and the software is perfectly usable as is. It's probably not feasible, but If there was a way to track downloads/installs so I would know how many people are using the software it would give me an idea if it's worth the trouble to fix the package to the guidelines or leave it in this repository. In that specific case, my recommendation would be for him to have one of his packages create a subpackage that dropped that library in a non-system location (/usr/lib[64]/myproject-shared/mylib.foo) and then the other packages can link to that library directly. Putting a library in a private location is a clear sign that other projects shouldn't attemp to use it (and that you make no claims whatsoever about its suitability for any other purpose). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNEOP0ACgkQeiVVYja6o6OkEgCfbpdmaPIJDPslgFSGBO5pNorM E5gAoKdGM1QcaDWOcdu4/3rM6kf4TGcm =bPiH -END 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: F21 Self Contained Change: Playground repository
On Tue, 08 Apr 2014 18:34:06 +0200 Marcela Mašláňová mmasl...@redhat.com wrote: There are other packages hard to package properly, which could rotten in Package Reviews. Mostly it's about bundling, but there is also stuff like Chromium. So, I need to fully read the change before making more comments, but I thought I would mention Chromium since it seems to come up a lot. Yes, it has a number of bundled things that cannot be easily unbundled. However, earlier this year it also started using another, as far as I know locally created buildsystem. GN at first was not buildable from source at all. However, it seems that they have improved this and you can now build it from source on x86_64 (only). So, aside the bundling, chromium has other issues. Would a package that doesn't build from source be allowed in the playground repo? (ie, uses downloaded GN binaries to build) 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: F21 Self Contained Change: Playground repository
Rex Dieter wrote: Adding repos definitely should not be taken lightly. Frankly, if 2 is really something worth doing, then perhaps also the (overly?) stringent policies need rethinking. I freely admit there's definitely some gray area here, and maybe another repo is indeed the right (ie, least-bad) approach. This type of gray area is what RPMFusion covers. Chromium should be in the free repository, but it appears no one has taken the initiative to do so. Why do we need a third repository for Chromium? -- 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: F21 Self Contained Change: Playground repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2014 03:04 PM, Michael Cronenworth wrote: Rex Dieter wrote: Adding repos definitely should not be taken lightly. Frankly, if 2 is really something worth doing, then perhaps also the (overly?) stringent policies need rethinking. I freely admit there's definitely some gray area here, and maybe another repo is indeed the right (ie, least-bad) approach. This type of gray area is what RPMFusion covers. Chromium should be in the free repository, but it appears no one has taken the initiative to do so. Why do we need a third repository for Chromium? RPMFusion maintains the same restrictions on bundling that Fedora has. Chromium would be unacceptable there as well. RPMFusion allows shipping of packages that are unacceptable for legal reasons in Fedora (usually patents with insufficient licensing). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNEWxAACgkQeiVVYja6o6OyrACfSHIDAbay17kRJ5g8aXIT8C2s wysAn0rIGil9DqLlshPPhcJO7kW+gbND =yE/d -END 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: F21 Self Contained Change: Playground repository
On Tue, Apr 8, 2014 at 6:17 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: Playground repository = https://fedoraproject.org/wiki/Changes/Playground_repository Change owner(s): Marcela Mašláňová mmasl...@redhat.com, Mirek Suchý msu...@redhat.com Responsible WG: Env and Stacks WG The Playground repository gives contributors a place to host packages that are not up to the standards of the main Fedora repository but may still be useful to other users. For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and packages that are never going to make it there. Users of the repository should be willing to endure a certain amount of instability when using packages from there. To avoid any potential confusion, we want to make it clear that the Playground repository will not host packages that have bad licenses, include proprietary software or include patented software. What's the point of this feature? I mean if we think we are to strict we might want to rethink the guidelines. And how is that different from other coprs repos where poeple already can host that stuff on? It even uses COPR (and thus shares the same problems like lack of multilib and thus dependecy problems). Is this going to be enabled by default? If yes how it is different from just adding the packages in fedora proper if not why is it a feature at all? It is just yet another external repo. -- 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: F21 Self Contained Change: Playground repository
On Tue, Apr 08, 2014 at 13:04:54 -0400, Stephen Gallagher sgall...@redhat.com wrote: Similarly, there are a great many useful Ruby libraries and applications out there for which unbundling them would be an exercise in futility. Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. This can result in more work when there are security events. One thing I was happy about with Fedora is that by updating openssl and restarting services I am pretty sure I have blocked that attack. Who is going to do the work searching for bundled libraries when similar events occur in the future? -- 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: F21 Self Contained Change: Playground repository
On Tue, Apr 8, 2014 at 4:54 PM, Bruno Wolff III br...@wolff.to wrote: On Tue, Apr 08, 2014 at 13:04:54 -0400, Stephen Gallagher sgall...@redhat.com wrote: Similarly, there are a great many useful Ruby libraries and applications out there for which unbundling them would be an exercise in futility. Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. This can result in more work when there are security events. One thing I was happy about with Fedora is that by updating openssl and restarting services I am pretty sure I have blocked that attack. Who is going to do the work searching for bundled libraries when similar events occur in the future? Who is doing that work within Fedora today? After the initial review, there is no on-going audit of packages _within_ Fedora to make sure they aren't bundling (or following guidelines at all). That's not to say that we have a massive problem. It _is_ implying that maybe one shouldn't blindly trust the guidelines to catch all of the potential problems 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: F21 Self Contained Change: Playground repository
However, earlier this year it also started using another, as far as I know locally created buildsystem. GN at first was not buildable from source at all. However, it seems that they have improved this and you can now build it from source on x86_64 (only). That sounds problematic - why x86_64 only? Hopefully that could be fixed? BTW shake [1] seems to be able to handle ninja [2]. I posted a review request for it recently. [3] So, aside the bundling, chromium has other issues. Would a package that doesn't build from source be allowed in the playground repo? (ie, uses downloaded GN binaries to build) I would say no. Playground should only contain packages built fully from source. So if chromium is only buildable from source for x86_64 currently then so be it. Jens [1] https://github.com/ndmitchell/shake/blob/master/README.md [2] https://github.com/ndmitchell/shake/blob/master/docs/Ninja.md [3] https://bugzilla.redhat.com/show_bug.cgi?id=1082515 -- 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: F21 Self Contained Change: Playground repository
On Tue, 2014-04-08 at 15:54 -0500, Bruno Wolff III wrote: On Tue, Apr 08, 2014 at 13:04:54 -0400, Stephen Gallagher sgall...@redhat.com wrote: Similarly, there are a great many useful Ruby libraries and applications out there for which unbundling them would be an exercise in futility. Ask yourself which is more important to most users: 1) My OS is perfectly maintainable by engineers. or 2) My OS lets me install the software I need without hassle. This can result in more work when there are security events. One thing I was happy about with Fedora is that by updating openssl and restarting services I am pretty sure I have blocked that attack. Who is going to do the work searching for bundled libraries when similar events occur in the future? I agree with this sentiment about security. I am torn between the raised points 1 and 2. There are many cases where the desire for 2 causes issues because the issues at hand aren't understood. If I wanted to install my awesome software, but then I complain something else isn't working. This blog post is a great example: http://blog.tridgell.net/?p=141 Could this not create more noise on bugzilla because of accidents in playground? There are many cases where people make mistakes about where an error lies (I myself have done it a few times) I understand that Fedora and especially the playground would come, no warranty implied. But surely we must aim for a base quality standard? Instead of this, why not just add a feature in copr to allow a user to link multiple copr builds together to one repository? Or even a user repository that just offers all that users packages in one place? That would seem to be a good middle ground. Copr is a useful tool for testing packages in the build system, and for me, building things to get them onto my systems before the are accepted to fedora, but I also don't feel comfortable installing a playground where every and any developer built package may end up on my system (Unless I am misinterpreting the playground idea ... ) -- William Brown will...@firstyear.id.au -- 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: F21 Self Contained Change: Playground repository
BTW shake [1] seems to be able to handle ninja [2]. I posted a review request for it recently. [3] Erm, okay it seems GN generates ninja files rather than building them so shake probably doesn't help here. -- 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: F21 Self Contained Change: Playground repository
On Tue, Apr 08, 2014 at 20:21:11 -0400, Josh Boyer jwbo...@fedoraproject.org wrote: Who is doing that work within Fedora today? After the initial review, there is no on-going audit of packages _within_ Fedora to make sure they aren't bundling (or following guidelines at all). That's not to say that we have a massive problem. It _is_ implying that maybe one shouldn't blindly trust the guidelines to catch all of the potential problems though. I think there is a difference in people not following guidelines than saying it is OK. Right now there is a reasonable chance that no one has bundled openssl into another official Fedora package. If we explicitly say bundling is OK, then it becomes a lot more likely that libraries end up being bundled. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
