Endless Linux Kernel Problems Are Fixed With Gitlab

Key Takeaways

At this point, the Linux kernel is one of the last beta projects doing all of their development through a mailing list. Now, most Linux related projects have at least the big ones have or had a mailing list. Take for example Arch Linux or most other distros out there or you know has a mailing list. I'm pretty sure it has one. Whand has a mailing list and all of these projects have mailing lists. It's just either they rarely get used, they get used for updates like is the case for Arch Linux, or there are still people actively using it. But it's a small group of people and it's people that have just always used it and never moved off of that system as it is still being offered. And for most projects using GitHub, GitLab, some other source forge, they're doing most of the development, the issue tracking, the pull requests, maybe even project discussions directly through that platform. Maybe they have an external chat platform like a Matrix or a Discord. Maybe they have an external bug tracker like a Bugzilla like KDE does. But the mailing list isn't really a core part anymore. And honestly, it feels like sometimes the LKML really stretches the power of a mailing list and maybe things would be better with a newer set of tooling. Now, it's probably never going to happen. I think in 50 years from now, the Linux kernel is still going to be using the LKML, but you know, there's only one way to find out, and I don't have a time machine. Now, the other day this was sent up to the LKML. I owe you uring fix for 6.17 RC5. Highline is just a single fix for an issue with the resource node rewrite that happened a few releases ago. Please pull. It is a very simple change. It's a couple of lines. Totally normal change to see when you are looking at an RC related fix. It is a bug fix. Nothing crazy. And Lionus doesn't take issue with when this is being submitted. This is not a Kent Over Street situation. Instead, he saw the change and is a little bit confused about the change. But the confusion isn't the main problem. It's trying to work out why this change was made in the first place and the lack of explanation for it, even though he thought there was one. I've pulled this, but the commentary is strange and the patch makes no sense to me. So, I unpulled it again. Yes, it changes things from KV Malik array to KV Caloc. Fine. And yes, KV Kellock clearly clears the resulting allocation. Also fine. But even in the old version, it used GFP0. In fact, as far as I know, the only difference between KV Kelloc and KV Malo array is that KV Kelloc adds GFP0 to the flags argument. So, as far as I know, this doesn't actually fix anything at all. So, it's a simple change, but Lionus is confused about why the change was made. Now, there is a lot of patches that come up like this, and if there is some justification for why the change was made, that's still totally fine. Lionus can then understand it. The problem though is the explanation is not an explanation. And damn it, this commit has that promising link argument that I hope would explain why this pointless commit exists. But as always, that link only wasted my time by pointing to the same damn information that was already there. I was hoping that it would point to some oops report or something that would explain why my initial reaction was wrong. Stop this garbage already. Stop adding pointless link arguments that waste people's time and add the link if it has additional information. Damn it. I really hate those pointless links. I love seeing useful links, but 99% of the links I actually see just point to stupid, useless garbage and only waste my time again. So, I have not pulled this. I'm annoyed by having to even look at this. And if you actually expect me to pull this, I want a real explanation and not a useless link. So, this right here is the commit in question. Give it a I I'll cut back to when this is loaded. IOU uring RSRC initialize IO RSRC data nodes array. And then there is this explanation on why this change is being made. And this is the change. This is the explanation that Lionus didn't really understand from what is being done here because this from what he can tell is effectively the exact same bit of code. and even though it's calling a different function, it's doing the same thing. So, it doesn't really make any sense why the change was made. Now, he saw this, didn't understand it, saw this, though, and hoped that by going to this link here, this would explain what's being done. Now, notice the text from here to here. It is the exact same text. So, there is a link that Lionus hoped would explain why this is being done or link to a bug report or some other explanation for why the change is being made. And all it links to is the patch email saying the exact same thing as the commit message. So, just imagine for a second you're in Lionus' shoes. You are going about your day. You're reviewing PRs as you do every other day and you run across what seems like a really simple change. It's a couple of lines. It's one function and you don't really understand why the change is being made. It seems like it's effectively the exact same code. So the commit message doesn't seem to explain why it was made. But you see this link which is supposed to provide context. you follow it and not only do you not get additional context, you get literally the exact same text you just read that doesn't explain why this is a problem that exists, why this is something that is being done. So, yes, I'm grumpy. I feel like my main job, really, my only job is to try to make sense of pore requests. And that's why I absolutely detest these things that are automatically added and only make my job harder. I'm CCing Constantine again because this is a prime example of why that automation hurts and he was arguing in favor of that just last week. Can we please stop this automated idiocy? Lionus at this point is not a core developer on the Linux kernel. He's more in a sort of management position. So, disruptions on the poor request review side, those are incredibly important to him. Now, link trails are a term you're going to see used quite often here. And a link trail basically just means this right here. It is a consistent machine readable form to include a link or other things at the end of your commit message. And the addition of links like this one, this is not something that is done by the user. Well, it's something they enable. they have to include an option to include it. But the inclusion of the link, this is actually automated. You can also include your own links and you know do all that good stuff. But links like this one which are entirely useless in most cases they're being put there by the kernel tooling from Constantine. Do you just want this to become a noop a no operation? Just get rid of it. or will it be better if it's only used with the patch message idlink domain namespace to clearly indicate that it's just a provenence link? So clearly indicate it is just a link to the patch message, not something where there might be context because this link right here, this email link, this doesn't tell you anything that it might be. This could be anything on the LKML. It's not until you actually go to it do you realize it's just the pat Gmail. So if it's in a clear form that indicates that is what it is, at least then you're not going to mistake it for something else. Going back to Lionus, I wish it had some way to discourage the normal mindless use and in a perfect world that there was some more useful model for adding links automatically. For example, I feel like for the cover letter of a multi-commit series, the link to the patch series submission is potentially more useful and likely much less annoying because it would go into the merge message, not individual commits. So oftent times patches submitted to the kernel, they're not just submitted individually, they're submitted in a series of patches. So, if you were to link to the cover letter, the thing that tells you they're all in the same series, that at least provides you some level of context. And there's likely going to be existing discourse under that cover letter. Because if somebody is actively looking at a merge message, they are probably looking for some bigger picture background or there's some merge conflict. And at that point, I expect that the initial submission might be more relevant. So, if you don't accept all of the patches in a series, maybe there is going to be some issue there. Of course, most people don't necessarily use the cover letter for a merge and only apply the patch as a series. So, it's also less annoying for the simple reason that it probably wouldn't exist in the git history at all. Anyway, the discourage mindless use might be as simple as a big warning message may just be adding annoying overhead. In contrast, a perfect model might be to actually have some kind of automation of unless there was an actual discussion about it. But I feel such a model might be too complicated. Unless somebody wants to explore using AI because their job description says look for actual useful AI usage in today's tech world. I assume such job descriptions do exist. I have a feeling that Lionus is maybe not the biggest fan of a lot of the uses for AI. Now, when it comes to other useful links, linking out to the Linux kernel Bugzilla or some other sort of discussion where there's some context around why this is a thing that is being addressed, that is useful even if it doesn't directly explain why this change is being made. It provides you context around why the change is being made. For example, since B4 ends up looking through the downstream thread of a patch anyway in order to add act by lines etc. I do think that in theory there could be some there was a lively discussion about this particular patch. So a link is actually worth it heruristic in theory. Now is this going to work in practice? You'd kind of have to go and do so to really find out but in theory AI could make this happen. And honestly, even if the discussion ends up being worthless, I do suspect I would be a lot less annoyed by a link that at least leads to some thread and not just the act by emails that already got gathered up rather than just leading to an email that was applied and nobody really had any input on. At least at that point, I'd feel like there's something there. And yes, as always, I realize that people think that PAT submissions will get more email replies at some hypothetical later date, but in practice that seldom happens because the downstream testing issues typically create new threads, not replies to original emails. And if they do react to the original email, we can already look up the commit easily and the lookup goes the other way. Anyway, now honestly, in most cases, what happens is if it doesn't get discussion, people are focused on other things and just, you know, have better things to do. So, rarely rarely does something actually get discussion after those maybe first couple of days. And if it is after those first couple of days, it's usually already got a lot of feedback anyway. Now, as a side note from Sash 11, the Nvidia engineer who is working on AI tooling in the kernel, they have something else that is being worked on. I'm facing a similar challenge both for the auto cell and the CVE work. There is very little historical context in most commits and the link tag is almost always useless and just points to the final submission of a patch rather than a relevant discussion around that code. I ended up creating an AI agent that knows how to dig through both a local git repo as well as our mailing list and knows to search related dashboards like kernelci lkft and sysbot dashboard etc. I'm not sure if at its current form it's useful to anyone else but here's an example of what it generates on the patch in question. So you have basically this timeline of all of the times the commit was actually talked about. This is kind of the idea of what Lionus is talking about. And this actually does provide some level of value, assuming it's connecting the correct things together. Now, this might seem like an overreaction by Lionus. Who cares about random little link tags? And I I get it, right? But remember, Lionus is not doing major development at this point. So when there are issues with the pipeline of reviewing patches of doing the management side this is the area where he's really going to get like personally bothered by it. There are other areas where he's going to be bothered by engineering standards and things like that but this is something which directly affects the work that he is doing every single day. So I get why he's annoyed by it even if it seems like a really small thing. So let me know your thoughts down below. Do you think this matters at all? Do you think Lionus is overreacting? Do you even understand what Lionus has an issue with? I'd love to know. So, if you like the video, go like the video. Go subscribe as well. And if you want to become one of these amazing people over here, check out the Patreon subscribe star liberop linked in the description down below. That's going to be it for me. And I don't know what I'm doing with the order of my outro here. My hand movements. Um, to vaults. Yeah, there you go. I just think these up on the spot in case you couldn't tell. >> Your best involve money then I don't accept. If it don't involve money, then I don't accept [Music] something like this. [Music]