[Proposal] Ring-based Packaging Policies

Kevin Fenzi kevin at scrye.com
Fri Feb 13 18:29:15 UTC 2015


On Thu, 12 Feb 2015 13:32:04 -0500
Stephen Gallagher <sgallagh at redhat.com> 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?

IMHO, no. 

(see below for discussion)

...snip...

> === 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).

These three points are around the review policies and such. I think we
may well be able to try some things to improve these without
sacrificing our quality. 
 
> * 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.

Yeah, there's many reasons upstreams bundle things. 

I know in the past the FPC has talked about relaxing the bundling
guidelines, perhaps we could get some of them to weigh in here?

Additionally, FPC folks have done a great job recently (mostly due to
Tibbs hard work) in catching up with their backlog. Bundling requests
I would think would be much quicker than in the past.

...snip...

> 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'd personally be inclined to see if relaxing the bundling guidelines
and working on ways to improve our new packager on-ramp could help
these things without sacrificing our quality. 

Some ideas about the review queue: 

* We have currently have 126 sponsors and 1614 packagers. How about
  some kind of system where we choose N sponsors and N packagers every
  week and ask them to go look at the queue and work with some new
  packagers or review some existing packagers packages. 

* Get some pool of people interested in being triage for the queue. ie,
  check that things build, run fedora-review on them, point submittors
  to how to get sponsored docs, close old reviews with no response,
  etc. 

* Moving reviews out of bugzilla has been proposed and some work I
  think has been done for an app to do that. This could do a lot of the
  previous point without intervention (ie, do a scratch build, check
  urls and so forth and just mark the review not ready or reject
  initial submit until they fix those things). 

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150213/abbe6bda/attachment.sig>


More information about the devel mailing list