FYI, this coming week we plan to move SDL development from Mercurial and Bugzilla to GitHub.
On Wednesday we’ll bring down the public services and I’ll send out an update when the transition is complete, with instructions on how to access the new repository. This will take a few days as we migrate all the bugs and so forth so we have full history on GitHub.
Cheers,
Oof, that is a surprising change, especially considering things said in the past. What changed?
Also the best of luck for the transition! Looking forward to this change.
The writing has been on the wall for Mercurial for a while.
Looking forward to it as well. It was about time.
Everything moved to git generally, and GitHub specifically.
Lots of tools and workflows expect you to be using git (Visual Studio and Xcode have built-in git support, etc) and Mercurial is becoming an alien thing to lots of people. Instead of being a thing you use, it’s now One More Thing to learn. It’s far more likely that people familiar with revision control generally will also be familiar with git specifically.
I am not a fan of git; I still believe Mercurial is a better piece of software, and that git has made some calamitous design choices…but for our personal needs we can more or less use a subset of git the same way we use Mercurial now, while letting everyone else use git however they personally like.
And the way that most people personally like using git is via GitHub.
One reason we hadn’t considered a move to GitHub before now is that this project has had a policy of owning all its infrastructure. This project survived the demise of Loki, it survived devolution being scooped up by a domain squatter, it survived Dreamhost’s flaky servers. Years ago, we had enough of it all and moved everything to Digital Ocean because it’s just a colocated Linux server; we maintain all the services and nothing is ever taken out from under us…in the worst case we would just move our nightly backup to a new host and update DNS and not be just generally screwed as providers drop services or break things and just generally don’t answer the phone.
The tradeoff for this freedom, of course, is that everything is buggy and janky and no one has time to make it better. Bugzilla doesn’t really look much different than it did twenty years ago (and, as we discovered, the Bugzilla developers didn’t bother updating their code when newer MySQL releases broke it, and I’m a game developer and don’t want to fix perl code from two decades ago to get the bug tracker working after I upgrade Ubuntu, blah blah blah).
It’s not just Bugzilla. It’s the wiki, the mailing lists, the quaint little Mercurial web interface. The little open source thing that we rely on but no one is working on and probably has security holes in it. It’s all janky, and it causes developer friction. It causes it for Sam and I, and we’re old Unix command line cowboys, so for those that expect computers to treat them like computers do in 2021–with slick UIs and without cronjobs that occasionally fail until Ryan rolls along to restart a service over ssh–it was becoming untenable.
So in moving it to GitHub, we’re finding that a lot of things are just nicer because a large paid staff of engineers is working on it every day. And I grew up during the heyday of the Free Software Foundation, so I know this is a trap, but I’m tired and don’t have the energy to be a server admin for something that’s held together with scotch tape and prayers when I’m really supposed to be writing OpenGL code.
So we’re moving to servers we don’t control, which does make me nervous, but the argument goes like this: Microsoft owns GitHub, and it’s highly unlikely Microsoft is going to go bankrupt anytime soon. If Microsoft pulls the plug on GitHub, it’s not just SDL that would be in trouble, it would be the entire open source ecosystem, so interested parties would move fast to help you migrate to somewhere else…right?
And for us? That somewhere else would probably be our own server, hosting a copy of the git repository we cloned ourselves.
We will be migrating on the 10th. Tomorrow. If everything catches fire, we’ll revert everything back on the same day, but I would expect services to be disabled for a few hours while we sort things out, and then most existing things to make reasonable attempts to redirect you to GitHub. Stay tuned and have patience and hope tomorrow goes smoothly.
/me Raises a glass, and wipes a tear for bugzilla, hg and the other tools.
Looking forward to it too though.
Thanks for finding time to write this down.
I feel kinda sorry for my hype erlarlier now.
It’s a shame how much I (and many others I guess) have lost the appreciation for being independent these days.
I can only speak for myself but if you need outside testers or anything, i (and probably many others) will be willing to help.
In any case, Strength and all the good things for tomorrow.
But why you don’t try gitlab for open source? It will give you all benefits.
Thanks for the break-down. This just happens to make integration into my projects a bit easier, but I don’t envy the work involved or the exhaustion that led to this decision.
Though I can identify with a lot of it, and ironically, SDL is to my controller library what GitHub is to your Mercurial solution.
I mean, Gitlab already supports migrating from Github, and a good thing about Github is that you can download all your relevant data either via git (the repos of course and also the wikis) or via a documented web API (issues etc), so moving away from Github without losing relevant data should be feasible if necessary (unless they go down without warning so you don’t have time to get all your data, but that seems extremely unlikely).
It’s the wiki
So you wanna migrate the Wiki to Github as well?
I haven’t looked closely at their wiki in a few years, but last time I did it was very basic and didn’t even support categories or TOCs, it was useless for my purposes and if this hasn’t changed (I couldn’t find any information that would indicate it did with a quick websearch) it’ll be useless for SDL as well.
(Of course I understand that getting rid of MoinMoin is very desirable)
The wiki is going to be a mess for a bit. I’ve pushed it through some Perl to deal with the worst issues, but it still needs a lot of manual cleanup. Right now it is…kind of daunting.
I haven’t yet, but I intend to write some scripts to deal with categories and such, so if GitHub won’t manage this for us, we’ll still automate it on our end. I like that the wiki will just be a git repo, so running scripts over a bunch of text files becomes possible.
I know this struggle all to well. It’s probably not of use to you now as you’re about to migrate, but I recently created a new mercurial hosting tool so I could move Pidgin somewhere when Bitbucket sunset mercurial support. If you’re interested you can check it out at HGKeeper.
Eventhough it’s a bit late in the game, for people who like mercurial and don’t wish to use github (not going into the details of why, it’s offtopic), know that there is a friendly fork of gitlab with support for mercurial : https://heptapod.net/
For FOSS projects, you can be hosted on https://foss.heptapod.net/ to get a project there you can ask via an “Hosting Request issues” on heptapod/foss.heptapod.net project there (they helped a bunch of FOSS projects migrate from bitbucket).
@grim good to know HGKeeper exists, we’ll take a look at that too. (diversity is key!)
@grim good to know HGKeeper exists, we’ll take a look at that too. (diversity is key!)
Appreciate it! Also speaking of diversity there’s also https://sr.ht which has git and mercurial support and is open source but is a bit much to host yourself.
If you like the feeling of infrastructure code that breaks all the time you can add Continuous Integration 
Well, first of all, do bro as you like. But. Why Lose Control? In any case, you and other developers need your own server (are you not going to just take and TOTALLY rely on github?) Let the development be carried out there (or rather, patches will be accepted there, and external discussions will be held, and the finished code will be merged there) But who prevents themselves from deploying wonderful GOGS for internal affairs? For internal discussions and even your own experiments? Don’t lose control, it’s just that there will be one place for the audience and another for you and your bros. And you don’t need to fiddle with this, just keep a mirror. You can take a snapshot from it, make changes and also send it to the github.
In any case, STORE EVERYTHING AND MIRROR YOURSELF ALWAYS. You just delegate the storage to the outside and that’s it, it’s not a loss of control.
In any case, these are all trifles, if you get rid of the hemorrhoids in order to just ebash the code, then that’s good. And even tomorrow the github will be closed, it’s not a problem you will always have a mirror and your own website.
If you look at this as a whole, then you just chose another file storage system and that’s it))))))
Write cool code, and where the copy will be stored is not so important))
Although I would certainly prefer that you just take something modern and ready-made, for example, the same GOGS, but this is just my Wishlist. The main code, the rest is secondary.
In addition, github is now like a social network, many young developers are there simply because … because it is a social network, they learn about the SDL. It’s good. And it’s not about github, it could be anything else, but just with a large mass of people and ready-made tools for typical development tasks.
Sorry for my English. Happy Hacking :
Thank you for your work on being a sysadmin for LibSDL for so many years. I’ve done a bit of work being a sysadmin at different places and times, and it can be a thankless and time-consuming job. I hope and can imagine that this change will be helpful in freeing up some of your own valuable time, going forward.
<< raises a glass >>
Ďakujem. Konečne to bude už lepšie. GitHub je super.
Probably was about time!
Hopefully after the big move you can concentrate on important things (coding) and less on petty maintenance of the infrastructure!
If you want what github/gitlab offers and keep full control on everything, maybe gitea is a valid option…
It’s an opensource self-hosted Git service, give it a look maybe…