On Mon, 2015-02-16 at 17:03 +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? 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 > https://bugzilla.redhat.com/show_bug.cgi?id=1125952 > 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? This is an interesting idea (and one that could be investigated irrespective of the original discussion). In the last few years, the fedora-review project has made the review process significantly easier for many packages. It covers a lot of the policies that are automatable, thereby reducing the packager requirements. Elsewhere in this thread, it was suggested that we could further improve the process by taking reviews out of Bugzilla and building a tool specifically for this purpose. If we built this atop fedora-review, we could make large parts of the review-submission process automated. (Automated guideline checks for those things that *can* be automated, automatically perform koji scratch builds for each architecture, etc.) With something like that in place to provide at least a minimal level of review, we probably *could* give members of the provenpackager and/or sponsors groups permission to pass a review solely based on those results (plus a manual checkbox of "this is permissible content"). In parallel with another discussion on the list, this could be a really worthwhile effort for the Google Summer of Code this year. Maybe Michel Salim (CCed) would be interested in having the fedora-review team mentor two or three interns to work on a web-app version of fedora-review?
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
