[packagers] Infrastructure - migration to GitHub?

Karanbir Singh mail-lists at karan.org
Tue Apr 5 15:44:30 CEST 2011


On 04/04/2011 09:34 PM, Yury V. Zaytsev wrote:
> The solution that I would like to suggest is to migrate to GitHub,
> because it addresses all (or most) of these points.

I'm all for that. Its also worth noting that GitHub will extend 
resources for open source efforts. I can speak with the people at their 
end should there be a need to do something of this nature.

> I don't know if it is so important though... I guess flipping the switch
> is actually not as complicated as that and can be done on the build
> system side to immediately benefit from the new features of git.

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.

> I think this addresses Karanbir's point. Nice static pages in a
> repository, just change the DNS and the website is up, zero
> administration hassle etc. ...

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.

> 3) GitHub provides you with a wiki and an issue tracker. Those can be
> linked to the repository. Wiki has a web-interface or can be accessed as
> a git repository.

> P.S. Trick question: what is the backup policy for the svn in place
> right now? I mean not only the checkouts, but also the history?

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 )

> Now bringing up a git server is easy. I have a local gitolite install on
> my private server and in the case if a disaster happens a new instance
> can be brought up on a VPS in a matter of hours.
>
> I am under the impression that finding a temporary VPS to host the
> repository is really not a big deal, now that high-quality paid-for Xen
> hosts start at $20 per month, this can be tolerated for a few month in
> the worst case before a sustainable solution is implemented.

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.

> In what concerns the implementation as such, I see it as a sequence of
> the following steps:
>
> 1) Create repoforge organization at GitHub
> 2) Collect the GitHub logins from everyone involved
> 3) Settle the repository migration day with Dag

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

> 4) Switch subversion into the R/O mode
> 5) Perform a final svnsync with the old repo
> 6) Start the conversion (takes around two hours on my hardware)
> 7) Perform few required manual adjustments and push it to GitHub
> 8) Set up a GitHub hook to send commit notifications to the list
> 9) Test that everything works (i.e. people are able to commit)
> 10) Switch the build system over to the git checkout
> 11) Post an email detailing what to do and what to not to do with git
> 12) PROFIT!!!


> Opinions?

Are we there yet ?

- KB



More information about the packagers mailing list