Re: [gentoo-dev] implementation details for GLEP 41

[Lance Albertson]

Lares Moreau wrote:

> I personally do not need Revision histories, I can't speak for other
> ATs.  Rsync with 30min delay is a noted improvement over the standard
> rsync policy.  Does this also allow us to sync to  main rotation mirroes
> is that already overstressed? I ask because IIRC it may take ~30min for
> all the mirrors to sync up to the 'Latest' revision, therefore the sync
> that I do _may_ be up to 60min old (worstcase). so main rotation mirror
> access would be nice.

They aren't overstressed. The delay is just a function of the
implementation we have. Now, to make this work better, we could do a
direct sync again cvs with the --exclude-cvs option. The down side of
this is that it doesn't include any metadata or glsa files. Basically,
any of the regen process we run on the public tree wouldn't be done if
we did the direct rsync. If files are all you need, then this approach
would probably be the best. I can see problems using the current rsync
mirrors because of the lag time.

Reason being, there's going to be at least a 25-55 minute delay from
when a developer commits something and the time it hits a mirror on
rsync.g.o. The flow works as this:

1) CVS is updated/regen'd at :05/:35 on the master box
2) rsync.g.o syncs at :00/:30

So, if I commit something at say :07, users won't see that file until
the next :00 rsync from the mirrors. But, if I committed something at
:01, the user will see it in 29 minutes. If we have a dedicated box that
does a direct sync, we can reduce that time to 30min. Is that needed, or
is the 25-55 minute lag good enough?

-- 
Lance Albertson <ramereth@g.o>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net