 Thank you everybody for taking the time to come and to the webinar. Let's get started. I want to talk about this is an important aspect of communicating with the developer community, your maintainers, your other developers by explaining what a patch does. A couple of questions. I'll start kick off with a couple of questions. Let's do a little experiment here. Did you ever think I wish the commit log describes the change clearly? So raise your hand, we'll just do a quick little call before we get started. I'll give it a little bit of a time to do this poll and see. Kristen, do we have any count? We have two people that have raised their hands. Oh, there's a third. Okay. Now up to four. Anybody else? Okay, we'll move on to the next question. So how many people wish that the commit log includes a little bit of a background information, either to do a better review or be able to maintain it in the long run or even learn. For example, you are somebody is looking at a new sub system or a new area to learn how many of you think it would be helpful to have more background information. Another little poll here. All right. We have six, now seven, eight, almost, yeah, eight people, Siwa. Okay, eight people out of how many attendees? Out of 18. Okay, that's good, that's good. So how many of you thought, oh, I wish I wrote a better commit log. If I'm, you know, you're looking at it after six months or two years and you're going, okay, what did I write? So how many of you thought you wrote a better commit log to maintain your own code? All right, we have seven people. That's good, great. So the last question, I struggled with this one. I actually find problems when I started to describe my patches. So how many people think, did you ever find problems while you are writing a commit log and though, I could do this better and change the patch? I'll find a bug. We have seven people out of 19 now, Siwa. Okay, cool. Okay, okay, that's good, that's good. So that is really, all of these questions are in my head when I was talking about putting this presentation together and then I keep thinking about it. So we're on the right track, I think. At least 50% of us think that way. Okay, let's jump in now. And so the commit log, so this is hitting on the same themes, right? So a commit log, why do we even, why do we commit, commit log is needed in the first place? The reason is that we want to, like I said, you know, the last question you just answered, sometimes you do find problems as you're describing your change. So that means that step acts as a self-review before you send your code out to, for review by others. And then for reviewers, like anybody reviewing the code, it gives them a context about the change, more specifically what, why, and how, right? And another thing that I think that we sometimes don't think about is it's a permanent record. It serves as a document that gets added to the code base. Essentially, it goes with the code change and then the description of what changed goes in there. And then for maintainers and developers, it becomes easier to maintain, especially you are looking at debugging a problem in an area and you're looking at, so how does this, what happened? Why did this change get made? And what is the reason for this change? Understanding that helps fixing a problem or adding new feature or new enhancement, understanding that. So it makes it easier in the long run to maintain. A well-understood change can be maintained better. For new developers, this is kind of the mentoring aspect of, or teaching aspect of it, that if you have a good documentation that goes with the code change, then somebody new coming in can understand it better. They can use that as a tool to learn the evolution of a subsystem or a feature and generally learning the code, the comets that went into that subsystem are a piece of code. So what's in it for all of us, for you and everybody? It's easier to get your page patch accepted because what happens is if you were to write, that is the first connection for a lot of us. We are making that first connection if you are a new developer, or if you are playing in a new subsystem, that's the first connection you're making with that community of developers. And then at that point, explaining what you're doing makes it easier for your patch getting accepted. And then also in the long run, maintain it. And like we said, it's also a good learning tool. Hey, Shua. I think we have a question from, I'm sorry to mispronounce the name here, but Iwa Wynman, you have your hand raised. Okay, go ahead. No, I didn't have a question. I just had a procedural thing with my password, so that's nothing. Okay, no problem at all. Thanks, Shua. Okay, no problem. Okay, let's go ahead. So there are some things that we follow when we write the commit logs. So a few things. You use the language. It's an imperative sentences that you're, it reads like a request. It's a grammatical term, imperative sentences. Seems like you're asking, requesting a change to the code base. So you would say add XYZ feature, fix XYZ bug. And then you would write a concise subject. There's two parts to it, right? Commit logs. You have the subject short summary and followed by a description. You'll write a short concise subject line that doesn't, these subject lines don't end with the period. You spell check, of course. And then describe what is being fixed, changed, added, and why not. And how is, this is what and why, right? And then how is, if you do think that that adds value to understand the change. It's not like, not a description of the code itself. You are talking about more of the design effects and how the change fits into the rest of the code in the rest of the code in there. So that's what you're talking about. And then include any supporting information. Like, for example, you ran a, you found a compiler warning. So you want to, as you're compiling, it's a compiler to find a warning. So you include that compiler warning and then you describe how it's being fixed. Same thing with all the other things. Spars, match, catch check, panic messages, and so on. So any supporting information. And they explain, if you have any information, you think that it's valuable. The, some of these spars and even compiler warning students will be very cryptic. So if you've figured out a why, why this, whether the compiler warning is valid itself and any background information that you can provide, that'll be very valuable for others. If applicable, add a commit tag. We do that in the Linux kernel for sure. We have a fixus tag that references the commit you're fixing. So what that does is that helps you go back and look at that commit and say, okay, this is the right fix for that particular, the problem that particular commit has or, or introduced or maybe included in the, in the first place. So my reference is, I gave you my reference to this. I refer to this when I'm looking at, I have learned from this resource. Take a look at this resource. This resource, the great resource for, explains all of the things, commit log. So now any questions before I, I'm going to go, going to switch gears here. I'm going to the mode of actual analysis of some of the comments. We'll look at, I just looked at a few comments. I picked some, a few comments at random. From the recent commits from the kernel. And so we can look at them and see how, some of them, how we can improve what we can learn from them. How, what are the elements in each of those, come it's logs, actually. Now we're not looking at code. We're just looking at the logs. So any questions before that? Yeah, looks like we have a question. Yeah, looks like we have a question. Shua, go ahead, Nander. You can. Thank you. Yeah, one question. I haven't been able to commit logs or messages. We said, sometimes if the commit logs becomes too long, let's say, I mean, I have some discussions around with some other developers and some other developers in the idea that, you know, you can put their commit messages, whatever, it doesn't matter. It's better to be more than less. That's true. But my, my view is that it's better to be exactly what it needs to be, not more, not less. Because sometimes I guess people when they open a commit message and there is a long message, they usually try to skip reading all of it. Thank you. So that is correct. I struggle with that as well. So how long is too long? I don't have an answer for that. Clear answer depends on the commit, right? Sometimes you have a panic information that you want to include. It is going to be long, right? Because so I wouldn't, so what I would say is if you're adding valuable information to it, more is not, being concise is important, right? That's what we say, not just subject lines. I didn't add that, but not just subject lines. Even the commit log itself need to be concise to convey everything. So that's the first thing. You are absolutely right. If it's very long, I don't know what is very long, how to set that limit. But if it's very long, yes, people will like know that. Does that answer your question? Yeah, yeah. More like I am referring exactly to not valuable necessarily information. But yes, that's, I just wanted to see what other opinions are about this. Thank you. And Shuo, we've got a question in the chat. If you could post the get links in the chat or I can go ahead and do that. Let's see. For this, for the reference I put in or just the comment. Let's see here. I think the reference link that you have on that slide is what people are looking for. Okay. Thank you, Megan. Thanks, Shuo. Okay, let me find the chat window. I found it. You got it. Okay. Yeah. There you go. We got it. Thank you so much. Okay, so any other questions before we switch into to the next one? Nope, looks like we're good. Okay. So they, let's look at this comment. I'm going to post the link in the window. And let me know if you could all pull it up. This is the, this is the comment that recent comment I looked at. And it is to, to the, just the conversation we had a little, a little while ago about how long it's too long coming. It is a long comment. However, I think that this commit log talks a lot about starts with the disc, describing this lock. And then it talks about what its current state is. And if you scroll down, yes, it gives you lots of information here. And then it talks about fix this by this section here. It talks about why it is, how, why this is being fixed. And then it talks about fix this by this section here. It talks about why it is, how, why this is being fixed to this way. So two aspects to this, I'm going to switch back here. It describes how the lock works and what it does. So for that, it helps the current reviewers, maintainers and new developers as well. In that aspect, it's helping the maintenance angle and then also review angle. And then as well as for anybody new developers long wanting to learn, it does, it gives you enough background information. So it also tells you what is wrong with the current core and how it fails. If you looked at this example here, it talks about the failure mode of this because it's giving you with the examples from the command line examples on how it's failing. And it includes the fixed details. If you looked at it, it's a, and then, and it gives it out command output example for reviewers to go play with and see how reviewers and maintainers as well as new developers, for if they are learning this new area, they can go and say, Oh, okay, I can compare this output with this. And then how it's being fixed. So I thought this is the, this is this commit lock has all of the elements we want in helpful commit log. Any comments on this? Let's, let's open it up for comments on, on what your impressions of this commit log is. If you'd like to jump in, you can go ahead and unmute your microphone. Feel free to just jump in with your comments. And if you want to play with this, can you, can you post the Jamboard link at home? Yes. I am, let's see. It's the first link in the chat actually, but I will, I'm going to go ahead and do that again, just for anybody new here. Okay. There we go. Just add a sticky note and then put your comment there and we'll, on this commit. So we're going to use Jamboard for a, from, for the next analysis. Okay. Perfect. So I'm going to highlight this is the sticky note right here. You can just click on that and, you know, play with colors. Or you can ask chat questions in the chat or just speak. Perfect. All right. So. I will wait just a moment before I switch to the next one. If you want to share any thoughts on this particular commit. Log, I should say. Well, my opinion is that it's very well written from the point of view that he says the problem and why it was fixed like that. Great. Yeah, that's, that's my impression as well. Yeah. And because I guess everybody can see what you are doing in the, you know, commit other commit message. And it's really explained why you choose this option. And not any other options and things like that. And what was the problem because it's not necessarily from your changes, code changes that, you know, what was the problem. Right. Great. Yeah. That's exactly that's what I thought too. So that does describe any other thoughts. No. Okay. Okay. I'm going to the next one. So let me first give you the link in the chat. And then I will go there as well. So this is, this is a comment that addressed a sparse a message. And the one thing that when I was looking at this commit, one thing that jumped out at me is sparse messages themselves are somewhat cryptic at times. So this commit explains why the sparse sparse is complaining about it and goes into a little more details than just giving the sparse message, the actual warning and just say, Hey, I'm fixing this warning. That's one thing I really liked about this commit log that it is going one more step off. It would have been enough to just give the warning. And then here is the fix. It's going into a little more detail on why sparse is complaining about it in the first place. So you can apply that somebody looking at that can apply that as they are looking at their code and say, Hey, okay. This might be helpful if when I'm writing my own code. So in that aspect, I thought this is a this added value in added more instead of just giving just the first message. So let's talk about this. You can use the Jamboard to talk about what, what do you think of this or speak or chat. Oh, somebody is saying they can't see that. Oh, um, let's see here. I think I can go ahead and there is no chat. Here's the, um, the link that she was referencing. There we go. We're all set to a. Okay, great. Yeah. So any thoughts on this one is my analysis. Can you add any, would you like to add your thoughts on my analysis on this or my thoughts. Jamboard. Let's play with it. I'm looking to see some colors on the Jamboard. Yes. All right, I'm guessing there are no other thoughts. So I will move to the next comment. I'm opening this up and then I'm also going to put the link in the chat window. All right. So let's look at this one. Um, this is a tree wide change, actually, removing KZ3 compatibility definition. So when, um, this, this commit explains what happened here when, when a tree wide change, this commit, the first commit, this commit right here made a tree wide change. And then we left, um, compared a backward compatibility. We do that. Um, that's for backward compatibility. So, uh, however, uh, more instances of, um, case if begins popping up. So, Hey, let's go ahead and remove it. So we don't have to keep doing that. So, uh, this is this. Gives. Lots of information. For those who tells you which commit is the one where we changed this added. We made this change to right change. And then how that's leaving that definition, compatibility definition in there is leading us to go keep maintaining this over and over again and getting rid of it, what is the benefit of it. So it's, it has lots of information. And then if I wanted to go look at, I'm looking at, oh yeah, yeah, yeah, that happened. So let me go look at this three-wide change. And what are all the subsystems because it's going to tell us every single instance of change that was made and how wide the change has been. This is going to be very useful information in here. So comments on this and then anything you can, you wanna add to what I said? Well, again, the funny thing is that your examples are signed by Linus Torval. So it's very, it's very hard to find a bad one. Oh, well, so they are, they are, they are, I, okay. So I will, I will, we'll go into the ones that probably can be improved in a little bit. I'm starting off with positive news, you know. Well, that's a, that's a really strong hint that they are written well, right? Yes, so, all right. So let's look at, I'm going to switch gears here. Let's, let's look at this probably is a good one that could generate, let's look at this one. So share your thoughts with me on this. When you read that, what does it tell you either a comment or you can use the Jamboard. Oh, there is something in the Jamboard. Somebody did. Oh, it's just me, Shua. Oh, okay. So my desire to see some colors, thanks, Mika. You're welcome. So, okay, so I will share my thoughts on this. I, if nobody else has questions, just say, you know. I can comment if your commit says add USB IDs and I see it in the div. But why does commit actually exist? Why do you have to add these IDs? Exactly. That's right. Yeah. Yes. So this is very use, I mean, maintainer knows what, maintainers know what this exactly means. And the commit log, somebody that wrote the commit log knows exactly what they're doing. This is, it really doesn't need anything else from the review, somebody that knows the subsystem. The one thing though, it does not tell you what that means to somebody that is trying to figure out what's happening. You're absolutely right. It doesn't tell you more. That it would be nice to even to just say probably a little bit, add a little bit more saying what it's doing is that it's adding support for this card, right? So we can figure that out. But if you know the subsystem and if you look at the code, you can see that it's adding that particular card support to this driver. But it would be nice to summarize that. Would be helpful. This is actually, go ahead. Sorry, this is actually a good example of at which level you write the information in this coming message. Because, okay, this basically only adds support for different USB card and it's exactly like you said, you know, the people that they are needing, let's put it this way. This information knows, they do know how to read it. And if you put more information here, like, you know, a card to be recognized by the USB subsystems needs to be able to have this information about the IDs. Therefore, we add the USB IDs for the ceiling MPL 200 card. So, you know, if you say like that, some people may see, let's say, what I said is it's not very long. It does explain, let's say, why those IDs are needed there. But then again, for people which are actually using this and modify this, they know exactly what this is. Exactly, yeah. So, the question might come up, well, why are you stating the obvious? Right? So that's kind of what you're saying. Yeah, yeah, exactly. So that's why I kind of picked this comment because I thought that the audience for this information is reviewers that know the subsystem well, maintainers that know subsystem well and understand the underlying code. And we also have to worry about new developers or new people new. And then let's not forget the user community itself. So, a user is going and looking at this, saying, hey, does this particular release support? This is my card, right? So, it doesn't have to give a lot of information. It could be probably enhanced a teeny bit by saying add support instead of USB IDs. It could just say support, maybe. That's my thought. I thought, how can you communicate without adding too much? Not sounding obvious. And then also, it's a kind of a thought exercise for us to figure out. You're absolutely right. This is, in this case, if you wrote three paragraphs, right? That could just turn off reviewers and maintainers. Oh, looks like we have another question here, Shua. All right. Go ahead. There is, I have a chat here but I'm not seeing the question. Where is the call? Let's see, they have their hand raised. It's agile? Yeah. So, actually, I just want to know whether we really care about the standard while we are committing. For example, USB, when we are seeing here, it's in a small letters even in the comments or the description level. But usually as a standard we use in SCAPs. So, that kind of details whether we look into while we're committing or it's just only the ideas which care about. So, yes, you can, so you're saying you can, yeah, this is a small change really. So, that's why you are seeing the whole thing. But if you run, so I don't know if I follow your question. I'm sorry, could you? Okay, I'll be reframing it. For example, in a standard, if you are talking about USB, we will be put everything in CAPS like universal serial bus is not in the small letters. So, if you see the commit and add USB IDs, if you specifically see, it's in a small letter. So, that kind of level, whether we really care in the kernel commits or like it's just only the idea whether it is always communicated. Does that make sense or should I explain it in detail? Yeah, don't know if I... I understood the question in a way. So, I mean, of course, when we write the commit message, it's very good to write the correct way the acronyms and everything that represents something so grammatically correct and things like that because... So, in this situation, USB, it will be advisable to be in CAPS, in my opinion as well. Oh, I see. But that's not necessarily, you know, and I guess that's from case to case, acceptable by some maintainers or somebody else will comment that you should change it and so on. But I guess, you know, the main point here is to make yourself understandable and then to use dramatically and from the acronyms point of view, correctly, the message. Yeah, that's true. Did that answer your question, earlier question? Is that... Ah, yes. Actually, I just wanted to know what you would stand on, like if, for example, some contributor has given something like this, whether it will be a reject bag or something saying that you have to use the correct acronyms or something like that or... No, no, so the maintainer or some reviewers, my suggest changes to the commit log and say, hey, can you explain it better? But I don't think the commit itself would be rejected just based on the commit log. No, that doesn't happen. Is commit logs also get reviewed in some sense? Because if a reviewer or a maintainer, they don't understand the commit, there seem to be a few things to look for, right? As if you're reviewing or you're a maintainer or just a reviewer, you have to see if the commit log is talking about the change that's actually being made. So if there is a disconnect between the commit log and then the change itself, then that would be, you would ask for a change, right? So did you really intend to make this change or your commit log and change don't seem to go together? That's one thing. And then this commit log, there is nothing absolutely wrong with this commit log. I mean, this is a good commit log. It depends on whether it's giving information to all parties involved. So that's where I would say maybe a little bit more helpful saying it adding. It is adding support for this card would have been a probably communicated better to a new developer or a new somebody user looking at, do I have support for my card? So to answer your question, writing a bad commit log doesn't mean that commits don't get rejected for writing a, based on the commit log, put it this way, code is what we look at, right? So it's just that you want to look at your code, explaining the change you're making will be helpful for reviewers. Any other thoughts on that? Go ahead. Thank you. Okay. Shua, it looks like you just have a few chat comments in the chat. I'm seeing that. Okay. In my opinion, nothing is wrong with this. You need a commit message anyways, and this one is short enough that's quite concise without being ridiculously concise. Yes, absolutely. There is nothing really wrong with this commit log. This is an example of a commit log, how it speaks to different audiences. So that's one of the reasons I picked that, this commit log, because it makes perfect sense to, we talked about this, I think, that reviewers and maintainers involved, however it might not give you, give you enough information, somebody knew that's looking at this or a user looking at this commit log to see if they have support, this driver support they're called. Perfect. And one more chat, it looks like, one more comment in the chat for you, Shua. Right. All right. This commit message seems to imply that just adding these IDs is enough to support the new card. No more code had to be written for that. Yes, that is true. That's what it's saying. Yeah. So from the angle of somebody go, somebody, yes, it is telling you just adding the USB ID itself is enough to add support for this card. That's what it's saying. It's not spelling it out clearly, but that's what it says. Any more thoughts on this? No, I think we're good. Okay, let's look at this one. Share thoughts on this one. Also, think about it from all different angles of how many, who will look, when this patch comes in, right? It's in the, it's committed now into the base, but when you are looking at this commit and you're looking at trying to figure out what changes went in, what, how can you improve this if it needs improvement? No questions, you are. No questions, okay. Well, I can say my opinion. Okay. All right. That's okay. So, to me also this one says some things, but the only thing which in my opinion could be proved is that, why do we need multiple AVMs or support for multiple AVMs and in which case those are needed? Of course, again, this might be perfectly okay for the people that understand the subsystem, but not okay for other people which they don't understand what is this? Absolutely. I think that's, and then I have a comment from in the chat saying it's missing the how and you're right. So that's what you're saying that it's missing how and background information. So yes, there is, this is perfectly good if you understand the context. However, for somebody new or somebody that isn't as familiar with this what AVM is or in a particular feature on how it's implemented, it'll be for them understanding how it will take longer. There is not, they will have a little more lead time in trying to understand what this change does or what happens. Any other comments? No, looks like we're good. Let's see how I'm passing through and let's see which one is, and let's look at this one and then let me give you the link to it. Sorry about that. And after this I'll open up for, let's open up for open discussion so we can share thoughts, not specific to comments. So yeah, just go ahead and give it a read and then post comments in Jambold or chat. Any thoughts on this one? Well, it says the problem though that doesn't say how it does fix this. Right, that's right. Yeah, so it talks about the problem itself and return values and then what happens because it identifies the problem. It's telling us what it's doing. One thing I thought was maybe it would be helpful to say, it explains what and how and I'm not clear on, I would say what would be, what is, how it changes the behavior in terms of what is the correct return value in this case or what would happen. What, it's a little more background might have been helpful but this explains a lot of things here. It does talk about and then it also gives you information on the comments it's fixing as well. So in all respects it's good. Any other thoughts on this? This seems to be a common line utility and it would help to describe what the user would experience if it continues to misbehave until this fix arrived. Ah, yes, that is a good point. That is absolutely good point, yes. Shua, it looks like there's an additional comment in the chat for you. Right, it is good to see the additional link in the comment for more detail explanation that might not include in the comment due to the size. Ah, yes, absolutely. Oh, yeah, thanks. Thanks for Jahuma memory on that link. So it does have a link to the discussion that happened and then also it would be good to see probably a link to a bug if a bug was reported on this particular problem that would give us more context around what is fixed. So some commit logs do include bug reports so which would be helpful having that. Is that, I think that's the question. Did I answer that question? Did you get your answer? I think that's your comment there. Were you all set? Okay, sorry, yeah, go ahead. Just ask the question or type again. Looks like he just said it was a comment so looks like he's good. Okay, go ahead, you're good. Okay, good, good. Okay, so there is one more. How are we doing on time, Kristen? Time check. Yeah, we have about 45 minutes left. Okay, good. Yes. So let's look at this one right here. This one, just comment here. We can take a look at this one and then see, share your thoughts on this one. Do you wanna share the link? Oh, so sorry, thank you. Don't worry. Thanks for prompting. Of course, no worries. Okay. All right, there you go. Thank you. The thoughts on this one. Okay, my opinion, you know, I mean, it will be very good to explain why this is not allowed and to have background information why this is a problem in the first place. And then also, to me, it will be important to understand why if we fetch it earlier fixes the problem. So we don't have background information to decide why this fixes it's good enough already. At least what I'm seeing here. Yeah, I'm typing your question answer in the sticky notes. Another thing I thought, another observation I made when I was looking at it, I don't see the, it would be helpful to probably see the error itself. So that would have been helpful as well to see the raw log. So use after free that it's fixing use after free message warn. The nature of use after free prevents seeing any good error or anything that could go wrong after you access memory, which probably used somewhere else. So for me, this message seems fine. It fixes some it's very simple fix which avoids a very complex effects if it's not fixed. Right. So, right, it would be probably helpful to see the stack trace. So, and then actual message itself, but yes, this is a, not all of them include that information. And a link to it might be helpful as well, just a link to the bug reporting in this particular case for background information. Right. All right. So, I have wanna open this up for discussion on we have time for an open discussion if you want to share your thoughts. Well, I've seen a lot of, in Linux kernel, you will have hard time to find a bad commit message. But in my experience, in other companies, I've seen a lot of bad messages like fix bug, what bug that doesn't really fix it and fix build, for example, which build was failing. It probably would help if you showed some bad commits, but it will be hard to find. And I can only think of proprietary software, which I cannot share in this chat. Okay. Yeah. So, yes, it is hard to find, so it's hard to find a bad commit, of course, in the kernel. What we are really looking for is, I am looking more at the angle of, does it meet all of the needs of all of the people, right? So, in some cases, the commit probably doesn't include the information for a new developer. Or, and so we are looking at it from a little bit different angle than just a bad commit, I would say. In general, because of the way the reviews happen, it is hard to find bad commits really in the kernel. You're right. I am trying to approach from a different angle that will the commit message useful for maintaining in the long run and then also teaching or learning, using that as a learning tool if you were to learn. So, any other comments? Could you suggest some automatic tools which would check commit messages and serve as a hook to a decline pull request, for example, if commit messages to shorter? So, there are, the kernel has the check patch tool that does checking on the commit logs as well. If you were to turn on, we talked about spell check, right? So, and then it looks at if your commit, so unfortunately it won't tell you what's missing, right? So, in the information, like for example, if we have one we looked at which had the commit information in there, like this one. So, if this commit, if this does not, this commit description isn't correct, it'll tell you and check and tell you, yeah, you didn't do that right. Or a fixer's tag is not correctly specified in the commit log. But it can't tell you what's missing, right? It's very, we are seeing that it's subjective commit logs itself. We looked at this commit that speaks to everybody, yeah, this one right here. And then this one right here that we thought, well, this is where the subjective nature of the analysis comes in. So, can that be automated? Some of the things can be automated. Obviously, spell checking can be automated, right? And then also whether it fits in the format, commit log, when you are referencing a particular commit, does it really give that information? Before we commit into the kernel, a particular patch, we check for whether the commit log is referencing the valid commit that's already in the code base and fixer's tag is referencing the valid commit that has to be in the code base. It will reject that based on that. There are a few things we do check, like for example, does the author match the signed off correctly, and so on. However, there is a subjective nature of the text itself that will be hard to automate. So the short answer is I can't, I don't know of any other tool than the check patch. And then there is a few other things we use in the kernel development process, whereas verifying signatures, verifying fixes, and so on that we look for, whether that fix is the SHA commit ID is already in the base, or the signed off are in good state. Well, in some situation, I saw repos that they use hooks for validating at least the format of the code message. You know, like usually in some repos that you require to have, which component did you touch in the subject line and then explain and have a subject line. So it needs to be that format. So yeah, it works, could be one way to validate this. Okay, yeah, I didn't know that. So does it say that if you are referencing a sub-system in the subject line, but that doesn't seem to be the fix, does it flag that? Is that? It will reject, well, I mean, for example, if you use other tools like BitPocket and so on, you can configure so that it will reject a full request. So you will need to fix that beforehand. And, you know, so yeah. That's awesome. Yeah, so do you have any links on, a link that you can share on the chat to, for now? Not unfortunately. Okay. So that's actually good. So that can, that again, more enhanced in terms of checking. It goes into checking and checking to see that the commit is context of the commit. Like, for example, you know, your commit, what you're saying you're fixing is what you're actually fixing kind of thing. But some of the subjective stuff, I'm not sure. Like for example, if you were to suggest recommendations on this particular commit saying, hey, what can you, what more can you add? Or maybe this one right here saying, hey, not that one. I'm sorry, the DRM one that we were looking at earlier with the, how and how, we thought that how is missing, this one right here. So that one, it's subjective, right? It's, then it would be difficult for a automated tool to do that. At least I don't know of any automated tools to do that. It will look like there's a comment in the chat and I just reposted it for everyone to see, but just wanted to direct that attention to you. Okay. So that's, thanks for the hint on check batch thing. Yes. It is a very elaborate script. It does multiple things. It will, there are multiple options. It has a spell check option too. So if you want to spell check your, it's a code check, code spell check option. That means that it can even go, if you added a comment and then you made a typo in the comment, it will check, it will go and check for that. And then in addition to that, it'll flag some issues, some problems like the code itself. It'll validate, it'll tell you what is wrong in any of the code that you're doing based on the coding guidelines for Linux. So it is a very useful tool to run. I do run it. It's developed, kernel developers use this a lot to verify your code during stages. And then I use it when I'm committing. I don't check patch on the patch as I'm committing to the code. For the spell check, I personally have my git configured so that the editor eats beam and the spelling it's automatically enabled when I'm writing a patch commit message. Right. So that happens already when I'm writing in real life. Right. I do the same. When you're committing, this can be very helpful when you're committing patches and then verifying them, one final run. Especially for me when I am writing cover letters, I tend to use that feature because cover letters for a patch series, they don't go into the commit. So that's another thing to look at. These cover letters is another thing that we write when you are doing a patch series. And then when you are doing that, that cover letters are very important when especially if you have multiple patches in your series explaining what you're doing. So that aspect I haven't touched on in this. And then talking about that, one more thing is when you are sending, when you are sending a revision, right? You have gotten comments on your version, one of the patch or two of the patch, then you would talk about making things easier for reviewers. You will be saying what you changed, what you addressed in your version one to version two. That information does not go into the commit log itself for the Cardinal, as for the Cardinal guideline. Where it'll go, some people include that, but where it'll go is right before the diff stack. If that information is valuable, then to be part of the commit log, the way you would do that is you would write it such that it's not a version one to version two, but you would say that if you consider another design, if it's a big enough thing to be included in the commit log, it's not like it's real fixes, then you would include that as a alternative or a design consideration. Or another way that version one fixed versus as it evolved during the reviews. So any thoughts on that one? So if you are sending Cardinal patch, it's something to keep that in mind, where that revision changes, patch revision, what changed between revisions. So what else? I'm hearing silence, no other comments? Anybody want to share any other thoughts? Well, I saw in some of the, for example, when you're talking only about, a patch set that contains only one patch, and in some of the repositories, for example, I'm going to correct you with repositories, it's so that they do recommend to write this information in the node sections of a patch, which means that it's not visible in the commit message, but it's visible in the patch itself. Just not to send a cover letter for one patch series. Absolutely, yes. Yeah, you do not need a cover letter if it's a single patch, absolutely. If it is multiple patches that you are sending, then you would talk about what the patch series are. It could be a feature that has a multiple patches in a series, or it could be a set of fixes, for example, you might find several fixes and you want to group them together just for review purposes, not necessarily that they are dependent on each other. In general, patch series, they are dependent on each other, but not always. Sometimes somebody might group several fixes in a patch series so that they get reviewed together. So the node section that you're talking about, is that something similar to what we do in the kernel where we add version changes between the diff lines? Like a good example is like diff stat goes down here and then we add it right between the signed off and diff stat. They get thrown away. Yes. Okay. So it looks like you have a label for that in your boot for you, that you use. If you have a link, just share it and then I'll show, I'll open in that up. Let me find this, see who I'm if I have. So it sounds like it's similar. We don't have a formal way. What we do is we say version one, version two, we do the changes that, talk about changes since, we say changes since we run, since we too, and it could go up to several levels. Well, it's the same here. You just, you know, the format is the same. You just put it in a different place, not in the cover. Right. So yes, the nature of the kernel patches is that since we take them, we take patches, we get patches on a mailing list. We came up with certain formatting type things to communicate different things. Like, you know, if you have a, if you're using a, another review process, a different kind, different review process than GitHub review process or Gerrit is another one that I have used in the past. You could have more mechanisms to communicate the same information. So yeah. So any other thoughts? I'm, you know, I didn't include a whole lot of comments. We can look at more comments, but any other discussion, this is a good discussion. We're talking about patch series and any questions you might have in general, any kernel development in terms of patches, patch process, development process that you may have that's relevant, that is relevant to this discussion here. I have a question. So as far as I know, the kernel side development mostly go through the emails or plain test emails where we send the patches. Is it still same or we have any pull request kind of things similar to GitHub or Bitbucket or planning to implement? Right, sorry. Yeah, it is still email based. Okay, so it will be like continue with the email based itself, right? Correct. For now, that's how it is. And then that's what we are using currently. Okay, okay, yeah. Thank you. And another thing to note is even the bug reports, bug reports also reports as well, follow through emails at the moment, all the get pull requests that go from maintainers to sub-maintenors to maintainers and so on. They are also plain text. Okay. So is there any, really, is there any PRs or is there just a different send it as a patch? Say that again, I'm sorry. I didn't follow. Okay, so in GitHub or Bitbucket where we used to date, there is a PR pull request exactly as it is pull request but here it is like more like a patch sending. Is it like really a PR or? Ah, no, what we do is we actually say, the pull request process is a little more involved than the sending a patch to the patch, right? So what we do is if I am sending a pull request up, what I would do is I would do a, I would tag, I would sign the commit, the top commit that I want to be included, and then the commit from the range, right? The top one, I would tag it and then I would sign it, then upload it to the kernel.org. Yeah, let me go and show that to you. I can show you the get. So we signed those, we, those are signed commits. So let's see, where is my get? I'm going to find myself because I did send it pull request recently. So this is what you will see. This is the pull request that goes in. So I would sign it and then I would include, this is the one that tells what is included in this pull request, and then good pull request, it will include that. So does that answer your question? Is it all signed pull request? Yes, that sounds great. Actually, the thing is like, I seen many people are telling like PR and we can hook up the things and automate, but I was confused like how really a kernel sending mails can be hooked up to an automated system. That's why I asked. So we have some more tools now, two before tool set that can pull patch bundles to apply and it will include the links, any links, discussion links and such. We are automating some of the process in terms of how you could pull a bundle, patch bundle or batch series to apply. But however we are not, we haven't, it's still email-based. There is some automation tool, automation happening to make life easier for maintainers and then developers in terms of sub-mining, maintainers sending a pull request and maintainers themselves pulling stuff from patchwork. So patchwork, if you haven't looked at patchwork, patchwork, it will be, we all have a lot of the, I think patchwork.org, okay. Let me actually, it'll be kernel.org. So you will see different patches, right? So you can review, no, that one, the sub-system doesn't seem to, maybe I'll go to mine again. So if you look at these patches, this is the patchwork project, right? So you could download, using a before tool, you could download bundles from here, automated command line. And then you can do reviews, for example, here if you want to do a easier way to review the patches. Oh yes, this is a good example. This one is going from, you'll see the changes, right? So can you see these changes? Let me make this, you want me to make this bigger a bit. So you will see this patch, this series has gone through 21. So even includes changes from V13 here, all the way to V21. That's where we seem to be right now, patch series version. So not all patch series will go through these divisions, but this is, this patch series is adding a lot of things. It's adding system calls, ptrace hook, file system. This is doing, it is a little more involved patch series. That's why you're seeing that. So this is where, this is what I was referring to, where the changes, like you're talking about, you would comment about note. So this is where we do the change revision information. So I think we, yeah, does that answer your question about the assigned tags and pull requests? Yes, yes, yeah, thank you. And then you will, I can show you a pull request that I would have sent, I think I have that here. Yeah, so that's how full requests funnel through the, to between sub-maintenors and maintainers and so on. Oh, okay, I have, thanks for the link. Let me see if I can open that stuff. This is, oh, okay, okay. So do you want to talk to this now that I have it open? I believe that's Unander that sent that link. Yeah. Yes, yeah, so this is the example with the, yeah, sorry, I was just going with my daughter. Boy. Okay, so this is the example like, you know, I mean, you do describe after the sign off and after this, the limiter. So this information will not be present basically in the commit message once this commit will be accepted, the description and testing and so on. Oh yeah, so similarly, similar to the, if I showed you all of that, anything below this line gets thrown away. Yeah, exactly, yes. So don't you think that this testing information is relevant to the commit though? Yeah, that's another thing I forgot to mention. That's another information, good information to include in a commit log, which is what kind of testing was done. But yeah, so it looks like in this particular case, this is a throw away information. Yeah, well, in this situation, well, you can always, I mean, there is a reason why the, you know, you would cannot use this mailing list for patch, for sending patches and so on, because as if I called somebody and I guess it was Craig mentioned that they, these are written in stone basically. So you can always go back from a commit from a commit to see the, in the mailing list, what exactly was discussed there and so on. Exactly, I guess exactly the same thing here. So the information itself, it's not necessarily lost. It's not in the commit message. And but if somebody needs to know what happened, they can go back and somewhere digging this information up. But this is exactly the information of the format which I usually use for a cover letter. And in this example, since it was only one patch, I put all that information in the section of the commit. Yeah, yes. Yeah, this is, so in the case of cardinal patches, so this anything, this information gets lost. So what I usually do is when I have a testing information that is relevant and adds to the review and then also information, I usually include the testing information in there, in the commit log. I, that's one thing I missed when I was talking about what should be included in the commit log. So something just keep in mind, yeah. So I, so when I said the supporting information, I didn't call out testing. Yeah, testing is again another supporting information that can give more context to work. And then that can generate discussion. Somebody could come and say, hey, oh yeah, okay, you tested this part. Did you test this? Or could you run this test? So that kind of generates a discussion that would be valuable as well. And then if somebody else coming along and then fixing something in the same area, they will have a commit log to look at and say, oh, the previous commit tested all of these. Let me make sure I test those as well. So having this information is very useful. Thanks for sharing this link. This shows a different, I mean, what you are doing and which is similar to what we do. We're just doing it in different ways, different format. No problem. All right. So any thoughts? I'm sorry, Shua. We actually just have 10 minutes left. So probably want to do a last call and then be sure you share your resources for everyone as well. Okay, great. Yeah, let's do that. I will, I think I am, yeah, just the last call for one question or one or two questions and then I can show you, we'll conclude it. Looks like we just have one question in the slide and the chat about the slides being made available. Go right ahead, Shua. Yes, yes. We can make the slides available. Yeah, definitely. So another thing we can do, Kristen, if we can share, if we can save the chat, maybe some of the answers that are, that during the discussion, we had discussion so we can include more resources like the Reuboot resource here, that will be another resource to include as well. So I can pull some answers and discussion as well into the slide set, add one more slide with all of that and then I can make the slides available. Perfect, okay, that's great. And just want to remind everyone as well, this session will be, it's being recorded and will be posted to the Linux Foundation YouTube channel as well. So you'll be able to reference in there. Looks like I have a question here. Yeah. Outside adding tests that was run during the comments as Nander did in the link you shared, is there any other thing that is important? Trying to think. We covered what, why and how. We talked about how it's supporting, adding supporting information is important in terms of description of the bug or link to the bug or a previous commit that's being fixed or a reference to a commit that added a feature that we are working on and fixes and testing information, test results. In some cases, what I have done is when I was doing a more involved feature that span multiple subsystems and multiple drivers, I had a test plan that I wrote for my own sanity. And then I included the link to the test plan in the comment. You have to make sure that of course the limit, the commit link you are giving is a permanent link. So that's the tricky part. But I include that other than that, I cannot think of anything. But if you can think of something, just chime in. But in my opinion, it's always boiling down first thing, which when I'm writing a commit message, I'm starting to think, who am I targeting? So if it is the maintainer of that domain, then of course you don't need to write it. I mean, you already know from the start that some of the things are already clear, not necessarily included. If you are expanding your range, so it's not only the maintainer, but other people as well. So then you decide that other information, it's relevant or that can be used by somebody else who doesn't have so good background in this area that they will understand what happens. Just the rule of thumb, what do you check when you write the commit message? And then of course, what was mentioned here about the why, how, and the testing. And basically in the end, all the relevant information that can be used to understand better what happened. So absolutely, that is one of the reasons. I, you know, that's one of the reasons I thought this webinar would be useful. This topic is useful because sometimes we think about, hey, it makes perfect sense in my head, I'm going to write it, and it makes perfect sense to reviewers and maintainers you always work with because you know the context. However, another thing to think about is how do we make this? So you might not be maintaining this five years from down the road, right? Somebody else might be maintaining this, right? Then what happens, can they understand it? How do you attract new people coming in and they don't feel lost? Can you, if you can give a little more information in the commit log, keeping others in the perspective than though these commit logs can serve more purpose than, they will serve a larger purpose than just communicating the change. So I think you described it very well. That's one of the reasons I picked this topic as a topic to talk about. All right, so with that, thank you very much for joining us today. And I hope that this is helpful to you and at least you'll understand, you'll get some context on what maintainers and reviewers look for and then also what would be helpful for you in the long run, even if you have to go and fix and maintain that area. In addition to that, I'll leave you with resources, additional resources. And we have LF at Linux Foundation, we have mentoring programs designed to help new developers with necessary skills and resources to experiment and learn, contribute effectively. And we have several projects currently. We have 88 projects active right now and 129 or 130 mentees are going through learning actively right now. And then in addition to that, Outreach has been a remote internship program that is run and Outreach supports diversity in open source. And then they span several projects, several open source projects, they span, I'm sorry, I cannot think of all the projects, they support lots of different projects. And then they have internship programs as well. And then the next foundation training, I have gave a link here. We have a free courses and webinars, tutorials for self-learning. And also events, we are doing things like this, we are bringing webinars like this one. And we also have a lot of other webinars that we're going to talk about and we are bringing webinars like this one. And the next foundation events are always a great resource for learning. And we are focusing on structured and unstructured learning. And this is part of our unstructured learning in addition to the structured programs like LF mentoring, Outreach that is also structured free programs. And then please make use of all of these resources for self-study. And I hope this webinar has been helpful. And thank you for attending. Thank you so much. Bye. Bye. Thank you everyone. Thank you. Bye. Thank you. Thank you. See you in Dublin next year. Yes, we'll see you there.