On Tue, 2020-06-02 at 15:40 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Jun 02, 2020 at 08:14:21AM -0700, Adam Williamson wrote: > > On Tue, 2020-06-02 at 14:42 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > On Tue, Jun 02, 2020 at 02:52:15PM +0200, Christopher Engelhard wrote: > > > > On 02.06.20 14:24, Mattia Verga via devel wrote: > > > > > Do you think adding a notice like > > > > > "The following command may take some time to work after this update has > > > > > been pushed to testing, because the dnf mirrors should synchronize." > > > > > would work? It may be not the best way to express that, since I'm not > > > > > English mother tongue, so if one has a best phrase let me know and I'll > > > > > push a PR to Bodhi. > > > > > > > > That would be great. > > > > > > > > Suggestion: > > > > > > > > "It takes some time for repository mirrors to receive this update. If > > > > the above command does not install anything, please wait for mirrors to > > > > synchronize and try again. This should normally not take longer than > > > > <insert typical sync time>. > > > > > > That would help. But maybe we should approach the problem from the other > > > side: figure out what <typical sync time> is, and then delay posting of this > > > message by that much (so that when users get this message, they have a > > > good chance that it'll actually work) ? > > > > We actually "know" this quite well, as long as people use metalinks > > (the default) at least: we know (or could know) when we publish the new > > metadata checksums after doing an updates-testing push, at which point > > the whole checksum system should ensure anyone using metalinks *will* > > get the new metadata. > > metalinks is the default, so I don't think we need to think about > other cases here. > > > But the tricky part I think would be co-ordinating the "update has been > > pushed to updates-testing" information with the "metadata has been > > updated in mirrormanager" information. Right now I don't think there's > > actually a message for that at all, but I don't see any reason there > > *couldn't* be. But that message would likely just say "published > > updated metadata for repo X" - mirrormanager isn't in a position to > > know what's actually *changed* in the repo. There would need I think to > > be some kind of agent which sits around listening to both mirrormanager > > and bodhi messages and figuring out "these are the updates which > > actually went out in this push", and doing the Bugzilla comments. That > > would be inherently more complex than a simple "receive message, > > publish comment" setup as Bodhi does currently. > > Or maybe bodhi could keep a queue of updates to notify about, and > listen for the next mirrormanager message and just do the bugzilla > notifications then? I mean, that's just an implementation of what I'm describing, with bodhi acting as the agent. It could be done that way or it could be a separate thing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
