 Okay. Welcome everyone. This is Jenkins documentation office hours. It's the 25th of January 2021 reminder that we live by the Jenkins code of conduct. So it'll be nice to each other. Here's what I've got for topics. Oh, let's see Vlad, we need to note that here. The Jenkins contributor summit and how we deal with the documentation track as to purpose as to propose topics. And then we had pull request progress and encouraging new contributors from underserved communities. Any other topics we'd like to add. And pull request progress. The Docker install instructions updates. Merge. Okay. Glad any topics you wanted to be sure we're on the list. Related to the latest item that you added. Mark, it's about Docker installation I noticed on GitHub you have wonderful repository related to Docker Docker LFS I guess it is called. It is under your name. And I noticed that some branches are ahead of the master so they never merge into master. So maybe you can just, well, whatever you want, spend a couple minutes or a couple seconds describing the process about this. Because usually I imagine into master but I noticed that well branches I had of the master by many, many commits and so it's kind of interesting. Just if you want to share your very happy to have very happy to yeah that's that's that's one that's yeah absolutely let's put it on the list will have some fun with that. Okay, anything else that you'd like on the list. Yeah, I noticed that well it is to Docker. I'm sorry, LTS 2633 right now. Yes, already. Oh, and you know what I did not update the. It's embarrassing. That's great I mentioned it, and then have failed to update does the install instructions. Okay, download download is updated already. Right, but Blue Ocean one dot 24.4 has released update completed. Not one I was proud of, but, but I missed the major release of a new LTS version today. So that's that needs to go under the checklist. Add to the checklist or automated until automated. Good. Any other topics to add to the list. Okay, then let's go ahead with the session. I'm going to quick hyperlink here. Okay, so I had, if it's okay I had put top topic this concept of a Jenkins contributor summit. Because it's something we've done before but this year's needs to be different. So we've done a contributor summit before where we use the fact that many jank or some Jenkins contributors many is probably too strong 20 to 50 Jenkins contributors commonly find themselves at Fosdham in Belgium. Each February, it's a large open source software conference. And at that conference we would gather together the day before and have a contributor summit where we talked about the Jenkins project. Jenkins development and the Jenkins roadmap. Well, this year, Fosdham will be entirely remote. And it'll be February 6 and 7 Saturday and Sunday, but we realize we don't have to tie ourselves to happening the day prior to Fosdham. So we're going to try an online format for the Jenkins contributor summit this year with a format that looks like this. So we'll start with an introductory session that we encourage everyone to join who wants to participate in any way in the, in the summit. All contributors are welcome encouraged. It'll be a 90 minute session where we'll introduce some concepts. Give a summary of how things are going where we're working and where we're not working. So this is for everybody but then beginning with that at that moment on day one and continuing through the closing session. We tend to have separate sessions in small blocks of time throughout 24 the 24 hour periods. At times that work for the participants so if someone is in the Far East, like Raihan Shoal for instance is in Singapore, or we have some contributors in Japan. They are in China they can meet during their working day and have conversations about topics like Chinese localization or about developer experience as they see it. Others who are at different time zones can meet on topics in their time. In these segments are subsets of the whole group that people can use to explore ideas and identify things that the Jenkins project would they would like to help and things that the project can do to help them as they help Jenkins move forward. Then we'll end with a closing session, a two hour block. We encourage everyone to attend it on day three and that will include a summary of all the parts and pieces that were presented. So here are some of the suggestions that have gone into the, what should the opening session look like. And we've got proposed presenters, etc. Notice there's one topic right here for us documentation. The intent here is to invite those of us who are in office hours to come to this and will host sessions relative to documentation in this three day period. Then to give a hint. Yeah, so any questions so far on on the idea topics or comments suggestions. The reason that this is very current contributors experience contributors right. Actually this is for anyone who's willing to contribute. It doesn't have to be, you don't have to particularly be experienced but you. The intent is that you're willing to continue contributing so you're coming not just asking for things. You're coming saying, here's this area where I plan to contribute I'd like to coordinate my plans for others who are like minded. So, how do we handle the mix, if, if we're not restricting it to experience contributors, we can get people who need to learn the very basics about how you do that how you work in this environment. So, so if they, if they come in with with no experience they say I've never done this before will will rely on the session leaders to keep it focused on where should we be going not on how to introduce them to to being part of Jenkins. Now we do have a topic around. See where is it called it's the developer onboarding track here that may may focus intense it's proposed that may focus intensely on what does it take to onboard new contributors. And in the documentation track we know we need to do a better job of onboarding so we've got that as a as a possible topic as well. So, I've never done any this before but I'd like to but I have no idea how to do it. I think it's something we tell them, you know, this is not the place you're going to get that information I guess well for docs we tell them show up at the, the weekly, this meeting. Right. Right. If someone if someone shows up and says hey, I need, I need coaching on how you do this thing will will deflect them away from the coaching and say hey this is focused on vision and direction and plan. More than it is on coaching specific contributors and please stick around and participate and listen to that and then come to these other sessions and we'll coach you up. Yeah. Absolutely. Yeah, so I could imagine us having Google Summer of Code students coming in and saying hey, I could use the onboarding. Uh oh looks like I've got to switch my headset. Sorry, my headphone set just told me it's getting tired and needs to be recharged. So, I'm going to go ahead and oops. I'm going to switch from one audio system to another I'll be offline briefly. Are the winds blowing where you are. Don't know if you can still hear me or not. There you are. Yes, the weather. Yeah, winds, winds are blowing a little bit yes, and rain is going on a little bit. Yes, you've got rain. Oh it's sunny here but windy is. Well, is that any better. It was fine before but this is still not. Yes. No, that's fine. Yeah. Yesterday was the rain. Yeah. And more I think tomorrow night or something. Oh really, I didn't know. Yeah, we this one's going to be big they're talking seven to 11 inches over here. They've evacuated the mountains. Really. Now I can hear. Yeah. A lot of surprises on different different areas on different levels. Yeah, all the micro climates yep. Okay, so can you hear, can you hear me okay. Yes, yes. Is that better. Can you hear me louder. Yes. Great. Okay, sorry about that my. I didn't realize I was getting low on batteries. Okay. It happens. So the idea here is that we use this, this summit as a way to gather people who are interested in advancing and contributing Jenkins and help them coordinate their efforts. Excellent. So as, as one where there's some cross coordination going on, there's a proposal to do a security track that may actually involve people from infrastructure from the security team core developers plugin developers talking about how they approach how we approach heightening security in in the Jenkins community. And Liam Newman has agreed to that he's willing to participate in the pipeline offering track that wonderful. Yeah, so we're, and we'll continue recruiting trying to find the right people to, to be participants in this to help us advance the state of things as well. Now that leads us to our next topic, this one, which is a proposal for how I think we ought to prepare ourselves, prepare the doc SIG for the contributor summit and what's happened is Daniel Beck asked a good question. Okay, Mark, do you plan to restructure the documentation so it's clear, better, better, more consistent and more evenly laid out. I've noted that hey we've got, particularly with many things that are copied from the wiki we're getting just things that are arriving sort of in a scattered fashion. And so the proposal was that I discussed with Zenab and with Kristen and on Thursday was, what if we assembled a structure discussion where we talk about an out on infant to an inventory of the documentation. That includes, let's, let's note that it's includes the genuine www.jankins.io and wiki.jankins.io in the inventory so include them both. And then begin an outline of which information belong square. The idea being, okay if we frame an outline for information we've already got that will give us a good hint of where where things need to go and is this is the documentation structure reasonably correct. Are the two of you willing to assist with that kind of an exercise. Absolutely. It really needs to be done. What about a subject that I absolutely hate which is writing standards. Oh, that's a good one yeah I hadn't thought of that I'm not sure what to do with that though so we've got some, we've got some standards. So writing standards and so is this like a style guide is that what you're thinking. Yeah, yeah, style guide, because the, the half asked I hear that you and Tammy have an agreement to steal from each other. When you want to, and you will go after each other and you won't coordinate, etc. Tammy has put together a very good style guide for our docs. And there's no reason why the open source community has to stick to those but there'd be advantages to us it might be worth us contributing this and saying does anybody have any objections. Okay. You know, there's a few things that are missing. There's a couple things that aren't necessarily how I would vote but but it's decent. Yeah, that's so that's a that's an interesting place to to consider as a as a starting point we've got we I think we have in the contributing guide has some style information already so that would be a good place to start the conversation. Yeah, we should compare that and see where you know. Yeah, good, good idea. I hadn't thought of a style guide I like that a lot. But it's the other someplace I get when I start reading this stuff I kind of want to start screaming have you guys ever heard of a topic sentence. Okay, engineers like to give you a paragraph of history and somewhere towards the end of it they'll tell you what they actually plan to talk about. And it's like third grade guys third grade. Okay. Yes, yeah that I think that's a that's a good. That's a good, good item to do and I would love to have a proposal there on hey. Let's see if we make would you be willing to check with Tammy if she's willing to allow that to be reused or used right yeah yeah I'll confirm with her I can't believe that she wouldn't but we need to confirm so. Let's clarify where trying my understanding initially, we were trying to get rid of Vicky Jenkins I or is it still our goal, eventually, or we're trying to keep both Jenkins the radio and Vicky Jenkins. Good, good question. Yeah, so that's migration plan. You're definitely removing wiki Jenkins.io as as content moves to better locations. So plug in docs into their GitHub repository into the plug in GitHub repository. And Jenkins core docs, the wiki. www.Jenkins.io History section, there's some out on the wiki there's a bunch of stuff that's really old it should not be showing as current documentation. It's still kind of fun to go back and you know when pipeline was brand new or when these things were brand new what do they say about it. And I don't know should we just bury that or should we have, you know, history, historical wikis or something. Well, so, so that's a that's a good question. Tim Jack home has actually asked the question. There is a wiki migration plan document that I've started. Plan here we go. And this thing one of the comments on it from Tim was hey should we just capture the content of this thing, the static pages, no longer editable because it's it's already read only. Right, should we capture the static pages and then turn off the wiki engine, so that all we've got is a bunch of static pages, and then we could migrate content from the static pages and leave the static pages as the historical documents you were mentioning. Yeah, that would work. Now the wiki site is is read only therefore it is effectively static for all users. And making it purely static pages is is a technical challenge but it's only a technical challenge and that actually might be something that we could consider as part of the documentation summit is should we put in see if we can find some folks with developer developer interest who'd be willing to make the transition to convert this thing to a static site. Great. So glad that address your question. Yes. And just go ahead. I'm sorry. No, continue. No, I was going to change the subject so please finish. Well, it's in general I wanted to clarify the purpose of this for them. It's only for contributors, as I understand. So people who are interested in Jenkins and trying to find some questions they may have and go into the quotation and don't find a quotation. Could they go to the summit or this is not for those users who have questions on. I don't think it will meet their needs. They, I would hope that those kinds of hey, I'm missing this information or missing that and missing that information. We use as input to the documentation inventory review exercise review questions and from users as input review comments in the user feedback spreadsheet. I, other than the four other words that are sometimes spread in there by people who are really frustrated. There are other comments that can be quite useful and good guidance I found several actually just recently there were there was a bug reported in there that wasn't had been reported. I hadn't detected elsewhere. Very helpful. Very fair to say that this summit is mostly for Jenkins developers, not Jenkins users. Yeah, it's for creators, rather than it's for creators and maintainers, more than it is for consumers and users. Although anybody who's a consumer who wants to become a contributor certainly welcome. Right, that's, that's, and that that is that is interesting, but I think that's less, that's going to be less. That's our way to encourage we want to kind of say, probably we should point to the office hours, you know, right. Let's see so have we any questions on the Docs track so the two of you are willing to be part of that so my proposal then would be next Monday in our Docs track. I'll bring my first draft of this, the beginnings of my Docs outline, and we'll talk about it and try to highlight. Hey, here's what I've learned. Invite the two of you then to help me with making comments improvements. I'm assuming I'll just use a Google Doc because that's convenient and an easy way to do to do comments and corrections. Great. Um, one other question that's and you guys can shut me up anytime you want to lurking in all of this is the question of audience. Got him going back to old I'm sounding an old writer. But I'm struggling with some of that we have my impression is that when Jenkins was first put together whoever used Jenkins did it all and it was structured that way. But I've been struggling a little bit because we're seeing more and more of a split either I'm responsible for administering Jenkins or I write pipelines. And actually with administrative managing there's some different levels but I haven't gotten into that, but stuff like notifications and credentials and there's a lot of these things where there's an administrative part and there's a pipeline part. And should they be documented together as the technology, or should that, here's how you use credentials in your pipeline and here's how you set up credentials as an administrator. And you can make arguments either way but I'm, you know, I'm wondering if it would make sense for us to consider and have some sort of general statement about where we want to go forward. Question. Okay, so, so I'm going to I'm going to offer my, my opinion, and I'm open to open to suggestions on it so I've, I'm going to use as an as a as opinion, a historical description so the Jenkins documentation initially was modeled after the docs were initially modeled after after the free BSD handbook. Okay, yes. That's a single book that is single book, all topics users administrators, everyone. Great. About two years ago I started thinking, oh, we need to split it and into user and at and now, after about two years of thinking along at lines, we haven't done the split just had the concept. I'm back, I've come full circle back and then now mark now thanks we should not split it. I'm not into user and admin, because I can't find seems between information for users and information for admins in the sense that I was expecting, but make your point of pipeline creators, and others is a very good distinction and one that might apply very well to okay separate technique and the pipeline authoring SIG might be the ideal place to decode. How do we help pipeline creators create pipelines more rapidly. Right. And there's it is because there is not a clean break. I mean in other technologies there's a real clean break between the two. Well, see for me pipeline authoring has has some other components to it that are that are tend towards less documentation and more use the code and let the code help you. So there are people who still don't know about the pipeline syntax editor. They don't know about the declarative syntax hints and things that could help them significantly significantly more effective, if they would just use them. Right. Well I think in the, in the Jenkins I don't think we have a place. There's a like, how do you use maven how to use cradle it's not our subject, but we don't tell them if you've used maven for your builds. Here's how you call those scripts. Here's the scent, the pipeline syntax for calling those. Right. And I actually know where you could steal some source material for that. I don't think anybody would object if you stole it, because they were pissed when I put it in the class. But I'm not, but I'm now seeing so I shoved at the very end of the class and it really should be up at the front because we're telling them to use this stuff but not how to do it so. Yeah, and so. So, I think that's an open topic and for me that's a worthwhile one. I'm open to your insights though, based on that concept of audience, oops, a concept of audience. Are you okay with us continuing with single volume for administrators and people doing other stuff outside of pipeline author. I'm almost okay with anything I just think we need to have someplace and agreed on strategy. And I, you know, and I, yeah, because I mean this is back in the 80s that was God, I triply tried to have a standards group for documentation and they met for months and months and I think about all they agreed on was that you should know your audience first. Okay, you know, and I think we've moved beyond that but it's, you know, but it is some of it is like, you know, and maybe, and some of it's going to have there's going to be. It was going to have there's going to have to be arbitrary distinctions it may be that right now we say, this is how you define a credential and you must have admin or you must have. Not that you must have permissions given to you through whatever your security your security matrix your authorization is to do this, and then in the pipeline here's how you call credentials to get to a resource. And somebody else had to have set this up and we become fairly arbitrary and a small shop you may be the one who goes but if we link back and forth. It's like, it's some it was, you know, if if you were a pure pipeline developer this should be done for you by somebody else. And, you know, which is it's an arbitrary I mean we're telling companies how to organize their people but you need some structure so that your comments you've you've got your experience and long time professional documentation just like what you're in what you're offering. Well, yeah, I agree actually mark that it is sometimes very hard to distinguish if the content referred to the user material to develop a material or to administrators. And I guess right now we have even in genkins.io two kind of administrator related sections one is system administrator. And the other, I even forgot how we call that administrator not system but something else. Yeah, system administration and there is administrative junctions also inside managing managing junctions is kind of administration. So it's, yeah, very. I guess it would be easier to find material in case it will keep everything in one kind of volume so people go to that specific to this specific junk is that you and after that the search inside. Yeah, this is like unrelated question about the search in documentation. Should we discuss this or inside inside this for some or we should just don't touch this subject. I think I think that is a brilliant topic because a frequent comment on the on the online on the online feedback is hey where's your site search. If you want to find a specific keyword and and only get even done a mock up. So, so I think it's worth. Yes, so let's. Yes, what I call site search as a feature and adding site search. Absolutely, I think that's a brilliant one. Very good. Before I was thinking that absence of size search is a feature of our documentation. Okay. I like that I think, I think that is intensely valuable. And, and it could use someone who has a different set of skill sets right there. We've got people who can contribute by writing and describing what their experience. The site search thing is more of a technology and deployment thing that it is a writing thing. And so I think that's this. We've got another one that's just happening right now is additional improvements to the. Let's call this with a different topic improvements to pipeline dock pipeline step generator and how to encourage more improvements. The reason there is make to your pipeline authoring question, or the pipeline authoring challenges. There are times when I'm sitting inside of a pipeline step. For example, let's go to the pipeline steps reference and let's pick one that I know about this one. Okay, so here is a description of a pipeline step. However, if I down at the bottom. It's gone. Good. Okay. On every other page on Jenkins documentation right here in the bottom left quarter there is a is an improve this page link that will let me improve it. It's not here, but this was this page helpful. All it does is let me complain about it not let them not take them to the place where they could actually improve the text that's written here. And this is coming from a source repository so it could be a link so that's that's one that's a candidate for a programming task around documentation generation. And now that's really sad what did oh it's in the right was the contributor so. So, because we get lots of complaints hey give me more, more example better text like well hey here's they improve this page you provide us an example. And, and we do have some search for instance in plugins Jenkins.io which is part of the project. There is search. And it actually works. So, there is yeah and and it, it is, it is well suited to things that, well, it only searches inside the pipelines, the plugin site but absolutely it is, it is there. Plus browser based control f, in case if we have a very. Right, right in, in, if, if you have to use the use the classic way right. Is there an easy way if I'm looking at a page to find out what issues have been filed against that page. There is not. I would find that useful, but that maybe. That's that's an interesting thought. The number of issues currently that's that's a good suggestion in terms of contributing contributor onboarding finding the page to fix finding the link that takes you to the page. What we've got right now is we have improved this page at the bottom bottom corner. And one of the suggestions had been. Okay, let's let's take this. Let's take our example here. Installing Jenkins. I'm in installing Jenkins on Docker. I'm here on this thing. I'd like to improve some phrasing. But there isn't an immediately obvious way here on the thing I'm seeing this hover to hover shows me a hyperlink. What if there were a hover pencil right next to it. Right. Oh yeah, that would take me to to the GitHub page. Yes, if I scroll down. So if I scroll down, I can at the bottom of the page find improve this page, and it will take me to a page that represents this. In this case, Vlad is fully aware it doesn't actually help because of this include. Right. It, because we have documentation reuse going on here that specific example. Improve this page isn't even as helpful as we'd like. But that's a place that we could encourage contributors better. Yeah, and all of this is sort of a wish list to be prioritized. I don't know if this would be the top priority but I get me either. Yes. Okay, so I've been I've been awfully scattered here. My apologies. Here's the back to our agenda. So we talked to we've talked about the contributor summit, anything else. Any other questions or topics there on the contributor summit as we prepare for and get to the next steps there. This busy. Okay. So, Vlad, we had injected this wiki migration plan. Anything else that you'd like to discuss on that topic. This, this is one of the things that will be moving. Viki Jenkins so well we clarify here that we're going to remove this in the future and it is going to be distributed among different locations. Those locations should be defined later. And we can use tool for the immigration which is kind of nice utility or tool, which every contributor may become familiar with, which helps. Right. Yeah. Next topic then we had pull request progress. We've got an open pull request on skating Jenkins I kubernetes still from Google season of docs. That's one that I've got to work with Kristen wetstone to learn what I've done wrong and why I didn't quite steps are quite working for me and then we'll, we'll merge it. So, we've got our install instructions. Now, Vlad, you had asked about this one, we've got about 15 minutes, are there other topics because this one could spend a long time with me with me droning on about what the concept is and why it's why it's doing that. The one that's left past that is mine and I have no report I posted something to somebody and they haven't responded so. Okay, cool. So, so you're okay if we spend the day. Okay, all right, let's talk doctor if repository. Okay, so the Docker Docker LFS repository is LFS. Okay. Yeah, large file support. Oh, okay. So, so let's let's take the concept first so I want to be able to Mark wants to test with a real Jenkins server. So that was that was the inspiration for this thing. But I want to test in many environments. Trivial setup. Trivial tear down. So I can, I can turn it off very quickly. And absolutely repeatable. And so what I did was configuration as code. In this case, store the Jenkins definition in the repository. I initially did it without using the configuration as code plugin. I was just storing XML files. And then what I developed was a stack of stack of configurations, one that inherits from the other. It's basically from its predecessor and the the intent was. Okay, I've got LTS as a base branch base branch actually let's start with the base branch master master is exactly exactly the Docker, the Jenkins Docker repository. It changes its and then the first level in is I called LTS, which is master refined to a specific LTS version. Then there's LTS with plugins master with my set of plugins. I like now at this point. This ends. This is the public repo. So this thing contains no secrets. No secrets nothing sensitive. Then the next concept is a private repo that is based on the public repo. And it includes LTS with plugins and credentials. And then LTS with plugins credentials and agents and kinds of agents all kinds of agents agents. Yeah, so well so and that's that includes so this thing includes secrets. It includes things that you were really in a perfect world never put into a repository but I needed a place to put them and I put them there. It includes secrets includes agent definitions. It includes job definitions. Actually, each of the levels includes job definitions. So if something is a public thing that can define a job. It, it's in there now. It's been a freestyle John or it's a pipeline also a job. Both. So freestyle pipeline matrix. It's pretty much got every kind of job in it. And the end result actually is this. Okay, so what we see here. This is the thing I manage as code and it's got, let's look first at the agents that are connected. So the agents include to arm servers on Amazon Linux, a Windows computer to free BSD computers, Centos, seven Centos a deviant 10 deviant nine, Susie 15, 18 to go to 20 deviant free BSD windows to go to a power PC, a system game frame. Whoa. Yeah. An Nvidia. What they call it nano which is a is a an arm processor with a GPU attached. Oracle Linux, some open BSD open Susie some raspberry pies. Etc. So, no vax. No vax, you're right. I missed not having a vax because I don't think John runs on a vax. So yeah, good, good point. But, but the idea was, okay, this thing is a an intentionally maintained environment where I can experiment with Jenkins in all sorts of places and ways. The concept goes further with, okay, each of the, each of these, for instance, the get plugin needs to test various hosting providers so I have sample jobs for many different get hosting providers that check various forms of credentials so they check to see that it can clone from those places. So I've got jobs that build the Jenkins plugins that I maintain or that are important to me. And these are GitHub organization or these are GitHub multi branch pipelines so that the get plugin for instance here are all of its branches. And all of the things that I care about on it so I can see code coverage reports on the get plugin. So that's been helpful having my own production Jenkins instance then the other really I thought elegant technique here is this repository called the Jenkins bugs repository is has one branch per bug that I'm trying to verify is above. And by now, after multiple years of doing this, you can see that I've got a lot of them. Having like 150 or 200 of these jobs that are used to test and each job is intended to test for itself is the bug fixed or not. I was my intention was initial intention was to fork this repository and duplicate the work that you were doing because I found it's interesting concept. But now I realized it is a result of many years of research and development that you had done and you put it in this repository, plus you have private repositories repository at least one. So in case if I'll fork your rapper, even with some branches, it will not work without this right. Okay. So I hope it I hope it would work. I originally created it with the intent that others could fork it. The more the more I worked well yet. So, so certainly you, I won't, I won't grant anyone access to the private stuff right because it's got my credentials in it, but the public things, the public things that are here. Not only can you fork it, but I would love to hear the results from somebody who did up to this point. It's been my personal wild experiment and that's all it's been. I'm not sure I have any evidence that anyone has ever done anything with it except me. I guess you are doing this you're trying to establish your infrastructure and hosting on your private on your private domain and private. Well, what you are using right for your, for your testing purposes, markway.net or supply this sort of sort of well and that's, that's where this thing shouldn't know about particularly the public repository here should not know any more than it has to about my specific network. So now it does and there are some embarrassing places where I'd say, for instance, let's look at this one. It knows that. Oops. There are some scripts in here that know that my network is once network 172. I apologize, but, but if someone else were to work on this, that would be a great. Okay, it's my perfect excuse then to say, oh, you want want to take this out and we need to replace it with something else. And that would be perfectly reasonable. I found it very interesting what you did because usually people are using branches to merge into master and you're using it in different way organize this hierarchical structure and so every branch kind of master plus extra features or extra things that you put there. Yeah, very interesting concept. Well, and that same that same treating treating branches as a stack on top of something else. Also happens in this other repository in this Jenkins bugs repository that I've been tracking right in my in my Jenkins bugs repository it's the same kind of thing where each attempt to verify a bug is an independent branch that will never merge to the master. They are, they are, and it's, it's the same thing it's like, oh branches don't have to always merge to to a central location. And in this case, it's helpful. And in this one it's helpful that they don't merge. Yeah, so your, but your, your observations correct this. This repository that is our branch that is 4,000 commits ahead of master is quite odd. We think you should file patent for this market maybe. No, actually, because, because this is exactly the concept that this concept of a patch stack is exactly what the free BSD people do and what I think open BSD does with their package, their package system where they say, you can, you can rebuild packages in free BSD, and they do it by taking the original code from somebody else, layering a little bit, a little bit of a patch on top of it and then build it so that's all this is you know this is just that same thing. This is this is certainly nothing that that innovative, but it's, it's, it's solving a problem that I have, and letting me test, for example, just this weekend, I was testing, where is it I was testing this thing. You know, I was testing this one. Yeah, I was testing Jenkins using Java 11 instead of using Java eight and I was checking all of my agents are still well behaved and trying a new version of Java Java eight update 282 instead of 242. And those kinds of things allow me to very rapidly assess. So is, is this new thing we're evaluating useful and helpful. Thank you. Yeah, so, so again, you are welcome to fork the Docker LFS repository. And, and I'm proud to say that this Jenkins bugs repository there are others developers in the community who are using a similar technique now I know at least one. So it's not that this is the only place that this is happening other people are using similar things. So, we are about at our end. Was there anything else that we needed to go over in terms of either the Docker LFS repository or other topics. So, look forward to checking with you. Vlad, I will also submit a poll request within the next few minutes to do this one, and I'm going to submit the Jenkins 2.2 to Jenkins 2.2 77 change log due today because it will release tomorrow. So I'll submit that and hopefully you'll see it later tonight or others can review it if you're not available. Thanks everybody. Recording will be posted in probably an hour or two. Thank you.