 Hi all, welcome to the Jenkins Governance Board Meeting. Today is December 16th. We have several contributors on the call. And the today's agenda is to go through the recent news, process of the trademark usage request from Wish to Shlap, discuss new year blog post, take a look at the roadmap and at least edit the topic for Jenkins electronic book which we need to publish. Are there any other topics we would like to discuss? Is the new year blog post also covering the concept of the CDF newsletter? Is that the same topic Oleg? Or is that, does that need to be a topic? Not exactly, okay. Yeah, so we can discuss it separately but CDF newsletter is basically a summary of key events in the project we need to send to them. And the new year blog post is what we use to publish every year. And I believe that we should publish it this year as well. Okay, so let's talk. Oleg, just quick question. So that blog, is that the same thing as the, kind of like a year recap? Yes. Ah, gotcha. Yeah, so Marky is not able to join today. So, yeah, I'll just discuss it on a high level then. Okay, recent news. So, yeah, last week was relatively silent. Two weeks ago we had a major discussion about the autogies, about new releases, Jenkins, three proposal and other things. So, if you're interested to see news, please refer to the previous meeting. Are there any new events we would like to share today? I guess not. And none for me. Yeah, so maybe on a small note, we have started a call for Google Summer of Quota project ideas and mentors. So, it's in the developer mailing list. They will also be a blog post from Cara published today. So, if you're interested to participate in Google Summer of Quota, to have a student working on a project of interest this summer. It's a good time to think about the project ideas and maybe submit one, so that we can start accumulating the project list for the application we will submit in mid-February. There is still plenty of time, but there are students exploring the project and if we have ideas earlier, it also means that we have better chances of attracting students who will discover during the Christmas break. Yeah, I don't think that we have anything new to share. So, let's go forward with the agenda. So, trademark usage request. Yeah, there was a long discussion in the mailing list. So, the context of that on October 14th, we adopted a new policy, which is saying that we want to follow Linux Foundation's trademark usage guidelines as a default. Though at that point we made an additional disclaimer that if in exceptional cases, mostly in the case where there's a precedent of similar name being approved, we may accept an alternate beta, but we set a clear expectation that the trademarks would be that our recommendation is to follow Linux Foundation's trademark guidelines. So, here we have got a request from Virtus.Lab. They are launching a new product and they would like to use Virtus.Lab Jinkins operator service. So, the problem with that trademark that it's compliant with our previous policy, well, we should be using a couple of years ago and before we actually started adopting the Linux Foundation one. And if we take the decision we had in October 14th, then no, it's not compliant because there are other patterns recommended by the Linux Foundation's trademark guidelines. And there was a proposal for Virtus.Lab operator service for Jenkins. We discussed that, but yet the request decided to proceed with the original name, this one. So, we started facilitating feedback in the mailing list here with those we have. I personally casted zero because, yeah, although I don't feel strongly, I don't see particular reason why it would be an exception. In this case, we adopted the policy and we should rather start following that. Same feedback from Gavin. We have plus one from Mark and we have minus one from Daniel based on the process discussion. So, right now we have net zero in the mailing list. And, yep, we didn't get feedback from all both members yet. So, from those who are on the call, Alisa and William haven't voted yet. And, yep, it would be nice to get your feedback. I think for me, if we want to adhere to the Linux Foundation guidelines and we need to start somewhere. So, let's start with this one. Yeah. So, I'm for sticking with the Linux Foundation guidelines. So, basically it's minus one. And, yeah, I'll take in the conversation. I'm also leaning towards reducing my vote because Daniel is absolutely right if we adopted the policy. We should rather go for that. Yeah. So, I'm not saying there shouldn't be any exceptions, but I think exceptions make sense when the result would be weirdly inconsistent. So, for example, a sibling product to a previously approved trademark usage has a reasonable case for an exception. This one is just something completely new which is why I don't really think it's a good idea to just go ahead with allowing it. Okay. Okay, this is not the same discussion as in the beginning of the meeting or because I came a little bit too late. So, same discussion. Same discussion. Okay, sorry. So, it's fine. I think if we now have adopted the new naming convention, we should stick to it. That makes sense. So, minus one from me as well. Okay. Oh, sorry. Almost. Sorry if I confused you. Yeah. So, yeah, I still feel that we don't have quorum. I suggest that we wait for feedback from Marki and then close it in the million list. But, yeah. I think that we either buy the ballot with the policy and it feels like it's time to do that. Quick question, like that you mean to put a zero for Gavin or is he on the wrong line? Yeah, zero is zero. Yeah. So, are you fine with these votes or does anyone want to reconsider, adjust? Looks good to me. So, I think, yeah, waiting a bit in the million list and then just following the discussion. We definitely don't have strong consensus to approve that. Okay. So, should we move on? I think that I'll take action item or to communicate it back. Because, yeah, it was rather me who probably over-emphasized the possibility for exceptions. So, yeah, I will take action item here to communicate. Okay. So, for the new year block post. So, we need to post one. Last year, we posted it after the new year. It was something like January 7th. This one, yeah, January 7th. And this block was basically summarized key highlights. It included project updates basically once we had from the Lisbon Contributor Summit. And after that, there were some stats that we collected from different sources. So, this is what we've got. And maybe it's a format we should follow this year. When we had a discussion on two weeks ago, Marky wanted to take a lead on this effort and cut in the block post. We wanted to have a sync up this week so that we would start drafting that. But yeah, Marky might not be available for a while. So, I think we need to regroup. And if, yeah, so next week, we'll just, some of our submitted drafts so that we can create a new block post together. Does it make sense to everyone? Or should we speed up that? It makes sense to me. And to me. I think that's reasonable, I like. Okay. Okay. Yeah. And on separate notes, we have this. Just to confirm what's the intended publication date? We don't have a strict date for publishing. Obviously, it's better to do it around the Christmas New Year period. But if it arrives slightly late, it's also fine. So historically, it was rather a beginning of January. Right, okay. Seems like, I was just wondering whether we're targeting January 1st or what the intended date is. But to clarify, late next week or mid next week is the intended publication date. The very main forest, is that correct? Optimistic one, yes. But yeah. So it really depends on contributions. And maybe it's a signal that we actually should start it even earlier. Yeah. Same for the CDF newsletter. So deadline for projects is a January 12th. But it's again a summary of key events and we have some. So I think that it should be just another document we create and collaboratively update. So I do, yeah, I will also create one. Again, I will coordinate with Marty what is his availability. But yeah, both documents, I think should just go to the developer mailing list so that everybody can contribute a patch and we just review them and send off an advocacy or some way before posting. Okay. So do we want to do roadmap review? I believe, so last time we did it, it was in November, since that I'm not sure we had any major changes. So there were some items here and there, which we need to draw. So, you know, we have confirmation that change template in engine is now under development. We have pretty big gap in tools and service integrations because even if there are plugins happening here and there, contributors do not put them on the roadmap. And yeah, this is something you probably need to figure out how we do because there are services appearing. But we need to improve contributor outreach because otherwise we will always have a kind of gap there, this GSOC project ideas on the right. So Oleg, can you share some examples of tool and service integrations that are in progress but aren't on the roadmap currently? So we can just take a look at hosting requests. So there are new plugins being hosted and half of these plugins integrations with different tools. Got it. Okay, thanks. I have a question. Which of these plugin integrations important enough and address significant subset of users to be posted on the roadmap? But yeah, I think that we need to highlight some of these activities. Now, would we had discussed in Google Summer of Code officers this morning get plugin or a credentials binding topic? Is that under tool and service integrations as a GSOC project? Would that be somewhere else? No, it would be a tool and services section. That's for sure. So regarding, so roadmap still highlights key initiatives with major impact. So what we will need to do is once there is clear scope for this project, we decide where they should be highlighted. Because yeah, this year GSOC projects will be smaller. Last year, we added many of them on the roadmap. I'm not sure about this year. So I think we just need to discuss it on a case by case basis. But the plugin is definitely important for pretty much every Jenkins user. So it's rather a question of what we put there. Great, thank you. Thanks for the clarity. Yeah. So user experience, plugin management, UI UX revamp, it's in preview. The rest of the changes flowing in. But I would say that plugin management completely changed thanks to Daniel, thanks to team and to many other contributors. So I'm not sure whether we plan any more major changes there. I don't. I think it's only really major because it's a collection of many individually minor changes. And yet for me, the delight of dramatically faster, more attractive user interface, more intuitive search. Yeah, I agree with Daniel that they may have been individual contributions, but I think it's much, much better than it was before. That's been a significant improvement over the last year in plugin management. Yeah, I totally support that. And I think that we should keep it in preview and maybe move it to completed with the next little CS cycle. But yeah, it's a subject for UI UX discussion. Next item we have configuration UI tables to these. So this one is definitely in preview. This one definitely needs more contributors. And if you're looking for a way to contribute to Jenkins, this is something to consider. And you can see that we landed this change more than one months ago. There is still many incompatible plugins which we need to address. And the clock is ticking because the next LCS cutoff is in a bit more than one month. So by this time, we will definitely need to take a look at this dashboard and decide what we do. Either try to deliver all these fixes or find the alternate solution. For me, it's rather push forward and try to get it done. But yeah, still it requires significant time because most likely this list is not even a final list. Most likely there are other plugins we still don't know about. So definitely something to consider and maybe you'll still need to come up with whatever compatibility layer in JavaScript. Though I'm not exactly sure whether we can implement that. We can do previous discussions. Okay. So, modernized mirror infrastructure, I believe it's done or not. I think it is done, Daniel. Any insight you have on things? Oleg, I bet if you click that, you'll see, if you click the link there, you'll see it will open for us. And I think most of the tasks, yeah. I think it, and we're now working again on Azure file storage. So we're back running the way we were before the outage. So I think that one is justifiably done. Okay. Then probably we should close it. Yeah, and is it okay if I submit that poll request? Yeah, that's fine. Great. Okay. Let me make myself a note. Okay. Then items in progress, more UI, UX, look and fill updates. We still have some stories flowing in. Definitely the scope defined by UX C hasn't been fully delivered yet. So we should keep it as is. Plug-in documentation, migration. We still have a lot of plugins to migrate. Well, last time I checked, we had around 600 plugins. So it's a big number, but we still have a lot which haven't been submitted or which haven't been released. Yes. And we did actually on that topic, we did have a conversation raised in the Jenkins info meeting from Olivia Bernin asking what our plan is for Jenkins Wiki. And so we've started a plan there in first draft talking about where we go with the Jenkins Wiki. It's going to stay read only and eventually we need to probably decommission it. Yeah. Eventually we definitely need to do that. Let's see what would be the implementation but now, yeah, there is still a huge gap to, I feel. Right. Yeah, maybe we could just archive these pages. So we don't really need confluence to display them. So let's see. Okay. Then documentation migration to Jenkins. I was still in progress, a lot of things happened, but yeah, there is a lot of documentation. Same for terminology. And pull requests get merged, but everything is in progress. So these columns remains the same. Management administration, do we want to go through the entire list today or do we want to stop at particular areas so that we cover other topics? Mark, you're muted. Packaging and platform support is one that I would like to be sure we touch on. Other areas are less of concern for me and Jenkins on cloud maybe is one that you want to touch on. Okay, so I think that they are all in the right state. They are, okay. Management's preview, remote preview, our plugin compatibility is still a work in progress, although I would say that the vast majority of plugins are compatible. So probably we could close it as an initiative. There will be still long tail, but whatever. The review services and script security, basically they're in the same state that a pull request suggested, but they haven't been fully integrated. For cloud platforms, Jenkins, fellow runner and the development that there are changes here and there, not ready for 1.0. I didn't expect it to be ready for 1.0 anytime soon. So just there is still things here and there to be completed. External fingerprint storage, it's in preview. It works, there are adopters. So we rather need to move it completed, but firstly we need to move the APIs for GA, but I think that the story is solid enough to call it closed. Tecton pipelines will step under development. There are some changes going there. There is a new roadmap, but it's in alpha. So the state is correct. Plugable built log storage for Jenkins pipeline, basically the same. So it's in preview. Everyone can evaluate that. At the same time, it's fully operational. So if you want to, you can use it. There is a plugin and a few other implementation attempts. Plugable unit test result storage. Again, it was shipped in the JUnit plugin. It is possibly a scale implementation by team. So we need team to comment whether it's ready for GE or not, but yeah, the implementation is definitely ready for preview. The command Jenkins on Kubernetes, I think we should move it to done once the last pull request is implemented. There is still a lot to do, but... But that project as a project has concluded, Xenob is actually continuing to write and we have office hours tomorrow with her. Okay? That's good. And yeah, basically no other changes on this list. So packaging and platform. I suggest that we close here and finish other topics after that. So Mark, would you like to summarize? Yeah, so for me there, the summary is that I need to be sure that I get updates made there and we've got significant work going on in the Docker image generation, trying to get towards these multi-plot multi-arch images like S390X, PowerPC, ARM64, and the pull requests are in progress, we'll continue making progress on them. I also owe the organization a JEP proposing a Docker image deprecation policy or a Docker image maintenance policy. And that I hope within the next, well, before the start of the new year. There is consensus, so JEP is, well, it would be nice to have one. Yeah, the platform SIG wants the JEP very much because we're behaving oddly right now and that's the benefit of a JEP is it'll get us more consistent document to refer to for our behavior. What do we do? How do we choose things? Okay. So, any other updates on platforms? None from me, but. So, yeah. I think, yeah, this is a good summary for now. We can discuss governance, but for governance topics, it definitely makes sense to have more governance both on my own bus and we need to plan our activity for the next year. So, I think that in January, when all the holidays are over, we will give discussion with William, Mark, Key and Gavin and Key, Tyler and all other contributors who are willing to split in the governance area so that we could prepare the roadmap for the next year. Because currently, yeah, we completed all major items to be planned for the year. Yeah, there are some items like funding which still needs to be addressed, but ultimately, we need more content there. It's a good time to think about that. Well, like, can I also add? So, when we were in past, in-person Jenkins user conferences and our DevOps world, we had a lot of people who comes to the booth and say, wants to know what's the latest and greatest in Jenkins. And then for this year, DevOps world, the virtual event, we also had, well, one of the top presentation or session was about people wanting to know what is the latest and greatest in Jenkins. And I think that was your session and, oh my gosh, partly. Oh, I'm so, I'm spacing out. Yeah, so there was a presentation by Jeremy about UI ads. There was a presentation by Mark about documentation and there was a top level overview by me. Yeah, I think it was yours that was at a very, that was very, that had a lot of views on it. So I'm wondering, would it be worthwhile for the project to maybe do a monthly, bi-monthly or quarterly update of, you know, the stuff that's going on of the roadmap and so that people can see what's the latest and greatest or what's going on with the project. And maybe, you know, that's an opportunity for us to ask for contributors as well. I know we're always asking for contributors, but that's just a suggestion. Yeah, bye Daniel. Yeah, I think it would be nice. So it basically boils down to the bandwidth to prepare that. Yeah, if we can do that, let's do that. Because all this material's help, we submit the monthly update to continuous delivery foundation. So maybe we could have collaborative version every few months on the Jinx.io website. Yeah, yeah, and CDF can also help us with, you know, the webinar, podcast, whatever we want to do. Yeah, right. So let's keep talking about it and yeah, let's try to find some time. Okay, I can help drive that. Cool. Okay, so the last topic in the agenda is for Jenkins e-book approval or to proceed to this governance but members as signers of the e-book later, right? Yeah, so a little bit of the background is we took about six Jenkins is the way case studies where we do have approval to use their logo. So we shorten it, very short and sweet into six very brief stories with solutions, challenges and what was the outcome? So my ask, so at the beginning of this document, can you click on the attachment? Yeah, so at the beginning of the document, there's a letter that it's kind of like a welcome letter and I was asking whether we could use the governance members as the signer of this letter underneath where it says the Jenkins project, right? But Oleg, I think your suggestion is great as well. I'm totally okay with, I actually think, I'm okay with putting my name on it as the events officer for 2020 and the outreach SIG. So whatever this team approved for me to do, I'm okay with it. Personally, I would prefer to give credit to you because it's all thanks to you and to sponsors that we've got Jenkins is the way program that we have got so much content and that we've got so much user feedback. Yeah, I would be happy to sign that but my contributions are pretty much zero. Well, for me, I'm happy doing it. I don't need the credit to be honest. Just glad to be able to help out and contribute. You totally deserve this credit. I think that it would be the best outcome. For me, I think it has heavier weight. It has more weight if it's by the governance board. But I'm totally fine with what we decide here. Other opinions? I like the idea to have Alisa's name there. I think it's really a good idea because you made the work and now you are the responsible person who is not responsible but everybody sees that you've done a lot of things and it's really good to see you there, I think. All right, Nody, thank you. Mark? What's one to Alisa's name? I hadn't considered that. I think that's great. I all in favor of that. And for all the reasons you mentioned, all like, very good. Yeah. So my suggestion is to just proceed with that then. Okay. All right, I'll proceed with that. Thank you. Thanks to you. Do we have any other topics? If not, let's stay for a second after the recording. And yeah, thanks to everyone who is watching and see you in the new year. Speaking of that, do we do a meeting con 30s? I'd prefer not personally. I would like to be out of out on the 30th. Plus one. No meeting. It's easy to find consensus on this topic, right? And I think that's a topic where you don't even, we have quorum by definition at those present in the meeting. So it might make sense to have maybe out of the meeting one week later, but yeah, let's discuss it when we get there. I think that's not an unreasonable idea. We did something like that with a doxig where we skipped one meeting, shifted the next a little later. So instead of doing December 30th, do it exactly one week later and then be back on track the following week, right? That sounds fine to me. Mm-hmm. Okay. So thanks everyone. Again, I'll stop the recording and yeah, let's give it up quickly. Bye.