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


Some of you in here may never see me again, so I'm gonna ask you to remember two words for the rest of your life. I'm just asking you to remember two words until you die. Attack life. Act life. Get after it every day of your life. Be aggressive with everything that is good. And with that same advice for two and a half days give me 100% and attack this competition. Get ready. Get set. Go. 2022 West Virginia Army National Guard best warrior non-commissioned officer is Sergeant Jefferson R. Lane. Best warrior soldier is Specialist Kendall S. Harris. The 2022 West Virginia Air National Guard best warrior non-commissioned officer is Staff Sergeant Mark B. Jarrett. The best warrior airman is Senior Airman Jonathan C. Holmes. The 2022 District of Columbia Army National Guard best warrior non-commissioned officer is Staff Sergeant Romique N. Naval. The 2022 District of Columbia Army National Guard best warrior soldier is Specialist Michael Honor McGlenn.


episode of We Are Being Transformed, tonight's episode is especially awesome for me because I have a very amazing guest from a great channel that I've admired for a long time. Here at the show, in case you're not familiar, we explore the liminal spaces and contours of reality, the myriad of ways people interact with their world through the vehicles of ritual, cult, and lore. And our guest this evening is Dr. David Miano. Dr. David Miano is providing valuable public-facing scholarship via his YouTube channel, World of Antiquity, and his Patreon page. So without further ado, I will bring on our guest. So Dr. Miano, welcome to the show. How are you? I'm great. Thank you for having me on. It's the pleasure is all ours. And I just want to give my condolences to you. I'm sorry your recent date didn't go so well. Not everybody knows their past life in Atlantis, but none the less. For me, my latest short, yes. Yeah, the short. That was great. My latest comedy short. Yes. There will be more. It's going to be a kind of a running joke. Awesome. Awesome. I always love to put those on. So Dr. Miano, I'm sure a lot of people who are going to be watching this, whether now or in the future, are familiar with your channel, but just in case, if you could tell the audience briefly a little bit about your background. Well, I am an ancient historian. And that means I study ancient times. Has no reflection on my age, but... And I kind of came to it in a roundabout way. I wasn't initially going to do this. So I changed majors a few times in college. Finally, I decided on history. And then I was just going to do like maybe all European history or something like that. But I found out the older it was, the more interesting it was. So I liked it better. And I just got into ancient history. And why it fascinated me is because we have less to go on. We don't have as many documents. History is the study of writings. And if you don't have a lot of writings, then there's more room for guesswork and trying to sort things out and coming up with different ideas. So that always appealed to me. And I also like the times because they are more alien to us. We know less about them. So that's why I got into it. I got my PhD at the University of California, San Diego. And in those days, I studied mostly the history of the ancient Near East. But since then, through my teaching and also through my YouTube channel, I have expanded into just kind of general world history in ancient times. So I do all the countries and I really enjoy it because I like to compare and see who was doing what around the same time. Thank you for that answer. I guess I should tell you my channel name is called World of Antiquity. And you can see me make videos about ancient history over there. Right. It's a very valuable public facing form of scholarship. Like a lot of my guests, like Justin from Esoterica, Dr. Litwa from his channel, and their patriot, their respective patreons, you're doing something that I think is very important. The educational system seems to be shifting in the past few years. So I think a lot of people, it's more important now than ever that we have solid scholarship out there to counteract all the Graham Hancock stuff that's kind of going on. So I think what you're doing is very important. So thank you for that. Yes. Do you think he's probably the biggest name now, wouldn't you say, in the alternative history? Is he bigger than George O'Zuckalos or I don't know. I would assume so. I see a lot of I don't really pay attention to my son and I like to watch ancient aliens every now and then just to kind of get a chuckle. But George will always be my alternative history scholar. But I think Graham Hancock is kind of the, yeah, the big name right now. And that leads us into another question actually. So I know this is a broad question, but in your own estimation, why should we study ancient history? Why does it matter? I know you touched upon it. You know, just how interesting it is from the point of view of how alien these cultures are yet also familiar. But I didn't know if you could kind of go a little bit more into that. Sure. Yes. And by the way, I wrote a little, a little booklet about why ancient history matters, which is how I've been able to I give it away for free so I can get people onto my mailing list. But anyway, so I'll tell you a little bit of what I've gotten there. But first of all, history in general matters, because by studying history, we learn where we came from. And I mean, yes, in the literal sense, but also intellectually, you know, we have a culture, the world has a culture. There's many cultures in the world, but we have ways of thinking. And those have all been developed over time. So we've come up with ideas over time. And by studying history, we learn where those ideas came from. And in other words, that's how where we came from, why we think the things that we do, why we value the things that we do. And so I think it's important to study history. Now, why ancient? Well, some things go way, way, way back, right? We there are origins of ways of thinking that go all the way back into ancient times, whether that we're talking about political ideas, philosophical ideas, religious ideas. Many of these things come from the very, very ancient past. And I think it's of benefit to us when we get to learn about the origins of those things, because we understand ourselves better. So I guess that's the kind of in a nutshell why I think ancient history matters. Well said. Thank you for that answer. And just for anybody in the audience who's not familiar, I've pulled up your YouTube channel here. Many interesting videos. You have a lot of travel, a lot of travel videos, a lot of debunking videos. Of course, the TikTok University series that I'm a huge fan of. Just a lot of really good resources for archaeological and ancient historical resources, so to speak. I will try to pull up your booklet towards the end of the show. But I guess getting on to my next question. As an educator in the classroom with your Patreon and YouTube channel, I'm sure you've had to dispel many, how shall we say, misconceptions your students or viewers have from popular culture. I know when I was first starting out, it's very interesting. You mentioned your journey in terms of getting into history. I got it so world history. Similarly through, you know, I changed majors a few times.  And I needed a class to get my dad off my back. So I had a full semester. So I took this western civ class and started learning about the Epic of Gilgamesh and the Sumerians. And I was really interested in that because at the time there was a book that was really big by this guy named Zechariah Sitchin, who is an ancient alien thing. And I didn't know much about the Sumerians. But when I actually I learned about the real deal, it was actually very interesting for me because I found what I was learning in that straight history books much more compelling than the fluff that they kind of give you in those conspiracy theory books. It's very, like, like you said, it was a very foreign kind of mill you. But at the same time, these people were very, very familiar. So just getting back to my, I guess, point, so in a perfect world, we wouldn't have to ask this question. But here goes. So why is it important to utilize sound methodology when researching history? Well, we know none of us were there, right? We don't know what happened. And there are obviously some people who are so, you know, they're ultimate skeptics, they're like, well, we can never know. It's impossible to know. But historians think we can piece it together from the clues, right? Just like you would if you were a detective trying to figure out who committed the crime, right? It might not be on CCTV, you know, so you have to figure out from the clues left behind what happened to the best of your ability. And that's kind of what history does. But there's a method to it, right? You can't just say, okay, this is what happened. If you want to take your case to court, if you want to prosecute someone for their crime, you can't just say, well, I believe very strongly that he did it. You know, that's just not enough. You have to have evidence. So history is the same way. You can have ideas about maybe this could have happened, maybe that could have happened. But what's the evidence for it? And you have to have solid evidence enough to convince a so-called jury, you know, that what you're saying is the closest to being correct as possible. So that involves using the historical method, which has been developed by the historical profession over many generations. And it works, right? In other words, you can't, in order to convince other people that something happened, okay, your feelings just aren't good enough. You have to show them something to convince them. Well, why do we think that? Well, look, we have this exhibit A, right? We have exhibit B, we have exhibit C, and you try to piece it all together from that. But you have to show them how you got there, what's your reasoning process, and how you got there. And the more convincing the case you can make, the more other people will accept it. So my job as a historian is to just make sure whenever I make a case for something, I need as much evidence as possible. Try to make it as strong as I can. And then historians also have to be honest. And if they don't have a great case, they're like, well, this is what we think it could be based on some evidence that we have here, but we can't don't have enough evidence to be absolutely sure. And you have to be honest about that too. Absolutely. And it raises a good point of, you know, one of the things you learn when you start college, or, you know, when you start, certainly when I was starting history, like the first thing you learn is how to use the sources like primary, secondary, tertiary sources, and how to develop arguments, things like that. So I really love that you're bringing that classroom aspect to YouTube.  And I was like, wow, this is so, this is so cool. Like I didn't expect to see this on YouTube, because everything you see is like on YouTube a lot in regards to archaeology is the pseudo category, right?  And that's why I was very impressed with your channel. What I've done here is I've pulled up your Patreon page as well. I've been on this for a while. There's lots of great resources here. Get early access to Dr. Miano's videos. Here's a great one that he just did on the cocaine mummies, which was, you know, a topic of discussion for a lot of alternative history types. But yeah, it's just lots of great resources here. Lots of different tiers you can subscribe at. And we'll get to that at the end of the show as well. So Dr. Miano, another thing I really like about your channel, like I was saying, you have lots of different resources. But one of the things that is very exciting is your Antiquities Travel Guide. I think it's in season three now, if I'm not mistaken. Yeah. So like the series, like you visited everywhere from like the pyramids of Giza to Stonehenge and everywhere in between. So I just thought it would be fun to kind of ask you what are some of your favorite sites that you visited. Okay. Yeah. My Antiquities Travel Guide is the first, well actually, it's the first series I planned for the channel. It was supposed to be the main one. And I went on two trips prior to COVID hitting. And then I didn't go anywhere for a couple of years. So it got put on the back burner. So I've been able to resurrect it lately with the season three. But anyway, I've been to England on my first series and then went to the Yucatan Peninsula for the next one. And now I'm doing Egypt. So I'm in the middle of Egypt and it's a lot. I mean, just to be able to go places and investigate them for myself is a dream come true. But then it's also fun to be able to take it all to present it to an audience so they can kind of experience it with you. So yeah, I think in those particular videos I worked the hardest on. They are not my most popular videos, but I am building the audience up. Yeah, everyone loves controversy. And so they like my controversial videos a little bit better, I think, or at least the audience that I've collected over the last couple of years have really liked those ones. But I enjoy making The Travel Guide the most. Yeah, I could see why. There's a lot of really beautiful archaeological places that reform history. And I just really, I think the one I really liked from this season right now was the second one, actually, the Libyan pharaohs. That was just very eye-opening.  It was very interesting. And I totally relate to you about the videos you enjoy making not being the most popular. Like, my most popular videos seem to be, like you said, more sensational, more a little bit more popular. Like, who would have thought that making a video in the ancient Greek novel would not do as well as something on the Hermetic, you know, or Pythea and 4th century Athens, you know, would not do as well. But, you know, it's part of what I strive to do here. I strive to do quality over sensationalism, but getting on. So probably my audience is made up of different groups, different factions, you know. Like, there are people who are big fans of the travel guide. I have a larger group that are big fans of the myths of ancient history series. And then I have people who love my comedy shorts, you know, they come in, they subscribe for that. So I get probably different groups that are like waiting for the next video from the series they like. And I don't know that I'm spreading myself out too much, but it's all ancient history. Right. And no, I think you're doing a great job because like I tend to, I came for the, I came for like the dispelling the misconceptions and the myths of ancient history. But I really fell in love with like the comedy shorts too. Those just like at the end of a long bad day, like if I need to laugh, that's something I'll like go to that or like an office or South Park Marathon. You know, it's just, I really enjoy those. I do have people complaining about those sometimes. Not a huge number, but I do get people complaining about them saying a serious scholar like you should not be making videos like this. You shouldn't be making fun of people. And it's beneath you. And you should just stick to the facts, you know, and I understand that. And I, I sometimes give a very uncomfortable thinking of if, if people think that I am just out there to put people down, which I'm not. I only pick, first of all, the, the, the funniest of the funniest, you know what I mean, like unintentionally funny. So they are more extreme examples. And they also have a lot of followers. So I don't like go after people that like are just, you know, not very well known. They have a huge following on TikTok, you know, so.  I feel like you're drawing attention to, I mean, it is silly right at the surface, but at the same time, these channels have lots of followers and we will get into that. And that they're in lives, the service that you provide in terms of, you know, just, just dispelling these misconceptions. I think I wanted to talk a little bit about, just diverge a little bit and talk about artifacts. Everybody loves these artifacts from antiquity. I think my favorite is the Antikythera mechanism myself, but I just wanted to know what your favorite artifact was. If you have one, or if you have a couple, that'd be great. Well, I have a favorite kind of artifact and that would be, I love inscriptions and the longer the better, you know, like if we find a Stila and it has an inscription on it, we've never seen it before and the excitement of being able to be the first to decipher it, to read it, you know, I love that. So I love like the newest finds that you can find. Every time an inscription is found, we get some more information and it's very exciting to be able to, to read it. And then once we've talked that one out, you know, I'm kind of ready for the next one. So, but finding inscriptions is very, very, it's rare, right? We find uninscribed artifacts way more often than we find inscribed artifacts. So that's why it's exciting. And even more rare is to find a collection of tablets, like an ancient library. That's like the ultimate find. Like when the Library of Nineveh was found, you know, that was a long time ago now, but amazing, like hundreds and hundreds of tablets and all the information that's on them. That's what I really love, those kinds of artifacts. I love art, you know, too.  But for me, I'll take an inscription. Well said, yeah, inscriptions are, I don't think a lot of people who follow history on a lay level understand just how important inscriptions are, just all kinds of inscriptions, like even more so, almost than written sources at times, like inscriptions, numismatics, these things give us as much, if not more information sometimes about the social and cultural world of the time. So yeah, it's, I'm not surprised that you would pick those. It was funny as I get people in the comments sometimes saying things like, oh, you historians, you know, you put too much faith in those inscriptions.  And it's an interesting criticism. Well, first of all, we don't do that because I told you before, we use the historical method, right? We differentiate between sources and when they were written and who wrote them and how would they know anything, you know, and so forth. So we don't just uncritically accept all inscriptions. But it's also interesting because why are they saying that? It's because they want to rewrite history and the writings are preventing them from doing it, right? So in other words, like, they'll find an amazing stone, right? And it has writing on it, but they don't want the writing to be on it. So they're like, well, I'm going to decide that this stone was made by a lost advanced civilization. Well, yeah, but what about the writing on it that says, you know, my name is Fred and I made this. Oh, I don't want to believe that. They just wrote on it afterwards and they lied. They stole it, you know. So that's why they don't like the writing, you know.  It's very unusual. But yeah, no, it's very interesting that you mentioned that it kind of ties into this. I'm not sure, but it seems to me just to my own estimation that the attractiveness of things like, you know, conspiracy and alternative history is that you're in on some kind of esoteric knowledge that some people, some other people don't have. And, you know, it's just this kind of ties into what I was going to ask you next. Just about your experiences as a YouTube content creator. Now, I commend you on this because I can understand how frustrating it can be to try to bring sound academic content to everybody in an accessible way, especially in a YouTube video that, you know, you have constraints of time. Maybe not everybody has access to the same sources, but you make those available through, you know, the descriptions and things like that. So it's very commendable. And why I think this is important is something we touched upon a little bit earlier. You have, for lack of a better term, conspiracy theories, alternative history, so to speak, floating around these platforms. Everything from Graham Hancock and his lost civilizations to the baffling TikTok trend that the Roman Empire never existed.  It's very strange or we don't know when the first century was. And then even in the topics I cover, I try to stay away from this, but there's a thing called Jesus mythicism that contends that Jesus never existed. And these would be very amusing, but like you mentioned, these channels are getting thousands, sometimes millions of views. So we touched upon why it's important to have a sound historical methodology, but I also wanted to just kind of touch upon what are some of the craziest encounters you've had in the comments, maybe in real life with these. I don't get many in real life. Most of my interactions are online. But the strangest ones are usually ones I get in my email inbox, because there are people that like to write me with ideas. Would you please read my new idea? And they'll send me like a really long email, right? Or they'll send me a document with a whole bunch of writing on it. And I mean, I just am so busy. I can't read everything, you know, and I get a lot of these people with ideas that they want me to read. And what's strange is they know how I feel about history and alternative history and all of that, but they still send me all this, which is, you know, very some of it's way, way out there. And they want me to read it and critique it. And most a lot of the time I say, I'm sorry, I just I just don't have the time. If it's short, you know, I'll give my two cents. But the weirdest ones, and they're not that uncommon, I do get them surprisingly more than I thought I would are people who are convinced that they are going to revolutionize history, that they they are like going to somehow win a prize for being a genius. I they'll say, I have solved the problem that no scientist or historian for 200 years has been able to solve, but I have figured it out. Right. So there are people like that. And they they kind of overstate their position. And a lot of times it's just them being creative. It's not really based on a whole lot of evidence. Some are better than others. But it's usually just them coming up with a cool idea and being creative with this idea and imaginative and innovative. But they don't really have much to back it up.  You know, but I'll try to because I want to encourage people. I want to I want them to enjoy history and to to come up with ideas about history, you know. So if I can, in some way, help them steer them in the right direction, I will, if I, you know, if I have time, but some people are very, very, how can I put this, they're very, they think they are smarter than everybody else. Yeah, we have experience and kind of like the religious studies area of corner of YouTube with a character named Ralph Ellis, who's kind of like that. Ralph Ellis is very much like he thinks he's cracked the case of who Jesus was in his bloodline and everything. Nobody can convince him otherwise. Like if you do bring contrary evidence, he's like, oh, well that kind of agrees with what I'm saying. So in a way, we're both saying the same thing. So, you know, it's very interesting. It's kind of kind of leads me into one, a figure that you cover a lot on your channel that has a lot of adherence, still strange enough, Ignatius Donnelly. So I wanted to ask you a question. Why is big academia trying to silence Ignatius Donnelly and the truth about Atlantis? Yeah, he's the OG alternative history guy. He, yeah, basically everything, well, not everything. A lot of the alternative history you see out there goes back, traces back to Donnelly. And people like Hancock even name drop them and say, oh, yes, I'm greatly influenced by him. I did a video on him, as you probably know. And, but this idea about a big academia. When you think about it, it's kind of humorous if you know, if you've been in academia, for people to ascribe power to it.  You know, don't pay much money at all. But somehow people think they're like, these ivory tower, secret society type people and the governments funding them and their, their shills, you know, and, and they're, you know, they're being paid to, to mislead the whole world for some nefarious reason, which they can never define. It's just like, well, they just want to control information. You know, but why do they want to control information? They never have an answer to have power. So they have power. Okay. Yeah, very sure. But what's the goal, you know, yeah. But also it's when people have an idea, right? And they think it's the greatest idea. And then they write a book or they make a video or they, and people are like, hmm, yeah, I don't really believe that it's not convincing. They can't understand it. They're like, how could someone not believe what I'm saying? It's got to be some sort of somebody behind this, because people would love my idea if somebody wasn't stopping them from loving my idea. You know, they just, they can't understand how maybe perhaps their idea is just not very good. No, it's not that. No, it's got to be something else.  Yeah, and that doesn't, that doesn't hurt book sales either when you're trying to present yourself as like this maverick going against the grain, right? I mean, I'm sure that, I'm sure that Graham Hancock's books have sold a lot more than.  I can't read his mind, but I wonder if he really is, like his feelings are really hurt because archaeologists are out to get him. I think it's part of the shtick. You know, it's part of the whole brand. You got to say this. In every episode of the series, he makes sure to say, you know, the archaeologists are trying to silence him or whatever. They're attacking him because it sells. And I, does he believe it? He might believe it, but he knows he has to play that card, you know, because it works. It sells books. Yeah, it's a tried and true trope. I mean, it's, when I talk to you, for instance, Dr. Litwell about antiquity and mystery religions or mystery cults. I don't like to use the word religion, but because there wasn't really an equivalent term back then for that. So I like to use ritual cult lore and in terms of like the story and the domestic and public sacrifices, things like that and the way you celebrated what we would call today a religion. But in antiquity, one thing Matthew or one thing David really likes to stress is that secrets have social capital. And I think that's what's going on here with these conspiracy theorists today. Like they're in on some kind of secret they have that you can access for a not unreasonable price. And they're trying to be, people are trying to silence them. And it really gets you into this whole kind of Da Vinci code kind of myth making.  Yeah, it's clickbait, you know, controversy, controversy that always sells. So yeah, it's very, it's very troubling that these videos are getting so many views and these people are selling so many books because as you've pointed out in past videos, a lot of these theories, for lack of a better term that they're selling or either covertly or even in the case of somebody like Robert Sefer overtly racist and their origins. And I think what you're doing is important in pointing out, you know, the not so savory origin of some of these things. So I didn't know if you could talk about that a little bit. Yeah, I mean, I have a slightly different view than maybe some others in my profession. I, if the my goal is to bring people over to the life side, so to speak, right. And I feel like when people, when people like academics, talk about like, Oh, these ideas are racist, you know, they're harmful in that way, which is completely true, by the way. Not all of them, I'm just saying some of them are like that. Not that the people who are saying them are necessarily racist, but that they have racist origins or they are racist tropes or, you know, they're based in an earlier racist thought or something like that, or any other type of prejudice or bad thinking. It could very well be so. But I feel like if I say this, and I use that as an argument against it, it's not going to bring anyone over. It will be preaching to the choir. In other words, it will make other people who hate racism and all that happy, you know, but they're already, they're already on board. I'm just convincing people who are already convinced. Yeah, those people are bad, you know, I don't know if that works. Right. I want to convince people. So I want to talk them in a, and so I will, I will focus on the facts. Okay. Well, how do we know this isn't true? Because I mean, if you think about it, if, if someone believes in a theory, right, that I'm just making something up here, but a theory that, that white people were the first to invent civilization and they therefore are the best. Okay. All right. Now you and I are going to be like, Oh my gosh, this is very, this is racist, you know, but you can't tell the person that because they don't think they are, because in their mind, well, it's just the facts. It's study the history. You will find out that it's exactly what I'm saying. Right. So how can it be racist if it's true? Truth isn't racist. So my way of approaching it is, okay, well, let's find out if it's true then. Okay. Let's find out if it's true. Okay. And that's how I approach it. Because I think it's easier to bring them over that way instead of accusing them of something, you know, or implying that they're something. So that's, that's my approach. No, that's great. That's spoken like a true educator. Like, I think somebody analogous that I know as well as a friend of the show, Justin Sledge, from the channel esoterica, he's, he's very much in the same vein. Like, I tend to get a bit zealous, like, I'll be the first to admit, like, when I'm, when I feel like something is wrong in terms of like, marginalized people or ideas and, you know, and when I talk to Justin, Justin's like, you know, that creates cognitive dissonance for people. You know, like, if you want to bring them over and convince them, I think it's an educator thing, though.  That's not what I'm talking about. I'm not talking about people who are actually saying racist things on the chat. I'm talking about people who believe in a theory that has racism in it. Right. Right. Like ancient aliens, for instance, a lot of people aren't going to, for instance, go, Okay, well, they just think it's very innocuous. Oh, that's cool. Kind of like giants and aliens built civilization and help people build pyramids kind of innocuous, right? But, you know, once they look further into that. But yeah, definitely what you're doing is really creating a platform where people can figure that out for themselves. Certainly, I went through that, that very short Zechariah situation phase, like I told you, I was watching a lot of public access on my whole time home from school, you know, in between classes. And I found that very interesting, you know, the 12th planet idea and everything. And luckily for me, it was only a couple of months before I actually took the world Western civ class, you know, so very, very interesting about sources. So that actually brings me to my next question. Now, like I said, your channel is a good resource for this and, you know, kind of vetting sources and figuring things out for yourself and getting good information. But I wanted to know what are some of the other ways that educators such as yourself and viewers can do? What are some of these things that we can do to vet good information and sift through the misinformation that some people put out, whether knowingly or sometimes maybe just out of ignorance, for lack of a better term? Yeah. Well, there's the easy way and there's the hard way. The hard way is the best way. And that is, you got to study the subject, which means collecting every article and book on the subject that you can find and digesting it, you know, and reading it, just gather information. And you know what? It works like there are people, people I know, fellow YouTubers, in fact, who started out, you know, on the bandwagon for all the ancient high technology kind of stuff, but they were interested in history and they studied, they read, and lo and behold, over time, they gradually come around because they realized like, oh, I just didn't have all the information. You know, my information was limited before, but as I've, you know, studied more, I've come to realize, oh, you know, but that takes time. The easy way, which is like for people who just, they just don't have the time for that. They just want to know. They just want to know. The right thing to do is, is not to pick out one person that you think has all the answers and listen to whatever they say. Some people do that. They might pick a, if it's a science topic, they might pick their favorite scientist. I'm just going to believe whatever he says or, or they might pick a Maverick, you know, I love the Mavericks.  You don't want to do that either. You want to find out what the consensus of the experts on the subject is. Okay. And, and go with that. Why? The consensus could be wrong. Yes, it could be wrong. And it sometimes is. Yeah. Sometimes it is. However, you don't have the time to research the subject. So you can't tell if it's right or wrong. You have no way of knowing without doing the hard way. You don't do it the hard way. You have no way of knowing. Right. So that's the next best thing you can do. All right. Follow the consensus because following what one person says over all the rest. Right. This is like betting on a losing horse. Okay. I mean, yes, it's possible that horse could win. Okay. But it isn't very likely. Okay. It has happened in the past, but it is a rarity when the one person knows more than everybody else. Right. So your best off going with the consensus. Okay. Just from the sake, from the perspective of the odds. Okay. So that's what I recommend. That's the easy way. Good answer. It really raises a good question. It really raises a good point that there's a reason why a lot of scholarly texts start with a history of the study of the subject. So you can get a general overview at least. And I think you should really expect if you're in one of these sciences like history or religious studies, you should expect not only look out for but expect that ultimately the consensus will change just back when I was in college. It does. It always does. Yeah. Back when I was in college 15, 20 years ago, there were things that when I kind of came back to study it on my own, I found, but I can understand where you're coming from in terms of talking about those, bringing those people over because I kind of felt like that in a way. Like I was never a religious person, but I was always into like the form critical kind of ideas when I was back in college and things like that. And when I came back to research all this stuff again and get up to speed, I was like, oh, nobody takes this seriously. Seriously. My cognitive dissonance started for a couple of weeks after that. But you know, you get over it, get back on the horse, figure out what's going on and you know, just go from there. The consensus is always updating. And if you're wondering like, where do you find, how do you find out what everyone thinks? You know, well, go to a textbook because the writers of the textbooks are their job is to determine the consensus and write that in the textbook. So those are good places to go to get the general view but always the up to date textbook. Okay, because a 10 year old textbook is going to be missing some stuff or have some things that are no longer the consensus. You got to stay up to date. Yeah. Yeah, it's kind of like, I like got an Oxford classical dictionary, but it was the third volume and I asked one of the scholars that I interview and learn from. He's like, no, you need the fourth edition. Just trust me, get the fourth edition. That's what you need. So, you know, so I did and all the better for it. So Dr. Miano, we've had a coming up just about an hour. I thank you so much for your time here. Thank you for being so generous with your knowledge and your time. I have one more question, perhaps my most important question. Oh, okay. What's the deal with the Sumerian handbags? Well, they are neither Sumerian nor handbags. Yes, I did. That was one of my very first videos, I think. I think it was my third myth video or something like that. But yeah, this is something that is information that was out there, you know, but people don't know about it. That's one of the reasons why I made the video about what these are. And well, first of all, you have to separate the Near Eastern ones from the other images that people say are also Sumerian handbags, which aren't, you know. But the ones that everyone shows from the Near East and they say, oh, these are handbags, they're Sumerian. They're not even Sumerian, they're Assyrian, and they are buckets. And I did a whole video on it. So if anyone wants to find out how we know that, see my video, I think it's called Mystery of the Sumerian Handbag Solved or something like that. Yeah, yeah, that's the one. Yeah. And it's two parts, because in this part, too, I talk about the other things that are believed to be handbags and some of which are, but not the ones from the Near East. Yeah, so I'm sorry to disappoint any of viewers that think that they're carrying radioactive isotopic material in there. Unfortunately, they are not handbags, they're like Dr. Miano says, just buckets. So Dr. Miano, I want to give you this time to plug whatever you'd like. Like you said, you have the Patreon, you have the YouTube channel, and your booklet. So feel free to use this time just to kind of go ahead and talk about whatever you'd like in terms of things you'd like to promote. Okay, well, the biggest thing is to go to my YouTube channel, if you're interested in ancient history, go see World of Antiquity. And I have all kinds, I've got over 200 videos now, 250, 251 videos, right? Yeah. Wow, I can't believe that. All kinds of topics on ancient history and many different series depending on your interests. So you can go there. If you'd like to support my channel, you can do that at Patreon, just as you do, patreon.com slash World of Antiquity. And very much appreciate helping me keep the channel going. I do have a booklet called Why Ancient History Matters, which I give out for free. And I have the link to that under every video, I'm pretty sure. And also, I have a little book called How to Know Stuff, which you can find on Amazon. And it's just a little book on just how to find out information so that you might enjoy as well. It seems simple, but learning how to vet information is absolutely critical for doing sound historical research or even living your day-to-day life. So I would recommend, I would recommend those. I pulled up the page for your e-booklets. I have looked over that many times. My son actually enjoys it too. You know, just very interesting and very important food for thought here. So Dr. Miano, thank you so much for joining us. The work that you do, the work that other content creators like Stefan, Milo, at Mini Minuteman, Sai from History with Sai, Garrett, Tolton Stone, you all do fantastic work in terms of facing the public and bringing us information we would otherwise have to dig through numerous library shelves to find. I hope to do this again sometime. But until then, you have a pleasant evening and thank you so much again for joining us. And thank you. Thank you. And thank you all for watching. I appreciate each and every one of you, whether you're watching now, whether you're watching in the future. I never knew that there would be so much demand even at this humble level for a dude sitting on a couch talking to scholars. So thank you so much for joining us and we will see you next week for Dr. Edward Watts, Dr. Dana Trell from the Modern Hermeticists, and the season finale with Daniel Ogden that is on Friday, May 28th. So until then, we will see you soon and take care. See you.