 Okay. Hello, and welcome to the Jenkins documentation office hours. Today is August 24th, and this is the EU-US edition. Today we have myself, Bernadette Rockton, and Chris Stern joining us. If Mark shows up, welcome him otherwise. I'll just take his name off the list for right now, but I have a suspicion he'll be joining us. Today on the agenda, so some updates on the Google Summer of Code. Chris has volunteered to provide a demo of the version Dock site, which is one of the projects that Vandit has been working on. Chris has been mentoring, so we'll look forward to that. Some blog posts that were published recently. We had our latest LTS release yesterday and weekly on Tuesday. The process of choosing a plug-in bomb. The proposal for Java 11, 17, and 21 in terms of Jenkins support and where we go from here. A new section in the documentation for stuff like support policies and Java requirements. A note on val.sh and just some notes on DevOps road tour. Is there anything else that we should add to the agenda or anything else anyone would like to discuss today? Okay. And Vandit is here as well. Welcome Vandit. Cool. So as far as the agenda, so Google Summer Code starting off with, would you like to do a demo of the Dock site? Or would we rather come back to that? We can discuss other things first. Can we discuss other things first? Yeah. My system is lagging. I think I will reboot it and then I'll join back. Yeah, no worries, Vandit. Thanks. Appreciate it. I'll just stick it down here for now so that it's out of the way. Cool. All right. So Vandit fixed his thing. Cool. So moving on then. So for the blog post that we recently published, so we have the Linux containers needed to be rebuilt recently. So this is something that Damian and Mark worked on. Mark had written this blog post announcing it and kind of just sharing what happened and what we did. We also had a nice blog post from Andrea who was, who did an internship with Jenkins Security over the summer. And this is a really nice insight and recap of his experience, his internship and what things they worked on, learned, it's like got from it and what he was able to accomplish. But really nice insights here. Thanks so much to Andrea, Kevin and Wadik for all helping with the internship, participating in the internship, being such great mentors for the internship, et cetera. This is impossible without the team work there. And then finally, the last blog post that we've published is actually an update from another one of our Google Summer of Code participants from, this is from Harsh. And he was part of the GitLab plug-in modernization project. And again, a really nice recap of the project, what things they accomplished, what things they worked on, goals and just their experience overall. And we'll have more of these coming shortly with the Google Summer of Code heading into its final stretch and other participants kind of getting to the wrapping up point of their projects, though they're submitting their blogs and they'll be published. Yeah, Mark. So it's worth noting that we should expect a blog post from each of the Google Summer of Code contributors, including Vandit, because part of the submission packet to Google, it requires a summary of their work. And the blog post is and has been repeatedly preferred as the way to summarize the work. It lets them point to link to pull requests, link to demos, link to the video of the midterm presentation. All those things are very helpful. That's all that I had to say on it. Great. Thanks very much, Mark. Yeah. And I truly appreciate just getting a chance to read through the blog posts and learn about their experiences and what kind of progress and like work they've been able to do on these projects. Because from a documentation standpoint, I don't necessarily get as much in-depth experience with some of these, but it's really great to just see that come across. Next up on the agenda, so LTS 2.414.1 released yesterday. So our new baseline has released. ChangeLoginUpgradeGuide are available. And thanks to Daniel Beck for helping clarify protocol for the security entries. There was one that was added into the ChangeLoginUpgradeGuide that had been released in a previous LTS, but still noted here. So there's a little bit of determination needed to be happening and make sure we're putting the right information in. So thanks to Daniel Beck for clarifying that. And we also had our weekly 2.420 release on Tuesday. So there were some issues in the initial building, but we got that released. So that is available as well. The next item on the agenda is the process of choosing a plugin to build a materials version. This is something we started discussing last week and is further discussed in this issue for Jenkins GitHub. But essentially explaining that there are various references, sorry, there are, I'm sorry. Mark, would you be able to speak a little bit? Sorry, picking up here. So choosing a plugin build materials version? Yeah. Okay. Yeah. So the story there is we've got, before I left on vacation, we had a good conversation with one of the developers, a plugin developer who said, hey, I don't know how to choose which release of the plugin build materials I should insert into my POM file because there's sort of a mix of, I've got to combine two or three different data sources to get the answer, which one should I include? And the person is exactly correct. It's more complicated because the plugin build materials supports multiple Jenkins versions concurrently, but it can only release a single thing at a time. And so that combination of multiple Jenkins versions, but releasing one bomb at a time means, oh, I have to look at things differently. So we've got some more work to do here to describe the, to give a better description. And if you scroll further down, Joseph Peterson gives one suggestion right at the top here where he says, hey, let's put it into choosing a baseline. And then another user, another developer puts in an additional suggestion that says, yeah, you know what, we should also consider this other location. And they're both right, right? It's every place we can describe, here's a good place to make this choice all the better. And this may be a place where we need Bruno's skills with update CLI in order to submit pull requests that automatically update the documentation to say, look, this is the current version of this thing. So it's, but those kinds of things are part of this more work is needed. Great. Thank you so much, Mark. And with that work will announce things and could potentially be an option for Hacktoberfest, but time to tell. Yeah, yeah, I think that one probably won't be Hacktoberfest. It's more technically detailed than most Hacktoberfest contributors could be successful at doing. I don't know if that works. Okay. Next on the agenda, so the ongoing discussion about the proposal that Mark's created for Jenkins and Java 11, Java 17 and Java 21 support and where we're at, what our next steps look like and plans for supporting and ending support. Go ahead, Mark. Yeah. And this one, this one needs some further refinement because I diagram something on my whiteboard and the diagram on my whiteboard highlighted a surprising side effect of the current proposals. And so I've got to bring, I've realized I've got to do pictures and I'll do pictures before I bring this proposal to the broader community in particular because some things I think in this proposal are too aggressive. And I've got to talk about why they're too aggressive and explain it to people and pictorial is the way to explain it, saying, look, this is how the calendar looks. If we do this, it's too aggressive in this context. If we transition towards that aggressive posture and in a year or two get to being that good, great. So all more work is needed here and that work will be in the form of pictorially building an explanation that I can share with a Jenkins developer list probably will be a Jenkins enhancement proposal because it's really becoming a process that will tie us to the Java releases every approach, approximately two years, every Java is now on this six month clock. They release a new major version of Java every six months and every two years they release a new LTS. So 17 was two years ago, 21 is now and the next one will probably be 25 two years from now. So they've gotten on a nice regular clock and we can benefit by setting ourselves that kind of a pattern, but I've got to outline it first, how we get there. Okay, I've been trying to write a blog post about JDK 21 and Jenkins and RISC 5. And I just noted that the paint was still wet when it comes to defining which versions of Java Jenkins will support in the coming months and years. So I'll be very prudent or something. So whenever you see the blog post PR, please have a look at that so that you can correct my errors. And your description is right. The paint is still wet, right? The discussions on this thing started with the Jenkins board and the Jenkins officers. We'll now bring the discussions to Jenkins developers and the Jenkins user list. It won't be a final decision until after it's been through discussion with the Jenkins developers and the Jenkins users list. So we've got a lot of discussion yet, but it's a big enough change that I think, or it's an important enough change that I think it's worth spending the investment now to think carefully about it so that we can talk very clearly about it for future releases. Sorry, Vandy. Sorry, Chris, I'm blathering on. That's it. Thanks, Mark. I appreciate the insights there. And side note on Java 21, it is available now as of yesterday in the LTS as preview availability. So not fully there, but it is available and supported. So it is usable within Jenkins now. Okay. So next up on the agenda, Vandy, everything working on your system? Everything good to go on your side? Okay, cool. So then I'll go ahead and stop sharing my screen if you want to go ahead and pick it up. And yeah, we'll go into a demo of the version doc site that Vandy has been working on during Google Summer of Code. Yeah. So I think the things that I would like to start on would be the version documentation. So starting with how we are versioning, we'll have a dropdown on version pages. So the version pages are user documentation and developer documentation. And we can change the versions from the page we are on maybe if a person searches on Google and he comes to this page. And but the version he is using is previous ones. These are just for demo right now, but they'll be LTS versions, previous LTS versions. So he would be able to switch from here on the about the version he is on. Also, if he directly wants to change the version and the page and like if he wants to access the solutions page, which contains the Jenkins solution, he can just go to Jenkins solution page and or you can say he can choose from here to change the version. After that, we have these version pages. We have changed how solutions pages look comparatively to Jenkins.io. So after that, we have developer documentation which is not versioned because as a developer, if a code gets updated, we don't need to have the entry of how previous code worked or that. So we have that. In the UI UX meeting, I also propose that we will be changing the home page, we'll create a home page which will be created with Gatsby and then it will and from there you can be redirected to all these pages. Currently, we are using the header and the nav bar from the Jenkins IO components repository maintained by Gavin Morgan. So we are since these are used by plug-in site and all that. So all these sites that currently these are not mapped correctly. So that will be done by the end of the program when we'll be good to go to push everything into production and we'll talk within pretty much that after that we have changed we have changed how some things were looking previously. Previously, if you on some pages like if you go to the international and if you go to this page. So previously on pages which were in working progress, there was a warning symbol somewhere there. We can still add that but it was not completely increasing the user experience. So I did not but we can do that and the admonitions blocks on the pages will look like something like this. The code blocks will look something like this and if we move if we move to some other pages if we go to the community page this is how this is how the participate and contribute page looks like. So from here we can go to other pages. Currently, the main problem in documentation perspective is we have a lot of links that are not that are not working because how austruct user references links to the other pages is different than how entora does it. So we have completed a lot we have I have already migrated a lot of pages and fix them but still we have to we have to test we have to test it before pushing it into production that all the links are working because that will that will heavily influence the user experience of the people who use Jenkins.io as a place to look into how Jenkins works. After that we after that current currently the components are currently the components are working well really well the we the GSOC projects section in Jenkins.io we have a project and projects your projects section. So the project section contains a previous year Jenkins previous year Google Summer of Code in Jenkins section. I still have I still have to refactor all of them because they use they use the layout of simple GSOC page and GSOC page simple GSOC project page which these three pages are different. So I am working on that currently to give it a give it a some type of uniformity in all pages we and if we go to the idea section if I can find that currently currently the sidebar is not well updated for the Jenkins project page because there are a lot of pages and I need to I need to consider how I would put that in a hierarchical way. So like it does not it does not make the sidebar very long and so so we don't have to scroll somewhere if you don't have to scroll after that after that we have we have we have the accepted idea space looking exactly how it looks looks on Jenkins.io I still have to add the images that I have added that but it is not working because I think it is because it is inside it is inside a table that's why it is not working so I'll find a look around for it but these are working and the author profiles the author profiles are yet to be created with Gatsby that won't take much time and after that we can link the author profiles everywhere on this site after that if we after that if we go to the event section we asked we I'm still working on we are I'm still working on fixing the card because we get a we get a card on Jenkins.io I saw how to I know I now know how it works where previously I did not know it uses a data.yml file to change the events that are listed on the card we have the event calendar that that that was integrated with by Chris because Ruby is not something I can handle pretty well so Chris really helped me there uh yeah so yeah this was it if you guys have any question feel free to ask me the version documentation is just the user docs the other the projects for instance if you go to projects yeah those those are not versioned right yeah okay because because I have a long-standing action item no very little progress on it but I have a long-standing action item to convert this thing from the concept of projects and project and sigs into a single concept called working groups so so I'm not overly concerned about whether or not the projects thing renders really well we've got to rework it in a major way to combine two concepts that are currently described on on the page special interest groups and projects need to become one thing working groups because it's really difficult to tell the difference between a sig and a project and also yeah yeah and also like you said while I was doing all that I saw that many many sigs and projects were like interconnected yeah so that if we in future they try to do that that would be really easy because we'll only have to move the files since I'm I'm currently giving them a uniformity so we only we'll only have to change the change move the files and merge content so that would be that would help it into the future because currently if you see when I when I also miss the Jenkins projects Jenkins project docs docs because I thought a project and projects is just one thing but when I was checking I was double checking if I did not miss anything that is not migrated yet then I saw that oh my the project section is still to be migrated so so could you open Jenkins project I didn't realize that there were two different things so projects is this one what's the singular form of it the Jenkins project thing what's there oh right this is the governance this is the governance material okay thank you all right so this is governance got it and and so the Jenkins project it's correctly named but projects of the Jenkins project yeah okay thank you yeah that could be yeah this one this this these two really confused me too okay yeah so yeah so that's how we can change the version and that all that the version things are solution page tutorials and user documentation because the advisories with advisory is a single page generate yml generated single page like it contains the change logs which is which is a yml generated single page so we'll we'll do that with Gatsby because since it is yml generated I don't think so someone wants someone wants to like manually do that because we can keep keep using the yml files change that and it will reflect on the on the site so yeah that was from my site I'll stop sharing now so actually before before you stop sharing so yeah I think there are more questions if you've got more time to ask to answer questions Vande so yeah could you take us back to the top level so on the here on the solutions pages that one should that be version so this I understand if I understand correctly is versioned and I guess this is a question to Kevin and to to Bruno more than to more than to anybody else it's solutions seem like yeah maybe they should be versioned but then again it's not a hot high-speed fast changing thing but they could be very different between Jenkins 2.400 and Jenkins 2.600 yeah like I see I see I see what you're trying to convey I I made them versioned because if we have some solution if we if we think of it as a standpoint that someone wants to see if Jenkins is something they can use for their project or their needs so they can visit the solution page and check out the it is integrated with this I can use it from that point of view I should not be versioned I made it versioned because I thought and I like I just got to realize that I thought yeah since on the version we can see you can like a person will a person can see if our solution related to his problem like his need is version is in this version or not but yeah I I think if from both of these POVs I I think we can it should not be versioned I can I can change that no no no quite the opposite I think I think your so your choice may have been exactly correct I'm really going to ask for Bruno and Kevin versioned or not versioned in terms of this one I would say version but maybe not linked to the version of Jenkins so that's what would be difficult for me to George you know when should we create a new version of this I don't have the answer well but but I think given that you said versioned I think the only choice for versioned for me is tied to the Jenkins version because that's the only clear version I can tie to and I like that because that means these should be versioned Kevin your answer I guess are the solution pages intended to be something as a general statement for something like Android or PHP or is it intended to be more specific and where that version of Jenkins really comes into play or I guess like in terms of one of these like Python for example is there a major difference between the like the last like few Jenkins versions where having a versioned option for this page makes more sense there there isn't and mostly that's because no one's taken the time to revise the solutions pages and and so I think for me that that is a problem I would love to have but we don't have but I think we we can conceive of how we would have it because many of these descriptions won't work with older Jenkins versions and so the descriptions that talk about let's say Jenkins and Ruby if it makes the mistake of talking about Jenkins plugins implemented with Ruby that no longer works and so that would be versioned specific now I don't think it does right these are just plugins that can help a Ruby developer and so they're they're perfectly fine but we had a period where you could actually write plugins in Ruby or write plugins in Python and we've taken that capability away because it was impossible to maintain so so for me go ahead sorry go ahead no go ahead I'm done oh okay I was thinking of dependencies outside of the Jenkins ecosystem unfortunately for the versions of the Android solutions for example when we had new features in Docker that help us with Android but also it's somehow tied to some of the plugin version that we use for Android for example I'm thinking of the Docker plugin so it's not directly linked to the version of Jenkins but more of external dependencies or plugin that we use in the Jenkins ecosystem that's not an easy question in fact well but but that one might have a fun answer in that we might consider backing some of these solutions with a plugins.txt file and a container image that says because we think we're going to do that with Ashutosh's example with Ashutosh's tutorials right where we will have versioned container images that represent a point in time so maybe maybe this would be a similar thing where hey if you'd like to see this at that point in time here's the current one and you could go back in its history yeah that would be cool you mean that you will have a different version of the Jenkins.io for each and every weekly release no no no this is only for LTS right yeah I at least now so as our my model in lobbying for that was command line Git has versions for every every version of Git that is a every minor version and they only do minor versions every three months so they get about four a year that they do and that's all that they update their documentation site typically on okay thanks Vandeet I think I've finished all my questions does anyone have any other questions okay yeah go ahead Kevin I only have no regrets no questions yeah same this looks great I'm really excited me too I'll stop sharing now I need to go somewhere can I drop the call right now if I am not needed yeah of course Vandeet please take off do what you need to do thank you very much for sharing and joining today very much appreciated thanks Kevin bye bye Kevin bye Chris bye Bruno bye Mark what a lovely demo so that's great really excited looking forward to that we are coming up against time and at time if anything so is there any so on the agenda we still have the additional platform information section that we're that I'm working on and a couple of mentions of val.sh which I just started reading about today and DevOps World Tour is there anything on here that anyone wants to discuss in depth or talk about further right now no val.sh I added to the agenda it's enough just to remind people that they're interesting command line tools that can evaluate our writing like oh that's kind of nice so think of it as sort of a grammarly or that kind of thing but in your command line yeah I started reading up on it after I saw it in the agenda so I'm actually very curious want to find out more thanks Mark great all right then we'll end the meeting here and then until next time but the video will be available in 24 to 48 hours and until next time take care thanks for joining and have a good day rest your day thank you thank you bye bye thanks Chris