Hacker News new | comments | show | ask | jobs | submit login
Why GitHub Can't Host the Linux Kernel Community (ffwll.ch)
395 points by okket 6 months ago | hide | past | web | favorite | 236 comments



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 was hoping to see discussion of the merits of this proposal here on HN... not a regurgitation of Torvalds' positions and personal demeanor. What other projects use a monotree? does it work well? How do those projects coordinate changes across subordinate repositories?


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


Of course, Launchpad is also terribly confusing.


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!


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


I can see how that that experience would have been poor for you, but I think it's a rather unfair comparison when comparing to GitHub. It's apples to oranges. Launchpad does more than git hosting, merge proposals ("pull requests") and bug tracking; it also manages the build infrastructure of a distribution and the publication of distribution sources and built binary packages. You did get tangled up doing the latter, but the former case is the context of this discussion. GitHub, GitLab and Sourceforge all cannot even do the much more complex tasks for which you had a poor UX on Launchpad.


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.


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 that I wouldn't adopt them as part of a company.


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.


> Disclaimer: I haven't looked at github's access control model, maybe it lets you lock down master?

It does. It's pretty easy to have specific branches with specific permissions.


I was thinking the same thing.

But then I realized that the advantage of multiple repos is that it is decentralized: anyone can start their own fork, and collaboration works similar to the official forks, and you don’t need any centralized administration.

Having everyone share a single giant monorepo sounds like you’ll need a lot of people to support the infrastructure. Microsoft can do that. Can the Linux community?

With a huge monorepo, you can easily archive everyones contributions. That’s probably important for Microsoft. It’s not important for Linus — he only cares about the stuff he merges.

Finally, multiple repos allow people to work on stuff privately, and only contribute back to the public when they are ready.


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.


GVFS has been working for years, but it's not even used related to the linux kernel at all. It's actually a GNOME-thing.



Not sure why people are downvoting you. Just because Microsoft decided to give an already-in-use name to an internal project doesn't mean that the original project no longer exists. https://wiki.gnome.org/Projects/gvfs


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

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


Some 'enterprises' love doing that sort of thing. One project gets behind or fails and there are so many cascading problems.


Why can't issues just be mime messages (think email-formatted messages) in a directory for each issue? You could even have an issue file that would contain the status, person actively working, &c and then the thread of discussion as the mime files.


I'm fine with that. Github is 'too large to fail' already, adding the Linux kernel to the pile and forcing the kernel team into Github's workflow are two big negatives. It would be great for Github but bad for everybody else.


Seriously. Linux will likely outlive GH[1], and more importantly, it doesn't need GH. The current workflow works fine, and I hardly think any potential kernel hackers are choosing not to work on the kernel because it is email-driven.

[1] Nothing against them that I don't have with any other commons that depends on corporate beneficence. But companies fail all the time; I can't think of a reason GH is immune.


I wonder if the email list acts as a gateway to filter potential troublemakers and trolls. A troll denied their audience is a troll defeated.


The kernel lists get plenty of trolls regardless.


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.


If Linux dies, it will either be because something better emerged to replace it (yay!) or the civilization necessary to support it imploded (boo!)


Wow. That's bleak. Linux will not last forever, irrespective of how it might change.

Change is gonna come someday. Don't get left behind because of sentiment. This isn't a judgment on the Linux project, this is reality.


Linux will likely outlive all of us. Network effects are massively strong for operating systems, we've been stuck with the same basic 3 for decades and that's likely to stay the same.


Only if you consider servers.

Mobile operating systems such as IOS have become huge and they're many new industries that look promising (my guess is IOT based one like alexa and Google home but who knows).


There are two major mobile operating systems, iOS and Android, both based on Unix clones, one on BSD and one on Linux. Mobile has dramatically increased Linux usage; what do you think Android is?


You bring up valid points.

However, ios makes most of the mobile profit just as windows and Mac do over Linux for desktop (I have only used Linux in server industry so I don't know how they fair in those markets too much).

In that light, How about this prediction.

Linux will continue to dominate in the server market for a long time as businesses factor in the cost of os licenses and the supply of linux users is big.

Consumer markets like desktop, mobile, whatevers next will flock to the lower personal cost (through customer time investment in learning the os).


Agree, thus Linux will live a long time.


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.


(Ir)relevant xkcd.

https://xkcd.com/1508/


> The current workflow works fine, and I hardly think any potential kernel hackers are choosing not to work on the kernel because it is email-driven.

I'm not so sure. If the kernel development was on Github, I may have looked into contributing, but as it stands, its not worth the trouble to try to contribute (as I don't have anything specific to help with). And, I suspect there are more capable developers who are closer to the edge than me.

Anyway, having a slightly lower bar to get started may not get more developers involved, but instead my get them involved more quickly.


Linux is one of the few open source projects to with plenty of developers. They don't need or even want your help, especially if your attitude toward tools is rigid, and if you have nothing concrete to contribute.

Linus has said this a few times -- in general they don't actively try to onboard new contributors.


"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 was saying the same thing.

I guess I got spoiled at my last job, where people generally sent high quality patches / code reviews. Although toward the end, I noticed some sloppiness. It wasn't the main reason I left the company, but it started to feel like the downfall... I don't want to work with people who don't know how to submit code reviews / patches.


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


That's fair enough. The only times I've submitted patches that way is to update documentation files. I'd never submit code that way.


Linaro isn't a company; it's a "collaborative engineering organization". It does employ some number of engineers, funded by donations by their member companies, but they also accept "in-kind" donations where engineers are detailed to work at Linaro for some period of time. So it wasn't really directed at Linaro per se, but more at the member companies of Linaro.


So, what's the age distribution of contributors to the main tree, and how does it develop over time?

This _might_ show a long-term risk for Linux.


80% of the kernel development is done by companies who want their code in the kernel (whether that's because they develop hardware or because that's less work than maintaining their own patchset).


It is important to understand development for Linux is heavily driven by a business need. There are more than enough companies (intel, google, etc) that would gladly contribute to Linux, since it makes business sense.


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.


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


Some things need to be gatekept. (One obvious example is OS kernels.)

If you won't submit a kernel patch because you feel that email is unfashionable, then you're kind that should be kept out of the gate. Sorry.


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.


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.


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


>This is gate keeping at its finest.

That's as intended.


It's the Kernel, the gates need to be kept else fools mess things up, thank god for Linus.


Launchpad has quite a bit of git support now.


Personally I'm a fan (and user) of gitlab since GitHub's recent policies and that GitHub takes forever to implement simple things that all users would love (like free private repos)


>GitHub takes forever to implement simple things that all users would love (like free private repos)

What makes you think Github is 'taking forever' to implement that feature, instead of refusing to implement it to help their business model?


I would like a free, private Aston Martin, but the manufacturer is taking for ever to implement that too.

But I take your point. This is why I drive a Nissan.


I'd say GitHub is not Aston Martin if GitLab is Nissan...


Well, my Nissan wasn't free either and I don't use GitLab at all.


Why on earth would they want to provide free private repo's, that's something they charge for... ON PURPOSE. They aren't taking "forever", they're simply not going to do that.


So that's why it's a good idea to use bitbucket as well. Then you get the free private repos there.


Fuck yeah Bitbucket.


I was waiting for someone to mention that. Free Aston Martins!!!!


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 convoluted but overall it's a very simple workflow. Now try decentralizing away from GitHub. If you have to add any steps then you increase friction likely lowering the UX and making adoption harder.

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. Until that happens the idea of decentralizing things is just going to remain a pipedream.

In my opinion, of course. I love the idea of decentralizing things like GitHub I just can't imagine a good UX way of doing it.


Sure, the UX might get slightly worse (early on at least) for some users but we are talking about programming related services. I do not think that having to use a well defined and popular standard protocol with the client of their choice in order to create a pull request or an issue would make contributing to a project difficult for a computer scientist.

Instead, I would argue that not having the ability to just send a mail/post to a mailing list/newsgroup by using my favourite SMTP/NNTP client without creating any form of account in a property service and without clicking buttons in a slow js-ridden web interface in order to create an issue or post a pull request is a bad UX.

> copy the URL, pull it down, make changes, push and click a button for a pull request

All of these (except clicking a button for a pull request) are possible just with git, they are not really github nor centralised-only features.

> Until that happens the idea of decentralizing things is just going to remain a pipedream.

I find sending an email and using NNTP with the client of my choice a lot easier than using a forum and a lot easier than using the github issue/pull request interface. Thus I would argue that this happened many years ago.


There's git-appraise[0] which decentralizes issues and PRs by putting them as objects inside of git. It also features a webui[1]

[0] https://github.com/google/git-appraise

[1] https://git-appraise-web.appspot.com/static/reviews.html#?re...


This is actually the one good way of handling it IMO.

Decentralizing git without losing the UX benefits of using a site like github is done by handling it like torrents and packaging everything into the repo/technology itself. The Linux kernel is already part of the way there, it's just the "local client" aspect that's missing, along with a focus on actually making it intuitive and fully integrated into git itself.

The repo itself should contain all of the bookkeeping, and git should host a local UI (web and CLI) that allows you to interact with it as you would with github, rather than the send-mail rituals, the relative difficulty of following development on mailing lists, and the "here's how to set up one of 20 different email clients to send mail as plain-text". Imagine get_maintainer.pl and send-mail being replaced with a built-in pull-request-like interface that is disseminated to everyone that pulls from the remote. That's what git-appraise is trying to accomplish.

The traditional mailing-list-based development is tried and tested, but at risk of displaying my appy app iPhone youth naïveté, it's really inconvenient IMO.


I think you just described the Fossil dvcs.


> Now try decentralizing away from GitHub. If you have to add any steps then you increase friction likely lowering the UX and making adoption harder.

Attempting to justify GitHub as a "win" because git is unwilling to fix its brain-damaged user interface is called "damning with faint praise", at best.


I think that works for smaller projects, but for larger projects that require more coordination, have heavy c-i running, etc, I don't think it makes as much of a difference.

However, there are some alternatives for larger projects: 1- make sure your community has a business model (donations or other forms of funding) for core infrastructure, 2- self-host a Gitlab instance :-)

It doesn't completely take care of decentralisation, but nothing stops from having multiple instances and some c-i duct tape. Github can also make a good mirror.


"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


There are marketing buzzwords, irrelevant in the open source community.


IIRC Gitlab has some issue on implementing federated Pull Requests, which would allow users to run their own Gitlab instances but still interact with Gitlab-proper repositories as normal.


Git itself is already a monoculture, which makes me sad because it means I have very few people to speak hg to. Github makes it even worse.

But having everyone speaking the same VCS language has obvious advantages, especially when part of that language is where to host it and how to get a web view of it and how to share it. People centralise because it means someone else takes care of the boring work and you can go back to writing code. There are disadvantages to centralisation, just like there are disadvantages to giving up your privacy, but it's so damn convenient to do so that nobody has enough activation energy to do the opposite.


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.


> Mailing lists and NNTP make decentralisation quite easy

For mailing lists, most people use one of the big email providers (like gmail), their ISP's email service, or they set up their own mail server. The last option is what would make email truly decentralized, but, in order to be able to send messages to others, you would also need to set up SPF and DKIM on your MX to ensure deliverability to other servers.

For NNTP, on the other hand, you would either have to use Google groups, or one of the free Usenet providers. If you set up your own news server (which would make this option truly decentralized), then you would also need to enter into a peer arrangement with several other usenet providers in order to have your articles distributed on usenet.

I don't have first hand experience with either option, so I don't know how much effort is involved for the decentralized options I mentioned above.


> in order to be able to send messages to others, you would also need to set up SPF and DKIM on your MX to ensure deliverability to other servers

This is actually quite trivial nowadays. I did hear that setting up and configuring mail servers was difficult with Postfix and Sendmail but I personally had no problem setting up qmail and opensmtpd.

> For NNTP, on the other hand, you would either have to use Google groups, or one of the free Usenet providers. If you set up your own news server (which would make this option truly decentralized), then you would also need to enter into a peer arrangement with several other usenet providers in order to have your articles distributed on usenet.

Not everything really needs to have its articles on the usenet. There are many NNTP networks that do not have that.


> This is actually quite trivial nowadays. I did hear that setting up and configuring mail servers was difficult with Postfix and Sendmail but I personally had no problem setting up qmail and opensmtpd.

I haven't really looked into it, but at least it's not as difficult as I thought it might be. The only other problem is that a lot of ISPs block outgoing connections on port 25, so you would either need a business account with them or would need to have a server on a hosting provider that allows outgoing connections on that port.

> Not everything really needs to have its articles on the usenet. There are many NNTP networks that do not have that.

While that is true, that would require that contributors sign up for some type of account on that NNTP network to post and it wouldn't nearly be as visible to potential contributers (unless they advertise their NNTP server information and not require authentication for read only access). gmane is one example that I know of (though you cannot post articles through it as far as I'm aware).


But spf and doing still don't prevent mail from being dropped by big providers like Microsoft and Google.

Hosting your own mail is roulette.


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 download and now I have trust issues.


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

You mean aside from that intended by the project maintainers?


If this is indeed what ythn means then git supports commit signing, so I fail to see how this would be an issue.


I like free and easy to use, so even if I wanted to leave GitHub, doing so would be pretty low on my list of priorities.


There's also Linus's personal aversion to how GitHub implements many opinionated workflows.

    > I don't do github pull requests.
    >
    > github throws away all the relevant information, like having even a
    > valid email address for the person asking me to pull. The diffstat is
    > also deficient and useless.
    >  
    > Git comes with a nice pull-request generation module, but github
    > instead decided to replace it with their own totally inferior version.
    > As a result, I consider github useless for these kinds of things. It's
    > fine for hosting, but the pull requests and the online commit
    > editing, are just pure garbage.
    > 
    > I've told github people about my concerns, they didn't think they
    > mattered, so I gave up. Feel free to make a bugreport to github.
https://github.com/torvalds/linux/pull/17#issuecomment-56546...


He really talks in extremes. I see all his points but it doesn't make these things pure garbage.


> He really talks in extremes.

Easiest way to herd cats on a mailing list.

> I see all his points but it doesn't make these things pure garbage.

Well.. you see his points and his opinion. People are always in a hurry to take affront to this, but really, he's just putting the argument where it's ultimately going to end up anyways, and in the process, he gets to avoid the dozens of follow-up emails that fruitlessly attempt to convince him out of this opinion.

You're really only left with two options, disagree and move on, or fix the problems he has with it and try to get him to use it again later.


Progress relies strongly on unreasonable people like Linus. Keep in mind that Github mutilated his baby so that's a pretty good reason to be upset.


Progress relies strongly on people working together toward a common goal. If being "unreasonable" works for Linux, that's fine. But before others go trying to blindly emulate Linus, I'd suggest attempting to be reasonable first.


What people really don't seem to get is that Linus' cultural background is Finnish, and that Finns tend to be extremely outspoken and that they couldn't lie or polish their words if their life depended on it.

http://www.karelia.fi/welcomingguide/the-finnish-way-of-life

What to American sensibilities are grave insults to Linus is most likely just him speaking his mind without any filter in place, the way he was brought up.


I'm aware of this, and I can respect differences attributable to different cultural norms. But firstly, I have spoken to a Finnish developer who has said that he also considers Linus more frustrating than average; secondly, acknowledging cultural differences creates a foundation for effective communication, but does not infallibly forgive any and all transgressions (context still matters); and thirdly, most other developers will not have the excuse of being Finnish, and so my suggestion to other developers to consider alternative approaches stands (i.e. blindly emulating Linus as an attempt to lead a software project makes as much sense as blindly emulating Steve Jobs in an attempt to lead a company).


Well, personally I prefer the 'Linus' approach rather than the politically correct avoid-the-language-of-conflict and make sure you dress up every insult as a compliment approach, but I can see why if you're not used to it it can be tough. Sure, Linus is an outlier, even by Finnish standards, but I'm willing to cut the guy some slack because of his contributions, I'd be less willing to cut someone slack who does not have the required merit badges and who just goes around insulting people for effect. Linus simply has a hard time feeling passionate about stuff he really cares about and expressing himself in a way that would not be frowned on at the boardroom level. It's a problem, but it's mostly his problem and I've yet to see others emulating him so if that's a huge problem I'm not presently aware of it (and I meet lots of developers).


> politically correct avoid-the-language-of-conflict and make sure you dress up every insult as a compliment

These are two extremes, and you can find a middle ground between them.

In particular, here's a middle ground from someone objecting to Linus for willfully breaking userspace because he didn't think backwards-compatibility was important (a thing that he flames others to a crisp for), in a way that clearly expressed objection but not insult: https://lkml.org/lkml/2017/5/29/541


I'm sure if you go and sift through the incredible volume of product that Linus has made over the years you will find a few more examples of absolutely shocking behavior.

What's the last time someone did the opposite and searched for all the times when Linus was on his best behavior?

Have you considered the parallels with the Richelieu quote:

"If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him. "

Linus has written far more than six lines and I'm sure you'll be able to do a stellar job of hanging him. But you're going to have to consider whether your ability hinges on Linus' perceived personality or on the volume of his communications and product.


That's a fair point, and I am really curious to see all the times he was on his best behavior now. :)

But I think it's a little weakened by the fact that Linus doesn't think that his poorest behavior was actually poor or indefensible; if pressed he says it's exactly what he should have done.

As a good counterexample involving a developer of another kernel, I once mentioned 'bcantrill making a personal attack on the Solaris development list in the midst of a technical argument in 1996, and he found the HN thread and replied to me with an unambiguous apology, despite it being almost twenty years later and him doubtless being a different person now: https://news.ycombinator.com/item?id=9040602

Even the smallest sign that Linus genuinely thinks the behavior was suboptimal (not a "I want you people to stop complaining," which is basically what the Code of Conflict was) would go a long way towards changing everyone's perception of his behavior. But he's standing by the six lines.


Agreed, Linus doesn't see it as a problem. But that's his right no? I think he only cares about one thing: to get the job done. I don't think he cares one bit about how people perceive him and I suspect that his words in written form come across a lot harsher than they would have been if they were spoken in person and in a room with just a handful of people rather than online and visible to all the world and archived for eternity.


You can prefer it all you want, but your opinion is unreasonable, and there's simply no justification for it.

...see? You can be direct, even uncompromising and arrogant, without being abusive.


Cultural differences aren't enough to explain away his open hostility to so many things and people.

To quote from the original comment in this thread:

>You're a moron.

I don't believe the Finnish mentality justifies being so aggressive - and if it does, I'd better stay a long way away from Finland, which is clearly an awful place to live.


> To quote from the original comment in this thread:

> >You're a moron.

> I don't believe the Finnish mentality justifies being so aggressive

A previous Hackernews thread referred to a reddit thread that found the now deleted comment that Linus responded to [1] [2].

[1] https://news.ycombinator.com/item?id=3962978

[2] http://www.reddit.com/r/programming/comments/tionj/linus_tor...


Torvaldes is not proud of his behavior, https://www.ted.com/talks/linus_torvalds_the_mind_behind_lin...


Which to me makes it even less of an issue.


For me, the video suggests Torvalde's communication style is less a matter of culture than individuality. That he is not proud of it seems missing from the caricaturizations of it used rhetorically.


> The Finnish language lacks a specific word for "please"

Now I see where the Klingon language drew some of its inspiration. :D


That's not a very good excuse for someone who's communicating with other people outside of his culture. He's had many many years to learn that his style of communication doesn't mesh with most people.


> He's had many many years to learn that his style of communication doesn't mesh with most people.

Well, considering that Linux is pretty much powering the world it seems to me that his style of communication tends to mesh perfectly well with the people that he's working with and that they actually get the job done. As opposed to a whole pile of floundering competitors which are of course much better from a technical perspective and tend to have more polite maintainers.

The man gets the job done, in a similar way that an army general will get the job done. Whether he would be equally effective if he would polish his words on those occasions where people get offended is something we probably will not know.

If you're easily offended don't contribute to the Linux kernel.


He surrounds himself with people that are willing to put up with his communication style. That doesn't mean he has a good communication style.

> If you're easily offended don't contribute to the Linux kernel.

That's a pretty shitty attitude to take. And you don't have to be "easily offended" to dislike interacting with Linus.


> That's a pretty shitty attitude to take.

Why?

The Linux kernel is mission critical, that means that tons of business and individual depend on it for all kinds of stuff that if it went down would be a major event with the losses likely hard to put a figure on.

Developing for such an environment tends to be a fairly harsh affair, Linus was not bred for this, he more or less accidentally found himself the leader of a substantial software effect, the likes of which had not been seen before outside of very large corporations. The fact that he managed to make this work and managed to get together a band of developers that work well with him - regardless of style - speaks volumes to me, I know I couldn't do it, work the best part of my life to give away my work and to be scolded for the form of my delivery would be reason enough for me to throw the towel in.

Personally, I've known bosses that were a lot less reasonable than Linus is who tends to simply be direct, to the point and sometimes (rare enough that people feel the need to point out their favorites) makes social faux-pas that I feel are minor issues, stuff that if it is part of someone's personality you can easily step over.

I've yet to be in a work environment where there aren't one or two 'hard cases' and typically they have their reasons for being short tempered, such as that when the shit hits the fan it is their shoulders that a disproportionate helping of manure will land on.

Being the maintainer of a large open source project has to among the the most thankless jobs in the world, being the chief maintainer of the Linux kernel is probably one of the worst of those.

The only other person in the open source community that gets such treatment is RMS and I really fail to see what the big deal is.


Correlation is not causation. Just because Linus managed to become BDFL of a hugely successful project doesn't mean Linus's communication style in any way caused this. And it doesn't mean that he should get a free pass on treating people badly.

A lot of people subscribe to the idea that if you don't have a thick skin you shouldn't be in tech. That's a terrible attitude to take, there's absolutely no reason why that should be true, and it discriminates against a lot of people (including women). This attitude just contributes to the current toxic tech culture.


> Correlation is not causation. Just because Linus managed to become BDFL of a hugely successful project doesn't mean Linus's communication style in any way caused this.

Just as it does not prove the opposite.

> And it doesn't mean that he should get a free pass on treating people badly.

From you? Or from those people?

If you're not the one that he was talking to why do you feel so strongly about it?

> A lot of people subscribe to the idea that if you don't have a thick skin you shouldn't be in tech.

I didn't say that. And I don't subscribe to that. But if you want to be in a project with a BDFL that tends to be a bit coarse then it certainly won't hurt.

> That's a terrible attitude to take, there's absolutely no reason why that should be true, and it discriminates against a lot of people (including women). This attitude just contributes to the current toxic tech culture.

Yes it would. But that is something that you mixed in all by yourself and you're making Linus the scapegoat for this particular shortcoming of the tech community, whereas Linus is just one person in an arguably un-enviable position who gets a lot of shit thrown at him for a few minor gaffes which the participants took a lot better than the bystanders. And personally I'm more inclined to see these as in the heat of the moment and soon forgotten afterwards, the fact that they are archived forever doesn't take away the dynamics of the original situation. Heck, if I got the kind of hate that Linus gets for his occasional flare-up I'd stick to solo projects. It's bordering on the ridiculous how this is pulled out of proportion.


and it discriminates against a lot of people (including women).

My assumption is you aren't a woman, but I thought I would stop in and ask if you are. If you aren't, what is the basis for your idea that his communication style would discriminate against women?


>And you don't have to be "easily offended" to dislike interacting with Linus.

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.

I've yet to work for a company where there wasn't some people I personally disliked working with. part of being professional is putting aside things like dislike and focusing on the core mission/goals and finding ways to work together despite how you feel.

Those that CANNOT work with linux I would say are those that are easily offended. Some may choose not to, but that is their own personal choice.


Most people _where_? In the USA or the whole world? What makes you think that USA is a better representative of the world culture than Finland? I'd be hard pressed to recall any place in the world where people hate Finns, while that can't be said about Americans...


Nobody cares how reasonable you are if you don't actually produce anything.


And nobody cares how much you produce if you're too unreasonable to sell them on your creation. Creating strawmen out of maximally-extreme arguments is silly. Unless you think that being reasonable is mutually exclusive with being productive?


I think it's fair to say Linus has already proven his worth.

But even the Linux kernel and git aside, the fact that people listen to him despite his frankness speaks volumes for how respected he is.


Agreed, just as it would be a fallacy to presume that one can't be both productive and polite, it would also be a fallacy to believe that being impolite immediately invalidates all productive endeavors. I'm not using this thread to try to tear Linus down, just trying to keep people from promulgating the myth that Linus' governance style is the only effective one. :P


> And nobody cares how much you produce if you're too unreasonable to sell them on your creation.

But Linus already has.


True, but irrelevant for Linus. It's not a good way to get ahead[1], but if you're already far enough ahead...

Personally, I think I'm on "your" side -- as it were -- on the side of civility, but sometimes you've just got to get shit done. Properly, which sometimes means shouting the right things at the right people[2].

I do think it's unreasonable of you to say that Linus is not "being reasonable", as you've clearly implied in your comment. To my mind he's being entirely reasonable, just not very "polite" or "civil" or whatever you want to call it.

[1] As in: Rise up the corporate ladder.

[2] Sorkin's "Too Big To Fail" was a big eye-opener in this regard, FWIW.


> I do think it's unreasonable of you to say that Linus is not "being reasonable", as you've clearly implied in your comment.

I'm literally using the terminology of the person that I'm trying to refute! :P If you want to argue phrasing, take that to jacquesm.


I'm sorry. I was too carried away to notice! :)

(Which reminds me: There should probably be some sort of mandatory-quoting mechanism on HN. It seems weird that you can snipe comments by editing at just the right time. That's not what happened in this case, I'm just saying that it would probably be a good thing to have measures against it. Sorry, that's my META-rant done.)


No, progress often relies on both those things-- people working reasonably together on ideas brought forward by people who might be deemed "unreasonable."


Progress also requires a common standard. Linux is not unreasonable, it just has its own standards.

Things that don't conform to that standard are 'garbage' or are simply in other words 'non compliant'. Linus could express all the same ideas without profanity, if people cared about quality as much as he does.

Strictly enforcing some compliance to their developing process doesn't make Linux development 'unreasonable', because trying to change their developing process just because of some external web tool doesn't constitute 'reasoning'.

Trying to change their development process is just fire and motion ( https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ ) from a third party.


Github also created the most productive (set of) open source communities ever around "his" baby.

Seriously: Everyone calling Github "garbage" should be forced to use sourceforge until they're willing to reconsider. Or Bugzilla. Or trac. Or whatever it is that ubuntu is using to make it impossible to ever find anything.


I don't see why you deem Trac worse than GitHub for helping a project.


I remember Trac, just browsing Trac instances was terrible.

But "whatever it is that ubuntu is using" — Launchpad — was pretty awesome. I used bzr before git, and I really liked Launchpad.


but muh bootstrap



I wouldn't say he is unreasonable.

He is firm, strongly opinionated, and doesn't waste time catering to irrelevant feelings. That isn't "unreasonable", more "difficult" in my mind as far as personal interaction goes.

His actual opinions are usually very reasonable, just not communicated in ways that come across as such. At least in my opinion


Progress relies strongly on strong-willed people whose strong opinions are going in the direction of progress.

I doubt you will find many people who think that the state of GitHub PRs today represents less progress than the state of the `git request-pull` workflow. And, to be clear, there are a lot of things I prefer about `git request-pull`, starting with the ability to provide inline commentary on the commit message itself. But it's clear that GitHub has built a better product that keeps improving and has enabled a lot of teams to successfully build their own software. `git request-pull` is easily available to anyone with email, and I use it myself when there's no PR interface for a git repo, but people still tend to prefer the GitHub-style workflow.


Maybe, but solving truly big problems relies on people working together. Linus (and the unfortunate proliferation of jackasses who emulate him) do more to hinder progress than help it.


He solved the problem with git, he's upset that the company trying to make money off it broke it again.

Most of the times Linus is an asshole are completely justified. Being rude to groups like Nvidia isn't hindering progress.


Ehh, he solved his problem with git + mailing lists. That doesn't make it the same problem everyone else wants to solve.


Yeah? What's the problem you solved for yourself?


I'm sure github has done more for git uptake than anyone else involved on the lkml or Linus himself. He should be thanking them for that.


He should only be thanking them for that if git uptake around a mutilated version of his tooling is something that Linus wants. I suspect very strongly that he doesn't want that. In fact, if GitHub were a less popular service he wouldn't need to spend nearly as much time dealing with people who don't RTFM and submit GitHub PRs despite Linus' objections to them.


He doesn't read them. There is a bot for that now. Example: https://github.com/torvalds/linux/pull/445#issuecomment-3203...


> In fact, if GitHub were a less popular service he wouldn't need to spend nearly as much time dealing with people who don't RTFM and submit GitHub PRs despite Linus' objections to them.

Does he even bother reading them nowadays?

If anything, I would say that if git were less popular, its developers wouldn't have to deal with constant complaints that their UI scares noobs.


Why do you think he cares that anyone else besides Linux kernel developers use git?


I don't much care whether Linus individually has the justification to be an asshole or not. The problem is that Linus being an asshole causes many other engineers to think it's ok/expected/encouraged to be assholes. All the non-assholes quietly disappear and we're left with a room full of assholes.


The whole "Linus is an asshole" is well overplayed, though. The guy's been developing Linux for 25 years, with most of his communications in the open. The kind of outburst he has once every few years, and which gets extensive coverage and discussion, is a weekly occurrence in many offices. It's just that we'll never hear of those.


And I've yet to see someone single out a particularly nice and constructive comment and use that for a counterpoint.


I suppose I'll bite:

https://lkml.org/lkml/2017/8/9/924

https://lkml.org/lkml/2017/8/8/873

https://lkml.org/lkml/2017/8/8/855

https://lkml.org/lkml/2017/8/8/760

https://lkml.org/lkml/2017/8/6/209

https://lkml.org/lkml/2017/8/6/219

https://lkml.org/lkml/2017/8/6/322

https://lkml.org/lkml/2017/8/4/634

https://lkml.org/lkml/2017/8/3/919

If you didn't notice from the dates, those are all (Literally all, I didn't leave any out) of Linus's emails from the past week or so. The only one that even really has a complaint in it is the ext4 one that you've likely already seen, and the rest are extremely helpful and include detailed descriptions of what he was thinking or what he'd like to see.


Seems like those people are just assholes trying to justify their behavior, anyone actually trying to emulate Linus would see thousands of helpful messages for every outburst.


I'm curious - where do you think we would be today with the Linux kernel and git if Linus wasn't here?


Running on BSD and Mercurial? Wouldn't have made a lick of difference for most of us.


And yet, so many small and large organizations choose to use Linux and git over BSD and Mercurial, 'despite' Linus' management style.


If GitHub were based on Mercurial rather than git, we'd very likely see hg as the major VCS and git the lesser alternative. If FreeBSD weren't the target of a lawsuit in 1992 and 1993, it's plausible (by no means guaranteed) that it could have been the major OSS Unix distro instead of Linux.

Technology choices are largely driven by network effects, and small variances in the seeds of the networks can ultimately dictate which networks win and which ones lose.


Github rode on the back of widespread adoption of git, not the other way around. It isn't like Bitbucket didn't exist.


I would like to think that Linux and Git have helped progress more than hinder it.


Linus has a very successful project, he put in a lot of hard graft to get his project where it is, he continues to put a lot of hard graft, and he has a very limited amount of time. We can ask him to sugar coat his communications, so had not to ruffle too many feathers, or we can ask him to churn out as much techinical work as possible. I think we're asking him to churn out as much technical work as possible, so therefore he is optimising against that and his communications with humans are going to be terse. Maybe we need intermediaries to assist him in managing his communications, but then we loose direct access, so ultimately there has to be compromise.

There is always compromise. We can ask Linus to compromise, or we can. Are his inputs better put in at a technical level or at a human touchy-feelie level? What do you think is the best use of Linus' time?

It is incredibly easy to offer criticism, but very much more difficult to offer real and implementable solutions.


> He really talks in extremes. I see all his points but it doesn't make these things pure garbage.

Why, from his point of view - if GH lacks functionality he needs and git proper delivers this functionality in conjunction with email, GH is just about as useful as an empty beer can ;)

But sure, outsiders with zero idea of what is being discussed love to take his words out of context and derive all sorts of bizarre conclusions.


He doesn't qualify his statements, though. In my view, one of the most offputting parts of the nerd worldview is "I don't like it therefore it's shit". This juvenile lack of empathy is at the root of a lot of conflict (and the reason many people leave tech).


The comment was also made over 5 years ago. GitHub PRs have improved since then, though he may still find them deficient.


It's not pure garbage, but it's not workable for Linus. Nothing wrong with that. Also, he's right in this case.


Surely someone who talks like he does will never go anywhere in life!


Mobile friendly:

> I don't do github pull requests.

> github throws away all the relevant information, like having even a valid email address for the person asking me to pull. The diffstat is also deficient and useless.

> Git comes with a nice pull-request generation module, but github instead decided to replace it with their own totally inferior version. As a result, I consider github useless for these kinds of things. It's fine for hosting, but the pull requests and the online commit editing, are just pure garbage.

> I've told github people about my concerns, they didn't think they mattered, so I gave up. Feel free to make a bugreport to github.


It looks like github's pull requests and other features Linus had problems with have improved since 2012. Here is a pull request that Linus opened recently:

https://github.com/Subsurface-divelog/libdc/pull/7


None of those commits are signed. Apparently people on GitHub can commit as torvalds if the author email matches his: https://github.com/amoffat/masquerade/commit/9b0562595cc479a...

(You can't fake a fork without hacking the torvalds account, though, so maybe it really was him.)


Subsurface was originally created by Linus. Its pretty likely that that he authored those commits.


> Git comes with a nice pull-request generation module,

Can anybody explain a little more about this module? I thought 'pull request' is Github only.


You'd run "git format-patch" to create a .patch file with the diff of changes for a commit, and then run "git send-email" to send an email with the patch as the contents (optionally with additional comments). The recipient can then run "git apply" to apply the patches to their tree and push the changes.

For "private" repos, the recipient would be a specific repo maintainer/owner. For "public" repos like the Linux kernel, the recipient is usually a publicly-archived mailing list.


It's known as git request-pull [1]. The generated text would have to be sent to the ones you would want to pull from the repository you host.

[1] https://www.kernel.org/pub/software/scm/git/docs/git-request...


Also, should it really be called merge request? What exactly are they pulling during the merge?


They're pulling changes from another repository. A pull request is a request for someone else (the maintainer) to pull the changes that you're submitting into their repo. You aren't pushing; you're requesting for them to pull.

GitLab apparently does call them merge requests, though.


Github calls it pull, even if it's within the same repo, but from different branch. It essentially is a merge anyway.


You are pulling the commits from another repository.

The base repository is behind the forked repository and the forker is asking the base to incorporate (pull) the changes (commits).


Why does it need to focus on who is doing it? I think merge is generic enough term that can describe both actors (i.e. if you for example have a right to write into upstream, you can merge it yourself, without asking the primary owner.


Because otherwise it wouldn't work.


I imagine after the Bitkeeper fiasco, Linus and others are disinclined to become dependent on a proprietary service.


It should be a complete non-starter for one of the largest, and most important free software projects to be hosted on a centralized, proprietary service like Github. I can't even consider it as a serious suggestion.


I always think this sums it up well:

    > Current state makes it very hard to mange/search/fork/open-issues etc
    > especially for newcomers,
    > please move the project to github so we can have nice disussions
    > forks/prs etc goodness.

    No.  Never.  Github is proprietary communications tool which requires
    users to accept a terms of service and login.  That gives power and
    influence to a single entity (and a for-profit organization at that).

    Contributing to unicorn is *socially* as easy as contributing to git or
    the Linux kernel.  There is no need to signup for anything, no need to
    ever touch a bloated web browser.

    The reason I contribute to Free Software is because I am against any
    sort of lock-in or proprietary features.  It absolutely sickens me to
    encounter users who seem to be incapable of using git without a
    proprietary communications tool.
https://bogomips.org/unicorn-public/20140801213202.GA2729@dc...


Linus seems to have a different take on OSS than most OSS warriors. I don't think he sees proprietary software as 'evil' or OSS as morally superior. I get the impression he just thinks OSS will be better in quality. Depending on the contributors, which is why he doesn't want or need endless numbers of average devs contributing to his baby.

I think his point about Tridgell's actions with BK reverse engineering were right, and El Reg was playing the OSS warrior card. It looks to me like Tridgell was trying to create a way to steal BK metadata - BK specifically required you to have a license to get that data.

OSS warriors annoy me as much as SJWs do, and seem just as narrow minded.


Hm, I don't think so. Linus never had a problem with bitkeeper being proprietary, and he actually was annoyed when Andrew Tridgell tried to reverse-engineer the bitkeeper protocol. Linus seemed very unhappy with Tridgell, not with Larry McVoy for making bitkeeper proprietary. He built git out of necessity, not out of some desire to have free software.


> He built git out of necessity, not out of some desire to have free software.

History has proven that necessity is a much better incentive, and produces better products than ideology.


I don't know about that. Hg was built at the same time for the same reason but seems to have more ideology around it, and I would argue it's a superior product that just was unlucky enough to not have github built for it.


For people who seriously care about performance like me, git is by far the superior product.

I don't care much about the github website, because 99% of the time I use git from the command line.


> and he actually was annoyed when Andrew Tridgell tried to reverse-engineer the bitkeeper protocol. Linus seemed very unhappy with Tridgell

Why was that?



Bitkeeper was proprietary software. git is not. This dependency exists with Github only if you use issues, wiki, etc. But even those are exportable with documented APIs.


This font gave me a headache Why not write with white on white? It would be so stylish


If things like this bother you, you should check out the chrome extension 'Dom Distiller'[0]. I saw it in another HN comment last week and it's already one of my favorite plugins!

It drops all of the non-article content on most sites and leaves you with a centered, decent width, blank-and-white version of the article that's almost always easier to read than the original.

[0]https://chrome.google.com/webstore/detail/dom-distiller-read...


Unless you're on mobile.


The font stack is just "Helvetica, sans-serif" but the weight is set to 100 which is extremely light. So if you have a very light variant of Helvetica installed it might be unreadable.

Edit: or if your default sans-serif font has a super light variant installed, it might look very different from what was intended.


100 is not a font weight that makes sense for a large body of text no matter what the font. We call 300/400 "normal" for a reason.

100 is a "sometimes food" for that giant header or over-sized pull quote.

Designers that insist that entire documents/web-pages must be "light and airy and always 100 font-weight" have A) never struggled with contrast or accessibility issues, B) maybe don't understand typography. "light and airy" also means "easily blows off the page and is unreadable".


Your browser has a 'Page style/No Style' option to take care of stuff like that.


Not that easy on mobile. Would be much better if people didn't feel the need to make their sites crappy


> Not that easy on mobile.

Why not? Reader mode is just one button press away in Firefox for example.


Because I HN links per default open in the HN app I, which is convenient.


What is convenient about it?


I like having both discussions and the article in one tabbed app without having to switch.


So that you can quickly switch between them?


Firefox has a reader mode. It gives everything a nice consistent style.


Firefox has Reader View. That works well on mobile.


Dark Reader extension on Chrome, black background with white font become much better.


Looks clear & readable on my computer (Mac/Firefox) Perhaps you are missing the font and the page has a bad fallback font?


Lost me at "And lots of people learned that monorepos are really painful, because past a certain size they just stop scaling." Plenty of counterexamples of monorepo projects much larger than Linux kernel.


True, but only in large organizations that can devote massive amounts of manpower and infrastructure and have extensive tooling to make it work.


Actually, my experience is that monorepos scale better than non-monorepos. Probably the largest project that isn't a monorepo is OpenJDK--and even then, that's only barely true, as the entire JDK (effectively, rt.jar) is itself a single repository.

If you're arguing it's not a (implied-to-be-evil) monorepo because, well, it's really managed as independent fiefs who do all their work in separate integration stages... well, that's basically how every other major monorepo project does it. So if Linux isn't a monorepo, then there's no such thing as a monorepo in practice.


Frankly, I think the Linux kernel is too important to even consider subjecting itself to the Github T&C, community guidelines, etc.


Someone desperately needs to come up with an open source replacement for GitHub that is completely decentralized. Sure GitLab exists and the repo is decentralized since it's Git, but issues, merge requests, comments, etc aren't Git based (though they could be)


I wish more people used Fossil. I find it much better than Git and if it had more developers you may get a much better replacement.


Check out Phabricator - https://phacility.com/phabricator/


Phabricator is awesome but GitLab is more similar to Github if you're looking for a direct replacement.

These are still centralized, but each organization can host its own server. A true decentralized solution would federate issues/tasks, pull requests/diffs and their comments, etc. similar to how Git federates changes.


Here is another overview of how the kernel uses git and why no emails is simply not possible (or sensible). https://www.youtube.com/watch?v=vyenmLqJQjs


I actually really like the MAINTAINERS file. Keeps the metadata literally in the repository and doesn't rely on an external system.


Yes, this is similar to how I would like to handle issues: just an issues directory full of yaml-markdown files. That way, issues are a part of the same history as the code. They can be specific to a branch, they can diverge as different solutions are attempted in parallel, and they can be deleted and retrieved after resolution.


I've actually been fine with to-do lines in files. Have a metric for the number you have, and don't abuse it, but they are easy to find and literally next to the code they relate to.


The kernel seems better suited to something like Phabricator instead of Github. Keep Github simple and clean for our "normal" projects.


What makes Phabricator not suitable for "normal" projects?


This website is completely fucking unreadable on mobile. But hey, at least it's stylish or something.


Is there some similar reason why Debian doesn't use more convenient bug tracking system that would allow a Web frontend?

I don't mind periodically using reportbug, but using something like Bugzilla is way more convenient.


Not mentioned in the article, but work is also coordinated by maintainers with the use of patchwork. For example, for the network subsystem: http://patchwork.ozlabs.org/project/netdev/list/. This enables tracking the status of a patch and not loose them.


At GitLab we're looking into addressing this use case https://gitlab.com/gitlab-org/gitlab-ce/issues/36239


Love the effort and the dedication, but "Make Monotree Merging Magnificent", really? :D

Made me giggle.


> Please support pull requests and issue tracking spanning different repos of a monotree.

Issue tracking you can already file against one or more repos and link them together. It's not ideal, but it'll do the job.

Is "pr against different repos of a monotree" not what submodules let you do? Update whatever things you want in whatever repos, and pull the submodule pointer update(s) as a single change in your monotree repo.


I bet he knows git technical options.

The issue tracking just won't fly for a community that large. Imagine the hours spent keeping everything aligned relevant and updated: all that is wasted time, plain and simple.


Ugh that font is unreadable on my phone.


Off-topic:

Why does this blog need to be whitelisted with Adblock Plus? See data-adblockkey in HTML source. Are there any ads in this page? (Maybe owner wants revenue from domain parking?)

Why is this blog not working with simple user agents that do not process javascript (e.g., curl, etc.)?


curls works for me; so does Firefox+NoScript and elinks.


Thank you for checking.

Problem is misconfigured DNS:

   1 blog.ffwll.ch:
   77 bytes, 1+2+0+0 records, response, authoritative, noerror
   query: 1 blog.ffwll.ch
   answer: blog.ffwll.ch 3600 CNAME danvet.github.io
   answer: danvet.github.io 3600 A 192.64.147.142
I mistook 192.64.147.142 as the correct IP address.

Try that one with curl, firefox or elinks.

Correct address is 151.101.53.147.


> Like pull requests, issues can be relevant for multiple repos, and might need to be moved around

Not sure about the Linux kernel (no enough experience) but same issue across multiple projects looks something necessary...


Oh wow, the MAINTAINERS file is a work of art: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...


Hehe, never read through it, enjoyed Linus' info at the end

THE REST

M: Linus Torvalds <torvalds@linux-foundation.org>

L: linux-kernel@vger.kernel.org

Q: http://patchwork.kernel.org/project/LKML/list/

T: git git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

S: Buried alive in reporters


I love using GitHub, but there is an established process and home for the kernel that works and I see no reason to change it.


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


> If Linus is a complete asshole and tells you to fuck off

Consider that he might be right and not a complete asshole. Also, consider that you are not the person he insults but someone else. You're making up this strawman very craftily but it is still a strawman: people are coarse in their conversation all the time, it's not a big deal until the recipient declares it to be a big deal. And then they - not you, unless you are the recipient - have all the right in the world to feel offended and to respond in kind if you feel like it or to do it a bit more precise and with more grace if that's your make-up.

But for all the weight given to 'free speech' the fact is that all you're doing is trying to control someone else's language and I find that a far bigger problem than someone throwing out the occasional insult in the process of communicating with others, there are plenty of reasons why that could happen, personality, lack of patience, culture and so on and all of those would be less of an issue than someone deliberately trying to control how others communicate.

Now if Linus had said something like 'you're dumb because you're a woman' or something to that effect I could understand the outrage. But calling someone an asshole - justified or not - when you're not the person being addressed is not enough grounds to embark on a moral crusade and is not enough grounds to lie the diversity problem in tech at that persons feet.


Speaking as someone who has been insulted personally and publicly by Linus, on a topic that Linus was completely wrong about, he's a real asshole. And it's extremely well documented that he's an asshole. I don't need to "consider that he might […] not be a complete asshole", because that's already a given.

> You're making up this strawman very craftily

I'm not making a straw man at all, and I resent your attempt to frame my argument in this way. Since this is how you choose to argue, I'm not going to engage with you any more.


Well, you could have put that gem out front instead of pulling a rabbit out of your hat. Otherwise to me you're just another anonymous person arguing on a forum rather than someone with a specific and relevant gripe.

If there is a specific case where you disagreed with Linus and he insulted you then I understand why you want to take this up in this way but I notice that Linus is not a participant in the discussion here so you're going to get the general case, not the specific one.

You've made up your mind about a person based on an online interaction that clearly left you seething and I'm perfectly ok with that. For all I know it was the defining point of your career and you've chosen to go into crusade mode, there is a good reason why I don't contribute to open source, I don't feel like getting heat from both maintainers and users. At the same time if I would go and do that I'd wear my flameproof jacket to work just in case. In short: lighten up, likely everybody but you has forgotten this interaction and it is a huge deal to you and hardly anybody else noticed. You should have seen some of the stuff that came my way on a public website, heck, even on HN I've been threatened with bodily harm.

Question: Did you contact him about this off-line, and did you try to work it out somehow? If not I'd suggest you do that, maybe you can get this behind you.


[flagged]


[flagged]


This comment is not constructive. When you see someone who is tired of responding to offensive and completely baseless accusations, why do you think it's appropriate to insult them?


Can we get a trade on this font, gosh it's bad. Color and weight both need to be increased. Seriously #00000 on #FFFFF makes life easy with a font weight of at least 400


[deleted]


I think you're right. And if so I agree with Linus. I don't get the entitlement of OSS people. They want to play in someone else's sandpit but enforce their own rules. If you don't like the way the project is run then fork it, go make your own or find another one.




Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: