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'm assuming mirrormanager pushes out all updates that bodhi requested. Zbyszek _______________________________________________ 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
