Earlier quoted context omitted.
I believe Cononical's launchpad was built to achieve such workflows. It came out of the need to create an integration platform taking upstream versions of software and applying Ubuntu-specific fixes. In the old days, before git and GitHub won, I liked their bug tracker way over GutHubs as it really supported these flows, where bugs are fixed not in the main repo but by some contributor first. But we'll, wrong bet on…
I wonder if there has been any work on porting launchpad to work with git.
Why GitHub Can't Host the Linux Kernel Community
201–210 of 251 posts
Re: Why GitHub Can't Host the Linux Kernel Community
#202Earlier 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.
The linked article explains at length why it works well for kernel maintainers. And since it does, why should kernel maintainers change it just to make things easier on newbies? It's much more reasonable to expect new participants to adapt to a workflow that works, than vice versa.
This is not "gatekeeping," it's just the reality that not everyone works the same way.
Re: Why GitHub Can't Host the Linux Kernel Community
#203As 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…
Re: Why GitHub Can't Host the Linux Kernel Community
#204I 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?
Centralization is indeed a problem, but I think we should all thank github for having standardized how to find opensource projects and contribute to them. This really gave opensource (especially opensource libraries) the kickstart they needed. And now, this centralization is lowering with concurrent products like gitlab, so everything is fine.
Re: Why GitHub Can't Host the Linux Kernel Community
#205Earlier quoted context omitted.
"They don't need or even want your help" There was in fact a talk given by Greg Kroah-Hartman, one Linux's lead maintainers, about development for the Linux kernel which he titled "I Don't Want Your Code" . https://www.youtube.com/watch?v=fMeH7wqOwXA
Haha, thanks for the video. I watched it, and I was surprised to see that it's about a specific company. He's at Linaro, specfically taking their developers to task for sending bad patches. And they indeed sound horrible, but he's good natured about it. I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build . And Greg…
Indeed, I've seen the same thing. I have considered automatically rejecting any patch made with the GitHub online editor (obvious because the committer name is always GitHub). They are pretty much invariably of shit quality.
Re: Why GitHub Can't Host the Linux Kernel Community
#206> If you don't do something because of a personal dislike, and expect others to cater to your culture and personal preferences, then the problem is you. Are you serious? If Linus is a complete asshole and tells you to fuck off, and you don't like that, the problem is with you ? How can you possibly defend that statement?
Re: Why GitHub Can't Host the Linux Kernel Community
#207Earlier 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.
I get the feeling most people who complain about how "clunky" email is have never actually tried to submit a patch to LKML. If I could figure it out when I was a high-school student, a professional developer should be able to figure it out as well.
Re: Why GitHub Can't Host the Linux Kernel Community
#208Re: Why GitHub Can't Host the Linux Kernel Community
#209Earlier quoted context omitted.
Yes, there has. Launchpad works fine with git today.
Oh, awesome. I was going to look at that later this afternoon. Cheers!
Re: Why GitHub Can't Host the Linux Kernel Community
#210I 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…
Ethereum