Auto-Sync for GitHub Mirrors
A long while back we decided to host a copy of Orchid (previously called JTor) in case the upstream project got deleted as it once had in the past. This is all well and good, but our mirror is now two years out of date since we only synchronize it manually. Stale mirrors like this can both cause confusion, and isn't really very useful in case the upstream project goes poof.
Imho we should have a cron task that pulls the GitHub content on a daily basis so our mirror stays up to date. Here's the irc discussion we had around it...
12:59 < atagar> Does it make sense for us to have a stale mirror of github repos? Mostly I'm thinking of jTor (https://gitweb.torproject.org/jtor.git). Our copy of it is now
a couple years out of date, and having it laying around might cause a little confusion if people pull from it.
12:59 < atagar> My two cents is that we should either have a cron task to keep it in sync or drop it.
13:00 < atagar> (iirc we have one or two other projects where we're mirroring github too)
13:00 < weasel> I'm all for moving it to a different directory
13:00 < weasel> on the web overview I've already put it into an Attic category
13:01 < atagar> Oops, didn't notice that. Good idea.
13:01 < armadev> attic sounds good to me
13:01 < armadev> we could also encourage xmux to keep ours up to date. or to tell us to drop it.
13:02 < atagar> I'd rather not ask a person to try to keep them in sync. A simple cron to pull daily would make more sense if we want a read-only mirror.
13:03 < atagar> (btw, jTor was renamed to Orchid - not sure if we want to rename our copy or not)
13:07 < armadev> i think we want to rename our copy iff we pull an update
13:08 < velope> there was a conversation about updating here with xm*x long before the orchid release.
13:08 < armadev> what was the conclusion?
13:09 < velope> basically the response was 'yeah orchid RSN and not until i feel like it'
13:10 < atagar> RSN?
13:10 < velope> real soon now
13:10 < weasel> real soon now
13:10 < atagar> ah
13:10 < weasel> some time between yesterday and never
13:11 < velope> i concur with the idea of auto or forget it, at least for people not already working primarily with torproject repos
13:11 < weasel> we gain nothing from automatically pulling from gitolite.
13:11 < weasel> one of the ideas behind having repositories on tor infra is that we know who put content there.
13:11 < weasel> if we auto-update from untrusted sources, then we lose that.
13:13 < atagar> The original motivation for having a jTor repo was that we couldn't find a copy of the codebase at all, and worried that it would be lost. I disgree - we
always thought jTor (and others hosted by GitHub) would be read-only mirrors. No one was ever supposed to push content to it. Rather it was only synced from
the github repo.
13:14 < atagar> But since we only do manual sync they became stale copies.
13:18 < velope> that oh-so-busy Somebody could update torproject repo if and when a signed tagged release is available
13:20 < atagar> I don't see a point in us having a copy at all if it's synced on an inconsistent basis like that. A stale mirror is worse than no mirror.
13:20 < atagar> oh well, not my project - back to code...
13:20 < velope> <worried that it would be lost>
13:22 < armadev> atagar: a stable mirror is better than nothing when the original author vanishes and deletes all his github stuff. which happened.
13:22 < armadev> (and then unhappened)
13:23 < atagar> At this point if he deleted all his stuff from github then we'd have a two-years-out-of-date copy which I think is marginally better than nothing.
13:23 < atagar> If we had auto-sync that only allowed fast-forward pushes then we'd have everything up until he did the deletion.
13:23 < armadev> would you like to set up an autosync? i think that would be great.
13:23 < armadev> (keeping it in the attic is still a fine idea.)
13:24 < atagar> It's a cron task. I don't have git permissions, iirc either weasel or Sebastian would need to add it.
13:26 < atagar> The one unpleasant bit I can think of about auto-sync is that it'll stop working if the upstream project ever does a non-fast-forward change. We would then
balk since they were deleting content. That said, the upstream really, really *shouldn't* push non-ff changes.
13:27 < atagar> Even still though - better than not having auto-sync at all. :)
13:41 < armadev> agreed
13:52 * atagar files a ticket