On 07/01/2010 12:47 AM, Kevin Kofler wrote:
Jesse Keating wrote:
> There is a slight wrinkle in that right now, the bodhi code will
> automatically request a push of an item that reaches this karma threshold,
> and I don't believe there is a way yet to force it to wait for even
> greater amounts of karma. I believe that fine grained tuning of karma
> automation is planned for the next major version (and rewrite) of bodhi.
That's not a "slight wrinkle", that's a fatal showstopper which means
this
change should never have hit production. I consider it completely
unacceptable for my updates to get promoted to stable when I didn't request
it (e.g. I disable karma automatism for all my updates).
If you disable karma automatism for your updates, they will not
automatically get promoted to stable upon critpath approval.
The way the workflow should work (*) is that:
* case 1: The maintainer requests the push to stable before the promotion is
approved. Then it will get withheld until approval. Once approval is
obtained, the push is automatically requested by Bodhi.
This is the workflow that occurs by default.
All critpath updates go to testing first, even if the maintainer chooses
stable. It's tested and approved, then bodhi automatically promotes it
to stable.
* case 2: The approval happens before a push to stable is requested.
In that
case, the update is marked as approved and the maintainer can queue it to
stable at any time.
That's the only sane way to handle such approval, everything else is just
plain broken. (And isn't that how the security team approval works now? Why
is the proventester approval implemented differently?)
This is the workflow that occurs when you disable karma automatism.
(*) under the (bad) assumption that this process makes sense at all,
of course
Your description of how the workflow "should" work is how the workflow
works.
luke