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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
