On Thu, 12 Feb 2015 13:32:04 -0500 Stephen Gallagher <sgallagh@xxxxxxxxxx> 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? 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
Attachment:
pgpNTdi3QOdZO.pgp
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
