shortening time passed in bodhi?

Michael Schwendt mschwendt at gmail.com
Thu Nov 27 19:42:38 UTC 2008


On Wed, 26 Nov 2008 22:32:15 +0100, Patrice Dumas wrote:

> On Wed, Nov 26, 2008 at 11:32:02AM -0800, Jesse Keating wrote:
> > > be checked manually.
> > 
> > er, this time period is I do believe less than a second, and it's done
> > automatically by bodhi when you make the request.  It just fails the
> > request if the tag isn't correct.
> 
> Ok.
> 
> > The pending state is there because people often work on an update
> > request at multiple times, and want to be able to add to it and adjust
> > it before doing the final push request, 
> 
> Who want that? In any case it should be optional. My update waited in
> pending state for 2 days. These are 2 days wasted.
> 
> > and also from a app code point
> > of view I think the update object has to have one form of existence
> > outside of either push requested or pushed.
> 
> But it could be instantaneous.

Only on the master download server. For the world-wide mirrors (and their
users), it still won't be instantaneous.  Unless you create a system
where the master can call back to mirrors and request them to sync. ;)

I see the benefit of being able to publish [security] updates quickly
(such as with the old extras/epel scripts, although the createrepo time
added up there, too), but the more packagers push pkgs instantly, the more
often the master repo (and the metadata) changes, and the more quickly the
entire distribution moves under the feet of our users. I don't think it is
a good idea to do that. A queue that controls the flow of non-security
packages creates less mirroring chaos.




More information about the fedora-devel-list mailing list