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

Why GitHub Can't Host the Linux Kernel Community

blog.ffwll.ch

Post reply on HN
Print view View original

211–220 of 251 posts

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

#211

Post by justinjlynn »

seanp2k2 wrote: post #209
justinjlynn wrote: post #208

Earlier quoted context omitted.

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…

Indeed. Launchpad has an incredibly bespoke feeling -- it is very much intended for Canonical's particular use case and it's clear they don't intend to spend much time making the on-ramp terribly shallow for new users/admins. That said it certainly represents a massive amount of work and it has a number of compelling features.

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

#212

Post by pm215 »

rattray wrote: post #184
clarkevans wrote: post #85

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…

I think a big chunk of "why is the kernel's git workflow the way it is" is just "it's a formalized and tooled-up equivalent of the preexisting organizational structure where everybody was emailing patches, submaintainers had kernel source trees on their local machines that they were in charge of, etc". That said, one area I suspect the 'branches in a common repo' model will have trouble is access control. With the kernel's approach I can set up a tree for the Foo subsystem without needing to have any kind of privileged access to the 'official' kernel tree: whoever I send Foo pull requests to chooses to accept them, or not, case by case. I don't get to make unreviewed changes to other bits of code. (Disclaimer: I haven't looked at github's access control model, maybe it lets you lock down master?)

You can do kernel development with a "we give commit access out fairly freely" model, of course (I think some of the BSDs are like that, again as historical accident of the cvs style tooling they used to use); but Linux hasn't historically been socially organised that way, and changing tools is easier than changing organisational structure.

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

#213

Post by qu4z-2 »

ythn wrote: post #62
snakeanus wrote: post #55

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?

It's really nice having some things standardized. I can tell from a glace how popular a project is by the number of stars. I can tell how many bugs it has by perusing the issues. I know I'm not going to get any spyware if I download something. The fragmented approach means you have to learn a bunch of different services, each with their own nuances. Then you have crap like sourceforce injecting adware into the downlo…

> I know I'm not going to get any spyware if I download something.

You mean aside from that intended by the project maintainers?

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

#214

Post by vertex-four »

johannes1234321 wrote: post #103
clarkevans wrote: post #85

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

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…

Of course, Launchpad is also terribly confusing.

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

#215

Post by coldtea »

rattray wrote: post #184
clarkevans wrote: post #85

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…

>to which I again say "not when GVFS is ready")

So they should base their decisions on the eventuality of some project being ready?

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

#216

Post by coldtea »

dlp211 wrote: post #156
gnaritas wrote: post #144

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.

>This is gate keeping at its finest.

That's as intended.

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

#217

Post by coldtea »

sverhagen wrote: post #178
nickbauman wrote: post #161

Earlier quoted context omitted.

So clunky! :D — With 2000 commits per day, I don't think they need more people. I can't even imagine trying to fit that amount of source code change into any management style, let alone one that has little or no gatekeeping. Making the barrier to entry higher is probably only one step to prevent the project from self-immolation.

So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities? Do you suggest a correlation, I find it hard to believe there is one?

>So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities?

No, the former is enough. It shows that whatever their programming abilities they are prone to bike-shedding, so they are better avoided.

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

#218

Post by shp0ngle »

KekDemaga wrote: post #97
shp0ngle wrote: post #84

Earlier quoted context omitted.

It's not like open source projects are immortal. Some die due to poor management, lost developer interest, lost funding, or some fork becoming more popular. Or all of the above.

For me Linux is the core of the open source movement. If it dies the rest of it might die with it.

Well, it might happen that Google will fork Linux into their own thing, and it will be harder better faster stronger, and for some reason hard to merge back into Linux. And the ecosystem will move.

It's hard to imagine now, but it can happen.

Or it will be GNU Hurd.

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

#219

Post by jo909 »

coldtea wrote: post #217
sverhagen wrote: post #178

Earlier quoted context omitted.

So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities? Do you suggest a correlation, I find it hard to believe there is one?

> So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities? No, the former is enough. It shows that whatever their programming abilities they are prone to bike-shedding, so they are better avoided.

Well they are doing both of course, your patch will still get rejected if it's bad, even if you were able to figure out where and how to send it. But it reduces the amount of patches that need to be read and rejected.

Also we are arguing backwards here. They don't make it intentionally hard to keep out new contributors, it's just not important in any way to make it simpler. The goal is to make it work best for the thousands of existing contributors, especially the gatekeeping subsystem maintainers.

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

#220

Post by coldtea »

jo909 wrote: post #219
coldtea wrote: post #217

Earlier quoted context omitted.

> So they're gating developers by their appreciation of the chosen toolset? Wouldn't you rather see them challenged on their programming abilities? No, the former is enough. It shows that whatever their programming abilities they are prone to bike-shedding, so they are better avoided.

Well they are doing both of course, your patch will still get rejected if it's bad, even if you were able to figure out where and how to send it. But it reduces the amount of patches that need to be read and rejected. Also we are arguing backwards here. They don't make it intentionally hard to keep out new contributors, it's just not important in any way to make it simpler. The goal is to make it work best for the th…

>Also we are arguing backwards here. They don't make it intentionally hard to keep out new contributors, it's just not important in any way to make it simpler.

Generally yes, but IIRC Linus has explicitly said that he likes the process being intentionally hard to keep out new contributors.

Post reply on HN