Linux 6.5 Last Minute Fixes A Performance Regression - 34% Drop In A Micro-Benchmark

[CochainComplex]

LKML as a mail-list is IMHO ten tons better than the mess that is GitHub discussions. Primary you don't have to register for some new account at some site to be able to take part of discussions, secondly you have perfect log and archive of every single message in the event say GitHub would go tits up. But ofc this is coming from some one in the same age group as Linus so it could be a get out of my lawn moment, I just simply hate to work with GitHub when I want to send in a few patches to some random project.

Also the CI provided by GitHub is nowhere near the CI that is done on the Linux kernel.

I do understand your arguments. It also depends what you are used to use. I'm primarily researcher and not programmer. At our research facility we have had svn before. It was a mess not everyone was using it. Codesnippets of small projects had been saved locally or on what ever backup media was favoured by the individual person. Exchange of new versions was maintained by sending mails back and forth. (Works if you only have very small projects but only if subject is indicating it ) Since a few years our it dep provides a gitlab instance. Its hosted by the institute and it uses the already established user account structure. Since we have this everything is not a mess anymore. We even use it to provide introductions, manuals for testing equipments and lab procedures. Everyone who recognises missing points will instantly be able to add it. And if its not clear we use the Discussion feature of the self hosted gitlab platform.

Concerning CI. Gitlab etc instances support docker so you can use what ever you want to test your code. There is simply no limitation. Maybe computing power of your server hardware.

Bottom line: yes mailing list has its advantages otherwise it would have been used over decades. But lets be honest Lkml has already additional UI tools, dedicated web ui etc to make it usable. Otherwise it wouldnt work at all as simple mailinglist. So lkml is not a pure mailing list as github is only simple git. And maybe its already too "fossilised" to be easily replaced by a modern git-whatever platform. But having a nice structured webinterface makes collaborative work a lot easier. And it doesn't mean that you have to use the web ui. In 90% of my work with those platforms I simply use the git CLI. IMHO its basically lkml just done well in a modern context.

*sometimes its good to have to subscribe. On lkml there is often a lot of spam. At least the last few times I have visited the lkml web site.

[F.Ultra]

I do understand your arguments. It also depends what you are used to use. I'm primarily researcher and not programmer. At our research facility we have had svn before. It was a mess not everyone was using it. Codesnippets of small projects had been saved locally or on what ever backup media was favoured by the individual person. Exchange of new versions was maintained by sending mails back and forth. (Works if you only have very small projects but only if subject is indicating it ) Since a few years our it dep provides a gitlab instance. Its hosted by the institute and it uses the already established user account structure. Since we have this everything is not a mess anymore. We even use it to provide introductions, manuals for testing equipments and lab procedures. Everyone who recognises missing points will instantly be able to add it. And if its not clear we use the Discussion feature of the self hosted gitlab platform.

Concerning CI. Gitlab etc instances support docker so you can use what ever you want to test your code. There is simply no limitation. Maybe computing power of your server hardware.

Bottom line: yes mailing list has its advantages otherwise it would have been used over decades. But lets be honest Lkml has already additional UI tools, dedicated web ui etc to make it usable. Otherwise it wouldnt work at all as simple mailinglist. So lkml is not a pure mailing list as github is only simple git. And maybe its already too "fossilised" to be easily replaced by a modern git-whatever platform. But having a nice structured webinterface makes collaborative work a lot easier. And it doesn't mean that you have to use the web ui. In 90% of my work with those platforms I simply use the git CLI. IMHO its basically lkml just done well in a modern context.

*sometimes its good to have to subscribe. On lkml there is often a lot of spam. At least the last few times I have visited the lkml web site.

Sounds like you had a complete chaos situation and ended up implementing a strict structure, and perhaps that is where the disconnect lies in that the use of e-mail reminds you of the old chaos days at your research facility? The thing is that LKML have been quite structured since a very long time ago, and IMHO the UI tools and web ui over LKML is most likely used by external non-regular LKML users when looking for something and yes there I can see it being quite a bit of hassle to search for something (on the other hand searching through old issues and PR:s on say GitHub on a large project is no easy mountain to climb either).

What I meant wit CI is that there are millions of external wacky people running all kinds of strange tests from single machines to several thousands at once but on specific code bases and patches that are of interest to them, now I have only limited experience with CI:s on GitHub from sending in patches to various projects but there it always bothers me that every single patch results in several new CI instances being queued up where many fails to be being misconfigured and 10 minutes when I add a new patch it all starts over again instead of just waiting for me to signal that everything has been patched (could be that every single project on Github is wrongly configured, I wouldn't exclude that fact at all).

Who knows what the future holds, my self though I prefer to look over a simple unified patch via mail when performing code audits.

People will probably die once I mention this but I also highly prefer SVN over GIT for centralized projects, the daily workflow of "svn up" code "svn ci" code "svn ci" go home is IMHO much easier and less complex than the GIT one when you are working one person per project and you have to commit to a central server at work anyway.