 Welcome to season or to the Docs office hours. It's the 14th of December. And I've extended this particular document to cover both Monday and Thursday office hours. So Monday office hours we do for the benefit of those of us in the US West. And Thursday office hours we do for more more for those in Europe. Okay, and in Africa. All right, so I've got, I had a couple of items action items for the change log progress on pull requests. LTS release line was a topic I think that we had last time and tutorials on runtime tools. Okay, good topics. Any other topics you'd like to add blood. Oh, no, I guess that's it. Okay. All right. Well then let's let's proceed so the 2.271 change log is it'll happen today, the release is tomorrow. So I'll, I'll prep it after this meeting concludes. It looks like there are a number of interesting changes as always in weeklies so it'll be fun to do it and there's some tooling that supports the creation of that. And then progress on Jenkins.io pull requests. I am proud to say that I've started detailed review of PR 39 79 scaling Jenkins on Kubernetes. And there are a number of challenges there so Vlad this may be one where you can guide me so running Jenkins in mini cube is complicated. You know, you have to deal with ingress you have to deal with installation with. What else with a Docker image repositories. It's all sorts of interesting ashing etc so fascinating. And it's it's documented I just got to be sure that I understand all the descriptions and then I've made sure that they work for me and there are some changes. A few changes have arrived as part of that review. And we'll keep doing that. More discussion in the Thursday session with Zenab. Now in terms of Hacktoberfest and other reviews. I've, it's been a week or two that a week, one it's actually in two or more weeks. And we have a lot of progress on the long term long lived pull requests, like Jonathan's more work during the end of December. We are actually down slightly from the number of open pull requests we had before. That's a plus. And so right now we've got 29 open with two or three of those two of those having just arrived within the last 24 hours. So we're, we're down from the 35 that we had reached before, making progress, but more work to be done. Good work. There are some questions on the progress there. Actually, this might be one Vlad where, if you're interested, happy to have others assist the Kubernetes examples, because they are interestingly complex. Using mini cube, you can run it on a local local Linux or Mac OS machine. Just to clarify, as I understand alternative to mini cube would be to running Kubernetes in the cloud. Yes, yes, also public cloud. Right. That's correct. And also run the same examples in a public cloud. For instance, Amazon's EKS, which is their managed Kubernetes service, Google's GKE, their managed service, and Azure's AKS. Yeah. And others, for instance, we've actually got a tutorial on IBM cloud and Oracle cloud, both have managed services as well. And actually that's a good one to highlight. Oracle cloud has a one month trial with a $300 credit. If you, if you can finish something in a month, they're a great candidate to use that month to explore Kubernetes. I'm now two weeks into mine. Go ahead. And I can't work with Oracle for a while. I mean, Oracle cloud. Are they using open GDK or are they using their own GDK? And if they're using their own GDK, will it be any issues with open source? That's a good question. And what I saw when I ran, when I was running marks, VMS on, so I was, I'm running Oracle Linux on, on Oracle cloud. And the JDK is open JDK, not Oracle JDK. Oh, okay. And I assume that the reason for that is that Oracle Linux is a derivative of Red Hat Enterprise Linux. So at least that was what that was what I observed. It seemed to be as far as I could tell. So that's a very good question. And we could, we could certainly take a look at it. Just to be sure. In fact, here, let's do it. There's a nice thing about having a Jenkins server all the time on. Here is OCI. Oracle Linux 8B system information says, okay, system information says what open JDK 64 bit server VM. So I'm pretty sure that it is at least what I'm running is open JDK base. Now I'm using my own. Yeah, I'm definitely using open JDK because I'm using my own installation of it. Yeah, so, so no, no conflict there with the Oracle license. Okay. All right, then any other questions or comments on the status of pull requests. Okay, so we had next topic was LTS release line. Glad was this a topic you put in or one that we had added that Meg, did you have questions? No, this is something that I submitted just today. I can clarify what I meant by this. There is LTS release line which is documented in our documentation and there is link provided to this on this like header line. And if you click on this like link above that LTS. Yeah, exactly. So it documents that LTS is kind of a long term support stable release which is released every month. And we have special version and model which we use for all these releases. So if we go back to our document, there is link below LTS releases. Yes, this one. And it defines which are stable release in our like on GitHub. And it says that packaging and there is releases I guess somewhere. Stable releases. Yeah, stable releases stable releases is a manually triggered release that happens around once a month. So it duplicates the same kind of statement that it is once a month and it is manually triggered release. At the same time, in our documentation specifically in download page on Jenkins.io. If we go to download page. Download Jenkins to 2631 LTS on the left. We have Docker Docker release which points in the Docker. Yes, this one. It points to this Docker hub. And if we go to tags. Yes, to tags and go to the bottom of this page. Okay. Yeah, and we can see that there are like a little bit up there are different LTS releases and those LTS releases like 31 minutes ago 36 minutes ago and so on. In spite of the fact that LTS release was delivered. I guess we have blog on that sometime ago. It happens like in automatic fashion, I guess, versus what is documented it happens manually and it happens once a time. I found it is kind of inconsistent, so I would say here is LTS release manual happens once a month, or is it automatic especially for Docker, which happens. We can see, well, on the regular basis, so in automatic fashion. And just I'm trying to understand myself what is right, what is wrong here and should we somewhere point about this in our documentation. This is like the question is all about and yeah. Excellent, very good question so I'm going to try to try to phrase it for the notes so that okay so it is that the Jenkins LTS release is delivered once a month. And the build is started interactively manually right interactively by people with the right permissions. I happen to be one of those actually so that's good. Okay, however, the Docker image is generated on a different schedule. I'm going to be a little more precise here the Jenkins LTS release what that delivers it delivers Jenkins dot war Jenkins MSI MSI for windows. Deb file for Debian and Ubuntu and RPM file for red hat. Red hat enterprise Linux, Oracle Linux, scientific Centos, scientific Linux, etc. And an RPM file for for Susie Linux and open Susie notice I didn't say anywhere that that process delivers the Docker image. And that's the Docker images in fact generated on a different schedule. The Docker image build process runs periodically, and I think it's roughly every four hours. And when a new release is detected, or there is a change in the base image operating system image, a new version may be pushed. So, because, because the Docker image bundles an entire operating system image, OS image, it needs more frequent updates. I think that's the purpose behind what we're seeing the other is, there's some history here where Docker Docker image construction was done much much more frequently and much more rapidly iterated than LTS releases of Jenkins work. But now what this really means is, when we release a new weekly, or a new LTS, the builder, for example, let's see is EG the correct thing to use here. Yes. Okay. Exemplis gratis. Oh, good the Latin that's just what I need. Okay that's excellent. Okay. Mark, usually runs the Docker build process interactively. Just to assure that we get it to assure it arrives promptly. But really, it's worth considering, we probably ought to couple the start of the Docker build process with an end and completion of the Jenkins LTS release of the war file because that's what's needed. We could launch Docker build after the war file is after Jenkins that war is released. That's all that's required to build those Docker images. Did that answer your question. Yes, well thank you very much Mark for clarifying absolutely it's wonderful explanation. What is the difference, like how docker LTS releases fits into general LTS releases scheme. Like one of the sequential questions that I have is, does it make sense to use Docker L Jenkins Docker LTS versus Jenkins Docker weekly releases. Yes, LTS releases. I mean, are Jenkins Jenkins Docker LTS releases more stable than Jenkins weekly releases. If I'm not sure if this question makes sense but just I think it's a good, I think it's a good question. Okay, so I think you're asking our Jenkins LTS Docker image releases more stable than Jenkins weekly. Exactly. So when you mean then. Sorry. Very good. And I think I think I can confidently assert they are because the base Jenkins code in the Docker weekly changes every week. The base Jenkins code in Docker LTS changes every four weeks. So that that so the weekly for instance right now is 2.2 70 will be 2.271 tomorrow. And right now we're 2.2 63.1 will switch to 2.2 63.2 in mid January. All this regular uploads of Jenkins Docker LTS releases are basically patches on the top of our base image base LTS image. Right. So the way the way a Jenkins LTS is constructed is by adding a relatively small number of so that 2.2 63.2 its release candidate is being developed right now the proposed poll request has been submitted by Tim Jacome the release officer. And in that poll request he proposed a set of five or as maybe as many as eight or nine changes that he thinks should be brought in from other streams into 2.2 63.2. Yeah. Okay. Yeah. So yeah. So it explains why we cannot appoint when we're talking about Jenkins Docker LTS releases to specific file because it changes very frequently. We can point only to some location or folder directory on Docker Hub where all this LTS release. Right. That's right. Yeah. So security fixes ever applied directly to the Docker images or do those come in they get done to the weekly Jenkins and then go to Docker through that path. So so it depends. That's a that's a that's a good that's a good segue. So let's go over so Jenkins security releases are applied to Jenkins dot war and then into the packages including and the doctor image. Okay. But so that's that's one angle. The other though is operating system security fixes. We had a complaint from users about three months ago that Alpine three dot nine was no longer receiving security fixes Alpine is an operating system on Docker. Okay. And so the Docker image. So the Docker image based on Alpine three dot nine was outdated for operating system security fixes because they'd stop patching it because the Docker the Alpine project stopped patching applying security fixes. And so what we did then is the Jenkins project thankfully Oleg Nanash of upgraded from Alpine three dot nine as the opera as an operating system base to Alpine three dot 12. And we will do something similar. We will do something similar and in a much larger to a much larger group of users. When we drop support for for the for Debbie and nine and replace it with Debbie and 10, and that's because Debbie and nine is already outside of their normal support and it will cease to be supported absolutely with the release of Debbie and 11 in 2021. Okay, and where's Ubuntu like 14 is about to be deprecators. Oh yeah we've and we've, we don't deliver any Ubuntu images at all. Okay, now so not an issue there. And, and no threat, because by now we're all on 18 or 20. So if we were delivering it would already be 18 based. And when you say Jenkins security releases that includes plugins right. Well, so the, the war file does not include right. Right, so, so Jenkins core. Let's do it that way plug in security releases are independent of Jenkins core releases. And plugins that are part of the recommended are treated the same as all the others right. Correct, good point yes so. So that's the, let's see what do we call it the setup wizard recommended plugins treated for security purposes, same as any other plug in. Now there is a there are some some noteworthy exceptions there are noteworthy, maybe process things that you it's good to be aware of. When a plug in is removed from distribution, for example, detected that it's not open source. And the example there is the TFS plug in, we discovered was dependent on components that are not open source. Therefore the Jenkins project stop distributing it when it's removed from distribution. If it is in the setup wizard. And just a small clarification, does it mean that any plugin, which has cloud bees inside its name should be removed from distribution as well because it is not open source, or it's not necessarily the case. Good question. No, so, so the fact that it was created by a company does not make it closed source. In this case, the TFS plugin was was in fact created by Microsoft. The problem was that one of the components that they depended on is closed source. So good question. Are there cloud bees plugins in the Jenkins update center that are closed source. And as far as I know there are not all the cloud bees plugins that are in the center are open source. Yeah, Mark, this is a brilliant write up. We should put this into the doc, shouldn't we? Now that you just sat here and wrote it. Well, the, yeah, and, and I just don't know where we would put this kind of thing because this, this is sort of a portion of this is describing the release process right and release processes change. And release processes are mostly relevant to people who run the release processes. We document them in, in the, in the release, the repository that has release scripts more than we document them on Jenkins.io. Yeah, but I can see some somebody who's looking for cutting edge brand new feature and waiting for it to show up in TFS and Docker. Right, right, being perplexed where where's my feature why didn't it arrive yet. Yeah. In case we could put this in a read me. I'd like to see it in the doc for say but it could be in a read me for something at the top. Yeah, and I think it actually is in I could I think all the things that I've shared here are already in read me's in various repositories I'm just presenting some sort of put together. Yeah, right. Correctly. This all this is doing is creating an assembly. Yeah. This wonderful write up which mark created defines the process and in our documentation we're not much talking about the processes, but talking about how well tools and Yeah, and that's a good point Vlad it's the process documentation we generally put other places, because the outcome based documentation the results documentation is we think mostly what the users want they want to know where do they create the LTS how do they know what changed in the LTS there to them it's largely and don't care how we created the LTS they they trust us and we've got. So I guess this one is a good one and a good example of this is very much a process document. The LTS release line pages very much process description. So, we're not without precedent if we want to put process description and we certainly can. So, any other questions with regard to to LTS release line and Docker LTS releases. So what's the summary is that the new Docker image for an LTS is available what within 24 hours can one safely say. Oh, it's shorter than that. Yeah, new new Docker image for a release is available within four hours release of Jenkins dot war delivery. Now that's assuming that there are no. I was allowing for the possibility that there was a problem that they had to rebuild or something like yeah and and if that kind of thing happens it could be. Let's see the example there is there have been times when the MSI for a build was delayed by two weeks while we worked on a problem. So, so the thing that the thing that we we don't hardly ever delay is the delivery of the war file. The other components to their delivery can be jeopardized by code signing for windows or GPG keys needed for the Debian package or etc. Right, which is also to me that's we're saying to though is that So every new Docker Jenkins Docker release is triggered by authorized people like like you mark and by automatically by the programs is actually it's it's dominated Docker image generation by default is on a clock. Schedule is on a schedule right exactly and Jenkins weekly releases are actually on a schedule. They happen every Tuesday and yeah so wonderful. Thank you. Excellent. Good. Any other questions on the Docker and LTS topics. Okay next topic then tutorials on runtime tools. So, Vlad, help me understand what give me some examples of runtime tools in this question. We're using inside actually inside our documentation when describing how to create Docker Jenkins Docker installation. We're using plugin installation manager as the tool to build our customized Docker Docker release. And this plugin installation manager, it, I guess, fits into category of the tools not plugins. It's the tool which managers installing plugins and so on. And we have the section in our documentation describing tools, but there is no description for this to plugin installation manager, should we include. Should it be hosted on Jenkins.io tutorial on how to use this tool, because it is. Well, I guess, kind of complex tool, valuable tool, and there are a lot of different options how to use it, should we describe it inside and host on Jenkins.io or at least point because we're referencing this tool and people who are using this. Well, they may want to find out how to use it or should they rely on their own kind of understanding on documentation or CLI documentation and so on. That's that's a very good question. So let's, let's take a look at that because certainly there are lots of people who come to the, come to the documentation site, come to Jenkins.io looking for information about how to install and upgrade and maintain their plugins. Yeah, good. Now, let me, I'm going to bring bring a question back to you as to what's a what do we think would be a reasonable place to put it so right now we've got the tutorials that have in them this using build tools section, and it talks about compilation tools build tools. Maybe we put a plugin installation manager tools tutorial here in more tutorials, maybe we put it someplace else because I think you've got a great idea to show people if you need to install plugins here are your choices. Right. So it is more about not built tools but run time tools when we're ready for management. I don't know what might be called configuration management or system management. Yeah, those I think they're distinct because they're not used to compile code they're not used to construct product. They're, but they are intensely valuable to achieve the goals you want with the thing that you're using your build tools for. I could, what I can see some other subjects that could use tutorials like CLI. Oh, good. Yes, we, you know, we talk about a feature from the UI and then we say, you can do this with CLI and maybe we give them a list of the commands. But, but we don't go, you know, there's a lot of some of those commands are, you know, abandoned hope all who enter here. And others are very nice useful, you know, and we have no place to real where that's ever really documented or just something, you know, some sample scripts and, and then I wrote this beautiful sample script and now I can't run it because I don't have the permissions or, or it's waiting for, you know, the system God to give me permissions or, you know, something that puts together all those pieces. Yeah, those, those, I think that's a very good insight that if we had something for the Jenkins command line interface as a tutorial so how do you use the, how do you use the tutorial how to use the CLI with the CLI jar file with SSH connections with WebSocket. I mean, there are some cool things there. Likewise, the rest API. Yeah, good. Now, Vlad, you had, you had started the question with, should we have a tutorial that describes the plugin installation manager. Do you have, do you want to go further with that. Are there structural questions that you would ask or Yeah, well, this is about where should, well, first question is, should we, Yeah, the answer is yes. on Jenkins tutorial. And another question is where, where we should put it on the more tutorials or on the management, or maybe we can refer to just read the file on plugin installation manager which is basically very good tutorial on how to use it. But like, we can put it anywhere on this link. Yeah. Does jcask support plugins yet. Is that only a cloud based task depends on what you mean so yes it, it will use the plugins and it will, it will configure plugins very readily from inside jcask. Right. So, so that's so for plugin manager, I've got the, the UI that I can use for plugin management. I can write groovy scripts to manage the configuration of my plugins right. And now I've got jcask. Right, right. So, you know, so I've got multiple ways to manage my plugins and each of them have pros and cons obviously. I think given the list, I wonder if isn't is this suggesting that what we ought to consider is just like we have a using build tools, should we have a system administration tutorials or a system configuration tutorials because it's not really for me it's, there are enough topics we identified with just a little bit of thought that it's, it's much broader and much more specific than more tutorials, it's really should we should we have the concept of system administration tutorials. Yes. Yes, and plugin installation manager needs to be in there. Yeah, so, and their administration tutorials, it's. Any one of these seem certainly this one for example Jenkins job DSL. I don't understand how to use it and I'm aching to learn how to use it so this one, that one configurations code I'm very comfortable with I've used it a lot and love it. So, so each of these has has compelling value in certain portions of the Jenkins use experience. I guess, Mark, we also need to address the question about the difference between tutorial and just general chapter amount of documentation, because for system administration we have. I guess chapter it was called, right, but maybe not in general Jenkins documentation. Yeah, in fact, good point. Right. Well, I guess we need maybe ourselves to clarify what is the difference between user handbook and tutorial and is there any difference. And maybe to go even one step further Vlad is the is the concept of a tutorial premature if we don't yet have a section in the handbook on that topic. Yeah, is it is it upside down for us to consider. Let's create a CLI tutorial, when we don't yet, or even better CLI rest API rest API tutorial, when we don't yet have a good tutorial in the developer docs or elsewhere and not a good to a good for for that topic so managing plugins feels like a great topic for managing Jenkins doesn't it. And we've got a page, and it's, I'm pretty sure woefully inadequate. Right. I mean, the many different ways that you can manage plugins shouldn't plug in installation manager be here. And then as reference material, and then once we've filled in the reference material, then we do a tutorial. Well, but there's, there's another way to slice it to is that the user guide right now. There's it's sort of targeted towards the new user of getting up and being successful quickly. And a lot of this stuff is power user stuff. And back, you know, a back assumption that the people who do this power stuff are going to be powerful people, and they'll figure it out, which is not necessarily which means I think that a lot of people are missing out on a lot of really good functionality, or they're finding out about it only in, you know, side places but like I don't see the user guide as being reference material, I guess, I would love to see material. And I do view it as reference material, particularly for things like, like this one where this is this long list of that is reference detailed reference material and, and likewise the managing security page for as much as it is is is very much reference style material. It's all mixed up. It's, let's say the some of the material could be reference material. To me it's not a convenient format I mean of course I come too many years in Unix where you had a guide and then you had the man pages and the man pages were your reference material. Right and and this is what you were doing that's all you looked at but here you, you've got to constantly slog through all the pros, and all the hand holding to get to the reference material. Yeah, this is decidedly not that not Unix man page style reference material you're certainly correct it's there's an awful lot of pros there. Yeah. But it's, you know, I would almost, I would like the user guide to almost be more tutorial, you know, this is an example of how you use it and then go here to find all of the, all the CLI commands all the syntax or whatever and have that broken out into separate reference material. Even if it's not man pages you know, be it separated, because that also if I'm trying to get the basic big picture, then having all the details of every last little jot twiddle an option is intrusive on that the two either one. It's not right for anybody. Good point. Yeah, grab some quick. I'm going to copy some quick hyperlinks into this document. So tutorials. So instead of more tutorials. And then, okay, other top you've got a bullet list of other topics, which still doesn't have plugin installation manager in it, but those should be under the administration tutorials right. Right, I think so. Yeah, I think that's the I think what we've really said here is here are here are topics. We already know would be interesting for people. And then the question is, do we already have places for for these, and I think we do for this one, or at least for several of these, we could identify which section they might logically add be added to as reference material because if I look at this one for instance I think what we really need to do is re architect, I re architect the administration documentation. That some of what they're. Well, I see it there's reference material for it. And now let's see the other plugin installation manager really belongs in managing plugins, I think, and go ahead and make. I'm toying with the idea that we're still. Well, I see it there. There's, there's tutorial. Generally, I think of tutorials as getting started for for novice users. Exactly. But then, there's another level of guy, let's call it guide type information for power users or people who are trying to become power users. And they're separate. And there is the question of the fact that we have the reference and the guide all jumbled together and inconsistently I mean from section to section and topic to topic. It's just it's all it's kind of what's there is kind of a mess. And I okay here's a question. What is the difference between the tutorial and guide material. I think I might know but I'm not sure but we need tutorials are step by step, whereas the handbook content is so the tutorials talk, take us through a step at a time do this do this do this. Whereas the, the handbook material takes us through concepts like here are here's what shared libraries are in pipeline here's how you deal with branches and pull requests. So, is that is that a precise distinction, not really. No. Yeah, I know it when I see it sort of thing. But that's, to me, I'm thinking I'm going to go back to the, to the managing plugin section that we had to me that's a little bit of step by step. But then here's how you install the plugin. That's almost a tutorial maybe it could be written better. And then here's how you do it from the web UI. If this were a tutorial how would this be different. Yeah, I would think if it were if we were trying to do a tutorial with this we would likely start with a problem statement. Take the user through how with how this tutorial will solve their problem so the problem statement might be. I want to use blue ocean, or it might be I want to use blue ocean, and I want to use declarative pipeline or some story like that and then we would, the tutorial would solve that that that hypothetical problem we've presented to them. Is that a complicated enough thing. I mean so you end up potentially with a tutorial for I want to use get. I want to use. Is that worth all of those tutorial I mean, do things change or aren't the things you do to manage plugins pretty much the same for all of the plugins and I'm missing something. No, I think, I think plugin management in general has an awful lot of the same things. What's going on right choose, choose to find the plugin you need install it monitor to see when it's upgraded, select if you'll choose if you'll upgrade it perform the upgrade restart and use it right. Besides that tutorials may use some specific software tool to go about tools may use some tool, we should dedicate it to tutorials, for instance, we're talking about catacorda tool, which is tools specifically for writing tutorials. So, right. That's another difference I guess. Yeah. But yeah and I'm struggling with this too that's what I'm, it's like, is there a reason why I can't when we're talking about web UI why we can't fly up a catacorda instance right from the dock. Other than funding. No, there isn't a reason but funding is the reason. Right, but, but the funding would be the same whether it's a separate tutorial or in the docs. Right. Yeah, yeah, I mean, in either case, if we embed the tutorial inside the handbook. It's or embed a link to catacorda inside the handbook so that they could launch it it will, it will have the same challenge you to play sure. Right. So that's what I it's like it's almost some toy with the idea that we need to go back and say, what does it what are the pieces that everybody needs to know about it's about managing plugins. And then what do we put where, and how do we form it and, you know, does this, you know, to some extent that seems like sort of a simple topic but to now from going here. So where am I told that you can install you can use jcast to install plugins install and manage plugins. You can do it from scripts. That's not here right at all. It isn't right and so this for me this is missing. So where, where is it described where it describes two techniques to install plugins. There are at least two or three others. I can install plugins with plugin installation manager tool. I can install plugins with the deprecated install dash plugins dot sh script. Yeah. Which if it's deprecated we don't need to document but you know what I'm saying is like, and then I just shutter this looks huge. And just my idea which came from the top of my head, one of the difference maybe a similar to difference between freestyle job and pipeline, where how to guides and handbook is just the forest of different trees and user is on on its own to select specific path, while tutorial is very specific path to do this. Like, so this is the way to master your skills and Jenkins for instance or specific aspect of Jenkins. I like that. I like that analogy. I think that analogy makes sense. So navigating tutorial would be easier for novice users then I go into handbook and just Right. What to say. Yeah, it's like, I mean, I can also see like a lot of what's here going away and you sort of say you can manage them these, you know, theoretically if we had all this stuff. This could be a fairly short what our plugins and what do you mean by managing them that you've got to install them and you've got to configure them and you've got to upgrade you know and some general stuff. And then it's like go here for a tutorial on how to install and manage plugins from the UI. Go here for a tutorial on how to do it with jcask. And then there's a tutorial on how to do that for CLI, which would be separate from there would be a general CLI tutorial that you, you know, you need to understand CLI so. But, yeah, but it could, it could mean actually that the user guide gets paired way down, because things that are more appropriately tutorials are tutorials that are referenced. So maybe in this handbook we have general education or like reference information or whatever about all different topics, really, really, really forced. And if you want to use specific environment, specific configuration to specific things here is the link to this tutorial, how to use. Yeah. Yeah. But it is there's a lot of I'm seeing like script console and groovy hook scripts which I haven't looked at for a while. But there's a lot of subjects that are out there that, but there isn't something that sort of puts it together does that make sense give you the big picture to know what all this is. Right. So would that be in something like the configuring the system page the entry entry page to it is give a high level view of here are your choices. Does that need to be some sort of something completely different video series or a some sort of hints. I think there's probably many paths. What we lack is sort of an architecture about how we're doing this. This, you know, got written by somebody who with some competence has got some information, you know, and maybe that maybe if there were a single issue yeah it's that it's hard to see the big picture. We've we've I think we're better at documenting trees than we are the forest. But if you don't understand the forest it's really hard to understand the trees and make the most out of the system. Yeah, that's what I'm saying. It's like, there's an argument. I'm talking to Tammy way too often these days you might notice but there's an argument for an information architecture of what how do we do this and because well another thing that we didn't. There are things like in this case, I'm not actually sure that the Catechota. If you know, given that it's going to have been expense that we can't do for everything. Do I really benefit by being able to do a lab for this or would a demo work just as well if I had a good demo that walked me through the steps. And I had texts that you know went with it until so I could go back exactly what were those steps. There are some things that are so complicated. There are four or five different things that are all coming together where a tutorial where an actual tutorial where they have to go into Catechota and do it themselves be very valuable. I think they're, you know, there's something of level of difficulty of the task that affect should affect it but and actually make you like raised very good point about labs in general because I noticed that cloud bees, they have labs kind of section which allow users to like. Yeah, train themselves and just execute different sessions on the labs. And I'm not sure but I guess we don't have specific labs. Maybe I'm wrong, but right the closest thing I think of to specific labs are the Docker install instructions for instance which is is precise steps do these things and it will work but it's it's quite rare that that kind of thing exists right it's just in the Docker image is Docker example here and that's a complicated enough case there that Catechota would be very nice to have. Right, or something but I get I mean I've you know I've hit this in another context but what's striking me is a ways back a time that I remember well you guys are old enough to remember it well too. It was very clear documentation was the set of books that arrived in a big truck and a whole bunch of boxes and that was documentation and training was what you got. When you reserve to slot and you went away for a week to someplace and a person walked into the room and led you through all this stuff and you had the conversations and you listen to the lecture and you did the labs and that was training. I'm not sure that I mean those there's everything's merging together because everything is remote and online and I don't buy books anymore. And what does it mean that I'm going to take. I'm going to go over and take this training module or I'm going to take a tutorial or you know that that all we're sort of trying to play with old categories that are no longer relevant, but I don't know how far to go in merging them do we just say it's one information set that. Not sure. Yeah, me neither. It's a it's a good question what worth worth further discussions for their conversations to decide whatever it is we are going to, we are going to throw out everything and we're not going to have a revolution to do we're going to have to start moving towards it incrementally and bring the areas that are the most egregious difficulties right now and pulling those out and re architecting them. But it would be nice if we started working towards some sort of common definition or something of the and I don't know. You know it's it's something that doesn't exist because Well, as the starting point I can just try to request for installation manager tutorial and put it somewhere, but I had some trouble actually running the tests on my Mac, and I figured out that well it was the version of Maven, because, like, I was able to do this using Google Cloud Shell, where was the latest Maven version but on my Mac it was not the latest but version three five something and with this previous version of Maven there was some errors one. So, yeah. How can manager documentation been updated for the new user interface. I didn't even notice we were looking at that. There really isn't anything to update there or you mean in terms of, well we've got screenshots and we used to get the laundry list and now it's just you know the favoring search over the laundry list. Not well that's a good question I don't know if, if the screenshots have been updated or not. Let's take a look and see it's easy to tell has not been because this is the old, the old face. The others. Okay there's one that has, but in general, it looks like no the screenshots have not been updated. And even a mention that there was a big change in the user interface for people you know. Right that that went out in a blog post, but not in a, but not has not been reflected in the documentation. You're correct. Right. Yeah, so the documentation sort of needs to rewrite for the new. Well and the hint of, I forget what is but there's something if you want the laundry list there's a search you can put in that will basically give you a list of everything. I forget what it was something trivial but so it's actually, if, if Vlad wants it that, and he could in the process of that re architect what's in the user guide and what's in a tutorial. Right. Well, thanks way dear. One, one poor request at a time. Yeah. Yes. Is that what you wanted to do. I mean, you like the way I just say what can do this. Well, yeah. So we say yeah what the problem you broke up is the tip of the iceberg of a bigger problem but it is a real one is that something you want to do. And I think it's a fair thing to say. Okay we need to be sure we got reference material. And I think an admin and administration tutorials section of the tutorials page would probably be well received. All right. So we have we have crossed our one hour time. I, I had one more item, which is relatively urgent calendar for the next few weeks. So December 21 2020 is Mark's wedding anniversary. So I will, I will probably not attend this session because the lady that has put up with me for all these years deserves my full attention on that day. The main of of Karen is she deserves that attention even if she hadn't put up with you for all these years. Exactly. Very, very well mark. I did I married far beyond what I deserve. No, I think she, I think she married well too so it's a nice. It's a good couple. Now, December 28. I'm back available we can we can meet December 28. Most, most of the of my colleagues in the company will be off and I'll be off but I'm happy to talk office hours. Anyway, so would you like to meet. Do we want to meet the 21st I propose to cancel, but I'm okay with meeting the 28th. Are you interested in meeting the 28th. I'm okay with the 28th but are you taking time off Vlad. I hadn't decided yet, but I can meet, I guess, as well for December 28. Okay, great. I certainly can I don't know, I don't know that I'm contributing anything anyhow but it's whether Vlad's doing all this work. I thought to contribute during this wonderful year. Oh yes. Okay, so let's let's declare it for for clarity we will meet on the 28th, and we'll meet on January four. Okay, enough. Sounds good to me. Let's see now wait a second I've got it. Yes, that will work. Good. Okay, I've got I've got a personal event January 7th I'll be out all day. I'll let everybody know when that time comes great. Anything else we need to discuss here today. Interesting Canada worms Vlad. Thank you I think. Oh, thank you very much for sharing all this information. All right, thanks everybody have a great have a great day and thanks thanks again. Yes and have a great anniversary then. Yes, I will I will wish the wonderful lady that that has put up with me all these year, a happy anniversary. What are you, what are you doing in this COVID crazed world are you cooking for her. I have no idea yet. I've got to think about that. The most crucial thing is the day prior will be our large, our family gathering, where we get all the grandkids that live in Colorado together for for fun time and so and you're going to do that. We are we we we know we're all COVID not caught non COVID positive, and we are going to very boldly do that because we, we like getting together and even the, even the son and law with leukemia is likely to be there and just rejoice with us. Absolutely. We just miss it. You always did dinner theater. That is, that is dead now right. The Boston pops Christmas concert is available for $30 any team between December 10 and I think January 9. There's probably there's some other stuff there's like things like that that are paid online you could have a some sort of theater event. Yeah, in my case that buy a good movie and watch a good movie with Colleen is even more entertaining than any major event. Yes. Well, good relations we will read in university and best wishes to Colleen and to you and have a wonderful time. All right, thanks.