 Alright, thanks everybody. Delighted to have you here. Kenneth Hoster will be speaking to us today. He's a PhD from Gantt University. Works in the high-performance computing team there. He also is the maintainer of EasyBuild, a build system for high-performance computing deployments. To it, Kenneth, it's yours. Alright, thank you very much for the introduction. I should say I'm not the only maintainer of EasyBuild. There's more than one, which is good. So what I want to talk to you today, talk about today, is the work that we have done in EasyBuild to make it easy for people to contribute back to EasyBuild. And now explain why we're doing that and how we're doing it. So first off, I'm sure most people here know what GitHub is, but I felt obliged to have a slide on it. It's basically the place where open source is being developed right now. It's absolutely huge. There's 24 million users, over 60 million repositories out there, and they recently crossed the boundary of 100 million merged pull requests. So that's absolutely amazing. It also has an issue tracker, code review stuff, Wiki, websites, a whole bunch of things. Underneath of GitHub, there's Git, which is the version control system that Linus Torvalds created. So the same guy behind the Linux kernel. It's certainly the most popular version control system today. There have been many others in the past, and this is what's underneath Git. So it was designed to have very good performance, even for very large projects like the Linux kernel, to support nonlinear development, distributed workflow, working offline, and then getting back online to share your work. And it was also designed not to be like the old CVS system. That was one of the explicit design goals. Internally, it works a little bit like blockchains before blockchain was cool. So they have that. All the hashing and all that stuff going on is pretty much also what's going on in the blockchain. So most of you will be familiar, hopefully, with the Git workflow a little bit. Even if you're not, that's fine. That's sort of the point of the talk. So don't worry. So typically what you do is you edit the file. If you want to use ZMAX, you can. You then go to Git, you create a branch, and you check out the branch. You want to commit your work by staging the file with Git add commit and hopefully useful message to explain what you did in these changes. And then you typically push it out to a remote repository in general, which is typically GitHub. So that's where you share your work with others. That was very high level what Git is. Now I want to go back a little bit in history and look at version control. This is not my idea to do this. This was done in a blog post on git-prime.com as well and basically stole their idea and expanded on it a little bit. So what they are doing is looking at the search traffic via Google Trends for all these version control systems. And 100% here means the highest search volume we will be seeing in this graph. So CVS was very popular for a long time, but since certainly 2004 it has declined a lot in popularity, of course because of other version control systems coming up like Subversion, like also Mercurial. So all of these names are hopefully at least familiar to you. And then Git came in. And Git, the search volume of Git quickly went up and the others, mainly Subversion and Mercurial, suffered from that basically. So Git became a lot more popular and Subversion and Mercurial are like at 10% in terms of search volume in Google compared to Git. Now why did Git become so popular? What happened there? Is it technically all better or is there also other factors? So Git started here. I think this was Git 1.0, 2005. For a long time it was going up a little bit, but what's this spike all of a sudden? So something happened there. That was basically GitHub. So GitHub launched publicly April 2008, which is here and then shortly after you see the spike on interest in Git. So at least that's my conclusion from this. You can never be sure, but let's see. There's another spike here. So this was a news item, like Linus Torvalds got a GitHub pull request to the Linus kernel and basically said, no, I don't want to get a pull request because they're doing it totally wrong. Send me a patch via mail and that's how we work in the Linus kernel. All of the people were surprised and certainly for me that's what I learned that Linus Torvalds was the designer of Git. I didn't know that before this. So he designed Git, which is underneath GitHub, but he doesn't like GitHub. It was a bit painful. So the interest in Git seems to follow the interest in GitHub. That's what I get from this graph. And subversive number curtail are like one tenth of interest if you want to put it like that in terms of search volume. There's another small peak here. This is like the 100 percent, the highest search volumes they have seen for Git up until now. Can anyone guess what happened here? This is pretty recent. This is like, forced them last year. Yeah. Sorry? A security issue? It could be that actually. What I found was like tech companies complaining about Trump his immigration ban and GitHub was one of them. If this is actually the peak, I'm not sure many people were like, Git up, what's Git actually? And they started searching for it? Yeah, that was it. So it's Git popular thanks to GitHub. Well, there seems to be a correlation but you can never really be sure. Maybe there was even some kind of feedback loop. So Git caused more interest in, GitHub caused more interest in Git which in turn made Git help more popular because people had to collaborate. Maybe that was it. Or maybe it's just because GitHub has Git in the name and Google Trends, you cannot really pull those apart. So I'm just talking bullshit, but I don't know. It's a popular version control system out there today, so I don't think anyone will contest that. So you'll basically have to learn it if you want to contribute to an open source project. You're kind of stuck to it. Everybody is. So you'll have to learn it. You'll have to learn how to use it. Now that's a bit of a pain point in Git. It has a pretty steep learning curve. This is the top three questions on Stack Overflow that are tagged with Git. Now the questions here are rising like how do you undo a commit? It's not really straightforward. Even from the help, how do I delete a Git branch both on your machine and on GitHub? How do you do that? What's the difference between Git pull and Git fetch? It sounds like the same, but it's very different. These get a lot of views. This has six million views. Now in comparison, the how to exit VIM only has 1.3 million views. So people seem to have a lot more problems with this than exiting VIM. So there seems to be an issue there. This was a recent tweet from a guy that works at GitHub that had to Google something to undo a last commit. So this stuff is hard. I mean, even people at GitHub find it hard. I hope he was okay with me using the screenshot of his tweet. And this is on Quora. So one guy asked just in general why is Git so hard to learn and then many people were replying. So many important people at important positions. And this guy said it's a little off-source control system. And that's not a good thing. So yeah, it's difficult. Also, Git is not for everybody. The main target audience is software developers. People that develop software have to work together in teams to develop software. It makes it very easy to do that. It was designed for these kind of people. Now a lot of computer people to use a term like this don't need it for the daily work. If you're not really developing software, you don't really need Git. So why do you have to learn it? Some don't have the time to learn it. Others try to learn it but can't seem to figure it out. And not everybody knows somebody that can help them because that has been very helpful for me. Certainly when you're learning Git, you have a Git expert in your office and whenever you're stuck and you can ask somebody, is it okay to do Git reset hard? That's very useful. If you don't, then maybe you shoot yourself in the foot and you'll learn even less of Git than you should. And some people don't want to learn it. And that's okay. If you don't want to, then you shouldn't feel forced to. Because it's so hard, and many people don't need it, it can be a major hurdle for contributors. So people want to contribute back to your project, but they have to learn Git first to do that and many people don't like this. And then maybe you'll just lose the contribution and you'll say, yeah, whatever. So the stuff that people have to do to contribute back is already quite substantial. So they have to know your project a little bit. They have to probably know the programming language you used or maybe use multiple ones in the same project. They have to know the code base a little bit. They have to get around, find their way. There are several project-specific policies and expectations that they have to be aware of. Like the normal Git workflow for that specific project. What do I have to test? What is being tested by reviewers and maintainers, what are the real rules? Just how do I implement the bug? What do I really need to worry about backwards compatibility or not? All of that stuff. And then on top of this they have to learn Git and GitHub as well to even be able to do the right pull request. The way the maintainers actually want to see contributions. So the initial effort for people new to your project is huge and it's very, at least in my experience, often underestimated. You need to know all this stuff before even creating a contribution and then on top of that, Git and GitHub as well. Of course documentation, sorry, let me go back. Documentation here can be very useful but it's not sufficient for everybody. So people don't always read documentation, at least not the way it was intended to be read. So it's not enough. So a little bit about the easy build just to have some context here. It's a framework to install scientific software on HPC systems which is not easy. It's not like installing Gzip with ConfigureMakeMakeInstall. It's a lot more complex than that and partially because of the scientist writing software. It uses easy build, uses easy config file as recipes and I'll show one. So you have a reasonable idea of what it does. It's written in Python syntax and it's basically key value definitions. It tells easy build which version of the software to install and so on. One of the most common contributions we get to easy build is people add a new recipe, a new easy config file for a new software version for example or built with a different compiler or anything like this because it's quite easy to do so because you can use an existing easy config file, copy it, change it a little bit and then give it back if it works for you and that may be a very valuable contribution even though it's a little bit of work. People, it's like a statement this works for me so it probably also works for you and that's a very valuable contribution. We would like to see many of these. Now to learn more about easy build I have a talk in the HPC Dev Room tomorrow that compares easy build with other tools so if you want to learn more about easy build you can come there if you can wake up early enough it's the first talk of the day. So how does easy build work? Well you do EB which is the main command you give it the name of an easy config file and it will pick up that file parse it, see what actually wants to be installed do the installation it completes and then the scientist can use the software. So it consumes these easy config files that look a little bit like this now I'm not going to go in too much detail here but one thing I do want to show is that it's very easy to tweak so this is a software version you can just bump it if there's a new software version and give us back that easy config file if the installation worked you can change the compiler toolchain that was used to install the software maybe tweak the dependencies in the new version of Python all of these things are quite trivial to change and then maybe you want to contribute it back to easy build hopefully so to contribute back well you'll need a GitHub account because the easy build repository lives on GitHub if you don't have that you'll need to create it you'll need to fork our easy configs repository into your GitHub account so you have some place to contribute from and then you clone the repository this is quite easy you only have to do this once these three steps right and then you start working with Git so again you create a branch you add the easy config file which you had to put in the right place and give the right name first you do the commit you push it to origin which is probably your fork on GitHub and then you go to GitHub if you're quick enough then you can click to make the contribution which will give you this screen then here comes a little bit of policy easy build policy comes in we expect you to make sure that you target the develop branch which is not the default we hopefully we ask you to format your pull request title like this so we know what you're actually adding to easy build maybe some useful information in the description and you better double check your changes to make sure you're not accidentally doing something wrong there so this is a bit of manual work and then hopefully you can click the magic green button to create the pull request and you're done well no you're not done yet this is just starting the contribution so now our Travis so our Travis configuration is going to trigger automatically it's going to do some tests on your easy config file mainly looking like is it actually sensible does it have all the dependencies for other stuff does it actually parse so very simple things like this then at some point the maintainer one of the easy build maintains will review or pull request somebody will test it so actually do the installation that your easy config file describes and then hopefully also report back whether that worked for him through the review the reviewer may ask some things to be changed or maybe Travis fails and because of that you have to go and change some minor things which means you have to go back to git so okay back to square one and maybe you have to do this even multiple times because it's typically a review cycle and you get some feedback over and over again that may happen certainly if you're a new contributor this is typically what happens okay so you've got the review there were some small changes requested you say okay I'm willing to do the extra effort go back to git first of all you have to figure out the branch name you used for your pull request you have to look at the pull request copy paste the branch name and see how to remember what you used in this case we use examples so we check out the example branch we again make the necessary changes as requested by the reviewer do a git omit of all our changes now be careful with this because if you have other changes it will suddenly push them in your branch as well which you may not want to do you push back the updated branch in your fork on git help which will also update the pull request and you have to do this a couple of times so this is a lot of overhead there's a lot of manual steps you need to know git a bit you need to come up with a funny branch name do four git commands to set up the branch and push it to git help you need to click around on git help to open the pull request and fill in some boxes and now in responding to the review we have to do three more git commands to fine tune the pull request and then afterwards if things got merged you have two branches to worry about the local one on your laptop and the remote one on git help and all of this assuming that you actually know the project policies already which may or may not be documented an easy build they are but nobody reads documentation so they don't know and it also assumes that you don't mess up any git commands because if you do something wrong in between you may even lose your work or anything like this alright so we have to do better than this there has to be a better way the situation that triggered me to work on this was the race we were seeing in contributions in easy build so this is the green boxes 2013 blue is 2014 in 2015 we had about twice the amount of contributions we had before this was going up quite quickly almost a thousand pull requests in a single year and I was almost doing this by myself reviewing contributions it just didn't scale anymore I was getting really worried like we're not going to be able to keep up if this keeps going but of course we want the contributions we don't want to tell people to stop contributing there's a bit of conflict there also a lot of people were struggling with the contribution procedure with the policies mainly with git stuff they were like I tried something that didn't work or messed up my branch closed this pull request open a new one lots of overhead there we trying to explain to new people how to do things right like try this git branch and try a git reset don't do dash dash hard because they're going to lose your work so trying to be careful lots of back and forth, lots of time being wasted some people even stopped contributing because of this so they didn't, they were not familiar enough with git yet and they said ok I can't figure this out I don't have time for this forget it leave the contribution close the pull request and we never saw them back that was not good and then the irony here is easy build is a project that aims to automate installations and then you have to do all this manual work to make a contribution it didn't make sense so I started working on the git hub integration that we have today and easy build I did this mostly over Christmas just because I was frustrated enough the week before that I couldn't get it out of my mind and I wanted to have some solution or at least try to come up with a solution so the idea was to automate the contribution workflow to make it easier for people to make them lose less time and also to avoid direct interaction with git because many people were not familiar enough to actually do the contribution the initial implementation had support for a bunch of things which I'll go over in a bit and for now it's limited to easy config files we can actually extend this to other parts of easy build and make it easy to do contributions there as well so underneath this is pretty basic there's nothing really fancy going on there's a git python library which is a wrapper around git that you can just talk to git from python which is it works pretty well the git hub has a very good rest API that you can talk to so this is just to automate the interaction with git hub so you don't have to click around with the mouse or even go to git hub yourself you can automate this whole workflow and then we use the key ring python package to save the git token that we need to talk to the git hub API on your behalf so with your account without you having to enter a password or anything this is specific to python but you can do the same thing in any other language you can find libraries basically all the thing you need is something to talk to git and then something to safely store the token that's general enough that any language should really have it so what did we add we added support for opening new pull requests in the easy build command line so eb new pr you run it like this you do eb new pr you give it an easy config file which can have any name doesn't matter one single command no git commands no interaction with git hub that was the goal what this will do is it will fetch the develop branch from the upstream copy this easy config file in there to prepare then it will create a branch with an automatically derived branch name you can pick your branch name if you really want to if you want to be funny you still can but this does this is just a timestamp and it checks from the easy config file which software which version and tries to guess a reasonable name from that you can actually just tell branches apart relatively easily it will push this branch to git hub for you just git push origin branch right during the copy here it's actually also renaming the easy config file based on what's in there and also getting the location right so you don't have to do it yourself every easy config file you contribute can be test.eb and if you do new pr it will rename it properly the way you're supposed to do and then here it's preparing the pull request so it's going to target our develop branch it has auto generated a pr title for you the way we would like it to have and of course you can override this description the default description is just this was created with eb new pr which is useful it's a bit of promotion for this as well and then it gives you a short overview pretty much like git stat does and it opens the pull request for you by talking to the git hub ebi so there's a lot of stuff going on here in the background but you only do one command eb new pr that's it and everything else is done automatically so to summarize this is what you do manually moving renaming files moving in the right location a bunch of git commands now logging into git hub and clicking around to open the pull request now you do this one command it does one single ebi command no git no git hub it pulls stuff so it parses the easy config file to get all the renaming right and the pr title right and it ends up saving a lot of time pretty much the same thing for updating existing pull request so you do ebi update pr the pull request number you give it the updated easy config file which again can have any name it doesn't care and here we force you to give a commit message yourself to describe the changes because this is typically changing a file that's already there rather than maybe something new from the pull request number it will automatically determine the branch name so you don't have to tell it it knows it talks to git hub what was the branch name for this pull request it will check that out again in a temporary directory it will add the file rename do all of that stuff again so put it in the right place it updates the files moves it to the right location shows you an overview so this was just changing one line right one line removed one line added and then it pushes the modified branch to git hub to open the pull to update the pull request and that's ebi update pr again lots of stuff going on in the background figuring out the branch name checking out the local branch going to the right place changing the file doing three git commands to push it is now just one command again lots of automation you save a lot of time one side effect of this is that you don't have a local branch anymore to clean up because this is done in a temporary directory when the update is done it blows away the temporary directory you never see the local branch so there's no cleanup either the reverse kind of is to use easy config files from a pull request so somebody has done the pull request and you want to test it you need to pull in these easy config files on your system to play around with them you don't have to do that manually again no git commands you do ebi from pr you give it a pull request number it will pull in those easy config files you can give them to easy build and do the test installation so this is how we test contributions you can combine this with upload test report from pr and pull test report together will do the installation and push back a test report in the pull request to notify the contributor like this also works for me and test it on this system and so on so this is what happens it adds a comment in the pull request with your account it uses your github token so it's your account so in this case it failed for me and it worked for me and it failed for Adam and then inside so it has a link here to adjust if it was a successful test report you get success here you get a bunch of details including some information about the system like which processor which OS it collects that and pushes in in this test report if it fails you'll get a fail here and you'll get a separate link with the build log so you can check why it actually failed you can check the errors of the installation and dive in and maybe make a suggestion to the contributor okay this didn't work for me for this in this reason so you'll need to make an update to your contribution that's all really nice we were quite happy with that it was working quite well so the github integration got extended quite a bit I'm not going to cover all of these some of these are very detailed but there's a couple that I want to go over we have a check github so the new PR update PR all of this made it very easy for people to contribute it automated the whole workflow but they still had to set up the github token had to make sure get python was there had to make sure the key ring model was there that the token was installed in the right location and that they didn't mess up copy pasting the token all of these things and we were getting many questions like I want to set this up but I'm not sure if it's actually right is there something missing I have no way of checking so we added check github that does a bunch of checks if all of these are okay then we know that the github integration works and it basically tells you based on these results what it can do so in this setup all of these work and if it doesn't you'll get a useful error message here and at least then that way we get more information like you have this part missing this is how you can fix it review PR this is very specific to easy build so you can review PRs on github like it gives you a diff we get a lot of pull requests with new files new easy config files so there's no diff there's just this big green box on github so that it means that the reviewer has to do a visual review sorry what we expect reviewers to do what we hope to do is that they compare a new easy config files with existing ones because if it's just a version bump you really want to see okay this is just a version bump trivial I can test it if it works contribution is good to go doing this manually is annoying because you have to find easy config files that are close enough that you can compare it have to do the diff manually because github doesn't have this concept right you have to figure out what is actually relevant so you pick the one with the same software version or the same tool chain or what if none of these are there so in both in preview PR and review PR we have this this is the output of review PR so for a particular pull request it will go and find the closest matching easy config file so this is one for bump tools 251 that's the contribution we have one for 250 so this is a pretty close match right and it shows you the diff the version number was bumped the checks almost bumped everything else is the same this looks like a very good contribution so you test it if it works contribution is good to go contributors can do the same thing with preview PR so before actually opening the pull request they can run this see the diff and then see okay this is the only difference by version number basically so this is probably a good contribution so it checks with the current upstream because since you have copied the easy config file stuff may have changed on our end and you may want to need to see that as well also for merging pull request we have a command or an option at least it does a couple of checks so this is for maintenance of course a contributor cannot do this this is to help ourselves it will verify whether contribution is good to be merged so is it to the right develop branch does it pass Travis does it have a test report that was submitted with upload test report and was it successful is there approved review so we still forced that a maintainer doesn't approve the review on github a visual check is there a milestone set so that's a detail if all of these are okay the pull request is good to go and this will actually merge the pull request so a maintainer doesn't have to do the double click on github this can do it for them they don't have to do the visual check if all of these ticks are there that happens automatically so it helps us we can very quickly open very quickly merge pull request once we think everything is okay and a double checks for us so we can't make any mistakes there the bot that I wrote so this happened a lot later so we have Travis checking pull request doing very simple test unit test basically if Travis fails you'll see a red cross in the pull request but that's it if you don't go to the pull request and visually check it you don't see that Travis failed there's no there's actually as far as I have found no way to configure Travis to notify both the contributor and the maintainer so it then cannot do a comment in the pull request or something there's just no way to tell it to do that so I wrote a bot that does that for me there's a bot that keeps an eye on Travis every time it sees a test for a particular pull request failing the bot grabs the failing test from Travis and adds a comment in the pull request triggers a notification and gets up to everybody involved seems to work really well the reason we did this is that to tighten the review cycle or the update cycle you have for contributions if somebody does a contribution and you never check back then Travis may fail but the pull request is just sitting there it's not happening if the bot drops in a comment they get a mail they see it failed they check why it failed oh this is an easy fix they fix it and then Travis triggered again and hopefully goes green after ok so I'm wrapping up slowly what kind of impact has this had on contributions so we I started implementing this in 2015 where we had about the thousand pull request in the easy conflicts repository at the end of this year this was implemented so let's say in January it was usable for the people that really wanted to and in 2016 about 500 pull requests were opened with new PR so that's pretty good and that's pretty much like the difference you see here so was did we get more contributions thanks to new PR we probably did it's hard to tell but I attribute this big raise to the automation we have the year after that almost doubled so today about 63% of the contributions we get are through new PR so people are doing contributions manually less and less which was sort of the goal right I mean even if you know get it helps you a lot because it does a whole lot of automation they have a lot less things to worry about you don't need to juggle branches makes things very easy even for experienced people so this is for myself if I add an easy comfort file this is how I do it I never do a manual branch get anymore I use get all the time but not for doing contributions yeah so we had 80% more pull requests and 16 and 17 compared to 2015 I think one of the main factors is because of the whole automation we have and the same graph with different colors this is green is merged red is closed pull request and blue is still open so in 2015 we were sort of keeping up with incoming pull request like 85% about it's a little bit lower here was actually getting merged let's say 10% was getting closed because there were good reasons to close them the ones that were open or maybe stale pull requests contributors never got back to them or there is some issue there that we never managed to fix so it stays open we should probably close these as well and just get them out of the way because they're probably not important anymore today even though contributions were really raising quite quickly in 2016 we were able to keep up the 80-85% merged so that's thanks to things like review PR, EB merge PR so that automate things a lot for maintainers as well and save them time that means they have time to do more reviews to test more contributions pretty much the same thing in 2017 who knows what will happen in 2018 so I'm reasonably sure that keeping the 80-85% merged to that level that would have been impossible without the automation we would have to close more pull requests or just keep them open ignore them I don't know what would have happened so to conclude I think it can be a major hurdle for contributors that's what we saw in Easy Builds people that are not software developers but that still want to contribute to your project and their contributions may be very good so you don't want to miss them it can be a hurdle there that stops them from contributing you can actually automate pretty much the whole workflow which is good we did it with Git Python and the REST API of GitHub which is very well documented today contributors don't need to use Git anymore if they don't want to they still can we still happily accept pull requests that were done manually we can't really tell the difference or maybe we can because you need to complain more about them or get some more work done even if somebody opens a pull request manually we still get the benefit of review PR, merge PR upload test report that still works even if it was done manually there's no there's no impact there so that's good so I think we have gotten more contributions thanks to this we've been able to keep up with incoming contributions even though it has been going up quite a lot and yeah there's less time wasted overall for everybody involved both maintainers and contributors that's what I had so I'm happy to take any questions that people have yeah how does Git scale up with getting many contributions really well we're not the Linux kernel the Linux kernel gets 10 or 100 times the amount of the volume that we do no so Git was really built to get lots of contributions lots of changes like this it handles it perfectly the special solution for easy build can I benefit in other projects that's a very good question so that's actually an idea I've had to maybe make this a library of some sort that people can talk to it's an option but it's not the project I want to start I already have too much work with easy build it's not something else I want to sure it's all on GitHub so the whole GitHub integration implementation is in our repository it's a GitHub.py file somewhere GPLv2 you can use it you can take a look at it how we did it and maybe inspire yourself like I said I think this is easy to do also in other languages if you have the right libraries for it you can do it there's a boot somewhere here at FOSDEMGitMate.io you should probably take a look at they do not this but also a lot of automation around this I was talking to the guy and he was stuck at his boot he couldn't come here but I hope he checks the video if he's watching high they had some ideas like this as well and they will probably look at what we did and get inspired by this hopefully so you may see it as a service even somewhere rather than a library alright I don't know if you do I mean easy build is a Python project so you can very easily access the code the code is always there if you find a bug somewhere and sometimes even if you don't know Python you can dive in and say you got this wrong true has to be a false whatever something like that that's an easy patch but then you have this updated Python file and then you need to learn git to push it back so something we want to do in easy build is eb newpr let's say tools.py which live somewhere newpr could even figure out where it has to be because it can check what's in the file put it in the right place create a branch push the branch to GitHub do the pull request why not not everybody is a developer if you're an active developer I use git all the time don't get me wrong it's very good if you know it and if you need it every day if you're doing software development you should learn git don't get me wrong if you're a one-time contributor that happened to bump into a bug that was easy to fix but you don't know git it shouldn't stop you from contributing back it's two different worlds we have a lot of CIS admins like the user support on supercomputers they don't develop any software but they have to install software so they use easy build and they find bugs in easy build and try to fix them because they're proud that they can fix it if you fix a bug you're very proud that you can contribute to the back right you have to learn git first to be proud yeah maybe you won't in the back yeah I can I can I heard you say big problems with scientists there it gets hairy and we don't at least in this there's no solution for that easy build doesn't no so at the time you create a pull request it will pull in the latest upstream automatically so it will pull our develop branch and base your changes on that so at that time there's not going to be a merge conflict but of course as the pull request is open then suddenly a merge conflict may appear and then yeah then you're really stuck to git then there's no other option what we then tend to do if people don't know git is we can grab their branch we can fix the pull request the merge conflict for them give them a pull request on their branch and tell them look this fixes it just merge it even if you don't know what's going on merge it trust me it will open it will update the pull request and they will see still what we did which is hopefully nothing just fix the merge conflict so then we can do that if we really have to in easy conflicts it's uncommon to have merge conflicts because usually you're working on new files and then you'll never have a merge conflict yes yes some people do but we discourage it the online editor yeah some people have done it but you end up with branch name like patch 1 patch 2 patch 3 patch 4 patch 100 and then as as a maintainer like patch 100 what was this about again and it's still a lot of they still have to do the manual pull request and things like that still clicking around for some people that works better people that use easy build are used to using a terminal so they're happy there and then they're usually happy with using one command to do get something done but it still happens we're not blocking that yeah like in documentation that's actually exactly where we see it a lot there's a type in the documentation they found the file they do an edit and GitHub will create the branch for them right yeah and even make the pull request for them I think so it's very it happens sure well certainly true that that was the three steps you still have to do create an account fork the repository do a git clone well the git clone is actually not really necessary anymore with not today because we push the branch to GitHub and we talk to the GitHub API to open the pull request if you have ideas there I'm keen to hear them because then we can get rid of this that's what a Linux kernel does so there must be something right there it would actually be possible if you don't have a GitHub account ebnewpr could trigger a mail to somebody and then you could then have like a cron job that pulls in the mail and creates a branch on somebody else's account yeah it could work you could actually make it work but is it creating a GitHub account really that hard if this is a hurdle for a contribution then I don't think you care enough to contribute BitPocket, GitLab, yeah sure sure maybe people don't want to have a GitHub account yeah sure you have to agree with stuff that's a good point it could be done I don't think there's any technical hurdle there you just need some other way to grab the patch and somehow still get it on GitHub because that's where we're going to merge it but you could do it sure yes because we've never had the question from somebody I don't want to have a GitHub account but still want to contribute back it hasn't happened so I don't think we'll spend time on it for now but in general you could do it any more questions if not I uploaded my slides follow them website I hope it was recorded so show it to your friends thank you