[Proposal] Ring-based Packaging Policies

[Michael Schwendt]

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.