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