 Hello, welcome to the Jenkins governance meeting today is May 5th and we have multiple participants on the call So we are doing the regular session. We've got a lot of items to discuss today Gavin will be taking the meeting notes. Thanks a lot to him for the previous meeting the meeting notes were maybe three times larger than before and Yeah Everyone else is also encouraged to contribute because his document is shared for editing Okay, let's start from use the first big news, which of course we missed is five years since Jenkins to the zero So it happened on April 20 2016 So well Just congrats We didn't do much celebration around that there is still an opportunity to do that someone is willing to take the section item But yeah Just for your information Thank us to the zero was nice. We introduced pipeline by default. We did plug in unbounding. We also Quite a lot of changes here and there and removed agents from the terminology. So yeah There are some things Sorry, we removed slaves from the terminology. So definitely something to celebrate Yeah So if anyone wants to take an action item under it, please do so Otherwise, it will be probably just a tweet Okay Nothing news. You've got two dot two seventy seven dot four release. It was just a few hours ago. Mark. Would you like to summarize it? Released had some infrastructure surprises delighted has a relatively few back ports We'll be discussing I'll be discussing with Darren Pope in a live stream later this week as well So basically everything is already available for downloads, right? It is confirmed available We will upgrade ci dot Jenkins that I owe later later today as it gets a little less busy Yeah, and it's not a security release. So basically if you're affected By the issues and if you want to get a back port just update when you're ready Okay, then she could Africa's summary maybe for you again mark Yeah, so five Five women from Africa were part of a large contingent of people who applied for the opportunity to spend one month Contributing to open source software Jenkins and two other projects were the mentoring organizations five mentors from Jenkins Assisted as these this group of five women contributed pipeline help examples pipeline documentation Project was a great success Plenty of things that we learned from it retrospective will likely happen this Friday with with them we've got a good retrospective document already assembled and We'll gather a little further and then do one final meeting to be sure we capture the things we learned so that we know How to do this better the next time? Is there going to be any Is it I don't know how to ask a question Is the is the retrospective plan to be like are you putting to take your learnings from retrospective and share it to the wider audience? Or is it going to be limited to this event and how are you going to do it? So I'll I intend to do a blog post to Jenkins that I owe highlighting it I'll I'll probably include notes from the retrospective in that blog post the the The participants were also willing to assist in a talk at DevOps world So I'm going to propose a talk at DevOps world for it. We'll do some other things like that I think Oleg had also suggested an online meet-up and again, I think that's a great idea That we should consider as ways to highlight. Hey, it's it's possible to come into the Jenkins project Contribute significantly Even if you have no prior Java experience in less than 30 days, we got these people Ramped up Compiling plug-ins loading those plug-ins working with them. It was it was a good experience I think now lots of lots of things we learned and we'll do better next time It's in it's in the same document it's in the retrospective section there page 14 and beyond So I will just say that So again, eventually the document will be referenced Somewhere from james say, you know, maybe Because here Yeah, that document actually already that the top level of that document is already referenced from jankens.io But we'll we'll do a summary of the retrospective. I think it would be a good part of the blog post Yep, that's for sure. We'll do the same for jsoc Mm-hmm Okay, anything else on chicota africa Then thanks a lot to mark christian angelic and mac mark roberts for running this event and for mentoring there We hope it was a great experience for everyone Of course, thanks for the to the mentees Yeah, thanks to all mentors and august mentees Okay, moving on devops world call for papers So firstly it happens. It was announced. The deadline is May 20. So you have just two weeks left um yesterday together with at least we did a janky's online meetup about the community agenda So at this meetup you basically spend some time to provide a review of what we are doing as janky's community at devops world And also there was a discussion of what to do as a part of CFP. So the recording is already published same for the slides. So we can take a look and yeah If you just want to feel some nostalgia, definitely go to this presentation because I put a few photos there But yeah, so it's a rather overview. So the presentation was relatively short see Sorry, was this was the presentation of that was given at the meetup or is this a presentation for people? Yeah at the meetup. So basically we did it together with Alisa We will be doing another session next week for a park time zone together. We sorry kind of maybe victor martinez But yeah, so yeah, here you can see mark Evelina There was also ulya somewhere Yeah, here's ulya Yep, so nice times. Hopefully you'll be able to repeat it some time MC another for He said another one might be next week for the apoc Hang on So basically we just wanted to provide some overview provide some concepts Because yeah, again devops world is more than just a conference for us We also plan to have contributor summit and other things Many things actually tbd But yeah, hopefully they will be confirmed Just a second Yeah, so what we have confirmed by the moment we will have two community workshops One is about contributing to Jenkins another is likely about Jenkins pipelines Um tbd then there will be community track also There will be continuous delivery foundation track, which will also include some talks about Jenkins Practition your track may include them as well Then community can notice to be decided most likely it will be by the continuous delivery foundation But if you have major funds for shares the Jenkins project welcome Then they will be asked the experts and hopefully contributors summit All to be confirmed and we are not doing Jenkins awards so this time because Jenkins awards will happen at cd con A gentle reminder to everyone We still have some time to submit donations. So it's open until may 14th It might be worth for the keynote to have I know it's a later topic but plug-in deprecation Policy should be a good one to announce there Not sure but it's definitely something to be discussed so Again, I I don't know how much time we would get what would be the scope There were discussions about Jenkins 3 or something like that if we do Jenkins 3 announcement We can just match the plug-in the replication under that But in the current state it feels unlikely that we will be able to announce it in autumn Even if everything goes well Because yeah, the match window will be mid to july. It's just two months from now Yeah, I'm still not allowed to go to the community this full my proposal Okay, so Yeah, anyway There are three limitations for this project Or a quick question regarding the keynote aren't key notes usually good news How would you mean that you think that the plug-in deprecation policy is positive for any users? It's not like we're doing It's not like we're improving the situation there. We're just making it easier for us to make changes but The obvious side effect is that all of those terrible long tail plugins that haven't been updated in years will stop working Rather than limping along as they do today So that really doesn't feel like and Let's get up on stage and proudly big Proclaim that we're breaking everyone's Jenkins kind of topic. I think we're holding a bit here so Yeah, I think you're right, but it's something to be discussed and Yeah, I think there's a positive way to phrase it as long as indeed we can show that we have done other things and saying this is a way for us to Focus our energy on what he's actually, you know Making Jenkins go, you know Forward rather than focusing on making nine years old plugins that nobody really uses like 60 times or something installed more wild to keep to keep those ones working. I think people would prefer the community to work on Making I don't know pipeline shine even more or something We're already not keeping them running As evidenced by tables to divs. So I really oh well, we have a lot of topics. So Let's discuss. Yeah, it's just a two more one because right now we don't even have consensus of what we do Not everywhere But yeah, let's see So what else? Again, the nations. I just put the link What is important topic there that there are only three limitations listed in our blog post But there are the limitations where Jenkins contributors may be potentially eligible. So there are also Global cdf limitations like top cdf ambassador top cdf contributor github's evangelist We I guess we already have Jenkins contributors in all categories But if you think about someone just put them here and there will also Two new awards just announced the last week. It's top cdf and user and Top github's and user So basically it would be just a company or from other user. Let's say one of the Jenkins projects That's for example And again, if you have A company which would be big highlight think about that Maybe it's also an opportunity to meet someone moving on Yeah, so just a quick update Just a few hours ago. We've got information about number of slots we get So announcement that yeah, we will have Jenkins projects this year And the number of projects is to be announced and the projects are also to be announced The announcement will happen on May 17th. So it's two weeks from now But yeah, I think you will like the announced projects Yeah, basically, let's say about jsoc. We're still in the Dark mode until the projects are announced You wanted to ask something I was just going to note that we are in dark mode. So no comment should be made by us, right because That's google's thing to announce not ours, right? Oh, like that's the the way it is. It's We will do an announcement as well, but firstly it should be official on the google side Because firstly decisions may change. Some students may appear to be not eligible. There might be other organizations reaching out and discussing Uh duplications, so we are not ready to do announcements by now because it may change Yeah, so who yeah, some people on this call are in the mentor channel. So you will be able to see the summary by the end of the day Okay So moving on Confirm grace they have talked project representative so For those who are not following this threat They can easily definition announced elections for the talk members They were there were changes Because this year they will be actually electing for representatives amongst six projects But the each of six projects I expected to make an elimination And what it means that we as a jinx project should also nominate someone And the deadline is May 14th. So we still have some time But this is the last governance meeting before the elimination happens So unless we change the process we should sign off some The elimination today though if Anyone wants we can extend it, but we will need to agree what would be the process after that And yeah currently basically it's only me nominated if someone Wants to eliminate themselves or eliminate someone it's a great time to speak up I'm not getting out of this I don't see any reason to extend it Yeah, full support from me for you being the nominee. Oh, like thank you for being willing Yes, thank you Thank you Yeah, I was I was showing a thumbs up, but then I realized that probably you have the browser full screen or something So I have several faces, but uh, you want to on the screen at this time? Yep, you have too many people this week No, I'm happy I'm happy with you being our candidate definitely Okay, then I think it's confirmed Thanks, everyone They will be still elections ahead. I have no idea how these elections will happen But you will figure out as we go And yeah other projects also are for election. So Jenkins x will be like making the elimination same particular tone Same for spinnaker and now the results to driver are still yours. So they will also make nominations Okay So anything else on the f-talk representative And the topic from but he's about removing common register from the core Yep so For anybody who didn't have the time to read the developer need the developers many least I sent and heads up there to About this removal. So we are working to update Jenkins. So In short, you may have seen or you may be aware that Jenkins has a common register 2.1 in its dependency tree, which is the dependency that was released in 2010 So it's even older than guava. So after many discussions with various people in Including especially in that thread. We got feedback from some people I think jc mostly said something like digester is not even fixable really. We should just get rid of it So instead of trying to you know, date it to commons digester 3, which anyways has a different fqn We decided to just remove it all together But then it would have the second step would be to it was to decide, you know, whether we would create a depth plugin and then again, I think What we've done is partly based on the feedback of JC's one, which I remember I think team said something similar that, you know We should be creating a detached plugin unless we can fix the ecosystem, which is what we're doing So we pursue just the latter because, you know, also we don't think When I say we it's it's I I'm trying to speak for the Jenkins project, but obviously that's more my opinion at this point um That removing it is a is a more The cleaner thing to do obviously this has the big and obvious caveat that I think Danielle pointed out On the pr itself at some point before we we fixed a more few more things and on the the thread on the dev list So We filed a pr for every single plugin we could find was using it, but Many many plugins have been abandoned for years. So I guess we have to decide as a community whether we You know release those old things that that are not even installed a lot of times in the world Maybe sending an ambiguous You know message to the world that those plugins are maintained somehow, which they are not really Or we have to accept that this is uh one of the One of the first or at least one occurrence of 15 years That that was you know posted a Jenkins i website already almost three years ago about the fact that you know To move the the Jenkins project forward. We need to break a few things Again, we filed a pr for everything that is impacted, but again, I don't think Money of those will just find somebody willing to just you know Own this maintain it merge it release it basically Um, so I got two questions. Um one There's probably a lot of people like me that have no idea what this does and why we want to keep it versus why we want to remove it Um, yeah, actually it's just the one question. So what does it do? Digester is a library for parsing xml at least. Uh, I I think it's only what it does um The the big thing is that even if some people could be still using the library per se Uh, it has wrong defaults. I would say I'm just repeating my understanding, especially from people like daniel Who uh insisted that you know, we make sure that the the the way that your series is Insuntiated is using the the the non default settings to be secure And uh, I think just he said something like on this on the pr that you know, there's no way No easy way to make this secure really, uh, and more importantly the the the fully qualified package names Of this library anyways changed between the the version that we're removing in the the version three So effectively upgrading would mean anyways upgrading the ecosystem like we're doing So, you know, it's that's why removing it from the core because again It's a library from 2010, which is the fact to you know, not a great thing in in 2020 21 11 years old library, uh, which is stuffed with with um, non cv is most if not all of them are um Unreachable normally, but could could be someday or uh, basically also making the security posture of Jenkins in the world Not great. Uh, when companies basically scan, uh Jenkins they find a lot of things that you know make them Uh, again, in my opinion in 2021 more and more complex more and more Tricky that the security teams accept this this tool, uh, you know in their toolbox, you know so looking at a leg screen share when you created the prs for other projects did you just, um Looks like you upgraded to digest your three were possible and then We're your plan was to remove it from core entirely Yep, this is what you're seeing right now. Uh, so not not right now. Sorry. This is Emma This is basically one of the plugins that we think we'll we'll never get a release Uh, if if you go back a leg or another tab or something to original pr Uh, you will see that I've I've created To this this table here that's basically pointing to everything that's impacted and when I put on the left side Uh, uh, red red circle. It's basically when when I really believe that we won't see anybody releasing and fixing this So those plugins are de facto, uh, going to be broken from now on um And and and if you look at the diff you will see that on this pr indeed we are removing altogether The digester library from the dependency tree not just upgrading either something Yeah, okay Of course mentioning that when we do such changes, there is always a risk that there would be third party plugins example, uh, there are vendors who provided their plugins outside of the main repository or Let's say sonar We do not scan and analyze these plugins by default And also there are zillions of proprietary plugins developed by companies just for their own use So there is a risk that something else will be broken from Sure, I mean, this is always, you know pros and cons, you know, um For what about what you just said though for open source plugins We didn't do just a scan using the search feature. We also used usages in plugin feature tool that that's if if uh, people here don't know all about this one Basically is a tool that is going to retrieve all hpis from all every every single Jenkins plugins in the ecosystem and scan the bytecode to see where whether there is a usage of a given Class in that And so we did that on on orgs org Apache commerce digester digester the class The one from Jenkins score itself and daniel I think was nice enough to to to to catch our One of the mistakes we did and to scan for the whole All classes from digester basically and this showed as far as I understood what daniel wrote like in the last comments or something on this of this very pr not not Additional hits in terms of findings. So the list at the top of this pr should be still accurate It is deemed to fix the whole ecosystem provided again, which is Not going to happen as far as I think Provided we would murder release every single pr that we have filed Yeah, but we still have an alternative because even if you don't ship it as a detached plugin You can ship it as just the api plugin users can install on demand So we can say that if you have one of these plugins Available without a fix you just install this additional plugin and everything starts working It was that the api plugin wouldn't be on the class path of this plugin Yeah, we can do is detaching and not bundling it Which is an option, but apparently jesse somewhere said that this isn't great I'm to be honest. I'm a bit confused by the approach chosen here because what is this you said, um We had the option going for a detached plugin or fixing up at the ecosystem and you said, yeah Let's fix up the ecosystem and immediately afterwards. You said, oh, look at all of these plugins. We cannot fix Isn't that Yeah, that's what you're saying. So what I mean is that we do I think the diligence to file, you know, every single pr But then I'm saying I don't think as a Jenkins as a project as an open source community We should be you know releasing. I mean understand. Okay, right. It's a bit confusing or ambiguous Um, I'm saying we yeah, we I mean, yeah, we filed a pr that would fix every single plugin that is impacted, but we I mean our personally at least I'm not very eager on getting and becoming a maintainer on on The SS GeneXus Java test report blames the version I think those plugins are not used enough to be to mandating to be mandating that basically. So yes We have done To show that we we value that but on the other hand, I think it's it's an example of shifting gears and yes accepting that breaking some things is A choice that we can do I think we could do we maybe should do Just to move forward and keep things simple basically Yeah, I guess we would need a job anyway taking the conversation on the mailing list Maybe before the job is filed. It makes sense to build the consensus of What pass we choose? Because if Daniel has a reservations about the chosen approach, maybe we need to resolve it before we spend time on jabs Yeah, I mean, so Daniel pointed rightfully on the compatibility matters of the Governors document, but indeed as was pointed out by Liam Maybe you you can open this one if you know what I mean Oleg, but so that just people don't not not as knowledgeable about that Can see Watching this record as a recording later Could see what we talked about but this this phrasing also talks about being very careful. I think we are very careful here You know this phrasing doesn't mean that we don't break anything I think it's it's we know that as professional in software that breaking nothing ever is also something to keep you, you know Is an impediment to to to innovate and to move forward sometimes This might be a good reason and kind of Catalyst and candidate for a jankin 3.0, right? This is something that will break It's a major version a lot of people complain that we release Non-major versions that are breaking changes even though our definition of breaking is different So that would be a good excuse and something and we're like, okay We've released a new we've changed the behavior Some plugins are gonna break that's 3.0 Yeah, and we just start collecting a bunch of these changes that we want to do for 3.0 release Yeah, but I mean I I like the Rational the only big caveat that I see with that rationale is that then Do you bump the major version each time you have something like this and because I know for instance guava is coming we are working on guava too and so But we bump to four then when we reach guava stage and so on, you know I I'm honestly okay with that as well, but I mean there's no reason we can't you can't wait to merge this for guava as well Right that both of those could be a 3.0 release Yeah, guava is going to take more time. There are 300 plugins inspected as far as our analysis is only But I mean chrome is now on 87 or a 99 or something like that like they're releasing major versions all the time And that's totally fine as well Yeah Changing the version in schema is was one Proposals for jinkers 3 So as long as I'm clear to publish my proposal. Hello mark. I will be happy to do that I think as long as we're clear with users. I don't think I think to dino's point and to your point Breaking something is not Something we want to do often, but it's not a problem to do as long as we're good at communicating it I'm not necessarily sure we're good at communicating it and a major version would be a Key to users that there will be something breaking We've never had somewhere so starting now seems kind of weird plus If we if we go the route and I and I hope we continue Don't get me wrong I think it's it's good that we look at all of those outdated dependencies. I mean extreme spring security Was a great step forward That might have made the 3.0 Or perhaps tables to diffs would have been the 3.0 and we would now be at 4 point something because both of them would deserve a major version bum but we've never had somewhere and If we start now, we really should Apply it in the way it is intended And I mean only is on the call and warnings and g is that major version 9 or something By now And he's really doing it and he got there in less than a year. So look forward to Jenkins 20 Next year or something and at that point we can go the browser route and say Everything's a major version or just you know ubuntu. This was released in 2021. So that's the version number we're using for it Yeah, but you know so that if we do that, there will be You know what i'm going to call a major version fatigue That people will start caring that is a major version update and just or maybe not update anymore and move away from Jenkins You know, uh, if if we if we make this like looking like we're going to break everything each time Which is not the case here, you know, there's definitely a balancer, right? Yeah Because you don't want to do a new major version each week. Otherwise, that doesn't mean it's a major version But if you never do a major version then people complain that the weekly is different than the previous So you got to find a way down and I don't have an answer right now So homo has strong opinions. You're welcome to start a discussion on the developer melon priest For this particular topic. I think that we are definitely not ready to vote for the pass So I suggest we continue the discussion and the developer melon priest You know, you know, I mean If I were going to create a jet anyways, but you know If if we think that is going to be a compromise to create a Detached plugin why I mean, I don't really I'm not going to to to fight for it I don't want to have on that on this hill I'm just thinking that it's time to kind of bite the bullet I would say if you look at the numbers those plugins are installed like the biggest one is installed Not even 500 times my my personal plugin. That's a very very small one is installed 4k times Most of the spriggy's are installed like 60 times or 100 times 160 times in the world So I'm like, yeah it's not Probably most of those instances are just having those plugins installed and they forgot about them I mean Emma seems 3.2 clover 2.8 Am I stat since 10 years? I'm wonder if someone's really use my tool or my format Because this plugin publishes a report in a particular format That means that you have to use Emma tool for that I mean, I mean, I think I think we can move on But is that thing correct me if I'm wrong? There will be a jab And I think the key part of that jab should be Explaining Which of the alternatives was chosen and why because I see Sure ones and the detached plugin perhaps even without bundling If we want to get rid of the dependent of the plugin as part of the what we deliver sort of Taking basal's approach and just you know accelerating it by a few years might actually be viable alternative And if not, if you think that's not a good Good solution, I would just like to know why Sure, we'll create a jab. Definitely. I think it makes sense to get aside the process and so on I'm fine for everybody attending here or people watching this recording later I encourage you to you know, watch the list of plugins that are remarked theme that's to be Broke a breaking when this is released and and voice your opinion if you think that none of these plugins make sense anymore Like like we were saying about Emma typically I'm interested. We are interested to hear your opinion and yeah, there will be a jab. Thank you very much Thank you John Okay, then moving on So for This might be another one where you might want to email the User's list and be like we're potentially doing a breaking change through these plugins Don't say it's a core change, but the plugins work to see how many active users there are as opposed to just people who's installed them Good point I mean maybe I could still point to the core pr, but yeah Yeah, sure. I can do that Thank you So technically it's possible to do some things like that is the telemetry engine in Jenkins But yeah, it would record Yeah, same thing to ask again. What? So there is jump to 15 if I recall correctly then Of the analytics Yeah So technically it would be possible to collect metrics like that from the Jenkins side I know not to 14 But yeah, it would require change in the weekly release So you wouldn't get information from LCS and I guess that the majority of such Less adopted plugins are rather on LCS versions Yeah, suspect also that, you know, this thing will never be really used because it would mean that we wait for some time No to percolate through the versions and I guess many many people are using the null version of Jenkins using a low version of plugins That actually would never see just such a Change in the core itself So we can telemetry we've previously backported into LTS because of the timing aspect to it So we could do that here I think I think we even backported broken stuff. Um, so I would recommend you write better code than me um, and in terms of Understanding the version Combinations that users of these plugins are using we have the usage statistics Um Site that has a matrix of core versions and plug-in versions Yeah For example, if the pattern is that everyone on Emma plug-in Is still on Jenkins 1.x that would tell us that they are and we can say well, they're never going to update anyway So we can stop caring about this particular plug-in Okay Yes, now you can move on. Sorry, Oleg Yeah, no worries. So the next topic for us is terminology So for terminology, we regard this topic. There is a threat where we are trying to agree at least on some terms and Yes, they made a call for terms where we seem to have a consensus So, yeah, basically These are the terms are listed here and I am going to exclude a few terms right now Uh, what did they do? You're fine Oh, yeah Uh, yeah, so here for example, um, yeah, what we have Um right now. So master node built-in node master label master branch agent to master security Jenkins master container Um, so for port It doesn't seem that we have a consensus right now because there is still an ongoing discussion of how we should call it whether it should be a broader port causes conflicts in Kubernetes terminology So I guess this topic I will exclude from the list for now We need to keep discussing that and civilization White list Will be now civilization allow list. It's for JEP 200 because it's also quite deeply integrated into our documentation and the core code base so this is these are the terms I would suggest to vote on Unless there are concerns about any of this term and we need to keep discussing them I mean, I already mentioned on the main list. I'm happy with the list Especially now that it's switched from allow to sorry permit to allow Yes Likewise for me. I think the list looks good. Do we expect potential Readability issues with English as a second language with built-in Now it's quite a common word Well, so so is there would there be an objection to hyphenating it? I think built-in Was that hyphenated labels? Oh weird. I think oh they are. Okay. So that's All right, then then I retract. Thank you. Daniel wasn't aware I think you may even be a Grammatical non-determinism in the antler Yeah, for this oh Oh, then absolutely retract. Thank you I don't know whether a hyphen is enough to get there. I don't think so, but it should be just alphanumeric Okay, so we are talking about this built-in or about this or both Well, the label is second Yeah, the label And I guess an underscore would work, but it would be a bit uglier event. Yes I mean a self would be an option, but I still like built-in better Yeah built-in built-in gives the right message and I think we should accept Yes, English is a second language may wrestle with it for a while Okay, then that's fine with me. It's just something looking at the term It looks like tin the metal So so I generally a plus one from me too, but I like yeah, this this label Looks weird and so I'm sorry. Maybe I'm stupid, but what's the problem with the hyphen there? The label is used in logical expressions and I think the parser that we have for those May have problems with certain Special characters And I've also in the past trouble with the auto completion Code for labels now. Obviously all of that is something That we can probably work on but it would Increase the scope there a bit Okay, there are some merits because if we make using controller label as difficult as possible those people will use it but Yes, we can seriously That's actually a good point Well, and I can confirm that I do use labels with hyphens in them all over my installation um, I haven't detected any problems yet with free bsd-12 or AMD 64 dash free bsd that are provided by the platform labor look plug-in. So But I mean, I think maybe that's what I'm not sure that's what you meant Oleg, but you nailed it We don't want people to use built-in label anyways You should have for majority of cases They explicitly want that so we cannot delete this feature Yeah To delete support for master due to compatibility Uh, but yeah using Hipfam is not a problem for me Yeah, that's actually a good point. I mean one of the suggestions that we discussed for for the replacement term might have been marks was um Reserved to indicate Do not use this do not build here um, and we recently also added a more visible warning message to the jinkans ui A few weeks ago that basically said do not configure jinkans to run builds on the built-in node so, um I I would like to retract my Concern here So we take built-in. We say hyphen because nobody wants to consider this option, right? also found about that I depends what label I think the series hyphens I think if it's messy, it's fine because a we're not recommending people do it and b It's pretty easy to type it sticks with the convention lowercase and like labels So I I mean I can see why built-in is looking like built-in but I I think for a label that we don't encourage. I think it's fine and it's Yeah, or that So to clarify you're saying no hyphen I hate punctuation. I never use it. So Yeah Okay, and I'm I'm still the other direction. I think the hyphen would be a real help. So We have no ejections hyphen. So I think we can On top of that, you know, we're talking about jinking itself, but you know now we have I mean yamal Configuration as code things everywhere movie scripts and sometimes things like these Yeah, uh, it might be weird or or broken somewhere. We were talking about compatibility a few minutes ago, right? So So my suggestion for a response here would be that we agree on built-in note and the built-in label And we will attempt to hyphenate it unless we discover specific real and not trivially addressed technical problems with that In that case, we fall back to not having a hyphen in the label Yeah, I'm uh, so so two comments When you put a hyphen in there, then it doesn't look weird anymore. So we can get rid of that But I do use hyphens in my Labels too. So Honestly, there's no reason we couldn't support both and just document one Actually Well, we're gonna have to support master anyway Actually, we don't if you look at my poll request as I suggested on the dev list You will see there is migration code an administrator who's updating from earlier versions of Jenkins Needs to click a shiny button to switch from master to built-in And only folks who start Jenkins for the first time in whatever release of Jenkins includes this change Will have the built-in label by default. But what about any Pipelines that use node master Well, you can explicitly configure additional labels if you need that to work But there can only be one what is called internally a self label. It is kind of a light label That usually corresponds to the node name except for the built-in node where it is currently master and Would be something else in the future Okay, then I retract. I'm good with built with the dash So too long didn't reach me to meet an upgrade guide for that It should be automatic. But yes I mean the thing is if you upgrade Jenkins nothing will change except there will be an admin monitor that says Click here to get the new behavior with a link to documentation We already agreed that the configuration of Scotios cases might be affected and configuration of Scotios cases become default ones In 2021 So I think that upgrade guide will be necessary And probably most of the people who are using that node label are not the ones that are upgrading anytime soon So it's good to have the docs Okay, so Uh Yeah, one of the options we can still Continue discussion for this term. So basically the only consequence that we are working Daniel for another For some time until we build the consensus But yeah I'm happy specifically So there is comment from Baptiste in the chat that uh, he prefers self. I know I think we were joking around Okay Yeah, I I feel like this this dash is my first contribution to the the jenkins governance board meeting So we we have to keep it at least for until another meeting. Yeah I mean as much as I do like self. I think built-in is way clearer So Okay, so yeah anything to discuss on terminology Because yeah, we have one important topic I would like to close Uh today So so we have closure already on the all the other topics on terminology. We're we're settled, right? Yeah, that's what I'm asking Okay, so yeah next question is about jenkins About securing delivery pipelines for jenkins So one of follow-ups we discussed at the governance meeting that we would like to adopt security tools And one of the tools we had in the list was lfx security, which is basically a source version of sneak provided by the linux foundation And yeah after the contributor summit, I started this exploring it. Basically, we already have a profile Well, it doesn't quite work because we discussed one of the previous board meetings because Yeah, because of too many dependency issues and the sneak is not good at passing How our dependency trees work because well none of the existing tools Have any idea about how dependency management works. So we end up with something like two hundred seven issues mostly false positives And yeah as a follow-up I reached out to our fact security team asked whether we could Basically fix it somehow in a way which would be scalable for the jenkins project. The answer is no Then we agreed to talk to sneak directly. We started the conversation with sneak And as a part of this conversation we discovered that there is a new lfx security to do zero under works And basically in this version they intend to provide administrative console for users As well as apis including configuration management apis and apis for triggering scans So all the things you get in classic sneak which would allow us to submit ignore lists for cvs. We don't like to see And yeah, basically they invited us to participate in the discovery project And I asked for formal permission to accept this invitation So what it means for us and yeah, basically we agreed to participate No commitment, but yeah once there is a pilot version ready. We invited to try it out And adopt if the project is successful. We would make a joint announcement together with sneak and the Linux foundation And the jinx will be basically listed as one of the first projects adopting lfx security tool with Maybe some testimonials to testimonials, etc. Like it usually happens And what we get out of that we would get direct support from sneak and lfx security while adopting that Because most likely in the pilot we will experience some issues So we provide feedback and we get help and hopefully with this mode we will be able to roll out support for sneak soon So currently we have All of you are interested in the security organization There are also some clarification questions from Daniel Well, I guess Daniel is interested as a security officer that is being informed about this project And yeah, my question is whether we want to accept it As a project for the jinkers Yes Definitely, I really see no downside here Worst case we try it and cannot get it to work the way we need and best case we have We have a dependency scanner that actually works for the crazy ways in which we Use maven and Has useful results And since it has an api, I think I watched the the recording That might actually be interesting Uh, if we if we would consider exposing this showing you as a say by the way, um There's a bunch of old stuff in this plugin. You may not want to install anymore Which sort of feeds into this plug-in deprecation topic as well Now, obviously this isn't quite as straightforward. Um, but I see I really see no downside here. So plus one Yeah, any objections? That's one for me. That's one for me as well Yeah, and Another topic we are looking for maintainers who are interested to participate in the pilot pilot program So the idea that we would start from a limited number of repositories like the jinkers core some libraries and some plugins And we would be rolling out LFX security for the entire organization only after that If someone is interested, please comment in the mailing list Okay So I think we can consider it is approved Okay, so quick update on the hosting team. We intend to do a meeting Today for onboarding new contributors Even though we had a few contributors who accepted the invitation. They didn't show up So basically the meeting was cancelled while we still had another discussion with Daniel and Alex So and we created slides which I posted in the thread So if you're interested, you can just take a look and once we have Somebody who is committed to participate, we will Reorganize the meeting and create recording for these slides The slide deck is basically enough to understand the idea and to get all the links So it should be okay even in a synchronous way Okay, so we have a bunch of topics here One topic I want to discuss is job project process updates So it can be done later when we have Pull request and there is quite a active discussion So we can just build consensus even without governance meeting there And yeah for the rest Yeah, I wanted to discuss using GitHub issues for open governance But yeah, one question to both members If you could provide feedback on that in the board committee, I would appreciate that Yeah, I'm Kind of leaning towards calling in here because it's been a long day meetings and we're over time. Yep I'm also wrapping up. So no intention to discuss now. I'm just highlighting that these topics is where it will be great Have a synchronous discussion Yeah So I'll move everything to the next thing Okay, anything else for today? Okay, I'm off. Bye Okay, thanks everyone. Have a great day Thanks Yeah, I'll publish a recording tomorrow because it's 10 p.m on my time zone Thank you. Thank you. Thanks all