23 ms·

SDL Moves to GitHub

292 points by Bl4ckb0ne 6y ago

agentdrtran 6y ago
"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 heydey 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." This seems to sum up the biggest pain point that drives people away from OSS. Not knowledge, not skill, not price, but the total experience of a nice piece of software that lets you get the work you actually want to get done... done.
- PurpleFoxy 6y ago
  Wonder why they did not pick GitLab since it is significantly better for FOSS ideals and has the same niceness of GitHub
  - fileeditview 6y ago
    My guess is the network-effect. If you want more contributions Github is the platform to pick for your project. Good or bad it is the de facto standard platform for OSS projects with a huge pool of potential developers.
    - iforgotpassword 6y ago
      That's it. Back in the day that's what was great about source forge. Now it's github. Many people already have an account there so you significantly lower the bar for people to get involved with patches, bug reports etc. If a project has self hosted infra and wants me to sign up to their Bugzilla I think twice before doing so. And if github really turns to shit because Microsoft shows their true evil face you can just move platforms again.
      - jhasse 6y ago
        Check out https://gitlab.kitware.com/users/sign_in https://gitlab.kitware.com/users/sign_in or https://gitlab.xiph.org/users/sign_in https://gitlab.xiph.org/users/sign_in You can sign up with your GitHub account.
        iruoy 6y ago
        https://gitlab.gnome.org/users/sign_in https://gitlab.gnome.org/users/sign_in even allows you to login with a GitLab account. Which ironically isn't possible on these other two.
    - devmunchies 6y ago
      I don't think this is it. I think it's more about (1) marketing and discoverability and (2) ease for current maintainers. Getting new contributors is overrated for OSS unless they are an exceptional contributor (like if a big org were to contribute). Main incentive is getting more consumers of the project (increase popularity) and making it more convenient for current team.
      - fileeditview 6y ago
        I agree but think it's a bit of both and depends on the project. I e.g. don't think SDL needs more exposure. Everyone in game dev knows SDL.. many game engines / frameworks are built on top of it.
  - 1_player 6y ago
    > has the same niceness of GitHub Debatable. As a previous paid customer, I have never been a fan of GitLab, I've always found it slow, buggy and of confusing design language. YMMV.
    - ta988 6y ago
      I think what was meant is that at least parts of GitLab are FOSS and can be installed locally which in not the case with github.
      - pitterpatter 6y ago
        But installable locally kinda defeats the whole point of this move? And as someone who manages a small gitlab instance, it's not always set it and forget it unfortunately.
        imtringued 6y ago
        No, it doesn't because Gitlab.com exists. Installability is an insurance policy.
  - john_cogs 6y ago
    GitLab team member here. For anyone considering a similar move, I encourage you to check out our GitLab for Open Source program: https://about.gitlab.com/solutions/open-source/ https://about.gitlab.com/solutions/open-source/
    - ta988 6y ago
      For academics, it take a few minutes to get a github academic account. For gitlab you have to write justifications and wait and wait, to maybe get it...
      - smarx007 6y ago
        Yep, our university has GH Enterprise and refuses to “procure” (as it requires the central body to agree to the ToS) free Gitlab for academia as “another” git solution. Our project team on Gitlab cannot get into that program for academics because they only let one application per institution. I understand each side but still don’t see how we can solve this problem. Would love to find a way!
        smarx007 6y ago
        Update: seems like Gitlab removed the requirement of having one application per institution from https://about.gitlab.com/solutions/education/join/ https://about.gitlab.com/solutions/education/join/, I just applied again.
  - the_jeremy 6y ago
    I use GitLab at work. My experience is that it has more features that work less well. There are a bunch of comments pointing to a GitLab issue to explain stupid hacks in our CI/CD pipelines.
  - nuritzi 6y ago
    Thanks, @PurpleFoxy! I tend to agree with @Fileeditview about the network effect and how GitHub has done a great job of helping OSS projects with visibility. Like john_cogs, I'm also a GitLab team member, and am part of the Community Relations team. I run the GitLab for Open Source program. I joined about a year ago and am really impressed by how fast GitLab moves forward. We have a lot of awesome stuff coming up to make the product, and our community, even better. With a release each month, we use our momentum to make big strides in the DevSecOps space -- so people can rest assured that we'll keep improving quickly! We like to build along with our users, and believe everyone can contribute to our product roadmap, and all aspects of our company (e.g. see https://about.gitlab.com/direction/ https://about.gitlab.com/direction/). For OSS projects considering a move, check out this GitHub vs GitLab Decision Kit: https://about.gitlab.com/devops-tools/github-vs-gitlab/decision-kit/ https://about.gitlab.com/devops-tools/github-vs-gitlab/decis... It outlines some of the key points to consider when evaluating a move. I'm also happy to answer any questions about the GitLab for Open Source program john_cogs mentioned below (https://about.gitlab.com/solutions/open-source/ https://about.gitlab.com/solutions/open-source/). It's a great deal in that OSS projects get 50,000 CI minutes for free along with our top tier in SaaS or self-managed. Feel free to reach out to opensource@gitlab.com with any questions!
    - apple4ever 6y ago
      Best two things GitLab needs to do: 1. Fix their bugs instead of new features (ex: rebase fails 9/10 time for us) 2. Fix their pricing (ex: $99 per user is way to expensive and that is the only plan that allows free users)
  - wdb 6y ago
    Github Actions is already a good reason to use Github over Gitlab. Also the pricing is much better with Github even for Github Enterprise. All kind of normal features are behind a $99/user/month fee. I don't understand why things like vulnerability scanning needs to cost $80 per user more and then at the same not supporting multiple report files as artefacts in monorepo.
  - ojnabieoot 6y ago
    I think they implicitly addressed this: > 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? Gitlab Inc. is dramatically more likely to go out of business that Microsoft, and Gitlab generally is dramatically more likely to have significant outages than Github.
  - mlindner 6y ago
    Sorry but GitLab is utterly horrendous from a developer's perspective compared to GitHub. It's massive enterprise bloatware (like most Atlassian products for example) that is nigh unusable without an entire team of people to manage it. My company uses it and it causes me problems almost every other day. Things that should "just work" never do. Further when something gets reported to GitLab they automatically close old issues and things never get fixed. One outstanding huge issue is that if you mark certain files as owned by a specific team for example, it won't notify the teams to come in and actually review the code. There's options that say they do it, but it never works. (The notification system in general is an utter mess.) GitLab is an example where everything is chopped up into tiny pieces and nothing works across different parts of the codebase. I don't envy anyone that works for GitLab as just the look of the code shows what a mess the backend must be.
    - john_cogs 6y ago
      GitLab team member here. We have Code Owners [1] and recently introduced Merge Request Reviewers [2]. Our team is working on the author-review handoff [3] as part of their work to improve the overall merge request reviewer experience [4]. I'm sure they would appreciate any detailed feedback you could share on the epics linked below. 1 - https://docs.gitlab.com/ee/user/project/code_owners.html#introduction https://docs.gitlab.com/ee/user/project/code_owners.html#int... 2 - https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/#reviewers-for-merge-requests https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-rel... 3 - https://gitlab.com/groups/gitlab-org/-/epics/5074 https://gitlab.com/groups/gitlab-org/-/epics/5074 4 - https://gitlab.com/groups/gitlab-org/-/epics/1823 https://gitlab.com/groups/gitlab-org/-/epics/1823
      - mlindner 6y ago
        Code Owners don't work. If you assign a team as the owner it doesn't do anything unless the team itself is also added to the project. Further it doesn't seem to properly notify people either. We've fallen back to emailing everyone manually whenever a pull request is submitted.
    - sofixa 6y ago
  - agentdrtran 6y ago
    > has the same niceness of GitHub I gitlab significantly harder to use and more error-prone than Github
- colechristensen 6y ago
  >This seems to sum up the biggest pain point that drives people away from OSS. Not knowledge, not skill, not price, but the total experience of a nice piece of software that lets you get the work you actually want to get done... done. This is why I continue to be fascinated by FreeBSD, I don't use it for much but when I do, what I'm trying to do almost always works right out of the box. My point is that is all comes down to packaging, which is done everywhere. Docker is so popular because debian-style/rpm-style/etc packaging systems and the maintainers of said packages do a pretty uneven job of making things work without luck or fiddling (or having to have package specific knowledge about how to do something obvious). Docker doesn't really do a great job either, but it has a different set of problems and having the old ones gone is nice.
  - oblio 6y ago
    What are you using FreeBSD for? I imagine it's quite good at some things, but isn't that range kind of limited? You need to have the precise set of hardware that's well supported and then use it for precisely the thing it supports well.
    - dazzawazza 6y ago
      In my experience of using FreeBSD for twenty or so years, for the most part, if it's a major vendor and a few years old then it's supported. It is true that FreeBSD is slower to get new hardware support but I actually like that, it's one of the major reasons why things just work in FreeBSD. You put the work in upfront, select the right hardware and FreeBSD will serve you well for years with very little effort. They aren't chasing some imaginary/political/technological dream they are delivering high quality software using tried and tested methods.
    - lmm 6y ago
      > What are you using FreeBSD for? I imagine it's quite good at some things, but isn't that range kind of limited? You need to have the precise set of hardware that's well supported and then use it for precisely the thing it supports well. No you don't? You can throw it on a random commodity desktop and expect it to work. I imagine laptops are harder if you want suspend etc. - it feels pretty similar to how Linux was a few years ago. (If anything support for old hardware tends to be better than Linux because they don't keep changing the kernel interfaces, so a barely-maintained driver from 5 years ago is probably still usable). You don't need to use it in some particular way, it's fine for a daily-driver desktop or home server. I used mine for a little bit of everything until recently - ordinary KDE desktop, fairly normal web hosting environment running some stuff I wrote in Python with WSGI, database server, home VPN server... all the usual stuff.
- zokier 6y ago
  Personally I find this far more worrisome signal of the health of foss ecosystem than the quibbles between elastic and amazon. To me the idea of software "by hackers for hackers" and scratching your own itch has always been one of the key attractions in FOSS ecosystem, but somehow now our itches seem to have outgrown our ability to scratch then. Doing almost anything yourself feels impractical these days. This is also why I like sourcehut, it represents to me sort of downshifting movement in the world that seems to be so very overspeeding. But I do feel that sr.ht does need certain almost monkish attitude to be satisfied with the austere facilities.
  - ketzo 6y ago
    I think there's a certain "hacker cred" that comes from using really user-unfriendly software. And that's cool, but at some point OSS communities are starting to realize that "ease of use" is a hugely important quality. If they don't, they won't keep up with closed-source alternatives, end of sentence.
  - hyperion2010 6y ago
    For better or for worse, this is nothing new. It is a symptom of the fact that the FSF and other FOSS organizations have displayed a fantastic failure of technical leadership for over 3 decades. The political leadership has not been bad, but if you go back and dig through the history of open source you will see that there have been multiple repeated failures by the supposed thought leaders to provide the equivalent level of technical excellence that is required to compete. Making the lives of developers of free software easier has rarely if ever been on the list of priorities for many of the core projects.
    - charliebrownau 6y ago
      This is what happens when you hire * Jewish Zionists * Mentally ill (trans) * Feminists (anti male brainwashed commie cunts) * Censor people and exlude White straight males that are skilled/qualied/experenced over non white people
    - AceJohnny2 6y ago
- vlovich123 6y ago
  I just wish they would invest in the code review aspect of their tools. It’s pretty trash compared to competitors like reviewboard or phabricator (haven’t used Jira or Gitlab recently so can’t comment on those). A big missing feature is the ability to easily upload a stacked diff. Also the whole pull request thing is confusing - why not just use the commit and automatically populate title/summary + figure out which branch I’m likely to merge in to so that there’s a 1 click button to create the review (or push to origin/pr/branch_name to create the review from git cli)
  - properdine 6y ago
    at least on Github, if your branch only has one commit, it will use the commit to automatically populate title and summary. And recently pushed commits show up on top of the repo page with a one-click button to open a PR :) (or you can go to the "branches" page to do this as well)
    - vlovich123 6y ago
      It does not prepopulate in my experience (or if it does, not reliably). And I literally said I want an easy hit command line way to just push to a special branch name to have the pull created. You’re answer is the stereotypical answer of telling the user to adapt to the tools instead of improving the UX (not to mention completely ignoring my point that GitHub doesn’t support stacked diffs). GitHub has a lot of advantages and has maintained their community but they lack pretty badly in some ways on the usability of their UX flow/feature set for power users. This isn’t necessarily accidental or a wrong decision since they might be prioritizing the broader dev community that isn’t familiar with more opinionated dev workflows and they’re solving the Ux for 90% of PRs. I still think there’s a way to strike that balance better and I hope they do so so that I don’t hate my life whenever I’m forced to use GitHub.
- MaxBarraclough 6y ago
  Depends on the specific software. Plenty of Free and Open Source software 'just works' just about perfectly. Firefox and Notepad++ for instance. In the specific instance of GitHub, I have to agree it's nicer and better polished than the alternatives, but I'd also say the Free Software alternatives (GitLab, SourceHut, etc) are catching up, and are already usable. Hosting your own GitLab instance gives you a far nicer solution than an old school solution like SourceForge. > we’re finding that a lot of things are just nicer because a large paid staff of engineers is working on it every day People are paid to work on various Free and Open Source software projects, including Firefox and Notepad++, and most famously, the Linux kernel.
  - sofixa 6y ago
    I wouldn't say GitHub is nicer or more polished than GitLab. Both have similar feature set ( GitHub did well to catch up after years of stagnating, with Actions, docker/package repositories, etc) even if GitLab still has an advantage there, good ecosystems ( GitHub has more tools integrating with it than GitLab), and both work and are fully polished.
  - Deukhoofd 6y ago
    I've been running Gitea myself, and honestly I've found it more polished than Github in general. Never really causes me issues either.
talhah 6y ago
I've never heard of mercurial until this post, I've been using git for version control and it does the job really well. To those who use mercurial over git, why?
- jmercouris 6y ago
  A much better UI. Git won because of the influence of the Linux kernel developers, that's all.
  - xyst 6y ago
    The influence of a single linux kernel developer is the reason it's adoption is so high - Linus Torvalds.
    - tux1968 6y ago
      That's much too simplistic. For instance Linus also denounces C++ and programmers don't fall into line behind him on that front. He is influential, but could not have caused the monumental shift in version control without producing a phenomenal tool to do the job. Git largely won on its overall merit, despite having some obvious UI warts.
    - kbenson 6y ago
      Eh, that's a bit reductionist. Git was developed by Tovalds because BitKeeper had shortcomings he kept grating against, and it really needed to be a DVCS for kernel development. So he created something that fit the kernel development needs well, and it happened to also fit the needs of other companies as well. That it was free and open source was icing on the cake. That Torvalds created it just meant that there was already a wide audience of people willing to consider it and give it a fair shake initially. I'm sure it didn't hurt that Torvalds had many years of experience dealing with lots of the shortcomings of different version control systems and their shortcomings in what is probably one of the more extreme version control situations, and is also known for optimizing the hard parts of things. It was really the perfect storm for good open source software. A highly skilled developer with massive amounts of domain experience that is highly motivated to solve the problem. What you often get in those situations is something that is an obvious step up from the status quo, at least of free offerings, and often matching the paid offerings if they are more advanced. If it wasn't Torvalds, it just would have taken longer to take over.
swatson741 6y ago
I've worked on SDL although I haven't contributed any code. Partly because it isn't convenient to contribute and partly because I felt that the work I did wasn't significant enough to merit jumping thru the hoops to contribute. The move to Github is a very welcomed change. > 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 is still a good policy to have. They've already done the work to migrate from mercurial to git so, the potential for moving to a forked gitlab or something like that is there. Personally I think that, especially if your doing open source, github is really the way to go here. Github has been great for open source.
- ocdtrekkie 6y ago
  I think GitHub is generally safe as long as you have an exit plan for when it's no longer the place you want to be. Know where you're moving your issues and actions if you decide you need to leave.
  - encom 6y ago
    Since the Microsoft takeover, the platform is compromised. It seems people have very short memories.
    - stu2b50 6y ago
      I'm curious, what is the threat model? For SDL, for example, what's the nightmare scenario with Github and Microsoft?
      - encom 6y ago
        Why engage with a company that have proven themselves to be an enemy of Free Software? I'm not buying their "how do you do, fellow Linux users" facade.
        stu2b50 6y ago
        So, to ask again, what is a specific way that choosing Github and Microsoft can hurt a software project in the future? I'm not asking in bad faith here. If there are such dangerous I would very much like to know them.
livvelupp 6y ago
Amazing boomer rant
- qbasic_forever 6y ago
  Just be aware that "boomer rant" creator made one of the most highly successful and used game development libraries in history. I would wager 75% of the games in your steam library use or depend on SDL in some way. Almost certainly most of the games from your childhood that you cherish and love have used SDL too. You should probably be thanking them for creating something that gave you joy at one time, and giving it away for free...
  - postalrat 6y ago
    Thinking takes effort.
  - HotVector 6y ago
    I see where the SDL author is coming from, but is it really that hard to get local GitLab instance running? Or even just using GitLab? I saw other replies about how GitHub has a network of open source developers, but that didn't bother the SDL author before, and I don't see why it is bothering him now.
    - rvz 6y ago
      If open-source organisations like RedoxOS, GNOME, GTK (Who use their own self-hosted instances of GitLab), etc are able to self-host, surely SDL can too, thanks to the new technologies out there that automates this. When your entire project is sitting on GitHub like nearly everyone else out there and something goes wrong, don't be surprised when one has to tweet at the CEO of GitHub if the repository is falsely flagged for 'some reason' or if your GitHub actions, pull requests and packages are experiencing a degraded service. [0] https://news.ycombinator.com/item?id=22663627 https://news.ycombinator.com/item?id=22663627 [1] https://news.ycombinator.com/item?id=26066365 https://news.ycombinator.com/item?id=26066365
    - qbasic_forever 6y ago
WrtCdEvrydy 6y ago
I'd actually argue for a Gitlab instance on some sort of docker container. Microsoft keeps dropping the ball on Github for my taste.
h_anna_h 6y ago
This is sad. It is as if we are going backwards, from an open source solution they decided to move to a closed ecosystem. They could at least use gitlab instead...
- slenk 6y ago
  Well, GitLab has recently hiked up their prices. As a GitHub Pro user, my price has only ever gone down.
  - h_anna_h 6y ago
    They could use the free version or self-host it.
    - rvz 6y ago
      Exactly. You have new solutions like GitLab, Gitea and Docker which can automate this stuff for you and it is yours and you own everything. Didn't stop RedoxOS, wireguard and GNOME from self-hosting.
      - slenk 6y ago
        The point is that they didn't want to deal with self-hosting anymore. I think he makes some valid points in the article re: owning all of your own infrastructure - there is something to be said for that. But it is so much more than just Git hosting. > "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."
        rvz 6y ago
        I don't see GNOME (GitLab), FreeBSD, Blender (Phabricator) or even wireguard complaining about their issue tracking management here. I have seen many examples of FOSS/FLOSS devs choosing a self-hosted solution over GitHub. For example, ReactOS's source is hosted on both GitHub and they have a self-hosted backup which they control in case GitHub goes down. If this was SDL being GitHub, so far they don't have a backup plan. Pull requests, issues and their GitHub actions will not work and they would need to wait for GitHub to restore their services or do 'anything'. I prefer 'Owning all of your own infrastructure' or even being on GitHub and having a self-hosted backup of your own infrastructure just in case GitHub goes down. But moving everything and being 'all in on GitHub' is the ridiculous quest to centralize everything on a platform you don't own because everyone else is doing it.
jrochkind1 6y ago
This is poignant for me, for reasons that have nothing to do with the technical merits of git vs mercurial, or github/Microsoft specifically as a company. > 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. The bar has been raised for developer tools in 2021. The OP recognizes it, it's true. The bar has been raised by hosted products, usually corporate/proprietary products, that companies often give out for free at least for some and at least initially. It is very hard to compete with this with "DIY" systems. It's just a fact. You have to spend a whole bunch of time on your tooling infrastructure, and you still don't really get close. As an open source developer you'd rather be spending it on the product, not the tooling infrastructure. (It's way easier to get people to volunteer to contribute to the product, often because they are scratching their own itch, then it is to get people to volunteer to do "ops" stuff for you. The ops has diverged into somewhat of a different skillset. Who wants to do ops for free for open source products? Some people, sure, but not nearly as much as there is demand, or as there would be demand if they were all "self-hosting" everything instead of using the oh-so-easy commercial hosted offerings...) And then a lot of those open source products themselves are just janky and poorly maintained, there isn't enough labor being put in. We could have imagined a different world. This is not the world the open source afficianados of 20 years imagined or wanted. But... this is where we are. Nobody wants to spend all that time trying to keep the janky self-hosted system running, when it's so much clunkier and you are probably making it harder for new contributors at the same time, and you'd rather it just were done for you so you can focus on the code. Even when you know what you are giving up in terms of control or the free software world we'd like to be contributing to. The author is writing knowing all of this, knowing exactly what is being given up, but seeing it as the best option to get the open source product (SDL) developed as high-quality as possible, and regretting that this is where we find ourselves.
- qbasic_forever 6y ago
einpoklum 6y ago
It seems to me people don't give enough thought to the possibility of hosting themselves elsewhere, and only "mirroring" onto GitHub for the presence effect. GCC does this (edit: LLVM half-does-it, in that issues are handled elsewhere). So does MonetDB and I'm sure there are a million more examples.
- saagarjha 6y ago
  The GitHub repository for LLVM is the official one: https://llvm.org/docs/Proposals/GitHubMove.html https://llvm.org/docs/Proposals/GitHubMove.html
- jefft255 6y ago
  This doesn’t solve the issues of stuff like Bugzilla, plus these mirror only offer a fraction of what GitHub truly offers (issues, CI, pull requests with nice interface). Basically, if you think your home grown infra sucks, a GitHub mirror doesn’t address that.
  - einpoklum 6y ago
    Neither does hosting your code on GitHub. Its issues mechanism is very limited compared to Bugzilla (or JIRA or whatnot). As for CI - GitHub itself doesn't give you CI. Travis does and they've gone mostly/wholly commercial. etc. I'm just saying you don't need to be fully on GitHub to be visible on GitHub.
- olmideso 6y ago
  Actually LLVM has their official repository there, not a mirror as GCC[0]. But they still do reviews and merges outside of github. linux kernel project does a similar thing. [0] https://github.com/llvm/llvm-project https://github.com/llvm/llvm-project
  - pengaru 6y ago
    The "linux kernel project" does not have its official tree on github, Linus just has a read-only mirror there. You can confirm this by reading one of the bot replies to a PR [0]: Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch. [0] https://github.com/torvalds/linux/pull/805#issuecomment-593375542 https://github.com/torvalds/linux/pull/805#issuecomment-5933...
krapp 6y ago
Awesome. I've been pulling from an unofficial Github mirror for SDL2 for a while now.
coliveira 6y ago
This sounds like an indictment of git. It was supposed to make it easier for OSS developers to collaborate, but it turns out that you become bound to a monopoly like Microsoft. Why can't git users develop an easy to maintain server, like svn and fossil did, for example?
- guidoism 6y ago
  Not sure this is an indictment of git. It still works great without central servers (unlike svn) but GitHub just makes it nicer for most people. And with GitHub the wiki is just a git repo so I’m guessing it would be easy to take with you. Not sure how the GitHub issues work so that would be a pain to move away from.
- iforgotpassword 6y ago
  This is not about git. Git is probably easier to set up and maintain than svn. This is about everything else github offers like issues, pull requests, discussions, wiki, ....
- qbasic_forever 6y ago
  Read-up on the history of git. It was not designed to be a new panacea of OSS development. It was designed to keep the Linux kernel development running smoothly after their commercial source code host dropped them--that's it. Running a git server is actually very easy, just run the git-daemon command: https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon This is actually easier than running something like Gitlab that requires setting up a database, a reverse proxy, or even an entire runtime environment like Kubernetes, etc. You're falling into a trap of conflating git with Github. Github took the mechanics of git and built a slick, centralized, commercial source code host on top of it. They made a social network that engaged users and gamified writing code. Lots of folks are working on similar commercial and open source variations of the same. But in all those cases git is just a part of the tech and not tightly coupled to the success (or failure) of them.
  - tootie 6y ago
guidoism 6y ago
> 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. OMG I feel heard. I feel like this is me.
gmueckl 6y ago
Should have put Heptapod in a docker container instead: https://heptapod.net https://heptapod.net A hosted version is also available: https://foss.heptapod.net/public https://foss.heptapod.net/public Works like gitlab, but on top of Mercurial. Use it myself and it works perfectly.
charliebrownau 6y ago
Moving to a big centralised website that can * pull the project on a whim * Is Anti merit * Anti free speech * Is anti white What could go wrong
Jkvngt 6y ago
I don't like this, everything is moving to GitHub which has already done some questionable things. I don't care for Microsoft and I don't believe them when they claim they "heart" Linux.
ausjke 6y ago
It seems libsdl2 does not support framebuffer anymore, which is critical for embedded devices(no gpu or 3D acceleration i.e. opengl needed there)
- mewse 6y ago
  Yeah, libsdl2 is built around more modern rendering devices and drawing APIs, and supports far fewer (but more popularly used) platforms. And is vastly faster on those platforms than SDL1.2 used to be, since it’s playing to the strengths of those modern devices, instead of fighting against them the way that SDL1.2 did. Do note that libsdl2 can emulate framebuffer-style “I just want to splat pixels to the screen”-style program architectures just fine using “streaming” textures [0], but that’s not going to help you if it doesn’t support your platform. If you need broader platform support and/or are running on low-power devices, then libsdl1.2 is still around and supported, and is probably a more appropriate choice for such projects. [0]: http://wiki.libsdl.org/MigrationGuide#If_your_game_just_wants_to_get_fully-rendered_frames_to_the_screen http://wiki.libsdl.org/MigrationGuide#If_your_game_just_want...
- anthk 6y ago
  It supports kmscon, maybe if works in software.
cupofinsane 6y ago
I wish distributed bug-trackers like git-bug receive more love here. They don't solve CI/CD like GitHub does, but hey, it's still something!
reidrac 6y ago
A bit sad that they gave up on Mercurial, if they really think is better for their needs; although having used Subversion, Mercurial, Bazaar, git, ...; I kind of like when it is just git. Not because is better or I like it better, but switching between tools in this case was PITA because of the subtle differences of almost the same commands. > And the way that most people personally like using git is via GitHub. I don't get it. In which way? I use GH for pull requests, may be issues? There's a lot more of my git day to day than that. I don't think you really use git via GH.
cpeterso 6y ago
What will be SDL's official GitHub repo? The article had no link. Seems like an important item to include. https://github.com/libsdl https://github.com/libsdl is an unofficial mirror and github.com/sdl/ is something unrelated.
- edflsafoiewq 6y ago
  > We will be migrating on the 10th. Tomorrow. Presumably you'll know then.
TinkersW 6y ago
Good, I remember wanting to submit a tiny patch but then giving up because I couldn't be bothered to make sense of the system they were using(and I use mercurial for my personal stuff).

292 points by Bl4ckb0ne 6y ago

"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 heydey 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." This seems to sum up the biggest pain point that drives people away from OSS. Not knowledge, not skill, not price, but the total experience of a nice piece of software that lets you get the work you actually want to get done... done.

PurpleFoxy 6y ago
Wonder why they did not pick GitLab since it is significantly better for FOSS ideals and has the same niceness of GitHub
- fileeditview 6y ago
  My guess is the network-effect. If you want more contributions Github is the platform to pick for your project. Good or bad it is the de facto standard platform for OSS projects with a huge pool of potential developers.
  - iforgotpassword 6y ago
    That's it. Back in the day that's what was great about source forge. Now it's github. Many people already have an account there so you significantly lower the bar for people to get involved with patches, bug reports etc. If a project has self hosted infra and wants me to sign up to their Bugzilla I think twice before doing so. And if github really turns to shit because Microsoft shows their true evil face you can just move platforms again.
    - jhasse 6y ago
      Check out https://gitlab.kitware.com/users/sign_in https://gitlab.kitware.com/users/sign_in or https://gitlab.xiph.org/users/sign_in https://gitlab.xiph.org/users/sign_in You can sign up with your GitHub account.
      - iruoy 6y ago
        https://gitlab.gnome.org/users/sign_in https://gitlab.gnome.org/users/sign_in even allows you to login with a GitLab account. Which ironically isn't possible on these other two.
  - devmunchies 6y ago
    I don't think this is it. I think it's more about (1) marketing and discoverability and (2) ease for current maintainers. Getting new contributors is overrated for OSS unless they are an exceptional contributor (like if a big org were to contribute). Main incentive is getting more consumers of the project (increase popularity) and making it more convenient for current team.
    - fileeditview 6y ago
      I agree but think it's a bit of both and depends on the project. I e.g. don't think SDL needs more exposure. Everyone in game dev knows SDL.. many game engines / frameworks are built on top of it.
- 1_player 6y ago
  > has the same niceness of GitHub Debatable. As a previous paid customer, I have never been a fan of GitLab, I've always found it slow, buggy and of confusing design language. YMMV.
  - ta988 6y ago
    I think what was meant is that at least parts of GitLab are FOSS and can be installed locally which in not the case with github.
    - pitterpatter 6y ago
      But installable locally kinda defeats the whole point of this move? And as someone who manages a small gitlab instance, it's not always set it and forget it unfortunately.
      - imtringued 6y ago
        No, it doesn't because Gitlab.com exists. Installability is an insurance policy.
- john_cogs 6y ago
  GitLab team member here. For anyone considering a similar move, I encourage you to check out our GitLab for Open Source program: https://about.gitlab.com/solutions/open-source/ https://about.gitlab.com/solutions/open-source/
  - ta988 6y ago
    For academics, it take a few minutes to get a github academic account. For gitlab you have to write justifications and wait and wait, to maybe get it...
    - smarx007 6y ago
      Yep, our university has GH Enterprise and refuses to “procure” (as it requires the central body to agree to the ToS) free Gitlab for academia as “another” git solution. Our project team on Gitlab cannot get into that program for academics because they only let one application per institution. I understand each side but still don’t see how we can solve this problem. Would love to find a way!
      - smarx007 6y ago
        Update: seems like Gitlab removed the requirement of having one application per institution from https://about.gitlab.com/solutions/education/join/ https://about.gitlab.com/solutions/education/join/, I just applied again.
- the_jeremy 6y ago
  I use GitLab at work. My experience is that it has more features that work less well. There are a bunch of comments pointing to a GitLab issue to explain stupid hacks in our CI/CD pipelines.
- nuritzi 6y ago
  Thanks, @PurpleFoxy! I tend to agree with @Fileeditview about the network effect and how GitHub has done a great job of helping OSS projects with visibility. Like john_cogs, I'm also a GitLab team member, and am part of the Community Relations team. I run the GitLab for Open Source program. I joined about a year ago and am really impressed by how fast GitLab moves forward. We have a lot of awesome stuff coming up to make the product, and our community, even better. With a release each month, we use our momentum to make big strides in the DevSecOps space -- so people can rest assured that we'll keep improving quickly! We like to build along with our users, and believe everyone can contribute to our product roadmap, and all aspects of our company (e.g. see https://about.gitlab.com/direction/ https://about.gitlab.com/direction/). For OSS projects considering a move, check out this GitHub vs GitLab Decision Kit: https://about.gitlab.com/devops-tools/github-vs-gitlab/decision-kit/ https://about.gitlab.com/devops-tools/github-vs-gitlab/decis... It outlines some of the key points to consider when evaluating a move. I'm also happy to answer any questions about the GitLab for Open Source program john_cogs mentioned below (https://about.gitlab.com/solutions/open-source/ https://about.gitlab.com/solutions/open-source/). It's a great deal in that OSS projects get 50,000 CI minutes for free along with our top tier in SaaS or self-managed. Feel free to reach out to opensource@gitlab.com with any questions!
  - apple4ever 6y ago
    Best two things GitLab needs to do: 1. Fix their bugs instead of new features (ex: rebase fails 9/10 time for us) 2. Fix their pricing (ex: $99 per user is way to expensive and that is the only plan that allows free users)
- wdb 6y ago
  Github Actions is already a good reason to use Github over Gitlab. Also the pricing is much better with Github even for Github Enterprise. All kind of normal features are behind a $99/user/month fee. I don't understand why things like vulnerability scanning needs to cost $80 per user more and then at the same not supporting multiple report files as artefacts in monorepo.
- ojnabieoot 6y ago
  I think they implicitly addressed this: > 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? Gitlab Inc. is dramatically more likely to go out of business that Microsoft, and Gitlab generally is dramatically more likely to have significant outages than Github.
- mlindner 6y ago
  Sorry but GitLab is utterly horrendous from a developer's perspective compared to GitHub. It's massive enterprise bloatware (like most Atlassian products for example) that is nigh unusable without an entire team of people to manage it. My company uses it and it causes me problems almost every other day. Things that should "just work" never do. Further when something gets reported to GitLab they automatically close old issues and things never get fixed. One outstanding huge issue is that if you mark certain files as owned by a specific team for example, it won't notify the teams to come in and actually review the code. There's options that say they do it, but it never works. (The notification system in general is an utter mess.) GitLab is an example where everything is chopped up into tiny pieces and nothing works across different parts of the codebase. I don't envy anyone that works for GitLab as just the look of the code shows what a mess the backend must be.
  - john_cogs 6y ago
    GitLab team member here. We have Code Owners [1] and recently introduced Merge Request Reviewers [2]. Our team is working on the author-review handoff [3] as part of their work to improve the overall merge request reviewer experience [4]. I'm sure they would appreciate any detailed feedback you could share on the epics linked below. 1 - https://docs.gitlab.com/ee/user/project/code_owners.html#introduction https://docs.gitlab.com/ee/user/project/code_owners.html#int... 2 - https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/#reviewers-for-merge-requests https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-rel... 3 - https://gitlab.com/groups/gitlab-org/-/epics/5074 https://gitlab.com/groups/gitlab-org/-/epics/5074 4 - https://gitlab.com/groups/gitlab-org/-/epics/1823 https://gitlab.com/groups/gitlab-org/-/epics/1823
    - mlindner 6y ago
      Code Owners don't work. If you assign a team as the owner it doesn't do anything unless the team itself is also added to the project. Further it doesn't seem to properly notify people either. We've fallen back to emailing everyone manually whenever a pull request is submitted.
  - sofixa 6y ago
- agentdrtran 6y ago
  > has the same niceness of GitHub I gitlab significantly harder to use and more error-prone than Github
colechristensen 6y ago
>This seems to sum up the biggest pain point that drives people away from OSS. Not knowledge, not skill, not price, but the total experience of a nice piece of software that lets you get the work you actually want to get done... done. This is why I continue to be fascinated by FreeBSD, I don't use it for much but when I do, what I'm trying to do almost always works right out of the box. My point is that is all comes down to packaging, which is done everywhere. Docker is so popular because debian-style/rpm-style/etc packaging systems and the maintainers of said packages do a pretty uneven job of making things work without luck or fiddling (or having to have package specific knowledge about how to do something obvious). Docker doesn't really do a great job either, but it has a different set of problems and having the old ones gone is nice.
- oblio 6y ago
  What are you using FreeBSD for? I imagine it's quite good at some things, but isn't that range kind of limited? You need to have the precise set of hardware that's well supported and then use it for precisely the thing it supports well.
  - dazzawazza 6y ago
    In my experience of using FreeBSD for twenty or so years, for the most part, if it's a major vendor and a few years old then it's supported. It is true that FreeBSD is slower to get new hardware support but I actually like that, it's one of the major reasons why things just work in FreeBSD. You put the work in upfront, select the right hardware and FreeBSD will serve you well for years with very little effort. They aren't chasing some imaginary/political/technological dream they are delivering high quality software using tried and tested methods.
  - lmm 6y ago
    > What are you using FreeBSD for? I imagine it's quite good at some things, but isn't that range kind of limited? You need to have the precise set of hardware that's well supported and then use it for precisely the thing it supports well. No you don't? You can throw it on a random commodity desktop and expect it to work. I imagine laptops are harder if you want suspend etc. - it feels pretty similar to how Linux was a few years ago. (If anything support for old hardware tends to be better than Linux because they don't keep changing the kernel interfaces, so a barely-maintained driver from 5 years ago is probably still usable). You don't need to use it in some particular way, it's fine for a daily-driver desktop or home server. I used mine for a little bit of everything until recently - ordinary KDE desktop, fairly normal web hosting environment running some stuff I wrote in Python with WSGI, database server, home VPN server... all the usual stuff.
zokier 6y ago
Personally I find this far more worrisome signal of the health of foss ecosystem than the quibbles between elastic and amazon. To me the idea of software "by hackers for hackers" and scratching your own itch has always been one of the key attractions in FOSS ecosystem, but somehow now our itches seem to have outgrown our ability to scratch then. Doing almost anything yourself feels impractical these days. This is also why I like sourcehut, it represents to me sort of downshifting movement in the world that seems to be so very overspeeding. But I do feel that sr.ht does need certain almost monkish attitude to be satisfied with the austere facilities.
- ketzo 6y ago
  I think there's a certain "hacker cred" that comes from using really user-unfriendly software. And that's cool, but at some point OSS communities are starting to realize that "ease of use" is a hugely important quality. If they don't, they won't keep up with closed-source alternatives, end of sentence.
- hyperion2010 6y ago
  For better or for worse, this is nothing new. It is a symptom of the fact that the FSF and other FOSS organizations have displayed a fantastic failure of technical leadership for over 3 decades. The political leadership has not been bad, but if you go back and dig through the history of open source you will see that there have been multiple repeated failures by the supposed thought leaders to provide the equivalent level of technical excellence that is required to compete. Making the lives of developers of free software easier has rarely if ever been on the list of priorities for many of the core projects.
  - charliebrownau 6y ago
    This is what happens when you hire * Jewish Zionists * Mentally ill (trans) * Feminists (anti male brainwashed commie cunts) * Censor people and exlude White straight males that are skilled/qualied/experenced over non white people
  - AceJohnny2 6y ago
vlovich123 6y ago
I just wish they would invest in the code review aspect of their tools. It’s pretty trash compared to competitors like reviewboard or phabricator (haven’t used Jira or Gitlab recently so can’t comment on those). A big missing feature is the ability to easily upload a stacked diff. Also the whole pull request thing is confusing - why not just use the commit and automatically populate title/summary + figure out which branch I’m likely to merge in to so that there’s a 1 click button to create the review (or push to origin/pr/branch_name to create the review from git cli)
- properdine 6y ago
  at least on Github, if your branch only has one commit, it will use the commit to automatically populate title and summary. And recently pushed commits show up on top of the repo page with a one-click button to open a PR :) (or you can go to the "branches" page to do this as well)
  - vlovich123 6y ago
    It does not prepopulate in my experience (or if it does, not reliably). And I literally said I want an easy hit command line way to just push to a special branch name to have the pull created. You’re answer is the stereotypical answer of telling the user to adapt to the tools instead of improving the UX (not to mention completely ignoring my point that GitHub doesn’t support stacked diffs). GitHub has a lot of advantages and has maintained their community but they lack pretty badly in some ways on the usability of their UX flow/feature set for power users. This isn’t necessarily accidental or a wrong decision since they might be prioritizing the broader dev community that isn’t familiar with more opinionated dev workflows and they’re solving the Ux for 90% of PRs. I still think there’s a way to strike that balance better and I hope they do so so that I don’t hate my life whenever I’m forced to use GitHub.
MaxBarraclough 6y ago
Depends on the specific software. Plenty of Free and Open Source software 'just works' just about perfectly. Firefox and Notepad++ for instance. In the specific instance of GitHub, I have to agree it's nicer and better polished than the alternatives, but I'd also say the Free Software alternatives (GitLab, SourceHut, etc) are catching up, and are already usable. Hosting your own GitLab instance gives you a far nicer solution than an old school solution like SourceForge. > we’re finding that a lot of things are just nicer because a large paid staff of engineers is working on it every day People are paid to work on various Free and Open Source software projects, including Firefox and Notepad++, and most famously, the Linux kernel.
- sofixa 6y ago
  I wouldn't say GitHub is nicer or more polished than GitLab. Both have similar feature set ( GitHub did well to catch up after years of stagnating, with Actions, docker/package repositories, etc) even if GitLab still has an advantage there, good ecosystems ( GitHub has more tools integrating with it than GitLab), and both work and are fully polished.
- Deukhoofd 6y ago
  I've been running Gitea myself, and honestly I've found it more polished than Github in general. Never really causes me issues either.

talhah 6y ago

I've never heard of mercurial until this post, I've been using git for version control and it does the job really well. To those who use mercurial over git, why?

jmercouris 6y ago
A much better UI. Git won because of the influence of the Linux kernel developers, that's all.
- xyst 6y ago
  The influence of a single linux kernel developer is the reason it's adoption is so high - Linus Torvalds.
  - tux1968 6y ago
    That's much too simplistic. For instance Linus also denounces C++ and programmers don't fall into line behind him on that front. He is influential, but could not have caused the monumental shift in version control without producing a phenomenal tool to do the job. Git largely won on its overall merit, despite having some obvious UI warts.
  - kbenson 6y ago
    Eh, that's a bit reductionist. Git was developed by Tovalds because BitKeeper had shortcomings he kept grating against, and it really needed to be a DVCS for kernel development. So he created something that fit the kernel development needs well, and it happened to also fit the needs of other companies as well. That it was free and open source was icing on the cake. That Torvalds created it just meant that there was already a wide audience of people willing to consider it and give it a fair shake initially. I'm sure it didn't hurt that Torvalds had many years of experience dealing with lots of the shortcomings of different version control systems and their shortcomings in what is probably one of the more extreme version control situations, and is also known for optimizing the hard parts of things. It was really the perfect storm for good open source software. A highly skilled developer with massive amounts of domain experience that is highly motivated to solve the problem. What you often get in those situations is something that is an obvious step up from the status quo, at least of free offerings, and often matching the paid offerings if they are more advanced. If it wasn't Torvalds, it just would have taken longer to take over.

swatson741 6y ago

I've worked on SDL although I haven't contributed any code. Partly because it isn't convenient to contribute and partly because I felt that the work I did wasn't significant enough to merit jumping thru the hoops to contribute. The move to Github is a very welcomed change. > 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 is still a good policy to have. They've already done the work to migrate from mercurial to git so, the potential for moving to a forked gitlab or something like that is there. Personally I think that, especially if your doing open source, github is really the way to go here. Github has been great for open source.

ocdtrekkie 6y ago
I think GitHub is generally safe as long as you have an exit plan for when it's no longer the place you want to be. Know where you're moving your issues and actions if you decide you need to leave.
- encom 6y ago
  Since the Microsoft takeover, the platform is compromised. It seems people have very short memories.
  - stu2b50 6y ago
    I'm curious, what is the threat model? For SDL, for example, what's the nightmare scenario with Github and Microsoft?
    - encom 6y ago
      Why engage with a company that have proven themselves to be an enemy of Free Software? I'm not buying their "how do you do, fellow Linux users" facade.
      - stu2b50 6y ago
        So, to ask again, what is a specific way that choosing Github and Microsoft can hurt a software project in the future? I'm not asking in bad faith here. If there are such dangerous I would very much like to know them.

livvelupp 6y ago

Amazing boomer rant

qbasic_forever 6y ago
Just be aware that "boomer rant" creator made one of the most highly successful and used game development libraries in history. I would wager 75% of the games in your steam library use or depend on SDL in some way. Almost certainly most of the games from your childhood that you cherish and love have used SDL too. You should probably be thanking them for creating something that gave you joy at one time, and giving it away for free...
- postalrat 6y ago
  Thinking takes effort.
- HotVector 6y ago
  I see where the SDL author is coming from, but is it really that hard to get local GitLab instance running? Or even just using GitLab? I saw other replies about how GitHub has a network of open source developers, but that didn't bother the SDL author before, and I don't see why it is bothering him now.
  - rvz 6y ago
    If open-source organisations like RedoxOS, GNOME, GTK (Who use their own self-hosted instances of GitLab), etc are able to self-host, surely SDL can too, thanks to the new technologies out there that automates this. When your entire project is sitting on GitHub like nearly everyone else out there and something goes wrong, don't be surprised when one has to tweet at the CEO of GitHub if the repository is falsely flagged for 'some reason' or if your GitHub actions, pull requests and packages are experiencing a degraded service. [0] https://news.ycombinator.com/item?id=22663627 https://news.ycombinator.com/item?id=22663627 [1] https://news.ycombinator.com/item?id=26066365 https://news.ycombinator.com/item?id=26066365
  - qbasic_forever 6y ago

WrtCdEvrydy 6y ago

I'd actually argue for a Gitlab instance on some sort of docker container. Microsoft keeps dropping the ball on Github for my taste.

h_anna_h 6y ago

This is sad. It is as if we are going backwards, from an open source solution they decided to move to a closed ecosystem. They could at least use gitlab instead...

slenk 6y ago
Well, GitLab has recently hiked up their prices. As a GitHub Pro user, my price has only ever gone down.
- h_anna_h 6y ago
  They could use the free version or self-host it.
  - rvz 6y ago
    Exactly. You have new solutions like GitLab, Gitea and Docker which can automate this stuff for you and it is yours and you own everything. Didn't stop RedoxOS, wireguard and GNOME from self-hosting.
    - slenk 6y ago
      The point is that they didn't want to deal with self-hosting anymore. I think he makes some valid points in the article re: owning all of your own infrastructure - there is something to be said for that. But it is so much more than just Git hosting. > "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."
      - rvz 6y ago
        I don't see GNOME (GitLab), FreeBSD, Blender (Phabricator) or even wireguard complaining about their issue tracking management here. I have seen many examples of FOSS/FLOSS devs choosing a self-hosted solution over GitHub. For example, ReactOS's source is hosted on both GitHub and they have a self-hosted backup which they control in case GitHub goes down. If this was SDL being GitHub, so far they don't have a backup plan. Pull requests, issues and their GitHub actions will not work and they would need to wait for GitHub to restore their services or do 'anything'. I prefer 'Owning all of your own infrastructure' or even being on GitHub and having a self-hosted backup of your own infrastructure just in case GitHub goes down. But moving everything and being 'all in on GitHub' is the ridiculous quest to centralize everything on a platform you don't own because everyone else is doing it.

jrochkind1 6y ago

This is poignant for me, for reasons that have nothing to do with the technical merits of git vs mercurial, or github/Microsoft specifically as a company. > 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. The bar has been raised for developer tools in 2021. The OP recognizes it, it's true. The bar has been raised by hosted products, usually corporate/proprietary products, that companies often give out for free at least for some and at least initially. It is very hard to compete with this with "DIY" systems. It's just a fact. You have to spend a whole bunch of time on your tooling infrastructure, and you still don't really get close. As an open source developer you'd rather be spending it on the product, not the tooling infrastructure. (It's way easier to get people to volunteer to contribute to the product, often because they are scratching their own itch, then it is to get people to volunteer to do "ops" stuff for you. The ops has diverged into somewhat of a different skillset. Who wants to do ops for free for open source products? Some people, sure, but not nearly as much as there is demand, or as there would be demand if they were all "self-hosting" everything instead of using the oh-so-easy commercial hosted offerings...) And then a lot of those open source products themselves are just janky and poorly maintained, there isn't enough labor being put in. We could have imagined a different world. This is not the world the open source afficianados of 20 years imagined or wanted. But... this is where we are. Nobody wants to spend all that time trying to keep the janky self-hosted system running, when it's so much clunkier and you are probably making it harder for new contributors at the same time, and you'd rather it just were done for you so you can focus on the code. Even when you know what you are giving up in terms of control or the free software world we'd like to be contributing to. The author is writing knowing all of this, knowing exactly what is being given up, but seeing it as the best option to get the open source product (SDL) developed as high-quality as possible, and regretting that this is where we find ourselves.

qbasic_forever 6y ago

einpoklum 6y ago

It seems to me people don't give enough thought to the possibility of hosting themselves elsewhere, and only "mirroring" onto GitHub for the presence effect. GCC does this (edit: LLVM half-does-it, in that issues are handled elsewhere). So does MonetDB and I'm sure there are a million more examples.

saagarjha 6y ago
The GitHub repository for LLVM is the official one: https://llvm.org/docs/Proposals/GitHubMove.html https://llvm.org/docs/Proposals/GitHubMove.html
jefft255 6y ago
This doesn’t solve the issues of stuff like Bugzilla, plus these mirror only offer a fraction of what GitHub truly offers (issues, CI, pull requests with nice interface). Basically, if you think your home grown infra sucks, a GitHub mirror doesn’t address that.
- einpoklum 6y ago
  Neither does hosting your code on GitHub. Its issues mechanism is very limited compared to Bugzilla (or JIRA or whatnot). As for CI - GitHub itself doesn't give you CI. Travis does and they've gone mostly/wholly commercial. etc. I'm just saying you don't need to be fully on GitHub to be visible on GitHub.
olmideso 6y ago
Actually LLVM has their official repository there, not a mirror as GCC[0]. But they still do reviews and merges outside of github. linux kernel project does a similar thing. [0] https://github.com/llvm/llvm-project https://github.com/llvm/llvm-project
- pengaru 6y ago
  The "linux kernel project" does not have its official tree on github, Linus just has a read-only mirror there. You can confirm this by reading one of the bot replies to a PR [0]: Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch. [0] https://github.com/torvalds/linux/pull/805#issuecomment-593375542 https://github.com/torvalds/linux/pull/805#issuecomment-5933...

krapp 6y ago

Awesome. I've been pulling from an unofficial Github mirror for SDL2 for a while now.

coliveira 6y ago

This sounds like an indictment of git. It was supposed to make it easier for OSS developers to collaborate, but it turns out that you become bound to a monopoly like Microsoft. Why can't git users develop an easy to maintain server, like svn and fossil did, for example?

guidoism 6y ago
Not sure this is an indictment of git. It still works great without central servers (unlike svn) but GitHub just makes it nicer for most people. And with GitHub the wiki is just a git repo so I’m guessing it would be easy to take with you. Not sure how the GitHub issues work so that would be a pain to move away from.
iforgotpassword 6y ago
This is not about git. Git is probably easier to set up and maintain than svn. This is about everything else github offers like issues, pull requests, discussions, wiki, ....
qbasic_forever 6y ago
Read-up on the history of git. It was not designed to be a new panacea of OSS development. It was designed to keep the Linux kernel development running smoothly after their commercial source code host dropped them--that's it. Running a git server is actually very easy, just run the git-daemon command: https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon This is actually easier than running something like Gitlab that requires setting up a database, a reverse proxy, or even an entire runtime environment like Kubernetes, etc. You're falling into a trap of conflating git with Github. Github took the mechanics of git and built a slick, centralized, commercial source code host on top of it. They made a social network that engaged users and gamified writing code. Lots of folks are working on similar commercial and open source variations of the same. But in all those cases git is just a part of the tech and not tightly coupled to the success (or failure) of them.
- tootie 6y ago

guidoism 6y ago

> 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. OMG I feel heard. I feel like this is me.

gmueckl 6y ago

Should have put Heptapod in a docker container instead: https://heptapod.net https://heptapod.net A hosted version is also available: https://foss.heptapod.net/public https://foss.heptapod.net/public Works like gitlab, but on top of Mercurial. Use it myself and it works perfectly.

charliebrownau 6y ago

Moving to a big centralised website that can * pull the project on a whim * Is Anti merit * Anti free speech * Is anti white What could go wrong

Jkvngt 6y ago

I don't like this, everything is moving to GitHub which has already done some questionable things. I don't care for Microsoft and I don't believe them when they claim they "heart" Linux.

ausjke 6y ago

It seems libsdl2 does not support framebuffer anymore, which is critical for embedded devices(no gpu or 3D acceleration i.e. opengl needed there)

mewse 6y ago
Yeah, libsdl2 is built around more modern rendering devices and drawing APIs, and supports far fewer (but more popularly used) platforms. And is vastly faster on those platforms than SDL1.2 used to be, since it’s playing to the strengths of those modern devices, instead of fighting against them the way that SDL1.2 did. Do note that libsdl2 can emulate framebuffer-style “I just want to splat pixels to the screen”-style program architectures just fine using “streaming” textures [0], but that’s not going to help you if it doesn’t support your platform. If you need broader platform support and/or are running on low-power devices, then libsdl1.2 is still around and supported, and is probably a more appropriate choice for such projects. [0]: http://wiki.libsdl.org/MigrationGuide#If_your_game_just_wants_to_get_fully-rendered_frames_to_the_screen http://wiki.libsdl.org/MigrationGuide#If_your_game_just_want...
anthk 6y ago
It supports kmscon, maybe if works in software.

cupofinsane 6y ago

I wish distributed bug-trackers like git-bug receive more love here. They don't solve CI/CD like GitHub does, but hey, it's still something!

reidrac 6y ago

A bit sad that they gave up on Mercurial, if they really think is better for their needs; although having used Subversion, Mercurial, Bazaar, git, ...; I kind of like when it is just git. Not because is better or I like it better, but switching between tools in this case was PITA because of the subtle differences of almost the same commands. > And the way that most people personally like using git is via GitHub. I don't get it. In which way? I use GH for pull requests, may be issues? There's a lot more of my git day to day than that. I don't think you really use git via GH.

cpeterso 6y ago

What will be SDL's official GitHub repo? The article had no link. Seems like an important item to include. https://github.com/libsdl https://github.com/libsdl is an unofficial mirror and github.com/sdl/ is something unrelated.

edflsafoiewq 6y ago
> We will be migrating on the 10th. Tomorrow. Presumably you'll know then.

TinkersW 6y ago

Good, I remember wanting to submit a tiny patch but then giving up because I couldn't be bothered to make sense of the system they were using(and I use mercurial for my personal stuff).