On Tue, 22 Dec 2015 16:54:07 +0100 Michael Schwendt <mschwendt@xxxxxxxxx> wrote: > On Tue, 22 Dec 2015 12:38:34 +0530, Parag Nemade wrote: > > > On Tue, Dec 22, 2015 at 12:34 PM, Dmitrij S. Kryzhevich > > <kryzhev@xxxxxxxx> wrote: > > > And now it is locked. I just can't drop it and redone (it is > > > locked) and I can't do anything (it is locked). > > > Any ideas? > > > > Check this https://fedoraproject.org/wiki/Bodhi2#FAQ > > And because locking interrupts the workflow of packagers, hopefully > it is only a temporary workaround. I don't see how to easily avoid it... > I've filed a new update ticket to move forward. Bodhi has had problems > with multiple updates for the same package too. I cannot > unpush/revoke the old update as long as it is locked. Whether I will > find the window when the older one is unlocked again, no idea. > > Ideas? > > 1. Let bodhi announce the next scheduled push? Is that possible? > Or is it a human, who starts a push a random times? It's not possible. It's a human that starts it based on how long it takes to sign how long the last push took, if someone is pressing to have a push for some urgent issue, etc. > 2. Lock bodhi tickets only for as long as it takes to copy the update > ticket data to private transaction space. Set up a link between the > original bodhi ticket and the private copy of ticket. > > 3. Unlock the bodhi tickets again. Work on the copied data (for > tagging in koji and repeated attempts during error handling e.g.). > > 4. While bodhi is still pushing, if packagers edit the original > tickets, no harm is done. Bodhi is working on a private copy of the > update data. Maintain a last-modified timestamp in the ticket. If > packager chooses to delete a ticket (which is frowned upon IMO), > forward the delete request to the private copy. (deletion is not allowed at all now, at least thats my understanding). > 5. Once bodhi is done with the push, compare the last-modified > timestamps of the original ticket and its copy, trigger actions that > may be fully automated (such as revoking updates, but it could be > that even this is only done during an official push these days). Well, but there could be some things that make little sense at that point. I guess they could just be rejected. (Like unpushing a update thats going to stable, etc). > 6. At next push, use the copied data for untagging and handling of > deleted tickets, then return to 1. Feel free to suggest this setup to bodhi developers. I'm not sure how difficult it would be to implement. kevin
Attachment:
pgpYO0gtUAMYU.pgp
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
