On Sun, Oct 11, 2015 at 4:11 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Sun, Oct 11, 2015 at 03:43:19PM -0400, Ganesh Ajjanagadde wrote: >> On Sun, Oct 11, 2015 at 3:33 PM, Michael Niedermayer >> <mich...@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
I don't know how much load on the VideoLAN box is coming from FFmpeg - if it is peanuts than we don't really need to bother. > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is what and why we do it that matters, not just one of them. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
