[HN Gopher] SDL Moves to GitHub
___________________________________________________________________
SDL Moves to GitHub
Author : Bl4ckb0ne
Score : 109 points
Date : 2021-02-09 21:39 UTC (1 hours ago)
(HTM) web link (discourse.libsdl.org)
(TXT) w3m dump (discourse.libsdl.org)
| krapp wrote:
| Awesome. I've been pulling from an unofficial Gitbub mirror for
| SDL2 for a while now.
| swatson741 wrote:
| 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 wrote:
| 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 wrote:
| Since the Microsoft takeover, the platform is compromised. It
| seems people have very short memories.
| stu2b50 wrote:
| I'm curious, what is the threat model? For SDL, for
| example, what's the nightmare scenario with Github and
| Microsoft?
| livvelupp wrote:
| Amazing boomer rant
| qbasic_forever wrote:
| 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 wrote:
| Thinking takes effort.
| agentdrtran wrote:
| "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.
| colechristensen wrote:
| >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.
| PurpleFoxy wrote:
| Wonder why they did not pick GitLab since it is significantly
| better for FOSS ideals and has the same niceness of GitHub
| fileeditview wrote:
| 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.
| 1_player wrote:
| > 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.
| john_cogs wrote:
| 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/
| the_jeremy wrote:
| 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.
| zokier wrote:
| 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.
| WrtCdEvrydy wrote:
| I'd actually argue for a Gitlab instance on some sort of docker
| container. Microsoft keeps dropping the ball on Github for my
| taste.
| talhah wrote:
| 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?
| ww520 wrote:
| I've briefly used Mercurial and found it to be slower than Git
| in large repos. Mercurial has the concept of changeset (similar
| to Perforce) where the changeset is actually stored, while
| Git's "changeset" is computed as needed from two commits.
| Branch in Git is clear and straight forward, and is easily
| malleable, while Mercurial's branch is part of the version
| storage and cannot be changed or removed.
| jmercouris wrote:
| A much better UI. Git won because of the influence of the Linux
| kernel developers, that's all.
| johannes1234321 wrote:
| Not only that, but GitHub came early and made the hosting
| easy. There was no similar offering for hg that early on.
| tomjakubowski wrote:
| Circa 2011, Bitbucket was Hg-only and pretty comparable to
| GitHub in repository hosting features at the time.
|
| Took a bit to dig up with Google their 2011 announcement
| that they're now also supporting Git.
| https://bitbucket.org/blog/bitbucket-now-rocks-git
| qbasic_forever wrote:
| Github wasn't created until 2008, and in those early days
| there were big limits on hosting (very limited number of
| repos per user, even public ones). The everything free,
| everything easy all you can eat buffet that you see on
| Github today is a much more recent change. Back in '05
| almost everything OSS was on source forge and Google Code,
| both of which offered super easy hosting, discussions, etc.
| xyst wrote:
| The influence of a single linux kernel developer is the
| reason it's adoption is so high - Linus Torvalds.
| tux1968 wrote:
| 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.
| danbolt wrote:
| I feel like GitHub made a lot of hacking around and software
| development a lot more seamless too. Before GitHub, the
| average state of software development seemed a bit more
| clunky to me.
| qbasic_forever wrote:
| Github made _Github style_ development seamless--i.e.
| centralized source control, slick web UI instead of CLI
| focus, pull requests instead of e-mailed patches. It's one
| of many different ways to build software though and it's a
| fallacy to say the entire field of software development
| didn't move forward until it existed. For someone who has
| only known Github style development it's true, but for many
| projects (including some of the largest in the world like
| the Linux kernel, all of Google's internal code, etc.)
| Github style development isn't necessary.
| folkrav wrote:
| > A much better UI
|
| Curious as how it's "better". I have in all honestly only
| ever used git.
| filmgirlcw wrote:
| Tbh, I don't even know if it is true today. Circa
| 2008-2010, I think Mercurial was certainly better -- it was
| certainly better designed and easier for a newcomer to use.
|
| I'm probably going to be wrong/off on some stuff, but this
| is what I remember from the old days:
|
| * Mercurial had a better CLI by default -- it was closer to
| SVN, which made it easier to use, and it was designed so
| that you had one command that did one thing, whereas git
| was more flexible but you needed to remember a lot of
| option flags. * Mercurial had better early GUI client
| support (this changed, but early on, I know this was a draw
| for me as a Mac user) * I'm pretty sure Mercurial had
| better Windows support (I didn't use Windows so I can't
| speak to this, but I seem to remember this) * Better
| documentation
|
| But git has evolved a lot over the last decade plus. Not
| only did GitHub really change the game by creating a more
| social layer on how to contribute/use git (and yes, I
| realize GitHub != git, but it definitely helped introduce a
| lot more people to git), it had features that really honed
| in on some of the pain points git had compared to
| Mercurial.
|
| Although BitBucket was sort of positioned as a GitHub for
| Mercurial solution, it never achieved the organic/viral
| adoption of GitHub. And when Atlassian dropped hg support
| last year, it was pretty much confirmation that git "won."
|
| Other than Facebook, I can't think of any major companies
| that use Mercurial or major projects that use hg.
|
| I used to be sad about this, because I felt hg was better
| designed, but I came to terms with the reality a long time
| ago. It is what it is, and version control is often
| something that network effects define. Use whatever you
| want for your projects, but git won.
| ufo wrote:
| One thing I prefer about Mercurial is that it doesn't have
| a separate staging area. To create a new commit in git you
| need to run `git add` followed by `git commit`. In
| Mercurial it's just `hg commit`. Furthermore, if you want
| to look at the diff in git sometimes it's `git diff` and
| sometimes you need to run `git diff --cached`.
|
| Now, I'm sure there are antsy git users in this forum ready
| to reply about how great the staging area is because of
| `git add -p`. My answer to that is that you can also do
| those things in Hg if you want. For example, the `shelve`
| command in Hg is analogous to `git stash -p`. If you want
| to commit only part of the changes you can shelve away the
| things that you don't want to commit for now. One thing I
| like about this workflow compared to the staging area is
| that if you run your test suite, the code that is being
| tested in your working directory is the same one that will
| be commited.
| acdha wrote:
| > To create a new commit in git you need to run `git add`
| followed by `git commit`.
|
| Or `git commit -a` -- and if you're making commits that
| frequently it'll be in your shell history anyway.
| acdha wrote:
| Kind of -- I started using Mercurial before using Git and
| found a number of things which were easier or only possible
| using Git. Using some of the plugins for things like rebase
| were the only time I've ever lost data in a version control
| system.
|
| By the time they had addressed some of those gaps, almost all
| of the projects I used had moved to GitHub, which seemed to
| be far more of a driver than Linux.
| formerly_proven wrote:
| Git is and always was very fast. Hg used to be much much
| slower, and still is.
| lifthrasiir wrote:
| Both were still very faster than the mainstream solution at
| the time that is Subversion. I don't think Git could
| achieve the domination comparable to today without Github
| for that reason.
| dialamac wrote:
| I mean git is wildly popular because of GitHub, and probably
| that was something to do with it in the Rails community... a
| community that if anything is culturally the opposite of the
| kernel dev community (or at least very different). I don't
| think any kernel dev influence had to do with it, even though
| it's often stated as a fact.
| pdw wrote:
| No, even at the time of GitHub's founding Git was already
| the clear winner. Think about it, why did GitHub feel safe
| launching with only Git support, while its competitors
| (Google Code, Bitbucket, SourceForge) had support for
| multiple VCSs?
| simonw wrote:
| Disagree. Git wasn't the clear winner when GitHub
| launched - and in fact the entire category of distributed
| version control was still proving itself.
|
| I remember the GitHub team investing huge amounts of
| effort into convincing people to use git and teaching
| them how to do it - one of the four co-founders (Scott)
| was dedicated to that effort full-time.
| eikenberry wrote:
| If I remember correctly Mercurial also made some dubious
| decisions early on (which they later reversed) that hurt
| adoption, like no in-repo branches and no ability to change
| history.
| fmakunbound wrote:
| Supposedly it has a nicer user interface. It's been ages since
| I've used it though and I am not sure if that's still true.
| throwawayboise wrote:
| My VC history includes RCS, CVS, Visual Source Safe, then
| several years with Subversion. Moving from svn, the hg CLI was
| more intuitive. I still don't understand git at all, beyond the
| basic "clone, pull, add, commit, push" commands.
| RcouF1uZ4gsC wrote:
| One advantage of mercurial is that it is less tied to a
| specific file format like git is. It is much easier to make a
| mercurial backend for a system which actually stores the code
| in a different way (for example a distributed data store).
| Mindless2112 wrote:
| ...or stores it in .git[1].
|
| [1] https://www.mercurial-scm.org/wiki/GitExtension
| klodolph wrote:
| Isn't this also possible with Git, at least for remotes?
| There are a number of different Git implementations besides
| the main one.
| qbasic_forever wrote:
| Git didn't exist until Linus Torvalds sat down and hacked it
| out in a few weeks during 2005. I remember using SDL back in
| '99 to play with game development on Windows 98. So the short
| answer is, git wasn't even an idea in its creators head when
| SDL was around and thriving.
|
| IMHO when you see a design decision that seems odd to you, it's
| a good opportunity to investigate the entire context around
| that design, rather than pepper the devs/issues/comment
| threads/etc. with pointed questions, "Why did you do X when Y
| is now clearly better??".
| TonyTrapp wrote:
| That doesn't really answer the question though as both
| Mercurial and Git were released in 2005.
| jrochkind1 wrote:
| However, Mercurial also didn't exist before 2005.
|
| https://en.wikipedia.org/wiki/Mercurial#History
|
| i would guess you are right, though, that at the point SDL
| chose Mercurial (I don't know when), git hadn't achieved the
| market domination over mercurial it now has.
| mrpippy wrote:
| SDL didn't use Mercurial until 2010. They used Subversion
| from 2006-2010 [1], and CVS before that [2]. A project on its
| 4th version control system!
|
| [1]: http://forums.libsdl.org/viewtopic.php?t=6047 [2]:
| https://discourse.libsdl.org/t/sdl-in-subversion/13289
| qbasic_forever wrote:
| Again, I will restate what I said. Follow the context of
| the decisions (as you have already done) instead of
| demanding people explain it.
| nijaru wrote:
| Mercurial is probably the most popular alternative, although if
| git wasn't so ubiquitous, I would spend some time trying out
| fossil.
|
| edit: I can't remember where, it was when I was researching
| fossil, but there are some good reads on why Linus created git
| and the history of VCSs.
| d1zzy wrote:
| Seems to be popular at Facebook.[1]
|
| Where I work Mercurial has been an option for some time now (no
| Git unfortunately) and coming from Git I must say I really love
| how it does some of its things:
|
| - hg split: split a commit into as many different commits as
| you like using an interactive patch editor (you can
| fold/collapse hunks, can edit them textually, can select which
| lines of the hunk should be applied). It will automatically
| rebase all the commits on top of the commit being split, ofc
|
| - hg histedit: a sort of "git rebase -i" where you get a list
| of commits that you can manipulate by reordering them, merging,
| dropping
|
| - hg amend -i/commit -i: interactive commit or amending of a
| commit, it's using that awesome interactive patch editor I
| mentioned earlier to select what exactly gets committed/amended
|
| - same for "hg shelve -i" (a sort of "git stash")
|
| The closest thing in Git to that interactive patch editor was
| doing "git add -p" which is not as good.
|
| [1] https://engineering.fb.com/2014/01/07/core-data/scaling-
| merc...
| zests wrote:
| I do this using magit. I've never split a commit directly
| (I'm sure its possible) but manipulate commits at the
| file/hunk/line granularity which I did not think was possible
| with git.
|
| Same with histedit, that's in magit as well.
| livvelupp wrote:
| What's the other options besides hg if it ain't git?
| pdw wrote:
| darcs is still actively developed and it has a niche in the
| Haskell community.
|
| Ubuntu might still use Bazaar.
| jen20 wrote:
| BitKeeper is one, Fossil is another. Then there are non-
| DVCS systems like Subversion, Perforce, VSTS etc.
| jimbob45 wrote:
| SVN still works well for our company.
| Shorel wrote:
| SQLite uses Fossil.
| klodolph wrote:
| Mercurial is used at Facebook, but it is heavily customized
| and goes through Phabricator. Just like Google uses Piper,
| which is "like Perforce" and goes through Critique.
| throwaway3699 wrote:
| Not quite. Google also has an internal mercurial tool
| (layered over perforce/piper), and I think it's the more
| popular tool at this point.
| truncate wrote:
| I heavily use Magit on Emacs to edit my patches
| interactively. It is my favorite way to interact with Git.
|
| I think Visual Studio Code has something of its own. Would be
| great to have that part of the Git command line, but I guess
| shouldn't be hard to make one, considering its already out
| there on so many IDEs.
| rileymat2 wrote:
| I had tried both in thier infancy, and honestly prefered
| mercurial by quite a bit. But git had the momentum.
|
| One thing I liked, that most do not is they had both git style
| branches in the form of tags, but mercurial had "real"
| branches.
| h_anna_h wrote:
| 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 wrote:
| Well, GitLab has recently hiked up their prices. As a GitHub
| Pro user, my price has only ever gone down.
| jrochkind1 wrote:
| 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.
| einpoklum wrote:
| 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 wrote:
| The GitHub repository for LLVM is the official one:
| https://llvm.org/docs/Proposals/GitHubMove.html
| jefft255 wrote:
| 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.
| olmideso wrote:
| 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
___________________________________________________________________
(page generated 2021-02-09 23:00 UTC)