[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