[packagers] Infrastructure - migration to GitHub?

Yury V. Zaytsev yury at shurup.com
Fri Apr 8 22:36:56 CEST 2011

Hi Karanbir!

The weekend is coming and I am back in business :-)

On Tue, 2011-04-05 at 14:44 +0100, Karanbir Singh wrote:

> If you can setup the resources on the remote end, I'm happy to do the 
> legwork to bring that git repo in automagic sync with svn as step-1.

Thanks for the offer, but I don't see much value in you doing this now
for two reasons:

1) If we don't want to keep the build system tied to svn why wouldn't we
switch to git for good and eliminate any possible confusion /

2) If we DO want to keep the build system as is (not changing a single
bit) for the time being, then GitHub has a gateway that provides access
to all of it's git repositories via svn client, so all it takes is to
make a new checkout...

So setting up a public git mirror which would be hard to use to push
anyway (git svn kind of works, but is a bit painful), only subset of
committers will be using it with no convenient way of accepting pull
requests etc. sounds like redundant to me.

Ok, it will maybe kind of solve my personal problem of waiting too long
to update the checkout, but that's pretty much it.

So I'd rather push for taking the decision to migrate, implementing it
and getting done with it.

> Tbh, I still prefer a conventional website somewhere. Dag has a machine 
> at hetzner, and I am still happy for surya to be dedicated to this 
> effort. Over the years its been a good place to park the .rf. resources. 
> If there is a need to expand the number of people with access, that can 
> be easily done.

I am not pushing for the host to be GitHub (although, why not use it if
it's there, free and rather reliable with zero administrative overhead),
but I would definitively advocate for using the "pages" functionality to
manage the website though.

I'm using jekyll for quite some time now for numerous things, and it's
truly great! Just think about it: no administration required, secure,
because there's nothing to break, performant because these are just
static pages, rudimentary templating available to keep the HTML layout
out of the texts. Of course, the texts are version controlled, because
they are stored in a git repository, and the access control is also in

Finally, to deploy the thing, you just push your changes to the server
and let the magic happen.

Ok, let's put this discussion off until later anyways.

> there is a svnsync job that runs on the hour, every hour. ( and I have 
> been cheating in that the svnsync target is actually a git repo :D )


> I would be very surprised if we run out of resources of this nature, 
> just given the membership on this list and what everyone here does - 
> finding machines and hosting stuff is unlikely to be a blocker.


> this can happen in async, since svn -> git targets are easily 
> maintained. Its only when the git pull requests start getting honoured 
> that svn needs to go r-o

True, I agree, but see above.
Sincerely yours,
Yury V. Zaytsev

More information about the packagers mailing list