Re: [Proposal] Ring-based Packaging Policies
On Tue, 17 Feb 2015 18:13:23 +0100, Ralf Corsepius wrote: On 02/17/2015 05:59 PM, Matthew Miller wrote: On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_-based distinction — instead, a _technical_ one. I know and understand this, but I expect the outcome to be the same: Ring 0 == Red Hat Ring 1 == The Red Hat business/RHEL-irrelevant parts In other words, on the techicall level I do not see any difference to CentOS+RHEL and to Core+Extras On the political and social level, it raises questions going far beyond these consideration I wonder why it has become silent in this thread already? Is there another place where those ideas get discussed? | https://twitter.com/Worldcleaver/status/565957125600321538 | | Stephen Gallagher @Worldcleaver | | Wherein I kick the hornets' nest again: | https://lists.fedoraproject.org/pipermail/devel/2015-February/207657.html | … (Proposal to relax Fedora packaging requirements in some cases) -- 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: [Proposal] Ring-based Packaging Policies
On Fri, Feb 27, 2015 at 12:32 PM, Michael Schwendt mschwe...@gmail.com wrote: On Tue, 17 Feb 2015 18:13:23 +0100, Ralf Corsepius wrote: On 02/17/2015 05:59 PM, Matthew Miller wrote: On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_-based distinction -- instead, a _technical_ one. I know and understand this, but I expect the outcome to be the same: Ring 0 == Red Hat Ring 1 == The Red Hat business/RHEL-irrelevant parts In other words, on the techicall level I do not see any difference to CentOS+RHEL and to Core+Extras On the political and social level, it raises questions going far beyond these consideration I wonder why it has become silent in this thread already? Because commentary on the proposal was made, and nothing new has been resubmitted? Is there another place where those ideas get discussed? Not that I'm aware of. 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: [Proposal] Ring-based Packaging Policies
On Fri, 2015-02-27 at 18:32 +0100, Michael Schwendt wrote: On Tue, 17 Feb 2015 18:13:23 +0100, Ralf Corsepius wrote: On 02/17/2015 05:59 PM, Matthew Miller wrote: On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_- based distinction — instead, a _technical_ one. I know and understand this, but I expect the outcome to be the same: Ring 0 == Red Hat Ring 1 == The Red Hat business/RHEL-irrelevant parts In other words, on the techicall level I do not see any difference to CentOS+RHEL and to Core+Extras On the political and social level, it raises questions going far beyond these consideration I wonder why it has become silent in this thread already? Is there another place where those ideas get discussed? Speaking only for myself, I'm still digesting the responses. There are some very valid points made and I'm trying to figure out the best way to incorporate some of the ideas. Some valid holes were poked into it (not least because the proposal really is about two different things - ring policy and bundling as a special case - and should probably be divided up and considered independently. Also, I got pulled into some high-priority stuff at $DAYJOB, so my focus has wavered a bit :) This is the best (and really, only) place that this topic should be discussed. I'm vehemently opposed to closed-door meetings for anything involving Fedora policies. Which is why I kicked the hornets' nest publicly. signature.asc Description: This is a digitally signed message part -- 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: [Proposal] Ring-based Packaging Policies
On Sat, Feb 21, 2015 at 04:33:41AM +0100, Lars Seipel wrote: Any new package that is *not* going to be part of the install media set is required to pass a lighter review and is permitted to carry bundled libraries, with caveats to be listed below. What would be the place for higher-quality packages that aren't on any install media (and are also not required to create those)? I think a broad collection of reviewed and guideline-conforming packages is a useful thing to have. Just mixing them together in a single repo with the lower-quality stuff would diminish their value in significant ways. Yeah, in my original rings proposal, I had something called Fedora Commons to represent this. Turns out that name is probably not the best choice, as it is used by the _other_ Fedora, the digital archiving system, so maybe Fedora Collection or something. Stephen's proposal doesn't have anything like that. I agree it's a good idea, but on the other hand I don't want to hold off experimenting with ideas until we have an absolutely perfect plan. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: [Proposal] Ring-based Packaging Policies
On Thu, Feb 12, 2015 at 01:32:04PM -0500, Stephen Gallagher wrote: === Core Packages === Any package that is provided on a release-blocking medium (which at present includes Fedora Atomic, Fedora Cloud, Fedora Server, Fedora Workstation, the KDE Spin and several ARM images) must comply exactly with the packaging guidelines as they are written today. [...] === Ring Packages === Any new package that is *not* going to be part of the install media set is required to pass a lighter review and is permitted to carry bundled libraries, with caveats to be listed below. What would be the place for higher-quality packages that aren't on any install media (and are also not required to create those)? I think a broad collection of reviewed and guideline-conforming packages is a useful thing to have. Just mixing them together in a single repo with the lower-quality stuff would diminish their value in significant ways. -- 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: [Proposal] Ring-based Packaging Policies
Dne 17.2.2015 v 17:18 Petr Pisar napsal(a): On 2015-02-17, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Feb 12, 2015 at 1:32 PM, Stephen Gallagher sgall...@redhat.com wrote: == Proposal == With these things in mind, I'd like to propose that we amend the packaging policy by splitting it into two forms: I think this needs to go beyond simple policy. It needs some buildsystem enforcement as well. [...] With the definition you have here, I'm afraid we are going to be constantly playing is or isn't on whether a package is core or not. E.g. things get sucked into the install media due to dependencies and nobody notices until it's time to trim the size. It just doesn't seem like this would scale, particularly since the distro is rather fluid. Perhaps instead the Base WG could come up with what they consider core, and we could really stick to that? Meaning, things in core cannot Require packages outside of core at runtime. [...] I'm OK with this if Ring packages land in a separated repo. That could be done by having a separate koji target that spits out things into a rings repo. My concern here is that if everything (ring and core combined) lands in the same koji tag and goes through koji just like packages do today, we're going to wind up with a big mess. Having dependencies on ring packages is going to entangle things and make it very hard to clean up later. I agree. While it's tempting to just tune policy a little (i.e. reduce packaging guidelines), it's not enough. The implications are huge (from security, suistainability, trust point of view). My impression from reading this thread is people do not want mixed system. Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? If the repository was fully supported by Fedora project (package databse, dist-git, koji, bodhi, bugzilla) with yum/dnf configuration knowing the easy-for-beginners repository, then both groups (deniers and supporters of the mixed system) would be satisfied. After some time, we can evaluate if the easy-for-beginners repository is a viable solution (from all the points of view I listed above). If the reduced policy is really the golden solution, then we will witness spontaneous move of packages from Fedora to easy-for-beginners repository. -- Petr What is wrong with using Copr for the ring packages. It already works just fine (may be BZ is missing). There are no reviews, no guidelines, you can bundle ... I believe that everybody understands that while Copr is supported by Fedora, you are using these packages on your own risk. I can't imagine better state. Vít -- 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: [Proposal] Ring-based Packaging Policies
On Tue, Feb 17, 2015 at 06:13:23PM +0100, Ralf Corsepius wrote: Core vs. Extras.) But no one is proposing a _society_-based distinction — instead, a _technical_ one. I know and understand this, but I expect the outcome to be the same: Ring 0 == Red Hat Ring 1 == The Red Hat business/RHEL-irrelevant parts In other words, on the techicall level I do not see any difference to CentOS+RHEL and to Core+Extras On the political and social level, it raises questions going far beyond these consideration Ralf, thanks for articulating this concern. You're seeing this from a different perspective than I am, and that's very valuable. I don't expect that outcome, for several reasons. First, the plan is for Ring 0 to be much, much smaller than current RHEL. As I understand it, that aligns with the direction Red Hat would like to go as well (because it fits with the general sweep of the operating system landscape), but independent from that that, the benefits are clear for Fedora on our own. (Better change management, focal point for QA, a place to work on integration improvements without requiring overwhelming thousand-package alterations, easier bootstrap of new architectures or sub-projects, etc.) But, a tiny Ring 0 is too small to be practically useful to most actual end users — Fedora users, but also RHEL customers. So, just as Fedora's interests in quality, integration, usability, and so on extend beyond that first ring, so do Red Hat's. In fact, second, Red Hat is much bigger than RHEL, and Red Hat has significant business interests based on not just Rings 0 and 1, but also what I called Ring 2 (environments and stacks) and Ring 3, applications. So, if the concern is that RH is planning to abandon investment in everything in Fedora except the minimal part, I wouldn't worry. In fact, one explicit hope I have here is that we can do this in a way that attracts engagement in Fedora from parts of Red Hat that have traditionally had difficulties, including the middleware/WildFly world, OpenShift, and (not to detract from the degree that it does work and the effort people have put in) OpenStack. I think, though, I hear at least a suggestion of an opposite concern: that Red Hat will end up the sole owner of Ring 0. So, third (and I'm going to go ahead and say most importantly), that is an explicit non-goal. That's true from a Fedora-plan point of view, and also, for the record, I hear no one inside Red Hat agitating for anything otherwise. The benefits of keeping Fedora community-based at all levels are clear and understood. Technical oversight and decision-making will still come from FESCo, and the Base Working Group as a FESCo sub-committee. Ownership of packages in Ring 0 (or any ring) will continue to be agnostic of employer, and official Change proposals evaluated by community leadership on their own merits. So, while there may be superficial similarity, it's quite a different plan, and I don't worry that the outcome will be what you're afraid of. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: [Proposal] Ring-based Packaging Policies
Dne 18.2.2015 v 12:52 Rahul Sundaram napsal(a): Hi What is wrong with using Copr for the ring packages. It already works just fine (may be BZ is missing). There are no reviews, no guidelines, you can bundle ... I believe that everybody understands that while Copr is supported by Fedora, you are using these packages on your own risk. I can't imagine better state. That's easy to imagine * Searching for packages in copr from the command line and GUI should be trivial * There should be a difference between experimental random builds of the day and packages which have gone through some review process even if it does include some bundling * Formalized bug reporting * pkgdb, tagger, bodhi etc Yes, and at the end you reach the current state of Fedora (with bundling) ... just going in circles. Vít -- 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: [Proposal] Ring-based Packaging Policies
Hi What is wrong with using Copr for the ring packages. It already works just fine (may be BZ is missing). There are no reviews, no guidelines, you can bundle ... I believe that everybody understands that while Copr is supported by Fedora, you are using these packages on your own risk. I can't imagine better state. That's easy to imagine * Searching for packages in copr from the command line and GUI should be trivial * There should be a difference between experimental random builds of the day and packages which have gone through some review process even if it does include some bundling * Formalized bug reporting * pkgdb, tagger, bodhi 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: [Proposal] Ring-based Packaging Policies
On Wed, Feb 18, 2015 at 08:58:34AM -0500, Stephen Gallagher wrote: On Mon, 2015-02-16 at 17:03 +0100, Kevin Kofler wrote: So, for my counterproposal: I propose that packagers with a sufficient level of trust (packager sponsors, provenpackagers, or a new, yet-to-be-defined group (maybe packagers with at least N packages)) be allowed to import new packages with a self-review. We trust those people for so many things, and we know that they understand the packaging guidelines, so why can we not trust them to import their own packages without blocking on somebody else? Here are just 2 examples of packages that have been sitting in the queue for months and would have gone in instantly with my proposed policy: https://bugzilla.redhat.com/show_bug.cgi?id=922781 https://bugzilla.redhat.com/show_bug.cgi?id=1125952 The submitter has been a packager sponsor and provenpackager for years (and even several of the people he sponsored are now also packager sponsors and/or provenpackagers), so why do we need to waste our time reviewing his packages when it's clear that he knows what he's doing? This is an interesting idea (and one that could be investigated irrespective of the original discussion). In the last few years, the fedora-review project has made the review process significantly easier for many packages. It covers a lot of the policies that are automatable, thereby reducing the packager requirements. Elsewhere in this thread, it was suggested that we could further improve the process by taking reviews out of Bugzilla and building a tool specifically for this purpose. If we built this atop fedora-review, we could make large parts of the review-submission process automated. (Automated guideline checks for those things that *can* be automated, automatically perform koji scratch builds for each architecture, etc.) With something like that in place to provide at least a minimal level of review, we probably *could* give members of the provenpackager and/or sponsors groups permission to pass a review solely based on those results (plus a manual checkbox of this is permissible content). In parallel with another discussion on the list, this could be a really worthwhile effort for the Google Summer of Code this year. Maybe Michel Salim (CCed) would be interested in having the fedora-review team mentor two or three interns to work on a web-app version of fedora-review? While I agree that it makes a nice project for a GSoC, it is my experience that we should not have too many students working on the same project. Most often they will overlap and might even conflict. So having one perhaps two (and that's a grand max imho) students might be interesting indeed. For further reference about this project: https://www.youtube.com/watch?v=PJ-Hjb1UrXw https://github.com/fedora-infra/fresque Because it's not completely a new idea nor has there been no work started on it :) Pierre pgpw9i0hHfIb0.pgp 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: [Proposal] Ring-based Packaging Policies
On 2015-02-18, Vít Ondruch vondr...@redhat.com wrote: Dne 18.2.2015 v 12:52 Rahul Sundaram napsal(a): What is wrong with using Copr for the ring packages. It already works just fine (may be BZ is missing). There are no reviews, no guidelin= es, you can bundle ... I believe that everybody understands that while Copr is supported by Fedora, you are using these packages on your own risk. I can't imagine better state. That's easy to imagine * Searching for packages in copr from the command line and GUI should be trivial * There should be a difference between experimental random builds of the day and packages which have gone through some review process even if it does include some bundling * Formalized bug reporting * pkgdb, tagger, bodhi etc Yes, and at the end you reach the current state of Fedora (with bundling) ... just going in circles. Yes. And that's was the point: To have the packages in Fedora. Users really don't care about repository the software comes from, if it's seamlessly integrated into the native package manager. With Copr there is no such user experience. -- Petr -- 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: [Proposal] Ring-based Packaging Policies
On Mon, 2015-02-16 at 17:03 +0100, Kevin Kofler wrote: So, for my counterproposal: I propose that packagers with a sufficient level of trust (packager sponsors, provenpackagers, or a new, yet-to-be-defined group (maybe packagers with at least N packages)) be allowed to import new packages with a self-review. We trust those people for so many things, and we know that they understand the packaging guidelines, so why can we not trust them to import their own packages without blocking on somebody else? Here are just 2 examples of packages that have been sitting in the queue for months and would have gone in instantly with my proposed policy: https://bugzilla.redhat.com/show_bug.cgi?id=922781 https://bugzilla.redhat.com/show_bug.cgi?id=1125952 The submitter has been a packager sponsor and provenpackager for years (and even several of the people he sponsored are now also packager sponsors and/or provenpackagers), so why do we need to waste our time reviewing his packages when it's clear that he knows what he's doing? This is an interesting idea (and one that could be investigated irrespective of the original discussion). In the last few years, the fedora-review project has made the review process significantly easier for many packages. It covers a lot of the policies that are automatable, thereby reducing the packager requirements. Elsewhere in this thread, it was suggested that we could further improve the process by taking reviews out of Bugzilla and building a tool specifically for this purpose. If we built this atop fedora-review, we could make large parts of the review-submission process automated. (Automated guideline checks for those things that *can* be automated, automatically perform koji scratch builds for each architecture, etc.) With something like that in place to provide at least a minimal level of review, we probably *could* give members of the provenpackager and/or sponsors groups permission to pass a review solely based on those results (plus a manual checkbox of this is permissible content). In parallel with another discussion on the list, this could be a really worthwhile effort for the Google Summer of Code this year. Maybe Michel Salim (CCed) would be interested in having the fedora-review team mentor two or three interns to work on a web-app version of fedora-review? signature.asc Description: This is a digitally signed message part -- 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: [Proposal] Ring-based Packaging Policies
On 2015-02-17, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Feb 12, 2015 at 1:32 PM, Stephen Gallagher sgall...@redhat.com wrote: == Proposal == With these things in mind, I'd like to propose that we amend the packaging policy by splitting it into two forms: I think this needs to go beyond simple policy. It needs some buildsystem enforcement as well. [...] With the definition you have here, I'm afraid we are going to be constantly playing is or isn't on whether a package is core or not. E.g. things get sucked into the install media due to dependencies and nobody notices until it's time to trim the size. It just doesn't seem like this would scale, particularly since the distro is rather fluid. Perhaps instead the Base WG could come up with what they consider core, and we could really stick to that? Meaning, things in core cannot Require packages outside of core at runtime. [...] I'm OK with this if Ring packages land in a separated repo. That could be done by having a separate koji target that spits out things into a rings repo. My concern here is that if everything (ring and core combined) lands in the same koji tag and goes through koji just like packages do today, we're going to wind up with a big mess. Having dependencies on ring packages is going to entangle things and make it very hard to clean up later. I agree. While it's tempting to just tune policy a little (i.e. reduce packaging guidelines), it's not enough. The implications are huge (from security, suistainability, trust point of view). My impression from reading this thread is people do not want mixed system. Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? If the repository was fully supported by Fedora project (package databse, dist-git, koji, bodhi, bugzilla) with yum/dnf configuration knowing the easy-for-beginners repository, then both groups (deniers and supporters of the mixed system) would be satisfied. After some time, we can evaluate if the easy-for-beginners repository is a viable solution (from all the points of view I listed above). If the reduced policy is really the golden solution, then we will witness spontaneous move of packages from Fedora to easy-for-beginners repository. -- Petr -- 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: [Proposal] Ring-based Packaging Policies
On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_-based distinction — instead, a _technical_ one. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: [Proposal] Ring-based Packaging Policies
On Wed, Feb 18, 2015 at 12:54:24AM +0800, Mathieu Bridon wrote: Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way. The comparison isn't really valid, the difference between the two repos is not technical but more based on the license/re-distribution rights. While, what has been mentioned before would be two repos having the same redistribution policy but two different technical requirements. Pierre -- 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: [Proposal] Ring-based Packaging Policies
Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way. The only difference in both repositories is the license of the software. The package guidelines are exactly the same as Fedora's (with the exception of kernel modules) in both repos. At another scale, it seems to not be working too badly already for Fedora+RPMFusion, where Fedora and RPMFusion have different standards for inclusion, and where packages in RPMFusion can depend on packages in Fedora, but not the other way. The standard for inclusion in rpmfusion is not being elegible to be in Fedora. Again, the reasons are purelly legal (with the exception of kernel modules). Again, there is no difference in the guidelines (bundled libraries must be unblundled, etc) -- 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: [Proposal] Ring-based Packaging Policies
Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way. At another scale, it seems to not be working too badly already for Fedora+RPMFusion, where Fedora and RPMFusion have different standards for inclusion, and where packages in RPMFusion can depend on packages in Fedora, but not the other way. If I understand correctly, Ubuntu has a similar setup with main and universe, and so does Debian with main, contrib and nonfree. History doesn't seem to unambiguously prove what you think it does, but then I guess you can always argue that those examples just haven't failed yet. ;) -- Mathieu -- 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: [Proposal] Ring-based Packaging Policies
On 02/17/2015 05:54 PM, Mathieu Bridon wrote: Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way. RPMFusion working fine? Sorry, but I vehemently disagree with this. Many of their packages are of low quality and their infrastructure is more dead than alive. History doesn't seem to unambiguously prove what you think it does, but then I guess you can always argue that those examples just haven't failed yet. ;) I am referring to RHL + Powertools (?) (A historic desaster) and many of these distro life cycle extending attempts (RHL had one I don't even recall the name; Recently SuSE's Everlast went down). Ralf -- 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: [Proposal] Ring-based Packaging Policies
On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. Ralf -- 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: [Proposal] Ring-based Packaging Policies
On 02/17/2015 05:59 PM, Matthew Miller wrote: On Tue, Feb 17, 2015 at 05:39:48PM +0100, Ralf Corsepius wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. If the distinction were drawn based on _who_ rather than _what and why_, it would. (And that was fundamentally the problem with the old Core vs. Extras.) But no one is proposing a _society_-based distinction — instead, a _technical_ one. I know and understand this, but I expect the outcome to be the same: Ring 0 == Red Hat Ring 1 == The Red Hat business/RHEL-irrelevant parts In other words, on the techicall level I do not see any difference to CentOS+RHEL and to Core+Extras On the political and social level, it raises questions going far beyond these consideration Ralf -- 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: [Proposal] Ring-based Packaging Policies
On Thu, Feb 12, 2015 at 1:32 PM, Stephen Gallagher sgall...@redhat.com wrote:
== Proposal ==
With these things in mind, I'd like to propose that we amend the
packaging policy by splitting it into two forms:
I think this needs to go beyond simple policy. It needs some
buildsystem enforcement as well.
=== Core Packages ===
Any package that is provided on a release-blocking medium (which at
present includes Fedora Atomic, Fedora Cloud, Fedora Server, Fedora
Workstation, the KDE Spin and several ARM images) must comply exactly
with the packaging guidelines as they are written today. These packages
must receive a full package review *when they are added to the install
media*. Any package present on the media if this proposal is adopted is
exempted from this requirement. Any package to newly appear on the
install media after this time *should* (I hate that word...) receive a
new package review, even if it is already present in Fedora.
With the definition you have here, I'm afraid we are going to be
constantly playing is or isn't on whether a package is core or not.
E.g. things get sucked into the install media due to dependencies and
nobody notices until it's time to trim the size. It just doesn't seem
like this would scale, particularly since the distro is rather fluid.
Perhaps instead the Base WG could come up with what they consider
core, and we could really stick to that? Meaning, things in core
cannot Require packages outside of core at runtime.
=== Ring Packages ===
Any new package that is *not* going to be part of the install media set
is required to pass a lighter review and is permitted to carry bundled
libraries, with caveats to be listed below.
I'm OK with this if Ring packages land in a separated repo. That
could be done by having a separate koji target that spits out things
into a rings repo.
My concern here is that if everything (ring and core combined) lands
in the same koji tag and goes through koji just like packages do
today, we're going to wind up with a big mess. Having dependencies on
ring packages is going to entangle things and make it very hard to
clean up later.
Ring Package Review Requirements
* A reviewer *MUST* establish suitability for the Fedora Project. This
means verifying that the package contains only permissible content
(legally-speaking).
* The package *MUST* conform to the FHS and other filesystem conventions
used by Fedora (such as %{python3_sitelib}), except when granted an
exception by the FPC.
* The package *MAY* contain bundled libraries or other projects, but if
it does so, it *MUST* contain a Provides: bundled(pkg) = version for
each such bundling. This is done so that we can use the meta-data to
identify which packages may be vulnerable in the event of a security
issue.
== Conclusion ==
So that is my proposal to consider for Fedora 23+ (it's too late in the
Fedora 22 cycle to consider this, but I'd prefer starting the F23
discussion right away). Comments and suggestions are strongly
encouraged.
Thank you for reading to the end.
I don't think the proposal is a bad start, but I'm concerned it isn't enough.
What I would really like to see if a proposal that focuses on the two
different needs: 1) packages that are used for the Operating System
(the distro/OS) 2) packages that run on the OS (Apps?). Packages that
are used to create Fedora itself should by most definitions wind up
being Core packages in your proposal here, regardless of whether they
are on install media (pretty sure gcc should be core...). Packages
that people want to run on top of Fedora could be the ring set. Some
might call that Core+Extras but that isn't my intention. Packages
in the ring set could move to core easily once they are cleaned up and
meet the existing FPC guidelines. There is also no separation of
schedule or dist-git or buildsystem or ACLs.
Really, I would like to see the Ring set of things not be RPMs at all.
RPMs are system wide installation. I know Dan Walsh would say that
containers do not contain, but the security model around them is
slightly better than blasting an RPM that bundles a bunch of stuff
onto the entire system. However, there is significant technical work
for that to be feasible and it isn't clear that there is a container
technology that is well suited for non-network apps yet.
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: [Proposal] Ring-based Packaging Policies
Am 17.02.2015 um 17:54 schrieb Mathieu Bridon: Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way maybe you are newer to Fedora than me what you describe is what was changed around Fedora 7 http://en.wikipedia.org/wiki/Fedora_%28operating_system%29#History * Fedora Core: Only Redhat * Fedora Extras: Community not that i say that was bad *but* it was changed intentional after the distribution is now claaed jsut Fedora you can turn and name it how you like but at the end of the day it would mean going back to the state of Fedora Core 6 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: [Proposal] Ring-based Packaging Policies
On Tue, Feb 17, 2015 at 08:05:30PM +0100, Reindl Harald wrote: Am 17.02.2015 um 17:54 schrieb Mathieu Bridon: Le mardi 17 février 2015 à 17:39 +0100, Ralf Corsepius a écrit : On 02/17/2015 05:18 PM, Petr Pisar wrote: Why not to create a new repository with reduced policy as Stephen proposed with the one-way dependency rule (between current Fedora and the new easy-for-beginners repository)? Because this would establish a 2-class society, with double standards standards and so on. Also RH and other distros history repeatedly has told the lesson such will not fly and are doomed to fail. It seems to have been working just fine in RPMFusion, where the free and nonfree repositories have different standards for inclusion, and where packages in nonfree can depend on packages in free, but not the other way maybe you are newer to Fedora than me what you describe is what was changed around Fedora 7 http://en.wikipedia.org/wiki/Fedora_%28operating_system%29#History * Fedora Core: Only Redhat * Fedora Extras: Community not that i say that was bad *but* it was changed intentional after the distribution is now claaed jsut Fedora you can turn and name it how you like but at the end of the day it would mean going back to the state of Fedora Core 6 This isn't correct. The division of Core/Extras was based on who was allowed to touch packages which isn't part of this proposal. That wasn't a sustainable way to build community. -- 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: [Proposal] Ring-based Packaging Policies
Stephen Gallagher wrote:
tl;dr Shall we consider requiring a lesser package review for packages
that are not present on Product or Spin install media?
TL;DR: No, at least not in the form you propose (allowing bundled
libraries). See also my counterproposal below (voiced already in the oral
discussion at DevConf, now written down for posterity).
* The no-bundled-libraries policy means that when a library module
requires an update, it means that only one package needs to be modified
in order to enhance all applications on the system that consumes it.
This is a significant time-saver when it comes to dealing with
(increasingly common) security vulnerabilities.
Indeed, this helps both security fixes and regular bug fixes.
Another advantage of the policy is to save both disk space and RAM by
avoiding duplication.
* Legal review and the FPCA ensures that Fedora remains true to its
Freedom Foundation (as well as protecting Fedora contributors from the
perils of the international legal system).
And this part must not be negotiable.
* Package reviews for less-interesting packages (such as those for less
popular SIGs) often remain un-reviewed for weeks, months or even years.
See my counterproposal below.
* The package policies are only ever reviewed during the initial
creation of the package. Once that initial (high) hurdle is cleared, the
packager essentially has free reign to do whatever they want with their
package. This sometimes means that as time passes, the spec files
bit-rot or otherwise start accumulating other inconsistencies. (A
common example is the package whose upstream starts bundling a library
without the packager noticing).
Surely the answer to that cannot be to simply allow poor quality from day
one.
* Many upstream projects do not concern themselves with being in any
particular distribution (with the notable example being the
Debian/Ubuntu flavors which have amassed a sufficient apparent userbase
that they sometimes get special treatment). For a variety of reasons,
this often leads directly to bundling the vast majority of their
dependencies. This is done for many reasons, but the two most common are
supportability and portability; it's impossible for many upstreams to
actually QA their package with every possible distro library. Instead,
if they ship everything they depend on, they can guarantee *that*
specific combination. This moves the responsibility from the
distribution to the upstream package to maintain their bundled
libraries.
And that is not practical, also because it is then OUR responsibility to
update to the new application that updates to the new bundled libraries.
This just does not scale. Without bundled libraries, when we get notified of
a security issue, we have to update the library and be done with it. With
bundled libraries, we have to do one of the following processes:
a) working with upstream:
for each package bundling the library {
1. forward the security notification to its upstream
2. wait for upstream to update the bundled library. We have no SLA
whatsoever there, so this can take theoretically forever!
3. pick up the new upstream release with the new bundled library
4. push that as an update to our users, with the required testing for a
new upstream release (typically longer than for a simple CVE fix)
}
Not only is this O(n) instead of O(1), but it also takes way too long for
any security issue of sufficient importance.
b) bypassing upstream:
for each package bundling the library {
1. patch the bundled library ourselves
2. push the updated application
}
Now this moves the delay again into our area of responsibility, so it can
be done faster (eliminating the wait for upstream), but it is still O(n)
instead of O(1) as in the unbundled case. In addition, this solution also
has the usual problems of downstream patches. In particular, once the
official upstream patch comes out, we need to drop our downstream patch,
and then also have ANOTHER round of testing with the new upstream
release.
So the only reasonable solution is to unbundle all the libraries, no matter
what upstream thinks of that.
* With many languages, there is no possibility of installing multiple
versions of the same library on the same system, so if an application
requires a newer or older version of the library than is in Fedora to
run, it fails.
In this case, it is the packager's job to fix the program to work with the
version of the library in the distribution. That's what we distributors are
for.
I am also not convinced that this bundling issue is the main blocker for
package reviews to begin with.
So, for my counterproposal:
I propose that packagers with a sufficient level of trust (packager
sponsors, provenpackagers, or a new, yet-to-be-defined group (maybe
packagers with at least N packages)) be allowed to import new packages with
a self-review. We
Re: [Proposal] Ring-based Packaging Policies
On Mon, 16 Feb 2015 17:03:51 +0100, Kevin Kofler wrote: So, for my counterproposal: I propose that packagers with a sufficient level of trust (packager sponsors, provenpackagers, or a new, yet-to-be-defined group (maybe packagers with at least N packages)) be allowed to import new packages with a self-review. We trust those people for so many things, and we know that they understand the packaging guidelines, so why can we not trust them to import their own packages without blocking on somebody else? In case your suggestion includes a form of explicit self-approval, there ought to be a few requirements for the packager to document what has been reviewed. And possibly a short window when somebody may jump in and contribute a real review or to block the package. New packages often contain fundamental packaging mistakes, because a packager may have stopped as soon as a build had succeeded. A second pair of eyes can make a difference. Not all submitters of new packages perform self-reviews. They don't run fedora-review. They don't even do test-builds and test-installs for all target dists. The guidelines read much more as if only the reviewers is the one to perform the review (and be the one to blame in case something slips through). = Every package submitter should attempt at doing a self-review. Here are just 2 examples of packages that have been sitting in the queue for months and would have gone in instantly with my proposed policy: https://bugzilla.redhat.com/show_bug.cgi?id=922781 It blocks the kde-reviews tracker ticket. So, is it correct to assume that the KDE Sig has not found time to approve this quickly despite your claims that it would be safe to give blanket approval? There hasn't been an answer to the last comment, btw. No responding is #1 reason for stalled reviews. https://bugzilla.redhat.com/show_bug.cgi?id=1125952 Assigned to a reviewer since Aug 2014, and it has taken many months for an update to appear in Jan 2015. That's progress! The submitter has been a packager sponsor and provenpackager for years (and even several of the people he sponsored are now also packager sponsors and/or provenpackagers), so why do we need to waste our time reviewing his packages when it's clear that he knows what he's doing? And still there are counter-examples. Now I don't keep a log of what really broken packages I run into (including ones that misplace files or don't work at runtime), but cases like the following are packaged to death and highly questionable: https://bugzilla.redhat.com/1175952 Hint: also compare with the duplicate that's packaged differently. Plus, no progress if not even two people team up. -- 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: [Proposal] Ring-based Packaging Policies
On Sun, 15 Feb 2015 13:32:57 -0600 Jason L Tibbitts III ti...@math.uh.edu wrote: KF == Kevin Fenzi ke...@scrye.com writes: ...snip... KF Additionally, FPC folks have done a great job recently (mostly due KF to Tibbs hard work) in catching up with their backlog. Bundling KF requests I would think would be much quicker than in the past. I appreciate the shoutout but James has been doing a ton of work too. Thanks to both of you! (and the other FPC folks) Anyway, I think we're going to do much better with not letting things fall through the cracks, and to update when things don't get discussed in a meeting. However, nothing is going to help the tickets sitting in needinfo. We can't track down all of the requested information ourselves. KF Some ideas about the review queue: Honestly I would really, really like to have a completely separate discussion about the review queue. Getting things hung up on bundling isn't the best way to make easy progress on any of the other issues. Sure. agreed. It just seemed like this proposal was two parts: relaxing bunding and reviews. KF * Get some pool of people interested in being triage for the KF queue. ie, check that things build, run fedora-review on them, KF point submittors to how to get sponsored docs, close old reviews KF with no response, etc. Easy: Most ofhis stuff needs to be submitted initially. I would ping and eventually close any review tickets where the submitter hasn't provided this information. And I have done this in the past; it's pretty thankless. Now that I'm mostly done cleaning up FPC stuff I might be able to find some time to garden the review queue, but I certainly wouldn't get in the way of anyone else wanting to do it. I think a lot of this could be automated. If our bugzilla to fedmsg connector finally appears we could even do it then. ie, new review submmited gets a fedmsg that a bot/script checks the new review, asks for missing stuff, runs various checks, etc. KF * Moving reviews out of bugzilla has been proposed and some work I KF think has been done for an app to do that. Bugzilla is merely a sort-of-convenient place to put reviews and it provides something we can bodge into a workflow, but I don't think anyone would complain if it moved somewhere else and if more things were automated. I suppose fedora-review itself could also grow a way to submit a reasonable review to bugzilla if someone hasn't already written a tool to do that. Yeah, with a review app we could do a lot of checking up front and only submit the actual review once it passed that. kevin pgpwyh_SqmCjo.pgp 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: [Proposal] Ring-based Packaging Policies
KF == Kevin Fenzi ke...@scrye.com writes: KF I know in the past the FPC has talked about relaxing the bundling KF guidelines, perhaps we could get some of them to weigh in here? Yeah, we had a big discussion about that a while back, where we sort of agreed on a basic change of philosophy regarding some cases of bundling, and an acceptance of reality in others. Unfortunately this was done back when the committee was a bit more dysfunctional than it is now, and I'm not sure it actually got written down. Which means that I have digging through a couple of years of meeting logs on my schedule. And in any case, I'm not sure it would really help in the majority of cases involved here. But it might help. Really the reason we fail to approve most bundling requests is because nobody bothers to provide us with the information we ask for. (Things like some statement of why the upstreams believe they need to bundle, whether any of the upstreams are amenable to patches, an assement of whether they actually track changes to the things they bundle, what kind of changes they make to what they bundle, etc.) I think having these is really kind of important to avoid just shoveling random stuff into random other stuff for reasons which aren't clear to anyone on our (Fedora's) side, even if we were to drastically relax the rules. KF Additionally, FPC folks have done a great job recently (mostly due KF to Tibbs hard work) in catching up with their backlog. Bundling KF requests I would think would be much quicker than in the past. I appreciate the shoutout but James has been doing a ton of work too. Anyway, I think we're going to do much better with not letting things fall through the cracks, and to update when things don't get discussed in a meeting. However, nothing is going to help the tickets sitting in needinfo. We can't track down all of the requested information ourselves. KF Some ideas about the review queue: Honestly I would really, really like to have a completely separate discussion about the review queue. Getting things hung up on bundling isn't the best way to make easy progress on any of the other issues. KF * Get some pool of people interested in being triage for the KF queue. ie, check that things build, run fedora-review on them, KF point submittors to how to get sponsored docs, close old reviews KF with no response, etc. Easy: Most ofhis stuff needs to be submitted initially. I would ping and eventually close any review tickets where the submitter hasn't provided this information. And I have done this in the past; it's pretty thankless. Now that I'm mostly done cleaning up FPC stuff I might be able to find some time to garden the review queue, but I certainly wouldn't get in the way of anyone else wanting to do it. KF * Moving reviews out of bugzilla has been proposed and some work I KF think has been done for an app to do that. Bugzilla is merely a sort-of-convenient place to put reviews and it provides something we can bodge into a workflow, but I don't think anyone would complain if it moved somewhere else and if more things were automated. I suppose fedora-review itself could also grow a way to submit a reasonable review to bugzilla if someone hasn't already written a tool to do that. - J -- 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: [Proposal] Ring-based Packaging Policies
On Thu, Feb 12, 2015 at 7:32 PM, Stephen Gallagher sgall...@redhat.com wrote: (Logistical note: please keep all replies to this thread on devel@lists.fedoraproject.org) [...] === Core Packages === Any package that is provided on a release-blocking medium (which at present includes Fedora Atomic, Fedora Cloud, Fedora Server, Fedora Workstation, the KDE Spin and several ARM images) must comply exactly with the packaging guidelines as they are written today. These packages must receive a full package review *when they are added to the install media*. Any package present on the media if this proposal is adopted is exempted from this requirement. Any package to newly appear on the install media after this time *should* (I hate that word...) receive a new package review, even if it is already present in Fedora. === Ring Packages === Any new package that is *not* going to be part of the install media set is required to pass a lighter review and is permitted to carry bundled libraries, with caveats to be listed below. This is completely backwards ... what we wanted to do is to make package is installed by default less important in favor of we have a working software installing experience just install it afterwards ... What you are doing here is to lessen the quality of the latter. Also I am not buying that bundles libraries are that much of an issue ... do you have any data to back this up? Other then chromium I cannot think of any package that is out of fedora because of this. Most packages just sit in the review queue due to lack of reviewers not due to bundles libraries. -- 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: [Proposal] Ring-based Packaging Policies
On 02/12/2015 07:32 PM, Stephen Gallagher wrote: (Logistical note: please keep all replies to this thread on devel@lists.fedoraproject.org) tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? == Premise == So, some time ago, we started talking about dividing up the Fedora package set into a series of rings. One of the driving purposes behind this idea was to re-evaluate our policies for packaging in each of these rings. In first place, let me mention that I am not fond of these rings and would prefer this idea to be dumped. * The no-bundled-libraries policy means that when a library module requires an update, it means that only one package needs to be modified in order to enhance all applications on the system that consumes it. This is a significant time-saver when it comes to dealing with (increasingly common) security vulnerabilities. It is significant improver and key feature to avoid and fight bugs and vulnerability. Actually I believe, those people who endorse bundling may not have experienced yet the harm bundling can cause and indeed has caused in the early days of Linux. === Disadvantages === * Very strict policies often leads to potential packagers giving up. That's on purpose. Of cause we the #1 objective is quality, but we set the hurdles high to weed out low-quality code and drive-by package submissions. Both were actual problems in the early days of Fedora. * Package reviews for less-interesting packages (such as those for less popular SIGs) often remain un-reviewed for weeks, months or even years. Well, this had been a problem of the Fedora review process ever since, which has many origins, IMO. 1. Open reviews are hard to find. 2. The principle of assigning reviews (owning reviews) discourages prospective reviewers. 3. Interesting packages/reviews are hard to find. I think Fedora has reached the point, most new submissions only address niches. 4. There are people who seem to be striving for badges, by picking low hanging fruits (easy packages). IMO, these people are harmful to Fedora because they are violently locking out other reviewers. 5. The administrational noise. Fedora has adopted an amount of bureaucracy and administrational overhead, which is driving away packagers (Just count the steps and mails maintainers receive until a package has been released). I for one can not avoid to simply erase them because the amount is overwhelming. ... == Analysis == First, I will make an assumption based on the First Foundation: We as the Fedora Project want people to have access to the software that they desire. We may disagree on how that is to be achieved, but I believe the goal is the same. Second, I will call attention to the fact that different Fedora users have very different needs from the software. For example, those running Fedora Server and Fedora Cloud are likely far more concerned with Fedora as a *deployment* platform than they are as a *development* platform. Correct. To me, e.g. Fedora Server and Cloud are not of any interest. No problem with this, unless it's going to harm my deployment. Packaging software for development and packaging it for real-world deployment can be very different. I do not agree. IMO, these are simply different configurations. But I agree insofar, as Fedora doesn't have the appropriate tooling to support such configurations. == Conclusion == So that is my proposal to consider for Fedora 23+ (it's too late in the Fedora 22 cycle to consider this, but I'd prefer starting the F23 discussion right away). Comments and suggestions are strongly encouraged. I regret, but IMO, the rings and different spins are just a waste of valuable and apparently scarce resources, which should better be invested elsewhere in Fedora. Ralf -- 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: [Proposal] Ring-based Packaging Policies
On Fri Feb 13 2015 at 2:02:27 AM Colin Walters walt...@verbum.org wrote: On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote: tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? It's worth noting here that having two levels is not really going to be new to the ecosystem; e.g. Ubuntu has had Main/Universe for quite a while: https://help.ubuntu.com/community/Repositories/Ubuntu I just have one question: You're defining this split at the *runtime* level. Last I saw the Base working group was trying to cut down BuildRequires (but sadly I haven't seen them fighting Requires yet - I would love if someone did that for Perl) If Ring 0 packages BuildRequire Ring 1 (or further) packages, ultimately their quality is going to be somewhat contingent on them. Using bundling as a differentiator though, it does seem like there's likely a lot less pressure to require quick security updates for BuildRequires. Anyways, something I think is missing from here is more details on how this on the install media set distinction is maintained over time. If it isn't separate (yum) repositories it seems like it's going to be hard to enforce. (Who would notice if a package in 0 started depending on a ring 1? Would that imply the new dependency needed another review pass?) Having bumped into bundled library issues in the past, this to me sounds like a good idea... provided exclude libraries at the beginning. So: this should only leaf packages, plus applications that happen to have add-on packages that depend on them, and only those that are not Ring 0 (not shipped in one of the install media). A nice alternative is to use the staging area we talked about for this Ring 1 category. Best regards, -- Michel -- 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: [Proposal] Ring-based Packaging Policies
* Paul Howarth [12/02/2015 20:05] : We generally have requires for most optional functionality in Perl packages at the moment, to avoid bugs being raised about missing dependencies when people try to use that optional functionality. Based on past emails, I suspect that Colin wishes nothing in Base depended on perl (ie. he wants Base to be perl-free), not that Perl packages had optional Requires. Emmanuel -- 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: [Proposal] Ring-based Packaging Policies
On Fri, 13 Feb 2015 13:54:59 +0100, Ralf Corsepius wrote: Meanwhile, we've had much more critical vulnerablities in widely used libs (Remember heartbleed), which all have been quite easy to fix packaging-wise. IMO, to a great portion, thanks to having mostly banned static linkage and bundling. There's more to it, too. Static linking is not only a risk with regard to security vulnerabilites. You cannot retest against an updated static lib without relinking the dependencies. You don't learn about new runtime breakage (or regressions) caused by the changed static lib, because the programs still use an old lib linked into them. The changed lib may have been out for many weeks as an update, but nothing test-drives it. What a surprise, if the lib were found to cause a sudden problem for a minor rebuild of a program. Or worse, if the rebuild were released quickly because of expecting it to be harmless, but the static lib under the hood has changed and breaks runtime for users. -- 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: [Proposal] Ring-based Packaging Policies
On 13 February 2015 at 13:06, Michael Schwendt mschwe...@gmail.com wrote: On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote: On Thu, 2015-02-12 at 20:18 +0100, Alec Leamas wrote: On 12/02/15 19:32, Stephen Gallagher wrote: (Logistical note: please keep all replies to this thread on devel@lists.fedoraproject.org) tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? Thanks for bringing this up. We really need to do something about this, and the proposal is likely to get things rolling. This is really about two things, right? A lighter review and a general bundling exception for packages not in the core (?) Ultimately, it's about one thing: Help get more software into Fedora without scaring people away. What is the background for this? Who has been scared away? Is this about a few vocal people, who boycott everything related to packaging guidelines and update guidelines? We've had a few incidents like that *many* years ago when somebody wanted to put pressure on the Fedora Project because things are not done in the same way as preferred by such people. IMO: What scares away people primarly is the actual maintenance period during the life-cycle of a Fedora. Somebody, who is afraid of making mistakes, whether small or large, will likely not join at all. Somebody, who takes the requirements too lightly, will run into trouble sooner than later. A good example is the first lib upgrade that bumps the soname and has been pushed to stable without even testing installation, because of treating the repo like a dumping ground. The sudden requirements to learn about what needs to be done to prevent this (ABI checks, buildroot overrides, rebuilds) make some people think twice whether they want to maintain the packages at Fedora. Plus, in order to rebuild dependencies, they would need to co-maintain the dependencies (for commit access) or actively communicate with the maintainers of the deps. For some this is too much effort to be worthwhile. Actually, a question I have about this is how it will impact people trying to become maintainers. When I last checked (it may have changed) the only way to do that was to create a new package. Typically that will be a package you're interested in getting into Fedora which may be non-trivial and benefit from someone more experienced doing it, or it might be somewhat arbitrarily chosen if you want to help maintain an existing package. So, is that implicit test (can you package according to the guidelines?) going to become easier? Is it necessary to then have a second level of approval before you can work on core packages if you started on a non-core package? Should becoming a maintainer become a bit more decoupled from the process of actually preparing a package? This doesn't really affect the proposal at hand, but it would be useful to know. -- imalone http://ibmalone.blogspot.co.uk -- 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: [Proposal] Ring-based Packaging Policies
On Fri, 2015-02-13 at 13:54 +0100, Ralf Corsepius wrote: On 02/13/2015 10:56 AM, Petr Spacek wrote: Modified version of Zbyszek's idea with time constraints follows: 1) Accept the new package into Fedora N even with bundled libraries. I am inclined to be Fedora needs to encounter a serious vulnerability originating from bundling, such that you guys comprehend, why bundling is utterly stupid ;) For those who don't know what I am talking about: Many years ago (IIRC, ~1999), nobody cared about static linkage or bundling. At this time, it was common to statically link and/or bundle libraries. Then a critically vulnerability was found in libz affecting all Linux distros. Nobody knew which packages all bundled and/or statically linked against different versions of libz. It took months for all Linux distributions to identify their vulnerable packages, to find solutions and to release security-fixes. Meanwhile, we've had much more critical vulnerablities in widely used libs (Remember heartbleed), which all have been quite easy to fix packaging-wise. IMO, to a great portion, thanks to having mostly banned static linkage and bundling. I'd like to point out something that I think you missed in my initial email. I'm not saying that anything should be allowed to bundle software transparently. The primary problem we faced back in '99 was that *we didn't know what was bundling libz*. With an enforced virtual Provides: bundled(foo) we can at least get an accurate listing of the set of packages that would need to be updated in the event of a vulnerability. Also, as mentioned in another thread, I'm certainly open to the idea of making some specific exceptions to the rule (such as you may not bundle packages like libz that have a long history of vulnerability). In other words, I think it might be reasonable to have bundling in the outer rings be a blacklist rather than a whitelist, so long as we can always find out with a simple repoquery what contains a package. signature.asc Description: This is a digitally signed message part -- 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: How to become a packager (was: Re: [Proposal] Ring-based Packaging Policies)
Hi On Fri, Feb 13, 2015 at 11:40 AM, Ian Malone wrote: Thanks. I think when I'd looked at it I'd discounted the review and comment on others' submissions process as it would seem to require you to have a better idea of what you're doing than the person submitting the package, and potentially just creating noise when other people are looking at it too. Yes, probably a good idea maintainers know how to package. :) You are also discounting the path of being a co-maintainer first. Random fire'n'forget builds in a public Fedora repo would be something that would scare me. This is sort of a situation we have by default, as it's simpler for people to package into the SUSE public repo. Not sure how. Please explain. If the goal is to make it easier to do fire and forget builds, then koji scratch builds and perhaps copr seems to be a good option. 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: [Proposal] Ring-based Packaging Policies
On 02/13/2015 04:51 PM, Matthew Miller wrote: On Fri, Feb 13, 2015 at 04:43:53PM +0100, Ralf Corsepius wrote: words, I think it might be reasonable to have bundling in the outer rings be a blacklist rather than a whitelist, so long as we can always find out with a simple repoquery what contains a package. To me, this idea is not helpful. All it does is to send upstreams a message which encourages to disregard the issues of bundling, to work dirty and not to care about their coding quality. I think the stark reality is that few upstreams these days care about any message we send, for or against coding quality. We're just not in a strong position there, as much as I'd love it if we were. I disagree - We need to send a message, to raise awareness about these issues (Beware the beginnigs!) and to be explict againt people who bundle. Or differently: Not-bunlding is one of the key features, which fuels Linux befamed security. If you're dropping this, we worse than Windows. Ralf -- 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: How to become a packager (was: Re: [Proposal] Ring-based Packaging Policies)
On 13 February 2015 at 15:35, Michael Schwendt mschwe...@gmail.com wrote: On Fri, 13 Feb 2015 14:00:07 +, Ian Malone wrote: Actually, a question I have about this is how it will impact people trying to become maintainers. When I last checked (it may have changed) the only way to do that was to create a new package. That isn't the only way to become a packager. And it hasn't changed for a very long time: https://fedoraproject.org/wiki/Category:Package_Maintainers - https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group Submitting a new package is just _one_ of multiple ways to find a sponsor, since it is an opportunity to demonstrate that you know packaging. Thanks. I think when I'd looked at it I'd discounted the review and comment on others' submissions process as it would seem to require you to have a better idea of what you're doing than the person submitting the package, and potentially just creating noise when other people are looking at it too. Yes, probably a good idea maintainers know how to package. :) Random fire'n'forget builds in a public Fedora repo would be something that would scare me. This is sort of a situation we have by default, as it's simpler for people to package into the SUSE public repo. -- imalone http://ibmalone.blogspot.co.uk -- 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: [Proposal] Ring-based Packaging Policies
On 02/12/2015 07:32 PM, Stephen Gallagher wrote: Second, I will call attention to the fact that different Fedora users have very different needs from the software. For example, those running Fedora Server and Fedora Cloud are likely far more concerned with Fedora as a *deployment* platform than they are as a *development* platform. Folks running Fedora Workstation or the KDE spin are likely to be somewhat more interested in the development side of things (though not exclusively). Fedora Workstation includes very, very few development-related packages, to the degree that it is completely unusable (by itself) for almost all developers. Many important development tools are completely outside the Fedora.Next package set. Previously, they were just a “yum install” away, and there was little difference in practice. I'm worried that this proposal will have a negative affect on the quality of non-core packages (over time at least). === Core Packages === Any package that is provided on a release-blocking medium (which at present includes Fedora Atomic, Fedora Cloud, Fedora Server, Fedora Workstation, the KDE Spin and several ARM images) must comply exactly with the packaging guidelines as they are written today. These packages must receive a full package review *when they are added to the install media*. Any package present on the media if this proposal is adopted is exempted from this requirement. Any package to newly appear on the install media after this time *should* (I hate that word...) receive a new package review, even if it is already present in Fedora. Based on the comments above, I think the definition is much too narrow. It excludes fundamental development infrastructure such as autoconf and cmake, and tools like gdb and valgrind. I have nothing against the proposal in principle (to some extent, it just reflects existing practice), but I do think we need a different definition for the set of core packages. By the way, this cuts in the other direction as well—I think the proposed definition makes Docker and Kubernetes core packages (at least eventually), and I think its developers really, really want a wide-ranging bundling exception. -- Florian Weimer / Red Hat Product Security -- 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: [Proposal] Ring-based Packaging Policies
On 13 February 2015 at 09:05, Ralf Corsepius rc040...@freenet.de wrote: On 02/13/2015 04:51 PM, Matthew Miller wrote: On Fri, Feb 13, 2015 at 04:43:53PM +0100, Ralf Corsepius wrote: words, I think it might be reasonable to have bundling in the outer rings be a blacklist rather than a whitelist, so long as we can always find out with a simple repoquery what contains a package. To me, this idea is not helpful. All it does is to send upstreams a message which encourages to disregard the issues of bundling, to work dirty and not to care about their coding quality. I think the stark reality is that few upstreams these days care about any message we send, for or against coding quality. We're just not in a strong position there, as much as I'd love it if we were. I disagree - We need to send a message, to raise awareness about these issues (Beware the beginnigs!) and to be explict againt people who bundle. Or differently: Not-bunlding is one of the key features, which fuels Linux befamed security. If you're dropping this, we worse than Windows. How do we send this message? Because it is clear other people are out of ideas on how to do this in a way that software that people want to use care about. -- Stephen J Smoogen. -- 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: [Proposal] Ring-based Packaging Policies
On Fri, Feb 13, 2015 at 6:06 AM, Michael Schwendt mschwe...@gmail.com wrote: On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote: Ultimately, it's about one thing: Help get more software into Fedora without scaring people away. What is the background for this? Who has been scared away? Here's one review where the submitter worked very hard to jump through all the hoops until it came to the FPC bundling exception process. It's my opinion that Carlos would be a Fedora package maintainer today if that FPC process hadn't taken so long. https://bugzilla.redhat.com/682544 In IRC, I've seen other users abandon ship earlier, once the prospective developers are told that their goal of packaging X in Fedora or EPEL would require doing some work to unbundle some library. It's hardly a theoretical problem. I have no idea of the scope, of course, but it does happen. For myself, I believe in unbundling libraries, and I believe Linux distros like Fedora and Debian contribute a great deal to the health of the overall FOSS ecosystem. Certain upstream developers enjoy lambasting distributions regarding bundling policies, and I wish these same developers could step back and acknowledge how many patches and improvements have also come upstream as a result of the distros' work (unbundling work included). Matt, you mentioned in another email in this thread that upstreams don't care about the messages that we send. I agree that some upstreams don't care about certain classes of problems, but they do care about others. For example, XBMC hates that we've unbundled ffmpeg, but on the other hand, they're quite happy to take our patches to fix format-string bugs that Fedora's GCC defaults bring to light. Things are not all rosy, but they're not all bleak, either. Here's the new policy that I would vote for: 1) We allow bundled libraries, and each bundled library MUST have a virtual Provides: bundled(foo) in the RPM spec. (The packager SHOULD provide a version number too, with the admission that it is sometimes difficult to get this number correct.) 2) If another packager comes up with a patch to unbundle the library and files the patch in Bugzilla, then the package maintainer MUST take the patch. 3) If the package maintainer disagrees with the patch for whatever reason (maybe it's a feature regression, or whatever), they MUST bring it to the FPC for arbitration. The FPC must take into account the loss of functionality that unbundling could imply. This revised policy would lower the barrier to entry for newcomers, and still leave room for more advanced contributors to do the work if they desired to do so. - Ken -- 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: [Proposal] Ring-based Packaging Policies
On Fri, 13 Feb 2015 17:45:23 -0700, Ken Dreyer wrote: On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote: Ultimately, it's about one thing: Help get more software into Fedora without scaring people away. What is the background for this? Who has been scared away? Here's one review where the submitter worked very hard to jump through all the hoops until it came to the FPC bundling exception process. It's my opinion that Carlos would be a Fedora package maintainer today if that FPC process hadn't taken so long. https://bugzilla.redhat.com/682544 So, everybody's grief is just the unbundling policy? Is that the only thing that scares away people? Everything related to this proposal is only because of bundling? Here's the new policy that I would vote for: 1) We allow bundled libraries, and each bundled library MUST have a virtual Provides: bundled(foo) in the RPM spec. (The packager SHOULD provide a version number too, with the admission that it is sometimes difficult to get this number correct.) 2) If another packager comes up with a patch to unbundle the library and files the patch in Bugzilla, then the package maintainer MUST take the patch. 3) If the package maintainer disagrees with the patch for whatever reason (maybe it's a feature regression, or whatever), they MUST bring it to the FPC for arbitration. The FPC must take into account the loss of functionality that unbundling could imply. This revised policy would lower the barrier to entry for newcomers, and still leave room for more advanced contributors to do the work if they desired to do so. Isn't the combination of 2) and 3) a potential threat that will scare away the maintainer again? (especially if upstream doesn't accept the patch) -- 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: [Proposal] Ring-based Packaging Policies
On 14/02/15 01:45, Ken Dreyer wrote: Here's the new policy that I would vote for: 1) We allow bundled libraries, and each bundled library MUST have a virtual Provides: bundled(foo) in the RPM spec. (The packager SHOULD provide a version number too, with the admission that it is sometimes difficult to get this number correct.) 2) If another packager comes up with a patch to unbundle the library and files the patch in Bugzilla, then the package maintainer MUST take the patch. 3) If the package maintainer disagrees with the patch for whatever reason (maybe it's a feature regression, or whatever), they MUST bring it to the FPC for arbitration. The FPC must take into account the loss of functionality that unbundling could imply. This revised policy would lower the barrier to entry for newcomers, and still leave room for more advanced contributors to do the work if they desired to do so. In the end, I guess this is a trade-off between doing the Right Thing from the overall security and distro maintenance perspective, and doing the Right Thing from the follow the upstream view. My gut feeling is that this trade-off is differs in different communities. So, what happens if we discuss this from a language point of view? What if we, as a a starter, applied such a policy to e. g., ruby packages? Expanding to other languages over time in a more controlled way? Cheers! -- 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: [Proposal] Ring-based Packaging Policies
On 02/13/2015 08:20 PM, Florian Weimer wrote: I have some people express the notation that they can always switch to the system library version in case a security vulnerability comes out, but I doubt that this works in practice (because then there wouldn't be a reason for bundling). It sometimes works. Typically in cases when upstreams bundle a library, as conditional fallback or build-time option - to cater cases an OS doesn't provide a library. - because they believe to need a version greater than the version the OS provides (This is sometimes true, but sometimes also isn't) - as convenience to occasional builders/installers, who doen't care about system integration. These cases aren't actually uncommon, but in most cases the reasons for bundling are elsewhere: - Dead upstreams - Non-cooperational upstreams - Don't care about system-integration. - Lack of experience/naive upstream ... Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Proposal] Ring-based Packaging Policies
(Logistical note: please keep all replies to this thread on devel@lists.fedoraproject.org) tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? == Premise == So, some time ago, we started talking about dividing up the Fedora package set into a series of rings. One of the driving purposes behind this idea was to re-evaluate our policies for packaging in each of these rings. A fair amount of time has passed and no formal discussions have taken place (that I have seen, at any rate), so I'm going to provide here a simple starter proposal that we can work from and see where it leads. To begin, I'll try to identify some of the major advantages and disadvantages in our current policies. (In no particular order...) === Advantages === * Consistency: every shared library, language-specific module and application should have packaging consistent with others in its category. This makes it easier for comaintainers and provenpackagers to pick it up and work on it. * The no-bundled-libraries policy means that when a library module requires an update, it means that only one package needs to be modified in order to enhance all applications on the system that consumes it. This is a significant time-saver when it comes to dealing with (increasingly common) security vulnerabilities. * Package review front-loads the task of educating the packagers. It guarantees that packages enter the collection by meeting a very high standard. This does a great deal to accomplish the consistency mentioned above. * Legal review and the FPCA ensures that Fedora remains true to its Freedom Foundation (as well as protecting Fedora contributors from the perils of the international legal system). === Disadvantages === * Very strict policies often leads to potential packagers giving up. * Package reviews for less-interesting packages (such as those for less popular SIGs) often remain un-reviewed for weeks, months or even years. * The package policies are only ever reviewed during the initial creation of the package. Once that initial (high) hurdle is cleared, the packager essentially has free reign to do whatever they want with their package. This sometimes means that as time passes, the spec files bit-rot or otherwise start accumulating other inconsistencies. (A common example is the package whose upstream starts bundling a library without the packager noticing). * Many upstream projects do not concern themselves with being in any particular distribution (with the notable example being the Debian/Ubuntu flavors which have amassed a sufficient apparent userbase that they sometimes get special treatment). For a variety of reasons, this often leads directly to bundling the vast majority of their dependencies. This is done for many reasons, but the two most common are supportability and portability; it's impossible for many upstreams to actually QA their package with every possible distro library. Instead, if they ship everything they depend on, they can guarantee *that* specific combination. This moves the responsibility from the distribution to the upstream package to maintain their bundled libraries. * With many languages, there is no possibility of installing multiple versions of the same library on the same system, so if an application requires a newer or older version of the library than is in Fedora to run, it fails. For those languages that *do* allow this, it still adds a significant maintenance burden on the packagers to keep multiple versions of the same package up-to-date (which gets particularly hard when upstream abandons a version that something else in Fedora depends on...) == Analysis == First, I will make an assumption based on the First Foundation: We as the Fedora Project want people to have access to the software that they desire. We may disagree on how that is to be achieved, but I believe the goal is the same. Second, I will call attention to the fact that different Fedora users have very different needs from the software. For example, those running Fedora Server and Fedora Cloud are likely far more concerned with Fedora as a *deployment* platform than they are as a *development* platform. Folks running Fedora Workstation or the KDE spin are likely to be somewhat more interested in the development side of things (though not exclusively). Packaging software for development and packaging it for real-world deployment can be very different. I'm not going to attempt to identify all the ways that this can be the case in this email. Others have done so with great verbosity in the past and I will not attempt to re-hash them. Thirdly, I will note (again) that many upstream projects have moved away from a distro-centric model. This is in part because unlike in the past, there are a great many distributions out there now, all with individual packaging requirements to be inside those distros. Taken in concert with the behaviors of many of the
Re: [Proposal] Ring-based Packaging Policies
On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote: tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? It's worth noting here that having two levels is not really going to be new to the ecosystem; e.g. Ubuntu has had Main/Universe for quite a while: https://help.ubuntu.com/community/Repositories/Ubuntu I just have one question: You're defining this split at the *runtime* level. Last I saw the Base working group was trying to cut down BuildRequires (but sadly I haven't seen them fighting Requires yet - I would love if someone did that for Perl) If Ring 0 packages BuildRequire Ring 1 (or further) packages, ultimately their quality is going to be somewhat contingent on them. Using bundling as a differentiator though, it does seem like there's likely a lot less pressure to require quick security updates for BuildRequires. Anyways, something I think is missing from here is more details on how this on the install media set distinction is maintained over time. If it isn't separate (yum) repositories it seems like it's going to be hard to enforce. (Who would notice if a package in 0 started depending on a ring 1? Would that imply the new dependency needed another review pass?) -- 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: [Proposal] Ring-based Packaging Policies
On Thu, 2015-02-12 at 14:01 -0500, Colin Walters wrote: On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote: tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? It's worth noting here that having two levels is not really going to be new to the ecosystem; e.g. Ubuntu has had Main/Universe for quite a while: https://help.ubuntu.com/community/Repositories/Ubuntu I just have one question: You're defining this split at the *runtime* level. Last I saw the Base working group was trying to cut down BuildRequires (but sadly I haven't seen them fighting Requires yet - I would love if someone did that for Perl) If Ring 0 packages BuildRequire Ring 1 (or further) packages, ultimately their quality is going to be somewhat contingent on them. Using bundling as a differentiator though, it does seem like there's likely a lot less pressure to require quick security updates for BuildRequires. Anyways, something I think is missing from here is more details on how this on the install media set distinction is maintained over time. If it isn't separate (yum) repositories it seems like it's going to be hard to enforce. Well, it already *is* a separate repository to create the build trees, so we always have a clear picture of what's in them. (The Everything and updates repos are always a superset). (Who would notice if a package in 0 started depending on a ring 1? Would that imply the new dependency needed another review pass?) We'd have to be keeping an eye on the contents of the install trees and yes, that would require a new review pass, in my current proposal. I'd be willing to grant a blanket exception for packages that were in the distro up to the acceptance of this proposal (rather than only those that were on the install media) though. signature.asc Description: This is a digitally signed message part -- 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: [Proposal] Ring-based Packaging Policies
On 12/02/15 19:32, Stephen Gallagher wrote: (Logistical note: please keep all replies to this thread on devel@lists.fedoraproject.org) tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? Thanks for bringing this up. We really need to do something about this, and the proposal is likely to get things rolling. This is really about two things, right? A lighter review and a general bundling exception for packages not in the core (?) As for the bundling exception I more or less just agree. One detail might be to add some text about not having bundled libraries in system locations, and not exporting (filtering) them. As for the lighter review this is not so clear to me. I agree that we need to relax the review, but: - Wouldn't it feel a little more comfortable to list the exceptions we allow compared to a regular review rather than starting with just some broad statements what the review is? - Shouldn't we make a distinction between 'review' and 'pass'. E. g., even if we allow bundled libs, we should definitely review and locate them. Isn't the situation similar for other things: while we still review them, things that are blockers in ring 0 could pass in ring 1? Colin walters wrote: Anyways, something I think is missing from here is more details on how this on the install media set distinction is maintained over time. If it isn't separate (yum) repositories it seems like it's going to be hard to enforce. A virtual provides in all ring 1 packages? Cheers! --alec -- 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: [Proposal] Ring-based Packaging Policies
On Thu, 12 Feb 2015 14:01:43 -0500 Colin Walters walt...@verbum.org wrote: On Thu, Feb 12, 2015, at 01:32 PM, Stephen Gallagher wrote: tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? It's worth noting here that having two levels is not really going to be new to the ecosystem; e.g. Ubuntu has had Main/Universe for quite a while: https://help.ubuntu.com/community/Repositories/Ubuntu I just have one question: You're defining this split at the *runtime* level. Last I saw the Base working group was trying to cut down BuildRequires (but sadly I haven't seen them fighting Requires yet - I would love if someone did that for Perl) We generally have requires for most optional functionality in Perl packages at the moment, to avoid bugs being raised about missing dependencies when people try to use that optional functionality. If there was consensus about use of soft dependencies, that would probably help a lot in the Perl world. Paul. -- 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: [Proposal] Ring-based Packaging Policies
Stephen Gallagher wrote: * The package *MAY* contain bundled libraries or other projects, but if it does so, it *MUST* contain a Provides: bundled(pkg) = version for each such bundling. This is done so that we can use the meta-data to identify which packages may be vulnerable in the event of a security issue. Before (and if) this becomes policy, it must be defined exactly what pkg shall be. In some cases it's obvious. In other cases a name exists in multiple variants. If we end up with one package bundling gpg, another gnupg and a third gpg2, then the policy hasn't fulfilled its purpose of making it easy to find all packages that bundle a particular piece of software. Shall it be the name of the RPM package in Fedora? Or the source RPM package? But what if there isn't a Fedora package of the bundled software? Shall it be the name of the upstream source tarball? Some projects don't even release tarballs. The soname? That works only for compiled libraries. The project name on Sourceforge/Github/Savannah/...? The domain name of its website? But one project can distribute multiple packages, and some projects use multiple websites and nothing enforces that the name is the same everywhere. Could the name of the root directory of its source code tree be used? Some source packages (especially those that are packaged in zip files instead of tarballs) contain multiple files and directories without a common root directory. -- Björn Persson pgp6ongLGAOLp.pgp Description: OpenPGP digital signatur -- 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: [Proposal] Ring-based Packaging Policies
On Thu, Feb 12, 2015 at 01:32:04PM -0500, Stephen Gallagher wrote: (Logistical note: please keep all replies to this thread on devel@lists.fedoraproject.org) tl;dr Shall we consider requiring a lesser package review for packages that are not present on Product or Spin install media? Despite the title, and the tl;dr summary, what you are proposing boils down to a blanket exception on bundling. This is both not enough and dangerous. I agree that we could relax the rules in some places, where the effort of conforming to Guidelines is just too big for the real gain. But I think the way this is done should be much more subtle, based on an analysis of individual tradeoffs. In your proposal the ring of the package is the important thing. But the dependency tree is a very well connected graph, and various fringe packages are used by core packages, so there's no way to develop anything using just the core, and any real-life server is also going to include packages from all rings. Security bugs in fringe web-facing services are more important than bugs in core tools which are purely local. For example, recent XSS vulnerability in jquery [1] nicely cuts through all rings. Unbundling jquery here would give a huge benefit, and does not become less important the farther a package is from the core. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1166041 == Premise == So, some time ago, we started talking about dividing up the Fedora package set into a series of rings. One of the driving purposes behind this idea was to re-evaluate our policies for packaging in each of these rings. A fair amount of time has passed and no formal discussions have taken place (that I have seen, at any rate), so I'm going to provide here a simple starter proposal that we can work from and see where it leads. To begin, I'll try to identify some of the major advantages and disadvantages in our current policies. (In no particular order...) === Advantages === * Consistency: every shared library, language-specific module and application should have packaging consistent with others in its category. This makes it easier for comaintainers and provenpackagers to pick it up and work on it. * The no-bundled-libraries policy means that when a library module requires an update, it means that only one package needs to be modified in order to enhance all applications on the system that consumes it. This is a significant time-saver when it comes to dealing with (increasingly common) security vulnerabilities. * Package review front-loads the task of educating the packagers. It guarantees that packages enter the collection by meeting a very high standard. This does a great deal to accomplish the consistency mentioned above. * Legal review and the FPCA ensures that Fedora remains true to its Freedom Foundation (as well as protecting Fedora contributors from the perils of the international legal system). === Disadvantages === * Very strict policies often leads to potential packagers giving up. True. But packagers often give up for many other reasons, including unresolved legal problems with the software, many different packaging problems other than bundling, lack of sponsors, etc. * Package reviews for less-interestingackages (such as those for less popular SIGs) often remain un-reviewed for weeks, months or even years. * The package policies are only ever reviewed during the initial creation of the package. Once that initial (high) hurdle is cleared, the packager essentially has free reign to do whatever they want with their package. This sometimes means that as time passes, the spec files bit-rot or otherwise start accumulating other inconsistencies. (A common example is the package whose upstream starts bundling a library without the packager noticing). Your proposal would only worsen, not fix that. * Many upstream projects do not concern themselves with being in any particular distribution (with the notable example being the Debian/Ubuntu flavors which have amassed a sufficient apparent userbase that they sometimes get special treatment). For a variety of reasons, this often leads directly to bundling the vast majority of their dependencies. This is done for many reasons, but the two most common are supportability and portability; it's impossible for many upstreams to actually QA their package with every possible distro library. Instead, if they ship everything they depend on, they can guarantee *that* specific combination. This moves the responsibility from the distribution to the upstream package to maintain their bundled libraries. I think this responsibility is an illusion. Most upstreams only care that the bundled versions allow their package to continue to work, and are not at all capable of fixing vulnerabilities or even other bugs. I think that it is also very unlikely that packages would be properly reviewed when they move to an inner ring. Look at how well the merge
