[FFmpeg-devel] setting up a proper Github mirror

[Michael Niedermayer]

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...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20151011/7bd64ea2/attachment.sig>