On Tue, 22 Dec 2015 16:54:07 +0100
Michael Schwendt <mschwendt(a)gmail.com> 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(a)ispms.ru> 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