[Proposal] Ring-based Packaging Policies

Ralf Corsepius rc040203 at freenet.de
Fri Feb 13 08:49:43 UTC 2015


On 02/12/2015 07:32 PM, Stephen Gallagher wrote:
> (Logistical note: please keep all replies to this thread on
> devel at 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





More information about the devel mailing list