[FFmpeg-devel] setting up a proper Github mirror
michael at niedermayer.cc
Sun Oct 11 22:11:40 CEST 2015
On Sun, Oct 11, 2015 at 03:43:19PM -0400, Ganesh Ajjanagadde wrote:
> On Sun, Oct 11, 2015 at 3:33 PM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> > On Sun, Oct 11, 2015 at 09:04:32PM +0200, Clément Bœsch wrote:
> >> On Sun, Oct 11, 2015 at 02:43:53PM -0400, Ganesh Ajjanagadde wrote:
> >> > Hi all,
> >> >
> >> > I noticed that the Github mirror: https://github.com/FFmpeg/FFmpeg is
> >> > over 3 hours out of sync with the main repos, making it unusable as a
> >> > fetch url for development. Anyone knows why this is the case?
> >> >
> >> Isn't this done manually by whoever has access to it?
> > yes
> > i (and possibly timothy) push to github after doing full build and
> > fate tests. If for some reason build or fate fails or iam aware of
> > a major/critical breakage in master which is not in github yet then i
> > do not push to github.
> > So github may be a few hours behind master but in the rare event
> > of a major messup it should not propagate to github before its fixed
> Thanks for clarifying. Any inherent reason you want to keep it like
> this instead of a post-receive hook?
just that i like github always building&passing fate on x86-64 and
that iam used to it, beyond that not really, no
> I do not see any concrete benefit for keeping Github slightly more
> "pristine' than our repository: someone who builds off master will in
> all likelihood not be using the Github URL, but our repo's url anyway.
> Furthermore, I do not consider such a difference useful (especially
> since it is not documented) - keeping both "complete" and up to date
> is IMHO good.
> Of course, the concrete benefit I am trying to get is to move
> fetch/pull load away from VideoLAN/our host more generally to Github
> who are much less starved for resources than us.
if theres a problem with the load on the videolan git server, then we
should consider using one of our own servers for git i think.
It would reduce the load on videolan and truth is, we have a basically
unused and rather powerfull box
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel