Live data from Hacker News

Why GitHub Can't Host the Linux Kernel Community

blog.ffwll.ch

231–240 of 251 posts

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

#231
post #101

Earlier quoted context omitted.

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.

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

#232
post #176

Earlier quoted context omitted.

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

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

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.

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

#233

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

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.

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

#234
post #28

Earlier quoted context omitted.

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.

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.

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

#235
post #205
post #175

Earlier quoted context omitted.

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.

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.

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

#236
post #176

Earlier quoted context omitted.

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

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

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

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

#237
post #54
post #20

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

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.

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

#238
post #38

Earlier quoted context omitted.

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.

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

#239
post #38

Earlier quoted context omitted.

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

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

#240

Earlier quoted context omitted.

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

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.

Post reply on HN