 All right, so I'm just bringing this up on the screen real quick. These are the instruction locations for installing Git and Garrett. The Garrett stuff is on the bottom of the page, which is why I have the note to scroll to the bottom of the page. And all of these links are in the etherpad, right? Yes. I put them in earlier when I also emailed everybody earlier in the week. And I did share the etherpad in the chat. This is one of those times where I'd be walking around the room making sure everybody's okay and how you're doing and stuff. So this is kind of awkward for me. Tomaslav Ivan, how are you doing? No news is good news. Tomaslav has git configured. And do you have Garrett installed yet? Tomaslav, oh, we have someone else who's not showing up on our list, we have more people. Sweet. There's a down arrow on participants. Welcome, everyone. So if I don't call you by name, it's just because I've just realized we have a downward button on the participants. But if everyone can let me know where you are on the Git and Garrett install. Elvis is here, too. I know. I just saw that. Good to see you again, Elvis. Tomaslav, if you go to this link. Oops, I just sent it to Kendall for some reason. That has the instructions for Garrett and it'll need a scroll to the bottom of the page. Forgot to bring my lawyer for the agreement. Yes, it is. Get review, Tomaslav. Yeah. And that's one of the reasons why I kind of sent the information out ahead of time. Because the very first time we did this in Tokyo, someone said they couldn't sign up without their company approving at first. We do have a yes-no feature within Zoom. If everyone can just hit yes once they're configured for Git and Garrett. Hi, Elvis. That would be really great. Yes, you do need to join what you kind of already did when you got your user ID for the summit. You do not have to join as a foundation member anymore, but you do need to at least sign up as a community member. But let's go ahead and just make sure everyone has getting Garrett installed and we'll go into the accounts shortly. Is there anyone who does not have Git and Garrett installed on their machines yet? Not necessarily configured, but just get the basic packages on. So maybe I'm just missing something. So I'm doing the Garrett part, but I don't see an actual client. I'm looking at where it's talking about SSH key pairs and this other stuff, but I don't see that there's actually a client there. It's actually going to be the commit, the commander actually going to use as Git review. So there isn't really a client. You just need to install the basic Garrett. Is that not on the page? I'm not. Maybe I'm just missing it. I'm seeing stuff for SSH keys and. And I see, you know, going in and doing your public key settings. And then it. It just talks about. Get review. Okay. So underneath where it says get review. There it is. I just found it. That's why I put that part about scrolling in the bottom of the page. I knew there was something weird there. Yeah, maybe we should reorder that Kendall and put installation first. Okay. We can. That can be a thing. Someone can fix. Someone can get a patch in today and be a contributor. Plus to it. And I know somebody that I can ping to get it workflowed too. So it'll actually merge today. Okay. I haven't clicked. Yes. He is. Installed. How's everyone else doing? Actually having a harder time finding the. The app. I'm good. I just can't find the button. Look at the participants list. And then at the bottom of the list, there are the options. Yes. No. There it is. Yeah. Yes. I don't want to move on before anyone's ready. And unfortunately I can't see everyone's faces. To see if you're stuck or not. So we're relying on yes and no. Walk through the list and call everybody's name. It's like roll call. Did you finish this thing? Yes. Whether typed or verbally said. Who cares. Like Elvis. I know. Sorry. Kind of makes me want to buy like a Chromebook. Well, Chromebook would be hard, but like some sort of small laptop to be able to. Like walk through all this again. Yeah. I updated some of the screenshots and stuff, but I couldn't, I didn't want to make another stacking Mcstack face. So. I'm not 100% sure on the open stack foundation, whether our screenshots match anymore or not. Thomas. Thomas love. Jeffrey. That could be another thing someone could do. Take a screenshot and save it and then. I should be writing these things down. So if they don't happen today, we can make people. We can do it. Yeah. We'll go make stories. Storyboard. All right. I'm going to go ahead and move on to the next slide. Just to keep us moving here. So as we kind of mentioned already, I'm actually not on my working conditions. Okay. Tomas, that's good. So we're just going to go over the different accounts. And make sure everyone's signed up. And also in any agreements are signed. This will especially become important for Garrett. So if you have not signed up yet, which everyone pretty much should have. At open stack.org slash join. Because you didn't need an open stack ID. To get into summit. Now, whether you joined as a community member or a foundation member, I'm not sure how that worked. And I'm going to go let a dog out because he's crying. My husband's making breakfast. That's a big no, no in my house to do so without Dalmatians. So I should go through. So this is the screen you should be seeing. This is one of the new screenshots. So this is slightly different than it used to be. But this will give you an idea of what you should be seeing when you click on join. And then picking in account type. And this is where I'm not quite sure this page is matching what you're seeing. But in the past, we had two different memberships. We had a foundation membership. And a community membership. And the only real difference was voting. But voting is very important. Because it gives you a say on who's on your board. Who's on your technical committee. So if you do plan on staying around and being active in the community, I really do suggest. Taking a foundation membership. And it's both free. So there's no difference that way. But it does give you that ability to. To vote for your leaders. And actually everyone. I'm just going to go ahead and read through this. I'm just going to go ahead and read through this. Here. Myself Kendall and Jay have all held leadership positions. Within the community. So. You can start as a developer. And become a leader. And then signed the ICLA. And I don't have a picture of this because I'm not quite sure what it looks like anymore. But you will need to sign up for an agreement. And I believe Thomas love already asked about this earlier. So if you think your company will have an issue with it. Maybe hold off on that part. You won't actually be able to participate today. But you do have access to the slides to go ahead and run through everything later. And all your noisy. Sorry. Sorry. I was going to say something and then I started replying to somebody. Yeah. If while someone signing the ICLA, they want to take a screenshot of what the like. What it looks like. That would be super awesome. And the account type page. Yeah. Yeah. Yeah. So like. Four years ago, I created stack Emix stack face. Who is an actual open stack foundation member. But. I didn't want to go ahead and create yet another test one to make sure that I was able to do that. So I'm going to go ahead and do that. I'm going to do that. I'm going to do that. I'm going to do that. You can get your contribute contributions. Do we need infromic in face? That doesn't work as well as stack Emix stack face. Yeah. I, I, we created him during the time when they were having that competition in England for the boat. Yep. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Like actually managed to get the patches done. If you could take the screenshots and send them to us. That would also be really excellent. You are finding us for work by doing that. Yeah. So if you're not comfortable doing the patch yourselves. I'm emailing one of us. The screenshot will be more than happy to put the patch up, but this is a super way of getting your first patch in. All right. So the Ubuntu one log in. You can go to story board. Open stack. Or or launch pad. Net slash open stack. And the, as I mentioned earlier, for those of you who are here from the beginning, those are our two bug tracking systems. And once you click on log in from either of those, you're going to come up with a page that looks like this. And you're going to actually click the first link that says, I don't have. And. Ubuntu one account. And then you're going to have a link, but the radio button. And then that will take you. To this page. And this is where you'll put your information. And then this is where we signed up stack emick stack face. We'll just hold here while everyone gets that far. And even though we're doing it in gear today, if you really want to learn more and also about IRC and other things, please attend the two OUI sessions we've got later in the day. And the first one is going to be on Thursday, which is open dev and the second one, which will be going over tooling is on Friday. So there will be some repeat of things on Friday, but there'll be some new information as well. And also more mentors. So we're a lot of fun. And it's a, the mentors are all members of the communities. We've got some PTLs, four more PTLs, TC members. And it's a great way to learn meet people within the community, because one thing we are missing out on this week is. My favorite, the hallway track, which allows you to just walk up to somebody after a talk and just introduce yourself and meet them and make those connections in the community, which is kind of how we all met. Now on the Ubuntu one, is it a problem if we already had one? No, not at all. I just logged into my existing account, didn't think it mattered. Nope, doesn't matter. Okay. All right. Just making sure. Yeah. The one person we had trouble with, with Grace Hopper, because she was on the windows machine was actually a former rack space employee. And the problem we had with her, with her logins was just remembering what they were. Because she wasn't getting the verification emails. So we had to clean up some of her older emails so she could get them. All right. So Garrett. So now we're going to go to a HTTPS review dot open stack.org and click on the sign in. I believe I have a string. So the sign in and is in the upper right hand corner. You should probably up these update these to be opened up. Okay. Just a thought. I guess, I guess they're going to keep the links. They're going to keep them. They're going to keep them. They're going to keep them. They're going to keep them. They're going to keep them. They're going to keep them. I mean, I did verify all links worked. I didn't have to use other links. And I already fixed everything that I found an issue on when we use this for Grace Hopper. Okay. And this is where your law, your Ubuntu one account is needed. So you're going to have to verify your email as I just mentioned. And then you just log in. And you sign the ICLA. Because if you do not sign the new contributor agreement, you will get a really unhelpful power message within Garrett. So you're going to select the ICLA. Put in your information. Stacey lives in Austin, Texas. I do not live in Austin, Texas. I live near Austin, Texas. And then you'll see now that it says you're verified as with an ICLA. So I want to make sure everyone sees this verified status before we move on. Once you're verified. Okay. Now what were the screenshots? Or the like actual. Form that you fill out when you joined the foundation. And what was the other one? Did anybody screenshot it for us? Bonus points. If anyone says they got it, I'll get them on. Unreleased RDO. T-shirt. Oh, swag. I do have access to swag. What's for breakfast, Amy? I'm assuming he's having fresh eggs and bacon. And coming. He's sharing with all of us, right? I don't think you want us cooking. This is hippie. Hippie. Okay, go in your spot. All right. Everyone have the agreement. Okay. Okay. Okay. We'll get this two more minutes. Right. And as Eric kind of mentioned earlier from that. Get review page. We're now going to upload our SSH key for Garrett. So we're going to create. And get the public key. If you don't already have one, this is the command that will run it. And the cat will allow you to see the pub key. Please, please, please. The pub key. Not your private key. You don't want to create a new one. Or they want to create a new one, I should say. There are some tricks to actually using two different keys. But if you have a single key that always does make it easier. All right. And this is the direct link to get to the SSH key part. I got rid of that setting. So you can do this. By going. To where your name is in the upper right. You can drop down and select settings. And then you'll notice where it says SSH keys on the left hand side. I'll give everyone a few minutes. And if you have any questions about creating your SSH key. Let us know. I basically. Do not put a pass phrase on normally. My current one does have a pass phrase. I will tell you when I do a patch, I think I end up. My pass phrase at least four times. So. There is a drawback to being more secure. But it is more secure and being more secure is always a good thing. Sorry, a tennis ball was required. Other things you do not normally see at summit. The requirement for tennis balls. Can we get a fresh batch of yeses if we're ready to move on. I'm sorry. I'm sorry. My yes is still from the previous step. Give me just a few more seconds. I can clear all. So. We're ready for fresh. Yeses. To Mars. Office night. And I do. Apologize if I say anyone's names wrong. By the czarot. I also speak with a Southern accent sometimes. Hello. Yes. Yes. I'm going. Okay. And you pronounce it correctly. Yeah. That means happy in English. Yeah. Thanks. All right. So let's move on to the open stack contribution process. So this is a typical development workflow. And this is for the Nova project. This diagram is actually within the upstream documentation. If anyone should ever want to see it themselves. But we kind of start up at the upper left hand. Corner with the upstream code. And what you would do in the, in the workflow is you would clone master. And one thing that's different about open stack is we don't fork. And I think that's important to mention. So we actually clone. Directly from the repositories. There's no forking. There's no pull requests. There's no forking. There's no forking. There's no forking. Garrett is going to take care of all that in the merging. And it's so much easier than pull requests that once you get used to Garrett, I can't. Do a good pull request. I'm always having to merge and stash and do other things because I'm used to being able to just patch on top of patches. So you're going to take your initial code and you're going to clone it. And then you're going to have your environment. You're going to have your project. That's going to change your project. We are going to use a couple of different types of branches. And depending on the project you use, there may be a requirement to maybe put the bug number in it. I usually just do something that tells me what I'm working on. So in our example here, we have get branch fix bug. And that's going to change our branch from master. To Nova fix bug. tests, talks, for example, and then we're going to commit it. Well, you're going to get add and get commit. And then you're going to have your branch, and you're going to type the command get review, which is going to set it up into Garrett. Now, it's important to note that there are different types of voting within the Garrett system. Everyone can plus one or minus one a patch. Thanks. This looks good. You've got a little typo here. I would recommend you change the order of things to this. A negative one is not a bad thing. It's a conversation. Now, I do make note that their core reviewers can plus two and negative two. Now, a plus two means from the core reviewer, yes, this is good to go. I approve it. Almost all projects require two core reviewers to plus two it. In a smaller project, they may go ahead and do it with only one plus two. OK, I need to deal with this. I'll just need a ball for every single one of them. Well, basically, that's why I just did it throughout a second ball. That's the dad growling at the sun. All right, so now a negative two is not a bad thing. Now, a negative two just means that maybe they want a spec, a blueprint. It's not what they're currently working on for this cycle. It may not be that we're never going to do that, but it requires more, and it's not really on the plan for this cycle. So even if you have a negative two, it's not necessarily a bad thing. It just may require more work. Now, when you get a negative one, so something you need to change, you're going to go ahead and just make those suggested changes locally, and then you're going to do a get commit amend. And what this is going to do is it's going to amend it to your previous commit. Then you're going to get review it again. Everybody loves it. So you get your plus twos. And the core reviewers are also going to give it a plus one for workflow. Now, one thing I didn't mention previously is during that whole review process, Zool, which is our review system, is also going to review it. So the initial review from Zool is testing your code against what tests already exist within your project. But once you get the workflow, you're going to be run through Zool again, and then it's testing it against the whole entire OpenStack code base. And that's what we mean by the gate queue. So we're now moving up to automated testing. You're being tested against everything. And then Garrett and Zool merge you into the code itself. And this is where we're different than a pull request, because everything is automated from the point where there's a plus one for the workflow. Any questions? Because I know that was quick because I'm usually pretty quick. But I do like this diagram because it is updated to include Zool. We used to be on Jenkins. And it is fairly straightforward in its flow. So Launchpad. So this example out of Launchpad is one of my favorite examples of the community working together. It's from the Ocata release. It's a documentation bug because Nova made some changes releasing Cells V2 and placement as being mandatory at that point. It was no longer optional. And the documentation was totally left out to put it bluntly. No one realized it till Ocata was actually released. So everyone got together, the Nova team, the docs team, other people. And we figured out the steps that were needed and the documentation was done. So it's a really good example of communication. And like I said, negative ones are not bad. They are a form of conversation. Are you snickering or are you just calling? Positively. OK. I mean, that's a good way of putting it. It can send that was saying that a minus one isn't a baseball bat to the face. Or was that like Griffith or? I know one of them said that. It was like, yes, I'm going to remember that forever. Yeah, I mean, the negatives and the requests for changes aren't bad. Often it could just be simple, reordering things or this is how we do it. And it would work better like this. Depending on the project, a lot of times what I do lately is I'll ask the person putting up the patch. This is real simple. Do you mind if I just fix it for you? And that's just so it doesn't go back and forth, but I can fix this in two seconds. It's just a rewording of a sentence. Let me go ahead and fix this for you. Because English isn't the first language for everybody. So having someone on a team that can go through and just fix things is often very helpful. But I never do it without asking a person at least the first time I do it. That's just a courtesy I do. All right, so as we mentioned earlier, you use your open to one login to get into Launchpad. And we're going to go over when to open or assign a bug and how bugs are created. So this is an example of Launchpad for the triple O project. And you can see how there's different statuses. And some of them are assigned. And they've been there a while and so on and so forth. Actually, we do not have screenshots for all this. OK, let me go ahead and bring up Launchpad. And we'll see if I can switch screens I'm sharing because that's an advantage of this. I think we do cover this later. Hang on a second. Or I break the stream. No, we do not. Interesting. OK. All right, can everyone now see Launchpad? Yep. OK. So the process for creating a bug in Launchpad. We're going to report a bug. We'll do sender. So you select the project you want to open the bug in. And you type a summary. And you hit Continue. And here you can see the sender mascot. For all the discussion that went into that one. Same discussion. That was like probably a couple hours worth of PTG and mid-cycle time. And there actually was another sender mascot before that one. The design didn't understand our request. Yeah, the Ferrari stallion just was not our group. That was one of the fun PTGs in Fort Collins. Should we read anything into it being the horse's rear end? No, it's exactly that. It is a horse's rear end. Hey, we control storage back ends. And the tail is a C. That was the thing they got in there that was brilliant. It's like, oh, it's a C. Nice. And plus, if you know the group, we were a bunch of horse's back ends at times. But they're lovable. Oh, yeah. All right, so now you've noticed that we have a list of possible bugs related to our summary. So at this point, you can make the decision whether one of these other bugs that already exist meet your needs. Or you can go ahead and scroll down and say, no, I need to create a new bug. Now, in as much as this is the actual live sender reporting, I'm not going to actually hit the button. Just want to see the bug. OK, latest report. I just want to look at one so we can look at a little bit of triage stuff. So there's different statuses. You can give to a bug. You can also give the important, and you can assign it. So if you're core, you might have permissions to assign to someone else, or you can assign it to yourself. I mean, you can assign to someone else if you're core, or you can assign it to yourself. See if I can't get us back to, we'll present again. Awesome. OK, so it actually brought us back to where we were. Kendall, do you want to do storyboard? I should have, like, waited to make a story. But yeah, I can do that. Let me share my screen. You need to enable screen sharing or make me a co-host or something so that I can. Yeah, if you do the more thing, you can make me a co-host. Yeah, yeah, hang on. No. Done. Thank you. Proud to thank you. Sweet. OK, you can see this beautiful project. So in storyboard, the way things, it's more of a task tracking and task management tool than just bugs. It was created by the OpenStack community for the OpenStack community. So it is created like API first, and it's easier to script against than Launchpad. And so as a result, this lovely UI that we have is the second priority after the API. So basically, when you log in, you have your dashboard view. And there are things assigned to you. There's also your boards and your worklists because we have this Kanban sort of setup for organizing work if you're interested in doing that. And then you have things that you're subscribed to. So if I have some new thing I want to make, I should actually be using some garbage ones. We have a test site and then the real site. So if you're just messing around with Storyboard, you want to use Storyboard-dev. And yes, there's an invalid certificate because it's our development site. We don't actually run any production or put private things here. This is kind of like a sandbox to use, basically. So oh, crap, I gotta log in. You gotta log in. Beautiful. Ubuntu 1. Yes, that's me. That is my email address. Awesome. So I'm going to go and make a story. And my story is that Summit and then you write a description. Everyone should share the pane of time zone conversion together. And then under a story, you can have lots of different pieces of work. So in a project, say, you want to implement some feature. OK, well, that's probably done in one repository. But then you have documentation that needs to be updated. And that might be in a different repository. Or maybe you need to make changes in two different projects to actually get your feature implemented. Well, the tasks are that work that needs to be done that's actually associated with a specific repository where the story is more of like the epic, the thing that needs to happen if you're familiar with Agile and all of the processes around that that you'd be familiar with that terminology. But yeah, so all Summit times should be in UTC. And I'll put that in the contributor guide repository because sure. And then you can save your changes. It won't actually let you save until you have a project or repository associated with the task that you make. So it's really important to have that. And generally, you can just assign it to like Cinder or whatever. And if it's in the wrong place, they'll get it to the correct repository. But Cinder is not actually on Storyboard right now. So that was kind of a bad example. Ironic uses Storyboard at this point. There's a migration happening that as we get features added to Storyboard, we're unblocking different projects so that they can migrate from Launchpad to Storyboard. And the reason why we're doing that is because Launchpad is basically at end of life with canonical. They have maybe one developer working part-time to keep it running. So they're not adding features. And basically, we have Storyboard as a community develop tool to take the place of that. And then also, once we're completely migrated off of Launchpad, we can get rid of Ubuntu 1 and you just have your open stack ID for everything. And that will be a lovely, lovely day because then you'll only have to make one account. You won't need to make two. But so I have this story created now and I can say it affects another project. So maybe this one is like the training guides. If I can spell or maybe we don't have training guides over in this test thing right now. Just make it against Storyboard because we track Storyboard problems in Storyboard. I don't know. My creativity is limited at 7.15 in the morning for me. So you can add tasks that are associated with other repositories. You can add more tasks specific to that repository. And all of them get these task IDs that we'll use in commit messages later once we talk about those, which I'm guessing is coming. Right, Amy? So there's also this tags. You don't really need to worry about tags when you create them. But in the future, when you're more involved in the community, you might be like some projects are really particular about differentiating bugs from new features, even though they're both technically just code changes. That's the work. It's a code change or a docs change or what have you. So they'll be like ironic bug or ironic feature. Or they'll say what milestone they're trying to get it in by or if it needs to be backported to a different release or that sort of thing. So that's kind of what those are for. If you're interested in a story that somebody else has made, you can subscribe to it. And then it'll show up in that dashboard view that we saw earlier. And all of these get organized by the individual project that you storyboard into the worklists and the boards. So if I go back to the regular storyboard. Just a warning, Kendall, we're at 30 minutes. Oh, OK. Well, OK. Well, there are lots of things. I could talk about storyboard forever. But that's the basics is you create the story for the thing and it will be organized by the team, I guess. Yeah. All right, let's see if I can grab it back. Participants to make it. You should be able to just click share screen again. Yeah, yeah, share. All right, so now we're up to where we're going to file above. And we're going to use this URL, which is launchpad.net slash get in Garrett training. So this is our own little sandbox. Don't worry about it affecting anything. You can do whatever you want there. And then as I walk through previously, we're going to report a bug. We'll enter the bug summary. I knew I went over this somewhere and provide further information on the bug. Extra options are things like adding tags. We're not going to deal with that. Our status will come up as new. Our importance is undecided. And then you're going to assign the bug to yourself. So I'll give everyone two minutes to do that. This is kind of why we never get to those advance exercises because we're going really good on time and then we spend time talking. So we kind of configured get earlier, but now we're going to do our actual configuration. So if you didn't do it previously, you're going to get config and you're going to say global user.name. And then it's going to be your first name and your last name in quotes. And then we're going to do something very similar. And again, this is one of the ones that was on the etherpad earlier. We're going to set our user.email. And then finally, we're going to configure our getreview.username. And then you'll place your username there. Now, your username in Garrett cannot be changed later. So hopefully you picked something nice. But you can change the display name. And one thing we do in OpenStack Ansible is we have our name. And then in a bracket, we put our IRC handle. And that allows us to be tracked. If we put a comment and you want to find us on IRC later to ask questions, you know who to look for. Because in IRC, we're all logged in with our NICs. For example, I'm Spots. That's a really, really good idea. We should encourage everybody to do that. We're leaders in OSA. I'm going to go change those. For example, Kendall's Diablo underscore Roja. You're Roja. You should be Roja. No, because Diablo is masculine. So Roja has to be masculine. And then J is Jungle Boy J. And then run a getConfig list. And this will show you what you have configured. And then we discussed earlier cloning and branching. And we're going to be using Sandbox. So again, you're going to be dragging down code and putting code up that's not going to affect anything. So you can do whatever you want to it. So getCloneHTPS colon slash slash opendev.org. See this one I updated? Slash opendev slash Sandbox. And that'll be a repository. I will warn you that you may have some issues later along the line if there's any conflicts. But it's Sandbox. So it's nothing against what you may be doing. It's just the fact that it's Sandbox. And then once you've cloned down, you're going to CD into the repo with CD Sandbox. And we're going to set up getReview. So I'll give everyone a minute or two to get to this point. So when you get to the getReview part, I went ahead and brought up the commands. So for Mac and Linux, it's going to be getReview dash s. On Windows, if we do have anyone using Windows, it is just getReview. And then you can do a getRemote update to set your remote. Doing weird things. And it's because Garrett was down. It's like, oh, oh, OK. Well, I guess I'm not doing that change today then. No, don't play with things. And then we're going to go ahead and getCheckout master. So this is going to be the master version of the Sandbox. If for some reason you're out of sync, you might do a getPool dash dash ff only is a fast forward of origin master. And then as we were talking earlier, we're going to do a we're going to branch. So the command to branch is getCheckout dash b, which stands for branch. And in this case, we're saying bug in the bug ID. Slash the bug ID. But it could be anything like in the workflow, fix bug foo. So it's mainly for you to be helpful to yourself to know what this particular branch was for, unless your project actually specifies that they want the bug, bug ID, or feature in a feature, know what's in the feature. So they might designate their branches like that. So now we're going to create, commit, and verify a patch. And the link down here is to some example getCommitMessages. So check those out, not necessarily for this exercise, but in the future. And we're just going to make a quick little file. So we're just catting into my test file and a file. But you can do anything you want here to create a new file. And we're going to add some unique text. And then we're going to do a getStatus. And it should show you in green. Yes, in green. No, that's the one that's added. If you do getStatus, it's going to show you that you have a new file. And we're going to do a getAddMyTestFile to then add it. So it's being tracked. Now I'm going a little quick because I'm trying to get us back on track. So if anyone has any questions or anything, please type it in the chat. And just let us know and we'll slow down and help you out. Now we're going to run getStatus again. And like I mentioned previously, you should now see that your added file is now green. If you had removed a file, it would be on the bottom as red. Because sometimes as part of a patch, you are going to remove content. Now we're going to do a getCommit-A. The dash-A actually stands for add. So even though we added it previously, this would make sure anything new was added into our commit. And as I mentioned previously, should you need to work on something you've already put up, but you had comments on. So you're changing things. You're going to use the amend. And you can use the dash-A and the amend together. A getShow will show you your status and everything. And then once you're ready, getReview. And getReview is going to send it up to Garrett. And I'm going to hold here while everyone gets to this point. You at least need to do the creating of a file, the getAdd, the getCommit, and the getReview. And if something went wrong in your configuration, this is where it's going to show up when you hit getReview. And I'm going to go ahead and clear all the checks. And once you have successfully getReviewed, go ahead and put a yes. If you are having any errors, go ahead and click no. And just for reference, the Zool system we've mentioned is also another open infra foundation project. It was originally just an infra project within OpenStack and it spun out to its own top level project. We've got a couple yeses in the list. We'll wait for one or two more before moving on. Kind of call this lazy consensus. Everyone doing OK? Any issues? Actually doing pretty well. Yes, I, you were one of my pluses. Ivan, Jeffrey, Tomasz, Seder, I think you came in late, so I'm not sure where you are in the scheme of things. Well, this is configured. All right, as we only have 16 minutes left, I'm going to go ahead and move on. So the Garrett and the Zool workflow, you should have noticed when you hit getReview and it went successfully that you received a URL that looks like this. H-E-T-P-S colon slash slash review.openStack.org slash pound slash C slash an ID. And that's your review. And here's an example so you can see where the number came back. Now you can also keep an eye on Zool and we call that gate checking and you can do that at status.openStack.org and I think it'll automatically take you to Zool but you might need to put Zool on there. And what you might need to go there for is if, for example, you put your patch up an hour ago and you still don't have a vote back from Zool and you just want to see where you stand on things, it could be that the gate is very busy in which case you'll see other patches ahead of yours or it could be that there's actually an issue. So that's why you go to the status page. So let's go ahead and look and see what a review looks like and this is actually from that example documentation on cells V2 and placement. So as you can see, there is the owner for the patch but there can also be other committers. So say for example, I saw something and you were okay with it and I just put a patch on top of it or in the case of someone goes on vacation and someone else needs to take over it. So there can be more than one person who's running the commit and then all the reviewers are listed there. And as you can see, I'm the only one who has their IRC NIC listed there. So I'm easy to find on IRC to ask any questions. The project that the patches in for is listed there and then different information. The individual code reviews. I am not core on OpenStack manual so I can only plus one or minus one. So the two cores that were involved here are Alexandra Settle and Lana. And then Lana gave, I mean, Alex gave the plus one for the workflow. And this is old enough that we were Jenkins versus Zool so you can see Jenkins gave the plus two there. So Jenkins said, okay, I've run through everything. This is passing, it can be merged. And then you can see all the comments down below. Okay, so again, you can see all the conversations if you looked at the whole entire review, you would actually see everything. Now a couple of things I'm just gonna make note of on the upper right-hand corner is patch sets. You can actually click there and pull down different versions of the patch that had been worked on in case you need to backtrack something cherry pick or whatever. And then Zool, this is just a copy of the status page. So you can see that there are different projects that are currently running, their timing, what's in line and so on. So here we actually are at the additional exercises but I'm not quite sure that everyone's actually configured and ready to go. So one thing we could also do at this point, currently reinstalling, take it for everything. Okay, yeah, sorry. I don't necessarily read at the same time I've got too many monitors going. So at this point, what we could do is everybody could pass, like put their review link in the chat and someone else can do a review. So you get that feeling of working through a review. We could go to the additional exercises which is making changes to an existing patch, help people finish getting configured. What do you all need from us? So far, I mean, it seems pretty straightforward. I guess maybe finishing the review would be the part that I'm not familiar with. Cause I mean, I've used Git in other places. So that part of it I'm good with. Okay, Eric and Hampus, because you both have the yeses checked, do you want to go ahead and put your review links in the chat and we'll just focus on those two reviews and everyone can go ahead and log in and review them and work through the process and ask any questions. But it's... And if your views to Git, reviews and Garrett are so much easier. So much easier. So much easier. I still am not entirely sure when I'm reviewing and Git if I've done it right. I'm not even sure if I have to, I know for a fact I don't do it right when I have to put up a second patch. Oh yeah. If anybody can explain that to me, that would be awesome. I'm afraid I can. Okay, so I'm going to go ahead and grab this. I've been trying to get my team to move to Garrett internally and it hasn't happened yet. Garrett's actually not hard to set up. All right, let's see if I can get a window here. But everyone can see Eric's review here. Or could Intel I? Jay! So this is Eric's patch that he put up and how we would review this. So click on the commit message and what some... Hey, he's already good. So you can like put a comment here. Like, please capitalize patch. Not that you would, but just to have something to say. And this is one of the reasons why we really, really love Garrett. Stand up, get out, grab coffee when it is a sample patch from... So... Somebody used the same file. Well, we have multiple of my test files probably. Okay, that makes sense. So yeah, so I could then give it a negative one if I felt like I needed to just because I put that comment there. If I really didn't feel strongly about my comment even, I can still give it a plus one or a plus two. You know, and something we might do is if you need to, you know, the comment could have been, if you need to do another patch, go ahead and capitalize this. In other words, I'm saying it's not really important, but if you're going to be doing this, you know, putting something else up again, you know, go ahead and make this change. So that's how it shows a negative one and a plus one. I'm going to actually... This is another reason why I really, really like Garrett because I can just come up here, like if there is a quick fix, I can just make that change, close it. Now I wouldn't necessarily do this for code unless it's something really simple, but I do it for documentation all the time. And then I publish it. And now you can see where we now have two names. So we have Erica as the owner and I'm the uploader. And one reason why I did this is I wanted to demonstrate this. So you can actually do reviews against a specific patch. Oh. You didn't know that? I hadn't noticed that before. I've definitely done this by accident and that's the only reason I know it's there. There was some other way that I would get it. You could do it here. Yeah, okay. All right, yeah, that's normally where I would do it, but that's nice to know we can do that. Yeah. The mentor become mentee. So again, reasons why we love Garrett. Not good. Files can still just go up. So does this answer any questions about Garrett and how much easier it is than doing a full request? Yeah, I do agree. Because I did a one character patch for Seth. And because I, they asked for a change and I went to do it kind of like I normally would do it. They weren't happy because it showed too many commits on it. I finally just like walked away. I couldn't figure out how to fix it. And it was literally a one character change from another open source projects core reviewer and I couldn't figure it out because this is so easy, so handy. Wow. Yeah. Yeah, the push model definitely jives with my brain much more than the poll model. It just seems like there are so many extra steps because you have to like fork the repository and then clone your own repository version of that fork and then do the change and then push it up and then do the pull request. It's like Garrett does all of that but hides it from you. So you just clone the repo and then push and then it exists in that middle area without you having to do all of the extra steps and go between. And a reverse pull request so you keep your fork up to date. Yeah. But yeah, it's very easy to, even though you're branching to have multiple branches then in one pull request. Yeah. I now have notes on how to fix it after I break it because I kind of messed up something from RDO because that part of RDO wasn't in Garrett like the website and I just kept making changes. And every time I'd make a new PR I would have the files from the previous work. Well, and it... Oh, yeah. What was that? Sorry. What are these buttons for up here? Okay. So, two of you are working on the exact same thing which happened to me recently. So one of us a little abandoned because you don't need the same thing or just change a direction might require no cause and abandoned. The cherry pick is say, for example, we just released Victoria. So we're now master branch but we want that change to exist in Victoria as well. So we would cherry pick it. Now, if it's soon enough and the code is similar enough you may not have to modify it and it's just a matter of cherry picking and getting it retested and merged. But sometimes you do have to do some more code work on a cherry pick. Rebase is more than one person is working on the same code. So it just replays kind of on top of code and make sure everything is good and can be merged. I've never used follow up. Neither have I. I haven't either. The cherry pick and the rebase really only work in a perfect world. So if other things have changed it's likely that you're going to need to do the rebase or the cherry pick in a local branch and then push it back up. Cause obviously if there are any conflicts if it's not smart enough to deal with all that. And sometimes it'll come back and it'll time out. I mean, this is not doing anything. And you just type in a recheck as a comment and it'll rerun it through the Zool processes. So you'll often see a bunch of rechecks in there and you don't have to do anything else to it but just type recheck for it to go back through the system. I mean, it is smart enough to do that. But please, please make sure that you look and it's not something like I've completely broken the code. Yeah. I mean, usually on a timeout. Right. So if it's like failing the Python tests then take a look and make sure you don't have a code issue before rechecking. Then it's just gonna fail again. Right. All right. So that is 945, which is the end of the session. Does anyone have any other questions or anything else they wanna cover? I just realized typing, not muted again. You need a quieter keyboard. No, it's so good. Like I encourage you to get a keyboard or a mechanical keyboard with blue switches. It feels so good to type. I can't even explain it. It sounds like the keyboard I have when I started at IBM, you know, 20 years. It probably is close to that, yeah. But mine's very pretty obvious here. Well, with blue switches, it's very close to that IBM buckling spring but, but yes, I totally agree. Mechanical key switches for the win. Yeah, they're so good. All right, so... People were very quiet in the discussions that things went well. At least a yes check would be good. Yeah, this is the one hard part about doing this. And like I said, one of the reasons why this is my favorite thing to do at Summit is I walk around the room and I can see when someone's having an issue and you know, you make that connection and you help them through it. And unfortunately, it's really hard to do that remotely. So I do appreciate y'all showing up and sticking with us through this. We try to make it as fun as possible because the community is fun. You know, we're all from different projects but we're family who sees each other once or twice a year. And that's how I like to describe our community. So our emails are in the ether pad if you need to reach any of us. I'm spots on IRC. If I don't answer, I'm on a bouncer. So, but I will try to respond to you on IRC when I get back. I've even been known to IRC off the pony so you never know where I'll answer you from. But thank you all for coming. Again, OpenStackUpStream Institute because it still is OpenStackUpStream Institute. It has not been renamed. It will be Thursday and Friday. So if you did run into any issues and you just wanna go over it again, we'll be working on things similar to this on Friday. And should we advertise the upstream IRC channel for people if they have additional questions. We're in there as well. So on IRC, it's hashtag OpenStackUpStreamDashInstitute on pre-node and I'm Jungle Boy Jay and there's Diablo Rojo, we're all out there. Feel free to ping us if you have a question. I put the channel in the Zoom chat too if you want to. Excellent, thank you. All right, so I haven't used IRC in like 15 years almost. It hasn't changed. Yeah, and I figured that, but I mean, the client landscape is different. Any suggestions on clients? So for a desktop client, I use HexChat, but I have an IRC cloud account also because of the free bouncer, well, free bouncer. It's like free for a month of history. And then if you want like all of the history and to be signed in forever, it's like $15 a year or something. And they have a web client and a app for your phone. So I'm like always available there. And then I just use HexChat when I'm on. There's a Windows client for IRC cloud as well. That's what I use. I'd recommend it if you're planning to continue to be active. Other words, yeah, HexChat's easy way to go. And we cover that more in the Upstream Institute as well and help get that set up. That same like contributor guide that you were walking through has a section on setting up IRC that you can go through and it'll like explain as if you've never done IRC before or it's been a long time since you did IRC last. Like how to register your NIC and things because you do need to be registered to be on the OpenStack channels because we had some really bad spammers. So we did lock things down. But there's instructions on how to walk you through it. So, and again, we'll be going over that on Thursday or Friday. I think Thursday. Are you saying HexChat like X-Men or H-E-X? Like Hex. Hex like a spell. I'm on Mac, I use LimeChat. I also use LimeChat on my phone but I run a ZMC bouncer on my own. Bouncers are very, very nice. Yeah. All right, well, thank you, I appreciate it. Yeah, a great session. Thanks very much. Great, thank you. Take care. Have a good rest of the summit. And hopefully we'll meet you in the future. Yeah. Yeah, this one's.