5 ms·

> Sending patches is as easy as sending one in GitHub or any other web-based system. Its still prehistoric in projects like the Linux Kernel, from a beginners

> Sending patches is as easy as sending one in GitHub or any other web-based system. Its still prehistoric in projects like the Linux Kernel, from a beginners point of view compared to GitHub, Gerrit or GitLab, which most of the active contributors are already working at large companies who's work requires contributing to it, thus already have invested in time and money learning the contribution process. To look at the LKML and do code reviews via back and forth emails looks simple for a veteran Linux developer at a large company but very arcane for a student sending a patch to the kernel. > The problem is that you (and many others) have never done it, and so anything different is harder. Your assumption is quite funny here as I have done both and I can tell you that most of the beginners particularly students are introduced into open-source via GitHub or even GitLab these days and its used as a starting point into contributing to a OS project. IIRC, ReactOS and FreeBSD has retained more student contributors from Google Summer of Code than say GNU/Hurd, by both improving the contribution process for beginners. I still wouldn't recommend beginners to learn about OSes in general by contributing to the Linux kernel due to the above reasons. Project making contributions more accessible for beginners isn't a bad thing, its actually how they attract potential long term contributors to stay on, rather than to make things simple only for veteran developers. > You should consider that if learning a handful of CLI commands is such a problem for you, perhaps it is not the system that is being unfriendly to you, but that you are unfriendly to learning anything else that is not your way. There's my point, it is still beginner unfriendly. Beginners these days would start with Github or Gitlab with a GUI to send PRs to a different OS project and wouldn't bother learning tons of CLI commands to send a patch in a email + code reviews. It is therefore favours veteran developers at large companies who stay on being long term contributors than the old days of random Linux enthusiasts doing this, which I'm very surprised you don't see the contribution process prehistoric from a beginners eyes. Perhaps something needs to change...

jfkebwjsbx 7y ago
If you cannot by arsed to learn a few new development tools or workflows, I am sorry but this field is likely to burn you out very soon, be it Linux kernel development, the next shiny GitHub replacement or the new edition of HTML/CSS/whatever. And let's not start about learning the myriad of tools you gotta learn to do in professional Linux kernel development (or any kind of specialized development for that matter). If you want to educate your students on being one more cog in the machine and make them complacent on learning the bare minimum, that's on you. I for sure wasn't taught like that.
- highspeedmobile 7y ago
  This isn't about me or what workflow I can learn. It's really about the entry point for beginners contributing to operating systems in general and making it accessible for them. Not just Linux. On that matter, the barrier for being a long term Linux contributor is still very high and this is from the perspective of outsiders in general. So unless you're working at a company that does professional Linux development with the hardware and software resources available to you, it is actually the outsiders that will be definitely burned out and won't bother with contributing anyway and will go to another OS kernel project to start from. Unlike you, I don't push beginners into the deep end for them to later drown. I get them started on an easier yet similar path where they use similar tools which eventually they later become potential Linux contributors at a company working on the kernel. But the starting path is certainly not Linux.
  - jfkebwjsbx 7y ago
    And why should beginners be contributing to the bloody kernel? Why should kernel devs (paid by companies) spend resources on making it easy for beginners? Here is the thing: kernel development in the most widely used production one is not a trivial thing. It is like pretending that architecture students should be helped to go work on the next biggest skyscraper as their first project and spend the time of actual architects to make it easy for them. If you want people to get into kernel development, there are kernels wrote specifically for teaching purposes.
    - highspeedmobile 7y ago
      Just read all my posts again and then you will realise that you constructed a strawman argument and addressed a point I never said. No-one directly said that beginners should be contributing to the Linux kernel when I actually said that beginners should get experience from joining other similar but easier open-source OS projects before joining a company specialising in Linux development to be long term Linux contributors. Technically, anyone can contribute to the Linux kernel due to its open-source nature given that their patches are reviewed by the maintainers and it is then accepted. > Why should kernel devs (paid by companies) spend resources on making it easy for beginners? Not only I didn't say that, but you do realise that there are companies that exist who both contribute to the Linux kernel and offer training for a one time fee as an introduction into kernel development? Given the beginner meets the experience pre-requisites: Bootlin, BayLibre and several others have professional kernel contributors that do this. > If you want people to get into kernel development, there are kernels wrote specifically for teaching purposes. Read all my posts again. I go beyond just 'kernels' and named other complete OSes to get OS development and kernel experience from before joining a company specialising in Linux development. I said in the last post that '...the starting path is certainly not Linux.', it seems you certainly didn't read that. Every professional Linux kernel developer started as a beginner somewhere and certainly wasn't born an expert. Some beginners were university students who either joined Linux companies by participating in programs like Google Summer of Code or took a paid Linux kernel training course by a company specialising in kernel development. You will notice that your last comment is in agreement with my whole argument.
salawat 7y ago
Here's the thing. Take GitHub, and boil it down, and it's a mish mash of version control, diff, and patch, all plastered over with a shiny HTTP veneer. Diff/patch, git, and email alone are the basic tools you need. Even before VCS was a really big thing, that is how software changes were propagated around. There is nothing wrong with sticking with the basics. In fact, I flat out refuse to tell newbies that they should host everything on GitHub, or GitLab. It's becoming a twisted new form of "social media-esque" hype.
- highspeedmobile 7y ago
  Well done. But here's the actual thing: There will always be those who don't like using the mailing lists for back and forth reviews and the same goes for GitHub (I use both anyway and have a self-hosted community GitLab and cgit). This isn't about me, its about attracting potential contributors to the Linux kernel in the long term. If I were tasked to attract as many beginners/students to go this path, It won't be to start with the Linux kernel or the LKML mailing lists (that will put them off). It would ultimately be other beginner-friendly similar projects like SerenityOS, HaikuOS or some of the BSDs even, etc so they can get some experience. Then their mental model is used to the Git flow so they can transition to using bare Git commands and can go into a technical discussion involving anything about kernel internals. Since Linux doesn't need to worry about attracting new outsider contributors due to commercial contributors doing most of the work, little needs to change. Which is why from the very start I much rather recommend beginners to start with other OSes and transition later to Linux internals.
megous 7y ago
Well, if you want to be more likely to get reaction from any one of 10 or so odd people the typical patch series goes to directly (sometimes simply because they may have contributed some code to some file you're also modifying now) + hundreds more on a bunch of subsys and more general mailing lists, forcing them to register on some random web service of your choice and then monitor it for further communication and replies and patch series revisions is not the easiest proposition. Everyone knows how to reply to an e-mail. It's very low effort way to find interested people to review your patch/and get some reaction from maintainers. That's how it is now. That's not to say, current system is not somewhat problematic to some maintainers/subsystems, but that's not really your businesss as a contributor.
- highspeedmobile 7y ago
  I'm not sure why you think I have a problem with mailing lists or not (I regularly use them myself), when the point of this discussion is about starting points for interested folks in Linux kernel or OS development in general. I just made a simple comparison on how different projects do code reviews from an outsiders perspective. The clear misinterpretation happens when I said 'beginners eyes' to assume that I'm some sort of 'beginner', when in fact as a maintainer I keep hearing the opinion of students and newcomers making this comparison and they use their preferred way to contribute (Github being mentioned often) when joining a project. Therefore, you giving a very naïve assumption that I somehow wanted to force everyone to '...register on some random web service' when I clearly said that beginners should start with a similar open-source project using similar tools like Gerrit, GitHub before trying something harder. Yes, I have confidence that everyone knows how to reply to an email. But in comparison to tools like Gerrit or Github, I won't expect many non-commercial contributors to stay for long if the review process was via mailing lists, unless they are paid to work daily on the project, which is why I recommended beginners other OS projects that have a similar review process before going onto looking at the Linux kernel.
  - megous 7y ago
    You assume contributing via mailing lists is hard, which it is not. In the project the size of a linux kernel it would be failry similar in complexity, and probably way harder to use anything else due to distributed nature of the project. (which I think is unreasonable to think will change) I contributed various things to the Linux kernel over the years across many subsystems. Each time I only had to prepare a list of recipients and send the patch series to all of them. Often times the patch series involved multiple subsystems. In the world where one maintainer is using github, the other his private gitlab instance, one is using gerrit, and the third gitea or whatever, and some holdout still accepts only mailing list contributions,... contributing for people like me who don't get paid for most of their work would be so convoluted, that I would not. While learning how to send a patch series via e-mail, while it takes some time to learn, allows me to contribute to any part of the Linux kernel via a single workflow, that is easy to replicate.

jfkebwjsbx 7y ago

If you cannot by arsed to learn a few new development tools or workflows, I am sorry but this field is likely to burn you out very soon, be it Linux kernel development, the next shiny GitHub replacement or the new edition of HTML/CSS/whatever. And let's not start about learning the myriad of tools you gotta learn to do in professional Linux kernel development (or any kind of specialized development for that matter). If you want to educate your students on being one more cog in the machine and make them complacent on learning the bare minimum, that's on you. I for sure wasn't taught like that.

highspeedmobile 7y ago
This isn't about me or what workflow I can learn. It's really about the entry point for beginners contributing to operating systems in general and making it accessible for them. Not just Linux. On that matter, the barrier for being a long term Linux contributor is still very high and this is from the perspective of outsiders in general. So unless you're working at a company that does professional Linux development with the hardware and software resources available to you, it is actually the outsiders that will be definitely burned out and won't bother with contributing anyway and will go to another OS kernel project to start from. Unlike you, I don't push beginners into the deep end for them to later drown. I get them started on an easier yet similar path where they use similar tools which eventually they later become potential Linux contributors at a company working on the kernel. But the starting path is certainly not Linux.
- jfkebwjsbx 7y ago
  And why should beginners be contributing to the bloody kernel? Why should kernel devs (paid by companies) spend resources on making it easy for beginners? Here is the thing: kernel development in the most widely used production one is not a trivial thing. It is like pretending that architecture students should be helped to go work on the next biggest skyscraper as their first project and spend the time of actual architects to make it easy for them. If you want people to get into kernel development, there are kernels wrote specifically for teaching purposes.
  - highspeedmobile 7y ago
    Just read all my posts again and then you will realise that you constructed a strawman argument and addressed a point I never said. No-one directly said that beginners should be contributing to the Linux kernel when I actually said that beginners should get experience from joining other similar but easier open-source OS projects before joining a company specialising in Linux development to be long term Linux contributors. Technically, anyone can contribute to the Linux kernel due to its open-source nature given that their patches are reviewed by the maintainers and it is then accepted. > Why should kernel devs (paid by companies) spend resources on making it easy for beginners? Not only I didn't say that, but you do realise that there are companies that exist who both contribute to the Linux kernel and offer training for a one time fee as an introduction into kernel development? Given the beginner meets the experience pre-requisites: Bootlin, BayLibre and several others have professional kernel contributors that do this. > If you want people to get into kernel development, there are kernels wrote specifically for teaching purposes. Read all my posts again. I go beyond just 'kernels' and named other complete OSes to get OS development and kernel experience from before joining a company specialising in Linux development. I said in the last post that '...the starting path is certainly not Linux.', it seems you certainly didn't read that. Every professional Linux kernel developer started as a beginner somewhere and certainly wasn't born an expert. Some beginners were university students who either joined Linux companies by participating in programs like Google Summer of Code or took a paid Linux kernel training course by a company specialising in kernel development. You will notice that your last comment is in agreement with my whole argument.

salawat 7y ago

Here's the thing. Take GitHub, and boil it down, and it's a mish mash of version control, diff, and patch, all plastered over with a shiny HTTP veneer. Diff/patch, git, and email alone are the basic tools you need. Even before VCS was a really big thing, that is how software changes were propagated around. There is nothing wrong with sticking with the basics. In fact, I flat out refuse to tell newbies that they should host everything on GitHub, or GitLab. It's becoming a twisted new form of "social media-esque" hype.

highspeedmobile 7y ago
Well done. But here's the actual thing: There will always be those who don't like using the mailing lists for back and forth reviews and the same goes for GitHub (I use both anyway and have a self-hosted community GitLab and cgit). This isn't about me, its about attracting potential contributors to the Linux kernel in the long term. If I were tasked to attract as many beginners/students to go this path, It won't be to start with the Linux kernel or the LKML mailing lists (that will put them off). It would ultimately be other beginner-friendly similar projects like SerenityOS, HaikuOS or some of the BSDs even, etc so they can get some experience. Then their mental model is used to the Git flow so they can transition to using bare Git commands and can go into a technical discussion involving anything about kernel internals. Since Linux doesn't need to worry about attracting new outsider contributors due to commercial contributors doing most of the work, little needs to change. Which is why from the very start I much rather recommend beginners to start with other OSes and transition later to Linux internals.

megous 7y ago

Well, if you want to be more likely to get reaction from any one of 10 or so odd people the typical patch series goes to directly (sometimes simply because they may have contributed some code to some file you're also modifying now) + hundreds more on a bunch of subsys and more general mailing lists, forcing them to register on some random web service of your choice and then monitor it for further communication and replies and patch series revisions is not the easiest proposition. Everyone knows how to reply to an e-mail. It's very low effort way to find interested people to review your patch/and get some reaction from maintainers. That's how it is now. That's not to say, current system is not somewhat problematic to some maintainers/subsystems, but that's not really your businesss as a contributor.

highspeedmobile 7y ago
I'm not sure why you think I have a problem with mailing lists or not (I regularly use them myself), when the point of this discussion is about starting points for interested folks in Linux kernel or OS development in general. I just made a simple comparison on how different projects do code reviews from an outsiders perspective. The clear misinterpretation happens when I said 'beginners eyes' to assume that I'm some sort of 'beginner', when in fact as a maintainer I keep hearing the opinion of students and newcomers making this comparison and they use their preferred way to contribute (Github being mentioned often) when joining a project. Therefore, you giving a very naïve assumption that I somehow wanted to force everyone to '...register on some random web service' when I clearly said that beginners should start with a similar open-source project using similar tools like Gerrit, GitHub before trying something harder. Yes, I have confidence that everyone knows how to reply to an email. But in comparison to tools like Gerrit or Github, I won't expect many non-commercial contributors to stay for long if the review process was via mailing lists, unless they are paid to work daily on the project, which is why I recommended beginners other OS projects that have a similar review process before going onto looking at the Linux kernel.
- megous 7y ago
  You assume contributing via mailing lists is hard, which it is not. In the project the size of a linux kernel it would be failry similar in complexity, and probably way harder to use anything else due to distributed nature of the project. (which I think is unreasonable to think will change) I contributed various things to the Linux kernel over the years across many subsystems. Each time I only had to prepare a list of recipients and send the patch series to all of them. Often times the patch series involved multiple subsystems. In the world where one maintainer is using github, the other his private gitlab instance, one is using gerrit, and the third gitea or whatever, and some holdout still accepts only mailing list contributions,... contributing for people like me who don't get paid for most of their work would be so convoluted, that I would not. While learning how to send a patch series via e-mail, while it takes some time to learn, allows me to contribute to any part of the Linux kernel via a single workflow, that is easy to replicate.