Two phase candidate package review (was Re: Council Engineering update)

[Nick Coghlan]

On 13 July 2015 at 17:49, Pierre-Yves Chibon <pingou at pingoured.fr> wrote:
> On Sun, Jul 12, 2015 at 02:54:21PM +1000, Nick Coghlan wrote:
>> On 10 July 2015 at 16:24, Honza Horak <hhorak at redhat.com> wrote:
>> > * shortly summarize plans for upcoming Fedora releases (F23/F24) in their
>> > fields of interests and send it to working group ML or update in [2]
>>
>> For me, I'm hoping to work with the Fresque developers
>> (https://github.com/fedora-infra/fresque/issues/9) to get the main
>> package review workflow out of Bugzilla, with a view to then following
>> up on the idea of splitting the package review process into a
>> preliminary redistribution review (which can be handled by any Fedora
>> Contributor and amounts to "good enough for custom development work"),
>> and a packaging policy compliance review (which would match the
>> current review process and amounts to "good enough to consider for
>> operational deployment without in-house developer support").
>
> The first review being something along the line of: Good for copr (playground?)
> and the later along the line of: Good for the main repo ?

Roughly speaking, yeah.
https://fedoraproject.org/wiki/Env_and_Stacks/Projects/PackageReviewProcessRedesign
goes into detail on my current thinking.

Nothing much changes in Aleph 0->2 - those are basically "Fedora as it
exists today", and I'd expect the Base and Edition WGs and the
individual language SIGs to define the specific policies for those.

The key new concept is the idea of a more explicit "redistribution
review" that just checks:

* that the component complies with Fedora's licensing policies
* that the component appears to have been published in good faith
* that the component appears to be benign

Unlike the main packaging review (which focuses on the software
itself), this would focus more on reviewing how the software was
created, and whether or not redistributing it might present a risk to
either the Fedora project or Fedora's users.

At the moment, that step is effectively part of creating and
publishing COPR repos, my idea would be to split it out even further
so you could do that level of review without creating an RPM at all.

However, adding that step into the *current* package review process
would be difficult, as there'd be a lot of education work to be done
in changing the way folks use Bugzilla. With a separate review server,
it becomes much easier to split the review process into two steps, and
allow a package under review to sit at the second review stage
indefinitely.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia