 Hi all, welcome to the regular Jenkins governance meeting. Today is May 5th. We have several contributors on the call. So my name is Alec Ninovich, I'm one of Jenkins governance board members. So Uli Haffner is also a Jenkins board member. Mark Ways is a documentation officer and documentation special interest group leader. And Mark Jackson is a leader of the Advocacy and Nutrition Special Interest Group. So at this meeting, we just discuss what happens in the project and discuss and make decisions on key items submitted by the contributors and the developer may at least like voting for particular issues, et cetera. But the most of the discussions happen in the mailing list and this is a section, a session to just formalize these decisions. Okay, if you want to know more about governance meetings, so there is a page on Jenkins.io, Jenkins.io, slash project slash governance meeting and you can find all the information there. And you can also see the embedded document and by the way, here's our agenda. So we have a few topics for today. Some good news about the projects in Jenkins also my request for approval and hosting for Uli Haffner's first repository, ULI themes support policy and window support policy. So this is what we have now. And if you want to add a topic, just feel free to put it to the agenda. So, okay, I will start from roadmap updates. So we have a work in progress public roadmap for the Jenkins project. And there is a number of projects which are currently under active development. So you can see them here. It's actually quite a list. And we have some good news about these projects. So since the last meeting, there were multiple updates. First of them, that we finally named the official Docker images. So now it's Jenkins agent, Jenkins inbound agent and Jenkins SSH agent. There is a blog post on Jenkins.io with a summary. So it moves agent terminology cleanup project forward which we're handling and focusing on three special interest group. Then related topic, official windows images. So now we have official windows images for all the same agent repositories. We have continuous delivery process for them. We have releases and everyone is welcome to start using them. So they are considered as fully supported images and let's talk a bit about what fully supported means. Okay. Then another major update that the project by team Jack, Pauline, Newman, et cetera you have up identification support. It was at least as preview one month ago but now it's in J, so you can just go to the Jenkins Update Center, install a new version of GitHub branch source plugin and get the authentication as GitHub app. So you get higher rate limit using independent authentication and security, et cetera. So this is also an item in our roadmap. It's great to see that. And also there is ongoing development in the Google Summer of Code. Just today we have published the first video about proof of concept being developed by our student. So if you're interested to go to the Jenkins YouTube and you can find it. So this project in GitHub checks API for Jenkins plugin and maybe you would like to summarize the current progress all the way here. Yeah, of course. It was a really nice meeting today. We had a presentation of a prototype which already does a lot of things. So I now have a good feeling about that there will be a good outcome of the project. Of course, it's just a prototype and the code needs to be cleaned up but we already have a kind of design document and we know a lot of steps we should go forward. And I think, yeah, it will be a very successful project, hopefully. The fingers crossed. It's really important to the Jenkins community. So, yeah, thanks for working on that. And yeah, by the way, once you have this major updates please don't hesitate to leave the project description so that video, for example, is linked there. And hopefully we could have a blog post soon, who knows. Yeah, not now yet. Or do you think just for the prototype or for? Why not? If it helps to facilitate the feedback. Okay. Yeah. And same for other projects. So apparently all people on this call are mentors in one of GSoc project or maybe multiple ones. So if you have a prototype or whatever which would be a showcase, please do so. So Oleg, as a topic on that theme we've got an upcoming release of the Git plugin that will include symbols for pipeline and some other stuff. Is that a viable blog topic? Why not? Okay, all right. So that would be one where I could blog about it. Great. All right, thanks. Mm-hmm. Well, any blog posts would be appreciated because again, we want to share stories. We want to share improvements about the project and if it fits the user experience theme, yeah, you know what to do. We will talk about that later. Okay. Okay. So yeah, another thing which is coming soon, hopefully the next weekly is major update in system rate permission. I have an action item to discuss when would be the weekly release. So long story short, we have a pull request which is needed to finalize this story. And we need it for the next week for crowd testing with your UX hackathon because system rate is really important for users of integration is called. So there is a pull request from team which is waiting for reviews and more reviews who would be appreciated. It's here, extended system rate and extended for agents. So actually what I'm going to do, I'm going to ask core maintenance about having for this not on Tuesday as we're discussing now, but maybe on Monday or even earlier. So that we could start testing that. So there are three contributors who already tested that and I think that we could learn that. So yeah, I'm about asking for such deviation but I think it's really important for the project. So the idea then would be system read would be in a weekly build even at the launch of the hack fest. Yeah, we have an event scheduled to Tuesday about system read permissions with demo, et cetera. And by this time, it would be awesome to have it in the Jenkins victim. Well, as assuming that merge conditions are passed but actually they passed even now. I approve that I just moved it back to review because I wanted to test a bit more. But yeah, I'm happy to start the official measure come down so that we could integrate it tomorrow. Okay, so sorry for such teacher about incoming changes and ongoing changes but I think it would be useful if we cover it a bit at these meetings. And if you feel that we should focus on other stories, just let's discuss that. Okay, next important news. We have been accepted to Google Season of Dogs. This is our first ever year in GSOD and actually this is the second year of the Google Season of Dogs at all. What it means to the project, we will have a technical writer working on the project from September to December or maybe even long way for it's a long running project. And yeah, it's a good tip that you need to improve particular area of documentation. We have a number of project ideas published here for example, just like in documentation migration and update, documentation, documenting Jenkins on Kubernetes, recognizing user documentation and probably extending that and also creating new solution pages. So this is the project ideas we have now and if anyone is interested to submit more project ideas please do so. Thanks to Mark for submitting new be friendly issues, et cetera so that students can try contributing something. Apparently actually we got a number of pull requests and comment from potential mentors in this program. So you've got nine pull requests like Mark. That's right. Yeah, so and counting. So we already get some contributions and obviously we are ready to facilitate it. So if you have any project ideas, please submit them. So we have one month until technical writer applications start. So by that time it would be great to have all projects in place. Okay, so another quick update is Cloud Native Special Interest Group. So it has been dormant for one year. We had a long discussion at the Jenkins contributor summit in Brussels in February. In January and there was a consensus that yes we want to recover that. Yesterday we had a first kickoff meeting with those who joined the meeting. So we had around eight contributors there and we agreed to price it on this scope. So major change is important for the project that we rather switch focus to user stories. So it means your plugins within the CNCF and keep managing Jenkins in Kubernetes, Jenkins on cloud providers and other things you can see in the list. We still want to work on architectural changes but architectural changes would be rather scoped to focus on delivery and user features because before that the seat was highly focused on architecture or cloud native Jenkins and yet personally I'm not sure whether we really need a cloud native Jenkins or whether we need cloud friendly Jenkins and cloud friendly Jenkins for me is also a really good goal for this seat. Okay, if you're interested there is a recording that there are meeting notes starting from June we will have regular sessions but the seat is back and I will be updating pages. Okay, and yeah, other important update is Jenkins UI UX HardFest. So if you have participated in any community meeting over past two weeks you may have heard about that because we discussed it almost everywhere but yeah, the idea that we run a one week HardFest specifically focusing on improving Jenkins user experience and it's about user interface, documentation about sharing stories, updating tutorials, providing guidelines so that users can easily use Jenkins and easily can find the information. So right now we have three tracks. So it's user interface, it's user documentation and yeah, well it's spread the word I need to submit a pull request to fix that but yeah, just sharing whatever stories including leveraging the Jenkins the way program we have started two weeks ago which was approved at the governance meeting. So yeah, that's the plan. Currently we are aligning a number of events so he's a draft, we have already published a few of these events, others will be published by Friday and hopefully it will be a great event where we will have many contributors joining. Right now we have 50 RSVPs in our registration form and we have around 80 RSVPs to the opening meetup. Personally, I have no idea how many contributors we will get in total but yeah, our hope is to have around 15. So let's see. Any comments about that, any questions? So like the gathering, the contributors work, the repository that you proposed, I think that's later in the agenda, isn't it? Yeah, we can just switch to that actually. Ah, okay. Okay, so one of the challenges for us in this hackfest that it includes not only code contributions like submitting pull requests, that part is easier but it also includes non-concrete contributions. For example, reviews, user experience testing and also spread the word including submitting stories, posting about Jenkins, et cetera. So we need an engine which would allow us to record these contributions. As a part of discussions we discussed multiple ways to do that. One of the ways was to just have a Google doc where everybody would be able to record contributions. Another way is was to have a spreadsheet in Google forum is basically the same. But I actually suggest a bit more sophisticated way is having a separate repository where everybody would be able to submit their contributions. And this is what I propose here. So I'll briefly show it to you how it looks like right now. So there is a UI UX hackfest page. Basically it's just implemented in readme indeed. And it has some advantages being compared to the forum because we invite contributors to submit information about their contributions as GitHub issues. So for example, here I can submit the UI UX enhancement, bug fix or whatever area. And basically for each contribution we ask participants to summarize what they've done to share some links, to share screenshots, if possible. And yeah, if users submit such issues then what we will do, we will process them, we will include them to the list of contributors. So you can see it right here. We are using all contributors. It's a default, well, it's pretty popular engine which allows tracking contributions. So we will be putting them there. Also we can aggregate this information, for example, for daily summaries, weekly summaries and we can use that to generate reports when the hackfest is over. So that's why I propose using such maybe a bit more sophisticated engine but it will be hopefully more efficient in terms of collecting information. So just to reiterate, all I need to do as a participant in the hackfest is submit an issue to this repository and use one of the templates that's there to describe my contribution and that will have recorded that yes, I'm attempting to contribute. Yeah. So for example, recently improved, yeah, improved docs navigation part on Jenkins.io. So yeah, for example, I can just link my pull request. I want to do that because I need some time to find that. But what I can do here, I can just take a screenshot of the new bar I created. Yeah, I'm just showing it in live because it just to show how easy to implement it. Then yeah, link, okay, just user documentation. Then some other pull request, then after that, yeah. Improved the navigation bar. Yeah, now it doesn't take three pages. It's still difficult to navigate on a mobile UI but yeah, at least it's better. Yeah, and user doc sections can be easily found. So yeah, basically I report such contribution. Okay, here how it looks like. And after that, then somebody who reviews that, what you will do, we'll use the bot because yeah, I forgot the command but it's easier so that all contributors. So somebody reviews my pull request at something like that. Aleksey Nashev for documentation. So I will cheat a bit because I haven't submitted the documentation pull request as a part of this hackathon but please be sure I will do. Right. Okay, I just asked the bot to update the page. And here there is a pull request which basically adds documentation to the table. And that's it. So right now it has been added only to the metadata but then there will be incremental pull request which will update this page and it will set the documentation icon here. So it's a widely used engine and open source and I think the hackathon is a good opportunity to try it out. I will also welcome bot there. I will let other bots which summarize these issues and create daily reports. Again, together with SmartKey we've been at the JSOC Mentor Summit in Munich this autumn, last autumn, and there are at least two sections which were related to community bots and promoting that. So I have a bunch of notes and I'll use it as my playground if you agree that it's a good approach for sharing the events. I would love to help on that. I have notes as well. Okay. So basically what I'm asking here is everybody fine with hosting? So there will be something like seven plus ones in the developer mailing list. So does it matter whether it's hosted in Jenkins Infra or Jenkins CI? Does the organization which hosts it matter? I would prefer to host in Jenkins CI because they have admin access. So I can basically hack things quickly if needed. Okay, that suits me just great. Is that does that slow down any linking of pull requests into it? They just hyperlink into them with a pasted hyperlink and that's sufficient. They don't have to use the GitHub link of pull request facility. Excuse me. Well, it doesn't really matter because GitHub pull request facility works across organizations. It does. Oh, okay. Good. All right. So it impacts, for example, team mentions but to be honest, I'm not sure why we would need that. I will probably create a team for reviewers, organizers and whoever wants to help us update into this website. But yeah, that's it. Okay. So then ultimately this read me page will represent when it's, when as we get towards the end of the week, the read me will have on it pictures of all the people who've contributed. So we'll have 50 or 60 people as contributors there. Exactly. Nice. So that's my plan. Everything is more or less automated. So yeah, as long as we don't have someone who uses strange GitHub profile, et cetera, it will be easy. Okay. So if you're fine, I will just move it because I needed for the documentation update anyway. So transfer Genki CI, that's easy, right? Okay. I will fix the team access later. So I will create a new team, but then something happened. I still didn't understand how the things work sometimes. Where are they? But okay. So now it's hosted on Genki CI I will go to move the prefix. Okay. So yeah, it will keep patching it, but yeah. I think that it's a good start. So thanks for your time on that. And yeah, at least you've got it published. So any questions or should we move on? None for me. Okay. So the next question is about themes support policy. And again, it's related to the hackfest because one of the items we put there right now is support of the dark theme. And why do they, they would be interested to have other things updated to have a better marketplace for themes and other topics which are currently in the draft Google doc. So in order to do that, we needed an official support policy for themes because the UXC, when we were discussing this topic, there were a lot of concerns about how do we align themes support policy with the need to evolve Jenkins UI. So there was a pull request from me which is based on the dev list discussion. So at that dev list discussion, I guess we got a bunch of plus ones. Notably, we got plus one from Tobias who is a maintainer of simple theme plugin. So it's a key feedback for us. Then yeah, there was this pull request. Actually, I didn't intend to have it merged before the meeting, but I forgot to put on hold. Sorry about that. But yeah, I just, I still want to discuss it here and officially sign it off because the policy is basically that we don't provide compatibility for themes. So it seems that we can break the themes by UI updates which is must have for roadmap. They will have stories like UI overhaul. And definitely it's not something which could be delivered without breaking changes in layout structure, et cetera. So there was a page and right. Yeah, I'll just show the current version since it got merged. It's to be then managing. So it's here, themes for user interface. So yeah, this policy includes two bits. One is yeah, things are provided disease without any warranty, just taken from MIT license. Y explains why we need that guidance, how to report that and best practices for developers. So this is what was proposed in the mailing list and signed off just to use a better text. So my question to the governance meeting, are we fine with that being host disease or would we review it, re-approve it, maybe reverse it? It's just fine. So in this, just merge it. Or it is already merged, but... Right, yeah. Sorry. And I don't know how to say it. I clearly approve, I merged it. So yes, absolutely. Well, it's a post merge approval. Yeah, sorry about that. Well, no worries at all, it's my mistake. I didn't mark it that proper accordingly. And the mark was totally right to merge it because it's within the user documentation. So it's hoping the editor who makes the decision whether we merge it or not. And I'm not sure whether it was a good idea to put the policy in documentation, but yeah, I just decided that until we have something formal, why not? But okay, if everyone agrees, we can just approve that, approve. So we will probably make some updates during the hardfest and this pages, but it works. Okay, the next topic is a bit more interesting. It's about our Windows support policy. So Jenkins project is 15 years old and during this 15 years, so basically we had no Windows support policy at all. Well, and for what it was, we still didn't have Linux support policy or support policy for any other system. So the theory behind that is that if you're able to run support Java version, most likely Jenkins will work. And this is a good theory, but we have a lot of native code in particular JNR, JNI, we also have Windows Service Rapper and other components. So it's not guaranteed that Jenkins will work on any platform. And this policy basically suggests a change. It documents the support levels we want to have. This is what we discussed in the developer menu list. Right now there is no conclusive decision there whether we measure this document or not, because, yeah, so let's check what we have there. So we have some more positive comments about having policy in general, but you know approvals in the developer menu list for this particular pull request. We have approvals from Mark, from Team Jcamp and from Sliden about the policy. And yeah, I suggest to briefly discuss the meeting and to see whether we need to get the most feedback or whether we can publish a day's version and the iterative needed. And I think we should publish and iterate. I think it's adequate and beyond. So it's a really great policy to have even if we didn't know iteration. It describes levels of support and which things we're actively testing in which we aren't. Yeah, so there are some follow-ups which will come up to that and which are worth noting. For example, currently we bundle .NET framework to .Zero binaries. For example, for Windows Service Rapper, we want to go to for .Zero. Basically it means dropping support for Windows XP Service Pack 3 and so on. I'm not sure whether it's that important in 2020, but it's a big technical depth for the project to maintain to .Zero. If you look at the code, we have a lot of branches. It also impacts current Google Summer of Code project because there is no YAML parsing libraries which would support .NET framework to .Zero at the moment. So we want to move forward and basically drop compatibility of some Windows versions. Yeah, and our support policy is basically level one is just the latest supported versions of 64-bit and versions which we put in Docker images which is currently not latest, but at least we put it explicit. Then level two is whatever is supported by Microsoft which is 64-bit. Level three, it's everything else. So it's no longer support versions of 64-bit platforms, 32-bit platforms, basically all other exotic, well, exotic versions. For example, I spent a significant part of my career working with Windows Embedded. And the Jenkins works there, but I'm not sure whether we are ready to support that especially since we have no practical way to fix issues at the moment and to test that. So I put it to tier three. Same for preview releases, same for wine, arctos and other Windows API emulations. I have no idea where the Jenkins works there to be honest, but I definitely know that it works with Siegwin. Again, it's not something I would wish for the support, but yeah, whatever. And yeah, level four would be unsupported. So things which we definitely don't support. So it's Windows XP all the way there's a typo, all the way when service pack three, then I put Windows phone, just an education, edge case example. And yeah, basically any other Windows platforms before 2008, so. Yeah, no Windows Visto support, not now, not ever. Well, it's up for discussion, but with the current policy it actually would to be tier three. Oh, yeah, tier three. So I still need to fix spelling a bit before merging, but in principle, this is what I support. And Moeva wants to improve this policy, open the platform specialist group we will welcome contributions. Okay, so what do you think about merging that? Assuming that I fix typos. I'm a plus one. I did not comment on this PR because I don't know enough about Windows. I didn't sort of, it's a non-binding plus one, if you will. I'm plus one, I think it's the right thing to do. And I promise to continue using Windows and making sure that it keeps working. Okay, Moeva, what do you think? Yeah, for me it's a plus one. I don't use Windows, but I think it's a good thing to have it working because a lot of my students are using Windows and they would be happy if they can use Jenkins and Windows. Josh, you're just a gentleman in the middle of the meeting, but if you want to comment. Give me a moment to try and find the documents that you're walking out of. Okay. Yeah, so they'll shade in the comments. This chart, this chart. Okay. I think I need to bring my son to bed. So goodbye and see you next time. Bye. Yeah, thanks, oh yeah, yeah, bye. Bye. Yeah, I think we are closing down more or less. Josh, you used that. Yeah, so do we have any other topics for today? I don't have anything. None for me. Okay, so the next meeting I guess it would be as usual. So it's something like June 3rd, I guess. June 3rd. I don't care about anything happening on this day. So I think you just schedule it as is. Again, I'm not sure whether it will be Zoom or IRC. So let's see. I prefer Zoom on my own, but yeah, I guess that might be contributors who prefer IRC. Let's see. Okay. Yeah. Josh, would you like to finish the discussion here? Sure, I mean, I look through it in the preview, it seems fine. Sometimes I wear Windows hat, sometimes I don't. My current Jenkins environment does not, but I definitely deal with Windows. Overall, it seems reasonable. Is the idea that right now you have zero documentation as to what you support? Exactly. So we will gradually improve in this documentation. For example, we just updated web browser documentation when we were working on Java 11 support, we created support policy for Java, but operating systems is still a terrain for us. Okay. Future document will be, will include Docker, or will future additional pull requests will try to talk about Docker in a similar way. Okay. Yeah. So I left one little comment in the GitHub. There's one line, which is a little weird. Cool. Okay. The colon, the colon, windows, I don't know what it's trying to do. You mean this plugin? Yeah, like, is, is, is plugin colon windows dash slaves a proper name of a thing, or is it? Yeah, so it's a macro. This macro will basically resolve to this website. Ah, okay. Yeah. So yeah, this is a special case. As a happy maintainer of this plugin, I would say that I see no real use case for that on modern Windows versions. And just configuring this plugin to be working on Windows versions would be a good challenge. But yes, since it's still, they decided to reference it. Okay. Right. We know we have talked about slaves, but masters is still the canonical term for the other side. Yeah. So we renamed agents. So now there is no slaves. There are agents. Right. We have a project in our roadmap to finish the cleanup, because there are still a lot of things to do. But yeah, we just discussed renaming Docker agents before that we renamed the SSH built agents plugin. So these were two major issues, but still a lot of minor things here and there. So we will gradually clean it up. It's here, but so there is just a link to the epic. For master terminology. So personally, I don't have strong opinions. I know that Marki has. So I think that we put it on the roadmap to name something like Jenkins server or whatever. But yeah, right now there is no specific plan for that. Okay. So as a general thing, we at my employer are in the process of moving away from Jenkins, this is a slight disclaimer, but I'm always happy to help out with terminology and things. So when you guys do get around to it, please feel free to ping me. I'm sure I'll still be reachable. Thank you. That's great. Thank you. Yeah, I'm, should I mark and approve in the PR or? Well, if you see it's funny, I feel free to just approve. So basically all our pull requests and the Jenkins project open for comments. So yeah. All right. I'm happy with it. Thank you for taking the time. Yeah, it's perfectly fine. Thanks for your feedback. Okay, so my next steps there, I will fix a few typos and then hopefully we will measure them tomorrow after the platform seek meeting. Okay, that's all of these requests to agenda and thanks to everyone for your time. Yeah, I will publish the recording soon. Thank you all. Also you online. Okay. Yeah. All right. Cheers.