On 02/12/2015 07:32 PM, Stephen Gallagher wrote:
(Logistical note: please keep all replies to this thread on
devel@xxxxxxxxxxxxxxxxxxxxxxx)
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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
