 Welcome. This is Jenkins documentation office hours. It is the 11th. Oh, sorry. It's the 12th of January in Asia topics for today. Contributor summit, Google summer of code version documentation for Jenkins.io. Sponsor attributions and integrating Docker compose into Jenkins documentation and maybe we'll get to a demo of that one before we're done with today. So contributor summit, we're pleased to have 20 plus individuals confirmed to attend four or five board members so we don't have confirmation from Kosuke but every other board member will be there. And really thrilled with it. The agenda is being assembled. We've got lots of cool topics that will be presented and looking forward to more. So it's going to be a great time. Sounds good. Then G so Google summer of code 2024 preparation has started. I have an open action item I flagged it in another office hours. Oh and in advocacy earlier today. The get plugin authentication. Idea is non viable. But the documentation back end extension indexer is still very viable. It just needs a prototype from me to assure that it's a really reasonable thing to do. And then we can put it as a as a project idea. Oh cool. So, and we've had last year we had a documentation improvement project the year before we had a documentation improvement project, each of them doing coding work so very nice. Very nice. And we will meet on January 24 of 2024 in an online meetup for meant for contributors. So, so this will be an introduction for potential contributors. This is how you get involved with the Jenkins project. Here's how you submit a project idea. Here's how you create a good plan, etc. Oh, and I see. And you're doing a blog for the call for mentors to we've got a call for mentors blog post and it was posted. I think it was posted back in December. Yeah, December 5. Okay, are we are you using is part of that the argument why companies need to contribute. It's in their best interest to contribute. No, but this is going for the right this is just give your time to help help these new contributors to open source. It's not doing a why would companies care it's rather just a give give to open source. Right. All right, and then the next topic was version documentation and here. The crucial thing is that we can report issues with current content. Well, bond it the creator of the of the project is taking exams. And then early February 2024. Bundy will return to the project and resolve open issues that we found, etc. Meanwhile, and the infrastructure team are preparing to deploy the prototype at docs.jankins.io. Well, yeah, it's it's we're I'm very pleased with it. Now, I'm sure there is more. There are more challenges hiding with it. You know, there always are. Right. Kevin's Kevin's done a good review of it. I've got more reviewing to do, but Vandy is has made great progress and is willing to keep working to make that progress. So very pleased. Any questions on the version documentation site. Um, so what will be your policy? Will it be like if you have something that works one way in release X and completely different in the release? Why? What will it be the content with that? Will you just freeze the doc for release X and it's up there as a version? Or will there be any attempt to put version information across releases or are you going to keep the releases pure? So intent the intent right now is to keep the releases pure if only because it's a lot easier to maintain that way. So what what we see if you look at the at the get documentation, for instance, if we look at get scm.com here when we look at their documentation site. In their reference manual, we can see, for instance, that up here, here's their pick list. And as far as I can tell, they don't go back in time to revise anything. Right. It's and so when we look back, you'll find all sorts of sort of glaring. Oh, here was this error long ago and those errors don't get corrected. They just stay there. Now we'll be using a branch per version. So each version will be on its own branch. So we could conceptually go back and correct things in a in a particular version, but I doubt we will. I'm thinking of the other direction in a new release. Will you preserve anything from the previous release or two? Oh, I think we'll preserve. We'll preserve everything. So so what what at least my mental model is just exactly what what the get project does here. What they do is they said they take the preceding versions documentation is the base for the next versions. Right. So every correction you made in N minus one is available in N. Right. I'm saying what about something that's different between release and and N minus one? Will you purge the material for N from N plus one? So, okay, let's let's let me give a very specific example. There's a here's one that may be may may be along the line of what you're thinking someday in the future, we will remove blue ocean from Jenkins will deprecate. Yes. All right. So there's a there's an example right so blue ocean someday in the future and it may be 12 months and maybe 18 months and maybe 24 months but someday in the future. Blue ocean is deprecated and its documentation content at some long term support release will be deleted from that versions pages and probably replaced by the thing that is taking the place of blue ocean in this case probably pipeline graph viewer. Okay. So, so today we see let's see today we see go ahead what was your question go go finish what you're saying and then. Well, so here's here's the example documentation for me it we look here and we see blue ocean and this entire section exists today in the version documentation so getting started creating a pipeline etc it's all there. Yeah, I recognize the bell yes, and when when that day comes in the future. I would expect this will be replaced by a chapter that still actually probably will will create a redirect from blue ocean to the next thing hearing you. Oh, you're not hearing me. I can see you. Oh, weird. Huh. So I'm not sure there you're back. Oh, okay. Good. Interesting. I wonder what happened. Oh, who knows. Yeah, so, so the when the day comes that blue ocean is removed from let's say it's removed from the plug in setup with or from the setup wizard in Jenkins. Uh huh. At that removal then for that LTS version, the blue ocean chapter will be gone. Well, a redirect will be created that redirects from blue this blue ocean page and from each of these pages to probably a single page that says blue ocean has been removed and then a link to and here's the new thing. Right. That makes sense. That's big and gross. You know, something with a big thing stays but an argument is renamed or is removed or something like that. So that's a that's an exceedingly rare thing but let's let's look at an example of that here what we're going to do is let's look for Remoting just changed one of its arguments. Okay, and there what you see here is a pointer to the library to the repository on GitHub. So the it takes us to the authoritative. There's another page here on this and not that one. Now I got to find it because I was just reading and in fact edited this page. Maybe it's Jenkins Remoting. There we go this page. Okay, so here if there were some mention in here of the command line arguments there isn't but hypothetically if there were, then I would expect in this page for the version that's associated with 2.426.2 the current and the shipping version it would show here's the here's the deprecated argument and that deprecation is well here you go. Here's the deprecated argument deprecation message and a link to the announcement of it. Okay, yeah, that's good. It is it's hard to do those things. That's what I go back in my head about it. Because the problem of course is that users often have hybrid environments and they look at one set of docs they don't look at all of them so just curious what you were doing about that. Okay, go on. Great. So, I think that covered all the topics I wanted to touch on version documentation any other questions there. Nope, looks wonderful. Okay, next piece then was sponsor attributions. And this one what we've had is a request from one of our big sponsors JFrog saying hey could you please add an attribution for us to the downloads page and attributions are a good thing. And we like those we want to be sure that our donors know how grateful we are for them and so we've got a whole whole section at the bottom of our page here for for donors and a way to say thank you to those donors. Right. I still like I'm wondering like you a couple of meetings ago you went through what they all did. I'd love it if there was a pop up for each one that said you know, they provide servers for us for this or right. You know. And I think I think that their employees are on our board or whatever. Right. And that's a, that's a that's sort of the direction we're going is to get become much more detailed about what this, what is in this very simple section because even at this horizontal thing here. There are very different levels of commitment between the various groups that are on this page. So, open source, the Oregon State University open source lab pretty much hosts our mirror, the roots of our mirrors, and, and that's more of a mirroring thing, whereas cloud bees provides an enormous bunch of people, and almost 100 over $100,000 a year in cloud that their their distribution is enormous. CD foundation likewise has provided in years past over $100,000. Great. And it's just interesting I mean it puts, because we've all seen this, the messy pages of here's all our logos. And it means that you know it puts a little, I don't know human face to it or something. Great. Right. And you're absolutely correct. So we want, we want certainly want to make it richer in terms of, okay, these two are mirror providers but this one and this one are actually monitoring providers. And here's one that hosts all of our prototype websites. These folks donate a mainframe that we use for testing. The way gives them an incentive if they want to start donating more. Maybe they're now giving a mainframe and then next year they say well you can, we'll give you two people for 50% of their time or so, you know. Right. Exactly. It's that kind of, we want to be sure. It's sort of like the, what your contributor highlight to is that it puts a story to it. Exactly. And in the company story, for instance with DigitalOcean we'll be creating a blog post that talks to people about how we use DigitalOcean's resources. And how we make that work smoothly for users of the Jenkins systems. Oh, nice. Yeah. Good. Good work. So any other questions on the sponsor attributions? Nope. All right. Next one that is integrating Docker compose into the Jenkins documentation and here, the story is really about how much easier it is to make, to go through this tutorial thanks to all the work that Bruno Verrachten has done in his, let's look at it. You've got to see it just to get a comparison of how much easier it is. So the thing that he has improved is on the tutorials page, this getting this build a Java app with Maven. And so if we, if we look here at the, here are his instructions to. The sample repository. Okay. Those are the same everywhere in the start your Jenkins instance section. Here's the new section. Notice the length. It's got three, three bullet items. And that's it. Three bullet items and a paragraph or two. Yep. Let's look at the old one to get some hint of what it takes to start Jenkins in that old one. I remember that. It is a horror. All right. So it's a horror if everything goes smoothly. Exactly. It's only horrible if everything goes smoothly. It's a total disaster. If anything goes wrong. Right. And there's so many places. I mean, so you're dealing with all these different operating systems and environments. There's so many things that can. Exactly. So, okay, we, we just, let's just talk about Linux and Mac OS scroll, scroll, scroll, scroll, scroll, scroll. And that's probably easier than Windows to do. Right. And now Windows scroll, scroll, scroll. Okay. And now how do you, okay, it's that complicated in terms of what do you do. And Bruno has simplified it to start your Jenkins instance with this one command right here. You clone this. And then where is the of this docker compose up minus D Maven. Boom. Why is that command buried in a sentence rather than. Yeah, I think, I think that's a good point is just looking to find it. We need to put that on its own line, make it big and bold item to use, you know, after cloning run this colon and then. Well, and the other benefit of doing that is then we can put this one should also have a copy item, a copy line or a copy icon. And this one could have a copy like icon as well. Right. So that the user knows copy this, paste it, you're going. Right. So, yes, it is. Bruno's done a great job with it. And that's all the topics that I had for today. Anything else from you, Meg? No, not at all. All right. Well, thanks very much. 8 minutes. Good work.