[highspeedmobile]

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]

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.

[highspeedmobile]

> You assume contributing via mailing lists is hard, which it is not.

Well, some OS projects optimise for attracting newcomers whereas some do not and clearly the Linux kernel project doesn't, hence the higher barriers for entry and its even reflected in the comments in this HN thread.

If the goal was to bring in commercial contributors into the Linux Kernel then this is not a problem. But, the Linux kernel isn't in any contributor shortage nor it is hoping to attract non-commercial contributors because they don't need to. For any other less popular open-source OS projects using mailing lists, why do you think they either moved or now do code reviews, contributions on GitLab, Phabricator, Gerrit via a web interface in the first place?

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

Well guess what? Gerrit, GitHub and GitLab all support send patches via email. The problem is not about preference, its about the starting point for beginners unfamiliar with OS projects and its certainly not the LKML and the Linux kernel. I instead recommended easier OSes (SerenityOS, Haiku, BSDs) to start with by using similar tools (Gerrit, Gitlab, Phabricator) for code reviews before looking at LKML and Linux.

Since the discussion is for attracting beginners into becoming long term contributors to open-source OSes, the starting point is not Linux or LKML. They first should look at easier OSes on GitHub/Lab/Tea or Gerrit to focus on contributing patches without trying or thinking about patch formats or top-posting, rather than starting in the deep-end, frustrating them with do's and don'ts for sending a patch and risking to putting them off altogether.