Live data from Hacker News

Why GitHub Can't Host the Linux Kernel Community

blog.ffwll.ch

201–210 of 251 posts

Re: Why GitHub Can't Host the Linux Kernel Community

#201

Earlier quoted context omitted.

I believe Cononical's launchpad was built to achieve such workflows. It came out of the need to create an integration platform taking upstream versions of software and applying Ubuntu-specific fixes. In the old days, before git and GitHub won, I liked their bug tracker way over GutHubs as it really supported these flows, where bugs are fixed not in the main repo but by some contributor first. But we'll, wrong bet on…

I wonder if there has been any work on porting launchpad to work with git.

Yes, there has. Launchpad works fine with git today.

Re: Why GitHub Can't Host the Linux Kernel Community

#202
post #156

Earlier quoted context omitted.

Kernel development shouldn't have a low bar, it should have a very very high one. Anyone that finds email a high bar for communication doesn't belong in Kernel development.

This is gate keeping at its finest. Email is a clunky tool to do development with compared with what is available. A persons willingness to use email (and all the quirks for submitting a patch) for patching the kernel has nothing to do with the quality of code that they write.

> Email is a clunky tool to do development with compared with what is available.

The linked article explains at length why it works well for kernel maintainers. And since it does, why should kernel maintainers change it just to make things easier on newbies? It's much more reasonable to expect new participants to adapt to a workflow that works, than vice versa.

This is not "gatekeeping," it's just the reality that not everyone works the same way.

Re: Why GitHub Can't Host the Linux Kernel Community

#203

As I understand, Daniel Vetter is proposing a "monotree" as a source code control pattern where a monorepo (and its branches) is not the primary place where development is done, but is rather where works are integrated from subordinate repositories. In particular, he's asking for GitHub to support coordination (issues and pull requests) spanning upstream repositories that are indicated by a particular change request.…

Especially in a world where GVFS is a thing (not quite yet), I fail to see the advantage of a monotree over a monorepo with lots of branches and scripting around a MAINTAINERS file. What's wrong with branches and folders? Why are upstream repositories needed? (My hunch is the answer is just "it's slow with that much code" to which I again say "not when GVFS is ready"). Not to say Linux should change their ways, just…

Sometimes a monotree is the only way. If your business model revolves around an open source core with some proprietary add-ons for paying customers, it's often not possible to merge those codebases into a single repo.

Re: Why GitHub Can't Host the Linux Kernel Community

#204

I can't really see the obsession that everyone has with centralised and closed services like github. We need to start moving away from them, not move more projects to them. Mailing lists and NNTP make decentralisation quite easy while being open standards and without having the need to have any account in any centralised service, why drop all these features away?

Were you around before github? It was extremely painful to contribute to any opensource project, back then. Some projects were on sourceforge, others were on self hosted svn near project homepage, others were grouped in community efforts like savannah.gnu.org ... It felt back then as you had to know maintainers personally to contribute to a project. Most of the time, you had to mail people to ask how to contribute (thus, patch mails are kind of obvious).

Centralization is indeed a problem, but I think we should all thank github for having standardized how to find opensource projects and contribute to them. This really gave opensource (especially opensource libraries) the kickstart they needed. And now, this centralization is lowering with concurrent products like gitlab, so everything is fine.

Re: Why GitHub Can't Host the Linux Kernel Community

#205
post #175

Earlier quoted context omitted.

"They don't need or even want your help" There was in fact a talk given by Greg Kroah-Hartman, one Linux's lead maintainers, about development for the Linux kernel which he titled "I Don't Want Your Code" . https://www.youtube.com/watch?v=fMeH7wqOwXA

Haha, thanks for the video. I watched it, and I was surprised to see that it's about a specific company. He's at Linaro, specfically taking their developers to task for sending bad patches. And they indeed sound horrible, but he's good natured about it. I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build . And Greg…

> I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build. And Greg was saying the same thing.

Indeed, I've seen the same thing. I have considered automatically rejecting any patch made with the GitHub online editor (obvious because the committer name is always GitHub). They are pretty much invariably of shit quality.

Re: Why GitHub Can't Host the Linux Kernel Community

#206

> If you don't do something because of a personal dislike, and expect others to cater to your culture and personal preferences, then the problem is you. Are you serious? If Linus is a complete asshole and tells you to fuck off, and you don't like that, the problem is with you ? How can you possibly defend that statement?

We detached this subthread from https://news.ycombinator.com/item?id=14974666 and marked it off-topic.

Re: Why GitHub Can't Host the Linux Kernel Community

#207
post #156

Earlier quoted context omitted.

Kernel development shouldn't have a low bar, it should have a very very high one. Anyone that finds email a high bar for communication doesn't belong in Kernel development.

This is gate keeping at its finest. Email is a clunky tool to do development with compared with what is available. A persons willingness to use email (and all the quirks for submitting a patch) for patching the kernel has nothing to do with the quality of code that they write.

You can send a patch to a mailing list with `git send-email`. You can format it first with `git format-patch` and then send the patch with `git send-email`. Configuring it to use your email server takes a few minutes, and you only have to do it once.

I get the feeling most people who complain about how "clunky" email is have never actually tried to submit a patch to LKML. If I could figure it out when I was a high-school student, a professional developer should be able to figure it out as well.

Re: Why GitHub Can't Host the Linux Kernel Community

#208
post #201

Earlier quoted context omitted.

I wonder if there has been any work on porting launchpad to work with git.

Yes, there has. Launchpad works fine with git today.

Oh, awesome. I was going to look at that later this afternoon. Cheers!

Re: Why GitHub Can't Host the Linux Kernel Community

#209
post #201

Earlier quoted context omitted.

Yes, there has. Launchpad works fine with git today.

Oh, awesome. I was going to look at that later this afternoon. Cheers!

Launchpad is also incredibly opaque to people who don't use it often. It took me a very long time to find the actual release binaries and how to get the sources + build info for them. It was for some nginx modules in a PPA which depend on a newer nginx than what is stock in Ubuntu Trusty. Took literally half a day to get binary-compatible modules built from source (building dynamic modules and they must match all the configure flags of the nginx you're trying to inject them into).

Re: Why GitHub Can't Host the Linux Kernel Community

#210

I can't really see the obsession that everyone has with centralised and closed services like github. We need to start moving away from them, not move more projects to them. Mailing lists and NNTP make decentralisation quite easy while being open standards and without having the need to have any account in any centralised service, why drop all these features away?

> We need to start moving away from them, not move more projects to them. It seems this topic comes up quite frequently on HN. Unfortunately, while it sounds great in theory, no one ever has a practical way of doing this. The main problem here is the user experience. When using GitHub I can find an open source project, copy the URL, pull it down, make changes, push and click a button for a pull request. A little bit…

"Now, if you can figure out a way to decentralize a service while maintaining the same level or less friction from the centralized version then you have a real winner and things can start happening."

Ethereum

Post reply on HN