Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SDL Moves to GitHub

discourse.libsdl.org

Post reply on HN
Print view View original

261–270 of 270 posts

Re: SDL Moves to GitHub

#261

Post by agentdrtran »

PurpleFoxy wrote: post #16
rockooooo wrote: post #2

"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…

Wonder why they did not pick GitLab since it is significantly better for FOSS ideals and has the same niceness of GitHub

> has the same niceness of GitHub

I gitlab significantly harder to use and more error-prone than Github

Re: SDL Moves to GitHub

#262

Post by pantalaimon »

iforgotpassword wrote: post #218
pjmlp wrote: post #189

Earlier quoted context omitted.

Being a bit older this is no different than seeing the 70's hippies generation that helped fighting the dictatorship, working in capitalist right wing companies. Eventually other things in life are more relevant and all that idealism fades away. Even Linux will eventually be replaced by something else, when all the kernel engineers that helped its adoption are gone. It won't be tomorrow, but it will come.

> Even Linux will eventually be replaced by something else, when all the kernel engineers that helped its adoption are gone. I disagree. Linux has reached critical mass, the biggest tech giants depend on it heavily and are the main contributors. If some new fancy subsystem, interface or syscall would benefit Google's workload, they will implement it and it gets merged since even of Google will be the only one using i…

> You come along with a not completely polished and thoroughly tested Lego mind storms usb driver for Linux today, you'd get laughed of the mailing list

This is simply not true. Even the new N64 port got merged even though it's not very practical.

> because security

As long as your module is not enabled by default, there is little security concern with it.

> who will maintain that?

Well you of course. Having someone who maintains it is the biggest factor in deciding whether code will stay or whether it will go.

Re: SDL Moves to GitHub

#263

Post by pantalaimon »

pjmlp wrote: post #243
dingaling wrote: post #240

Earlier quoted context omitted.

> The only guarantee of the future is that it is unpredictable. Yet here you are making predictions... I doubt Linux will fade away until there is some major paradigm change away from Van Neumann architecture. It has survived and become dominant over 30 years by constantly adapting and innovating.

The plethora of IoT FOSS OSes with MIT/BSD licenses already show where the train is going.

Those do target an entirely different class of devices / applications.

Re: SDL Moves to GitHub

#264

Post by dialamac »

pdw wrote: post #35
dialamac wrote: post #15

Earlier quoted context omitted.

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.

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?

Um.. no it wasn’t. Git was a complete trash fire on Windows when GitHub was founded for one.

I started using git when I was working on embedded Linux professionally in 2005, witnessing the whole bitkeeper saga. I am keenly aware of the history of DVCS 15 years ago.

Meanwhile outside the bubble of academia and startup web devs in 2008, Windows was still by far the most widely used dev platform. I typically deployed Mercurial when I wanted to convince a wider technical audience others of the beauty of DVCS.

GitHub felt safe the same way Instagram (among many) felt safe deploying for iOS only, even when then Android had a larger user base. There are other factors at play, and it was not that git had some kind of major advantage in 2008. If anything mercurial had a slight edge. But if anything in 2008, the wider DVCS market was still in its infancy.

Re: SDL Moves to GitHub

#265

Post by dialamac »

Person5478 wrote: post #244
mikey_p wrote: post #90

Earlier quoted context omitted.

Not really, lots of folks were using mercurial with BitBucket which didn't support Git at the time. Bazaar and Launchpad were also pretty common. I remember at one point around 2009-2010 I was semi-regularly using CVS, Subversion, Mercurial, Bazaar and Git.

lots of people were using lots of things at that time, most were using git.

You have no evidence to back this claim up, because it’s not true.

Re: SDL Moves to GitHub

#266

Post by Aeolos »

DominikD wrote: post #226
swatson741 wrote: post #18

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 stil…

Found two bugs, reported them, sent patches. It was as easy as it gets. The idea that forking a repo, pushing changes to your own copy, then posting a PR is simpler than posting a diff on a bug tracker is bizarre.

When I moved my open source project to GitHub, contributions skyrocketed by roughly 10x. I attribute that to three things: - contributors need to learn a single workflow to submit patches to any open-source project:fork and submit PR - contributors already have a github account, so a significant barrier is removed for flyby contributions (no need to register a new user account to a mailing list / bugtracker / or both for each trivial or non-trivial fix.) - network effects and improved visibility

Each of those may appear small by itself, but they combine into a significantly better experience for contributors.

Re: SDL Moves to GitHub

#267

Post by mlindner »

john_cogs wrote: post #162
mlindner wrote: post #156

Earlier quoted context omitted.

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 ol…

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#int... 2 - https://about…

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.

Re: SDL Moves to GitHub

#268

Post by mlindner »

wahern wrote: post #164
mlindner wrote: post #155

Earlier quoted context omitted.

Which is one of the reason's Stallman's ideas are fundamentally flawed as if there's a better product available even if it's only free as in beer, people will use it over the worse one, from the end user's perspective.

In the worldview of Stallman, your argument is analogous to saying that advocating for democracy is flawed because if an authoritarian regime or slave society provides a better product, people will choose it over worse democratic ones. To Stallman, your counter-argument is a non-sequitur. His goal is maximizing user freedom. UX may be one dimension of user freedom, but at best it's secondary to certain prerequisite f…

> In the worldview of Stallman, your argument is analogous to saying that advocating for democracy is flawed because if an authoritarian regime or slave society provides a better product, people will choose it over worse democratic ones.

Except that's exactly what human behavior does.

Re: SDL Moves to GitHub

#269

Post by pwdisswordfish6 »

pabs3 wrote: post #168
lazypenguin wrote: post #145

Earlier quoted context omitted.

I don't agree. I spent a significant amount of time playing around with servers and never developed "mastery". I think that server administration has gotten more complex and the tools haven't changed much to help. A simple example is setting up an HTTPS/TLS/SSL endpoint. In the past, you just ran the HTTP server and you were off. Now there's a whole load of extra ceremony to setup a CA and sign your own cert or downl…

If anything TLS has gotten easier since Lets Encrypt came along. You just install one of the clients for it, configure a domain and periodic renewal and you're done.

It's not easier than HTTP sans TLS, which is the point that was being made.

Re: SDL Moves to GitHub

#270

Post by pwdisswordfish6 »

Lammy wrote: post #103
zamadatix wrote: post #94

Earlier quoted context omitted.

So the threat is some number of years down the line they may have to go back to paying to host and maintain the infrastructure themselves again? I'd take that deal.

Tough luck for anyone who had linked to the project/issues on github dot com instead of sdl dot org.

It genuinely surprises the shit out of me that people haven't created a "middleware" layer that treats GitHub as its backend / source of truth, but everything gets routed through a custom domain. E.g., spin up this glorified reverse proxy on Heroku, and now example.com/bugs is really just example.github.io/bugs, which is a page with all its form actions pointing to the Heroku service acting as a go-between for managing github.com/example/whatever/issues with full backups, etc.
Post reply on HN