you didn't mention carving out the translation branch, which would make sense for commit-priv reasons... any thought on that ?
On Thu, Feb 21, 2013 at 2:43 PM, Karol Nowak <[email protected]> wrote: > How about bitbucket.org? > > https://confluence.atlassian.com/pages/viewpage.action?pageId=273877699 > > > Karol > > > On Thu, Feb 21, 2013 at 2:33 PM, Eric S. Raymond <[email protected]> wrote: >> >> Gna! does not host git repositories. Supposing it did, one of the >> motivations for the move is a sense that Gna! is teetering on the >> brink and not a safe place to remain. We need to pick a new >> hosting site. >> >> GitHub has a lot of fans in Wesnoth's developer base. But it is not >> going to be GitHub. The reason is size. >> >> AI0867 did a test conversion with git-svn to scope the size of the git >> repo. With aggressive GC and repacking it is 1.4GiB. GitHub has a >> limit of 1GiB per repo, not because of storage space but because they >> fear downloaders becoming bandwidth hogs. Mordante asked the GitHub >> admins for an exception to this policy; he was politely but definitely >> denied. >> >> On IRC I have heard two different kinds of attempt to argue away this >> denial. One was "but it's just described as a guideline, not a hard >> quota". This will not wash; we asked the GitHub admins if they are >> willing to host a 1.4GB repo and they said *no*. Trying to fly in the >> face of that denial would poison our relationship with the site and >> quite possibly get us kicked off for TOS violation. This is not a >> risk that would be in any way prudent to take. >> >> The second form of evasion is various schemes to carve the repo into >> chunks of less than 1GB size, by breaking out some subset of (a) >> music, (b) the website branch, (c) the resource branch. >> >> This won't fly either. I could run exact numbers, but I don't need >> to. We are *not* going to trim more than 400MiB off the main repo >> this way (that's nearly a full third of the historical content!). And >> even if we could, it wouldn't solve the real problem; what GitHub >> cares about is the aggregate bandwith of our downloaders, not how it's >> divvied up into parcels. They would (rightly) interpret a carve-up as >> a skeevy attempt to end-run their refusal. >> >> The clincher is that our release manager wants (quite reasonably) that >> everything that goes in a release bundle to be in one repo. That >> precludes breaking out the music - and the other plausible split >> candidates are small enough to be noise by comparison. >> >> So, no GitHub. I don't even have to get into my nervousness about >> replicating the BitKeeper fiasco by relying on proprietary closed >> source, or my near-certainty that trying to carve up the repo into >> chunks would set us up for troublesome unanticipated synchronization >> problems down the road. >> >> Given our circumstances, I think the obvious best candidate is >> SourceForge. It doesn't have a size quota, we already own the >> Wesnoth project there, and we'll be able to write our own >> bugtracker integration hooks from git using the Allura API. >> >> However, I do not want to make that SourceForge decision unilaterally. >> Senior devs and release manager, please weigh in on this. Please >> either +1 or state a reasoned objection. >> -- >> <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> >> > > _______________________________________________ > Wesnoth-dev mailing list > [email protected] > https://mail.gna.org/listinfo/wesnoth-dev > _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
