QA's Package update policy proposal

[Kevin Kofler]

Adam Williamson wrote:
> The proposal isn't really about expanding testing activities, it's about
> formally codifying how the updates process is actually supposed to work.
> Right now, we don't in fact define how the Fedora update process is
> supposed to work: how updates get submitted, how they get promoted and
> how they get released, who has what responsibilities at what point, none
> of these is written down. That's what the proposal submitted by Kamil is
> about. It's not really about trying to impose additional testing or
> restrictions on updates.

Then why does it codify things which are not current practice, and in fact 
require Bodhi changes to be implementable at all?

And why is "updates get pushed to stable when the maintainer feels they are 
stable" (which is basically the current practice) not sufficient? We should 
trust maintainers. That's what we have maintainers for. Stuff like karma 
should only be a tool to help the maintainer decide.

> The most important thing is to have a framework explaining who does what
> at what point in the process; exactly what criteria are used to accept or
> reject updates is not the main thrust of this proposal. As Kamil wrote,
> the numbers in there at the moment are essentially placeholders, they
> could be changed entirely, and that's not the important thing about this
> proposal.

The numbers aren't the only controversial part of that proposal. Even 
changing all the numbers to 0 would still create a policy which is much more 
restrictive than what we have now (e.g. direct stable pushes aren't in the 
workflow at all; a direct stable push is different from requesting a push to 
stable after 0 days of testing, which assumes that we allowed it to hit 
testing in the first place, so it can only go to stable in the next push).

        Kevin Kofler