[Proposal] Ring-based Packaging Policies

Michael Schwendt mschwendt at gmail.com
Fri Feb 13 13:06:23 UTC 2015


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 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?
> > 
> > 
> > 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.

The review process is only a minor hurdle. Especially, if there are two
people with real interest in a package. It's too easy to approve a package
without even adhering to all guidelines. It's even easier to reintroduce
packaging mistakes _after_ approval. Mind you, we don't re-review packages
regularly unless the maintainers do their update/upgrade jobs painstakingly.
But what to do if package bugs are found in a released package? Then the
fun starts. Especially for those who shall "maintain" the package.

The quality of some submitted new packages during review is lousy. Some
don't build (not even with plain rpmbuild). Some don't even work. Some
introduce the most basic and harmful mistakes, just because the submitter
does not even show interest in skimming over the review guidelines or
giving the fedora-review tool a try. Some spec files are full of
dist-independent conditionals, which are out-of-date and don't add
any value. => For such packagers, there will be a lot to learn, and
eventually they will give up, if packages cause problems when they are
exposed to more users than when offering a source tarball to download
somewhere.

We've all started somewhere with packaging. We do need to start *somewhere*
during times when the packaging related Wiki pages seem to be crammed
with guidelines.

The review queue is the first place where you get a chance to find a
helping hand that offers a bit of guidance. It could even be a co-worker
to team up for the reviewing. The second pair of eyes that may make the
difference!
But if there's nobody else than a single submitter, a bit of activity from
that submitter is needed. The same amount of activity that will be needed
also later during the actual life-cycle of the package in the Fedora
dist. Simply waiting in the review queue for magic to happen won't work.
Those, who wait months without even trying to follow the "How to get
sponsored ..."  guides, bear a huge risk of turning AWOL suddenly. And
once a potential sponsor shows up in the review ticket, not even then
the process is speed up with a bit of activity to jump over this small
initial hurdle. There are enough review tickets where a simple response
from a submitters takes many weeks or months.

> The ultimate goal being that Fedora becomes
> (remains!) a leader in the distribution of open source software.

To reach that goal, something else would need to change instead:
Declare official project-wide goals for the Fedora Packaging project
with regard to what maintenance level the package users can expect,
especially for the "Core Packages" you refer to. Or else you run
into the dangers of the "Quantity vs. Quality" pitfall, and problems
when propagating a package from the dumping ground "ring" into the
core.


More information about the devel mailing list