 So, what I'd like to do is introduce Rai Jones from the Linux Foundation, Rai will be walking you through the various activities today. And if you are not speaking, if you wouldn't mind putting your phone on mute and then just taking it off if you have any questions. And with that, I'll hand it over to Rai. Thank you, Todd. Today, I want to cover a quick intro here to Garrett for people who wish to contribute to Hyperledger. I sent out an email just a little bit ago asking that you set up a local Git client. So if you've done so, could you say that you have in the chat window, it isn't a big deal if you haven't. So this is your, this is Git, which I assume that everyone is familiar with for the purposes of this call. And as you can see, I have nothing checked out. And the project that we're working with is LF Sandbox. So if you have set everything up, you may go to the Garrett page for Hyperledger, go to Projects, List, LF Sandbox, then you'll have a number of options here for the way that you can check this out. For me, it is easiest if I clone it with the commit hook and SSH, copy it to your clip board and then go to your Git window and run that command. I have already done that here. If you have not, you may do that now. The main difference between Git and Garrett is that in Garrett, we do not have pull requests. What you do are you propose patches or changes. So any individual change may have multiple patches. So for instance, this change only has one patch, which you can see here. And the change, much like GitHub, you can see the difference between your base patch, which is I'm adding a file, so there's nothing in the base, and what you have proposed to change. So Craig, is that Craig who said that you had this checked out? If you wanted to check out a pending change, you could go here to a patch that has your name in it and you will have a list of patches and then how you would download that. So if you wanted to download this and make changes, if you wanted to update this, you would click here to cherry pick it and then you could go here, paste it, and you will see that this is a straightforward Git command. And now if I do a Git log, you will see that I have, I'm in this detached state. I have the text file for Craig. And if you wish to make additional edits and changes, you could at this point. But let's look back here to the Garrett UI. If you were logged in, which I suppose you all are, you would be able to reply to any pending change. So this is very much like you would in GitHub, how you make comments about changes or pull requests. So for instance, you come in here and notice that Craig doesn't have his name and so what you might do is insert a comment here which says, needs actual names. You will see that it is in the draft status, which means that it is not published and no one else can see that. So if you go back to the change, it is, again, you will see that your comment is draft. So I would reply and say this and that you have three options to score the pending change. One is the code review, which is, I would prefer this not to be merged or I have no opinion or it looks good to me. All of this is very similar to GitHub if you are familiar. And in this case, it is not good. Slide is similar, but this is for code review. So if you thought that the code in a change that you were reviewing was subpar or you had comments about the structure of the code or it didn't compile, you would set that to negative one. This will usually be set, this score will usually be set by either Jenkins or the other builder Travis. So you won't usually have reasons to set this, but you might if you try to compile it and it doesn't compile, you could say that it is not verified. And then you would post your comments and you would notice that the code review is now negative one. If we go back to the main UI for the project, you will see that this has a code review of negative one. And if you are logged in, please feel free at this point to log in and take a look at any of these changes and make comments or vote on them. What I will show you here is the second stage after you have uploaded a change and you wish to have people review it. You can either add them one by one. Oops. I don't remember your email address off the top of my head. Or you can add a group, which is LFGarrett class. And it adds everyone that signed up for the class with their Garrett account. All five of you should have just gotten an email saying that you have been added. And what you would notice is if you went to the My Changes page, you will see that you will have an incoming review now for this text file. This is very similar to the way in GitHub, where you may tag people with an issue or tag people on a pull request. So in general, you would be following the same workflow where you would be adding either distinct sets of people or you would be adding a specific person that you wanted to have review a code request, a patch. If you wanted to change your vote, you've reconsidered, you are able to go in through the UI and either re-reply and reset your code review or you may simply delete your vote. You'll notice that the code review is now unset. If you look at the UI, you'll see that it is unset. I see we have a review, so let's take a look. It looks like Craig has given it a plus one. So Craig, if you could, go here and check this out and edit the file. I will walk you through how to edit a change, someone else's change. So I will do this with the change for my file and Craig, I assume that you will do something very similar in your window. So what I will do here is reset so that we are in the empty repo state because it is not particularly interesting to carry on there. So this is the key difference. This is the step that is the big difference between GitHub and Garrett. So what I see is that I have this file and it doesn't actually have my name. So that's not helpful. So what I will do is edit the file just using whatever editor you choose. And unlike GitHub, what I will do is amend the commit. And what I'm doing here is I'm saying that I want to commit all of my changes. I wish to amend the previous commit and I wish to sign the commit. This is also another step which is important and I will circle back to in just a bit. So I will just do this part. And what we will see is that we are presented with the same commit message that we had before. And I will say this. So when you are pushing to Garrett, you will be pushing to a special type of target which is refs for branch. So in this case we are working on master branch. So we will push to refs for master. And if we go back and look at my change, you will see we have one patch and the commit message is as it was when I checked out. But then when I do this push to refs for master, because my commit message has the same change ID in it and that change ID is given to you when you do the get check out with the commit hook. So that change ID comes from the commit hook. Because the message has the change ID in it. When you do the push, you will see that what we get is a message that says we have updated the changes. And if we go back to the UI and refresh, what we will see is the commit message has changed and we now have a second patch. So again this is distinct from the way that GitHub allows you to do work on PR. So if we go in here and take a look, what we will see is by default the difference between the base commit and where we are now. But if you were particularly interested in what the changes were that were made by someone else, you can change the patch set that you are doing a diff with. And as you see, this shows the difference between patch one and two. Here the primary piece of work would of course be pushing new commits as opposed to updating existing ones. So we can do that here and I will just get back here to the beginning. And all of this is straightforward get work which you are should be well familiar with. So if I do a get log, you will notice that I have a change ID. But what I don't have in comparison to the previous commit is I don't have a signature. So if I push this, because the change ID is new, it should create a new change set but it should be rejected because it is not signed. So this is familiar to you if you are working on GitHub. You will have noticed that we have the DCO bot which is making sure that you have signed your commits. So this is the same workflow even though the error comes a little bit earlier. So what you can do is a menu commit and just use a dash s and that inserts the proper signed off by. And then when you push, you will see this which is created a new change. So if we go to the UI and reload, you will see that we have another change and it is waiting for Jenkins to come through and mark it as verified or for it to come through and mark it as unverified. Craig were you able to get to a point where you uploaded a second patch? Looks like the answer is no. That's fine. Does anyone have any questions to this point or any differences between the GitHub and the Garrett workflow that I could focus on a little bit more? Okay. Well, I will go through just a little bit more of the Garrett workflow where it is distinct from GitHub. And one thing that you can do is you can abandon your changes if you decide that this is not a change that is worthy of your continued effort. You may just click abandon and put in a message that is now abandoned. You will most frequently do that if you are working on the wrong branch. If you had a branch that was for a release or something of that nature, you could at this point, you could cherry pick it to a new branch. I won't go through with the cherry pick right now. The remaining stuff that you can do is, let's see, you don't really do, we don't really do topic branches, but there is nothing preventing you from doing that. This is very similar to a lightweight feature branch. If the Hyperledger project starts doing topic branches, I can circle back around and touch this up a little bit. I will show you a little bit of the reviewer workflow, which is, for the most part, not something that everyone is going to need to do, but I will go back here and... So now, hopefully, if I reload this page, I will have additional options. So this is what you will see if you are a Committer. And that is that you can put a roadblock in front of a change. And once you have voted negative two, you cannot be overwritten. Other Committers could come in and delete your votes, but no automated process is going to be able to delete your vote or vote on your behalf. Furthermore, if you happen to, if the person who owns this patch set happens to push up a new version of it, it should not remove the negative two vote. So I will show you that here. So what we should have now is patch set three with a negative two vote. I guess it's because I'm the person who voted on it, so I overrode my own vote. Oh, no. Okay. So patch set three does actually still have a negative two. The votes are promoted. If you are here as well, if you are a Committer, you are allowed to vote, to merge, and set the verify bit to verified and post, and then you will have a new button here, which is to submit. And once you do that, the change is merged. If we go over here and take a look, you will see that we have quite a few patches in progress over here on LF Sandbox. If you are logged into the Garrett UI now, feel free to go into the LF Sandbox in the Garrett UI on the web page and take a look at that. You should have the ability to mark your changes as approved and merge them as you wish. If you have any questions, feel free to ask. All right. This is Jeremy Sephard. I don't know if you covered it previously or not, but would it be possible, the significance of verified as opposed to the code review? Is that just sort of arbitrary steps in a workflow that can be customized? Verified is usually restricted to being set by the automated processes. So a build job on Jenkins would usually be the piece that sets the verified bit. However, for right now we don't have Jenkins running through the LF Sandbox verifying things. Verified is usually this code builds or this text file completely renders or whatever the check-in gate is that the working group has set up. The code review block is up code review. It's for the content of the change. There may be additional blocks here. So I will show you. So on this other project, you'll notice that we have an SR column, which is the security review column. So it may be that other working groups add more columns and somewhere in here there's another column. I don't remember what it is. We don't have any open changes with it, so it doesn't matter. As the projects wished, they can add columns or they can have columns added. So you could have, for instance, a localization column, which says that all the localization has been done or something of that nature. Does it answer your question or did I go off on a tangent? No, no, that does. That's great. Is it possible to control who or sort of govern who can do which approvals? It is. In fact, this particular project I have set up so that just for purposes of illustration it is very close to wide open. Usually people's ability to vote is severely restricted, especially on something like this where we will have Jenkins coming through and verifying. You would typically only want to vote that you verified in a particularly in a bad case if for some reason the verify job was failing when it shouldn't be failing or something of that nature. I don't know if you were here to see that earlier when I had not upgraded everyone here. The only options available for code review were negative one through one and the same for verified, but when I made everyone a committer plus two became available. Oh, I see. Yeah, yeah, I understand. Okay. That's great. Yeah, so in the default view, basically you could do CR plus one or minus one and only committers can do plus two or minus two and someone, anyone, I could go through and vote negative one on everything here with just having a Garrett account, but it is provisional. All the minus one and plus one, it doesn't get you, two plus ones aren't a plus two. So it doesn't get you any closer to actually getting your commit merged other than it's nice. It's letting people know that you've looked. Oh, I see. I see. So the fact that it's in America is sort of not really the case, if you will. Sure. It's, again, I will go back to other project. Let me take a look. So for instance on this change, you'll notice that Joshua Spain has given it a CR plus one and it looks like he had a couple of comments as well. So this is where Josh has made some code review comments and it looks like Christian has replied. Usually on this project and please keep in mind that every project gets to set their own roles, people will typically code review plus one and wait 24 hours for any objections or any substantive comments to come in. And then one of the committers who for this particular project would be Dan, Greg, Kevin and Marcello and Wei, they could come in later and merge it. There's nothing other than social convention preventing them from merging immediately. Understood. But if for example we wanted to draw a line between sort of like the rule set that goes for stuff that's in incubation versus the rule set for stuff that's in mature for projects, it sounds like that's something that we could do. Yes, absolutely. The project rules, Garrett has a very rich rules engine and pretty much anything that you need expressed can be. There's no, it's just like get in that. There is no get workflow, right? Get supports many workflows. And Garrett is very similar in that you could make an arbitrarily complex or wide open set of rules around who can commit and who cannot commit or comment for that instance. Right, right. That makes sense. And it looks like there's OAuth and some sort of hash IDs for the users and the code or content respectively. So you sort of know like, you know, I assume that that change ID for example that's shown on the screen, that's essentially a hash of the thing that is either being changed or the combination of it and what it's applied to. So it's, you can not only be sure of who approved but of what they approved. So sort of, the commit ID here, this is a get commit ID, right, that is a hash. The change ID is distinct from the commit ID in that the change ID is constant for a change. So no matter how many patches you submit, let me go back to mine that already merged. So all of these patches, one, two, and three, had the same change ID and that is so that if you make comments, you can go through and see the changes across patches. I can see that my comments were addressed. So the change ID is generated when you do the checkout with the change ID, which I will show you because I believe you joined after I showed this. So this is the commit hook piece of this and this commit hook, this hook slash commit message, this is just a shell script and you can go look at how that is generated. This is 191 line shell script, but it is right there for you to take a look at if you have any questions on exactly how that commit message is generated or how the commit, how the change ID is generated. Well, I guess it's just sort of the broader question of, you know, if we're looking at building software that's going to control money and other high value things, it sounds like GitHub is not sufficient for locking it down, so people go to Garrett and then Garrett gives you some workflow and some entitlements around changes and some tracking of that and a piece of that is at least tied into OAuth and SSH, at least for the back and forths. Because I guess the question would be then is, you know, say somebody downloads a version of Hyperledger and starts running it, will they have ideas, hash IDs that they can check to make sure that what they've got is what we think they should have? Sure. And that would be, I mean, that is exactly, I don't know if I have any changes checked out right now, but I mean that is the hash ID, the, right, I mean this, right so this is like the hash ID on the patch for that piece of the source. And then there'd be a quick, and so it sounds like this is a strong step beyond what GitHub provides straight out of the box in terms of locking down our code base. It is, I believe that the largest motivator here is that we get this for free, so instead of having DCO bot run around behind and approve all the changes, if you try to push an unsigned change it will just be rejected. Furthermore any of the changes that led up to this being your commit hash are still tracked in the public web UI, so you can go and look and verify where this came from. So you can look for this change ID and see what its history was. If I go to the UI here and search for that, it should take me back to the same page, but yes, you can verify exactly what it is that you have and what it is that you suppose that your user has. Nice, nice, and presumably if we start treating documentation as code or as checked in things then we can get the same for, say like HTML pages or PDF or whatever else format the docs are in. Sure, it's a little bit trickier with PDFs only because they don't render so well as source code because they're binary-ish, but yes, if you were to check on HTML it will do a diff or YAML or MD, whatever it is that you're using to control your documentation, it will show that there's a difference and if it's binary, if you have included JPEGs or PNGs or something of that nature then it will show you that there is a difference, but it doesn't display in the UI exactly what the difference is, so there's a little bit more work to do to see. But yeah, you can and I think probably should track your documentation in yet just as any other part of the product. Right, right, and that might suggest that at some point we start migrating stuff out of the wiki, for example, or consider it at least. That would be a consideration for the working group. You could, wikis have, wikis are good in some ways, right, because the barrier to entry is much lower. So that is, does it a conversation that the working group is going to have to have about if they want the documentation in a wiki. Another thing that you could do would be to run essentially an extraction on the wiki and have a bunch of whatever the base format of the wiki file is, export that and check that in, and then people could do the same process on the wiki and say, if I download this and do a hash, is it the same hash as checked into GitHub or Garrett, and then you could do the reverse as well. You could have a wiki where you're doing your edits and then have that saved in Garrett and then extracted for a read-only presentation. Again, that's something very similar to what we do over at AllSceneAlliance. You can, I will show you. So for instance, this is an edit that Jared made on the onboarding guide. And this eventually, once it's approved and the release is approved, will end up on the web page. If you were to go to the AllSceneAlliance web page, this will generate HTML which will be shown to people. And it's read-only in the presented format, but anyone again is able to log in and propose changes. These changes all happen to come from people that are part of the companies that are working on that, but there's no restriction there. Pretty much anybody can upload a change or propose a change. Right. That makes sense. And then presumably, just as with docs, the test cases, automated testing, some of that could be put into this as well. Absolutely. So that would be something similar to these changes which are made to the CI management repo right now for Hyperledger, and this is standing up the Jenkins instance. So I don't know exactly what's in this change, so let's take a look. Not much. Fixing the path. This is just YAML, and any, you know, any text format could be in here. So provide your text cases are specified and something that people can read, then sure, you could just make it such that, make it part of your process that you edit those through Garrett changes as opposed to through any other changes. Gotcha. Nice. Does anyone else have any questions or was there anything that I should cover in more depth? I guess with that, I will give everyone 20 minutes of their morning back then. Thank you for your time.