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