 Alright, welcome everyone. This is the Jenkins contributor summit 2021. This is our first experiment with doing this contributor summit online and please note I consider this experiment and I hope you'll be patient with us as we work through what this experience is like in the path. Well, I'm going to share my screen and talk about why we're in this format, etc. Let's let's just go ahead. So, this is the Jenkins contributor summit will be running for two, two days, 23rd through the 25th that basically a 48 hour period, where we're going to encourage people to be can act as contributors and help us understand the vision for where we want to go. This session will last for about two hours. The intent is we'll have welcome and introduction that I'll provide then project related updates and team related updates, special interest group updates, and then we will take about the last 30 minutes slip into breakout rooms and schedule the tracks for this summit there are specific tracks of interest, and those specific tracks of interest we would invite you to, to enter into those breakout rooms, work with the track leader to assure that you're you've found a time that work for everyone to meet together, and then hold those meetings sometime within the next two day period so that for our conclusion on Thursday, we have a ready summary of what came from those track meetings. So, now, why are we doing a contributor summit. Well, we need to gather Jenkins contributors as the Jenkins developers people who test people who write Jenkins administrators Jenkins users, many more of those who are actively willing to assist with Jenkins and its development. Jenkins is used in over 250,000 installations worldwide, it's widely used very popular and matters deeply to many organizations, both companies and open source organizations. In this session will review the last 12 months of work, what things we've achieved, and talk about what leaders believe we should do as the neck in the next 12 months and then that will be discussed in more detail in the various tracks that will be meeting separately. Schedule wise, we're now in the opening session will do 60 to 90 minutes of presentations from the Jenkins board from Jenkins officers and special interest groups, then we'll slip into breakout rooms, where in the breakout rooms. We have the track leaders seek to choose a time when that track could meet so that everyone can be part of the discussions that are held in that track meeting. This is a 24 hour a day world. I was just chatting with a colleague in India minutes ago, and that is this is a really bad time for that person in India so we rely on us track leaders and as participants in the track to find a meeting time that will work for you. If most of your team members are in China meet meet during a time that works for Beijing if most of your team members are in Europe or in some part of the US meet in a time that works for them. It's also okay to do multiple tracks, the document or multiple meetings of a track the documentation CIG already knows we will do two track meetings. So we're going to do one meeting for the Europe time zone and one meeting for the Western US. So that those track meetings will happen beginning today or whenever you would negotiate through the start of the closing session on Thursday anytime in that 48 period meet together, you're welcome to use zoom or jitsie or hangouts whatever works well for you. The track leaders, as assigned right now actually have access to the CDF zoom account that they can use that use other systems if you need to. Then in the closing session will look forward to the track leaders presenting a summary of what the results are in the track and will look to see updated proposals submitted to the Jenkins roadmap. So let's do project and team updates now. And I think now it's Oleg it's yours. Okay, I can do that. So, do you want me to present myself or do you want. I was assuming it would be simpler for if I advanced the slides and but if you'd rather I can I can give you control and we can let you share what would you prefer. Okay, let me I'll stop sharing and we'll have you share your screen then. I usually jump between links so right understood host disabled participants. Yeah just a minute I'll allow you to share. I was trying to be careful. So no Zumba. Right, please. Okay. So do you see my screen. I do. Thank you. Yeah so just a quick update on Jenkins governance. Last year was actually quite busy. In 2019 we had first ever elections, we expanded the Jenkins governance board and we started pushing a few topics in the community. Most notably, streamlining some of the community processes and getting more people involved in maintenance roles. I think that there were several important changes. This isn't prioritized I will just go through that quickly. So one of the first items that we introduced a new Jenkins public roadmap, which he aggregates initiatives in various aspects of the projects like features documentation outreach programs, etc, etc. We wanted to put all major initiatives happening in the Jenkins community on this list so that potential users and contributors can discover them. And you can find a lot of topics there and one of subjects for this event and also for the Jenkins governance meeting tomorrow is that the road map and to see what we're missing, especially in terms of near term and future. We wanted to do and we wanted to see in the project in a possible future. And then we have graduated from the continuous development foundation. Well, we're still a part of continuous development foundation but Jenkins was the first project to create as part of it. We changed our processes we updated our code of conduct, we have achieved the full compliance with current construction initiative requirements, etc. And it was helped us to get some validity key and to get the promotions by the continuous development foundation. Other important change was terminology cleanup and code of conduct. Both of them happened in the beginning of the summer to address concern raised by community members and now we are more aligned. We know it's still ongoing process and we look for contributors to get it over the line, but it's still a significant change. Then you've got a new funding page, we've also got a page for Jenkins adopters. So if you're interested, you can just go to the browser and find these pages. And you can find a lot of things here. Basically all this documentation has been created or moved and updated here during the last year. So, And the last but not least, we had to solve in 20 elections at these elections. So we added to new board members marty Jackson and Gavin Morgan. Do we have them on the call? Yeah, just not. But yeah. So currently we have five active board members and you can drive different initiatives in the community if needed. So it helps to achieve the goals and also to facilitate particular topics which we would like to drive in the community. So what's next for the board? Actually, when we were doing 2020 elections, one of the questions was, what do you like to see in terms of Jenkins governance for activities? And we got more than 40 responses, some of them your paragraph long, some of them your short, but there are three key items in the feedback. So first they keep growing in the community, keep the community healthy, help new contributors to join, etc. It was one of the biggest areas of feedback. Then there are participation changes and organization, also a lot of feedback, and they diversify Jenkins beyond CICD. They were surprisingly many answers, proposing that. So Jenkins is an automation server, but it started a lot of applications on the CICD. But it's nice to see that people want to see other areas as well. So at the end of the day, you're also able to put it back in there, request to organize more events, return Jenkins world conference. Maybe we should do that as a Jenkins user conference who knows. But yeah, these are key items. What we also have on our roadmap in the to-do list. We have a contributor onboarding, individual contributors and company contributors. We need to fix the Jenkins roadmap. And there are a number of formal items which we need to address at the governance board. So first the Jenkins enhancement proposal process needs to be reworked. Currently, it doesn't work as it was intended. And it becomes an obstacle for those who try to create the jets. And at the same time, we cannot appoint people to the process because this process doesn't help to deliver changes and build consensus around them. So we will need to work on that. And finally, Jenkins trademark has been transferred to the Dynamics Foundation. It's just updated from the last week. And what it means for us so that we as a Jenkins project need to perform updates including the Jenkins website, all Jenkins websites, also our CLA, also our documentation. So there will be a lot of activities required that there are also other programs like print of Jenkins, which are not quite active at the moment. And it's just the top of the list. And of course, there are many other items we need to think about when it comes to governance. On the roadmap, currently we don't have much things, but I believe that we still have a technical steering committee here, which is slightly aligned with the Jet Process Revamp. And there was also a lot of discussions about user advisory board over past months. So maybe we should also put it on the list so that we can also start working with users maybe as a part of continuous delivery foundation efforts with user consult or independently. So these are the items which are currently on the list. And if you have any other proposals, if you would like to see any additional changes, we have a governance meeting tomorrow. And I suggest to use it to discuss what's next in governance and what are the requirements. Any questions, comments? So if you think that I talk too much, then Jenkins Corp. So this is one. Okay, so Jenkins Corp was quite active in the past year. So historically, Jenkins Corp was rather a set of extensibility features like extension points, some basic frameworks, et cetera. And historically, there were not so many features being delivered from the Jenkins Corp director. This year it's slightly changed because there will be projects specifically targeting features provided by Jenkins Corp and other frameworks. The key highlight is your UX Revamp. There will be many changes in different focuses. Later we will have UX update. But yeah, basically, there will be a local and field improvement. So there will be new controls. There was a bit of support for things introduced and a dark team for Jenkins. And there was a major revamp of plugin manager. It's two revamps by now. Also cloud configuration management, et cetera. And there is upcoming changes related to tables to these configuration. And many other smaller accessibility and UX topics. So if you use Jenkins, you may have noticed that the web interface changed a lot over the past year. Then for users of configuration as code, there is no support for it only configuration UI so that you can configure everything as code but still access information. There is managed permission which provides reduced permission set. So you can have managers in addition to full admins. In the Google summer of code introduced external fingerprint storage. And there is also new windows installer. Again, it's not all new features. It's just one top ones from the change logs. And there are also some changes which are not that public facing but which are really important for the project. The first of course is security. There will be a lot of security hardening and fixes around the Jenkins core. There are many advisories this year. Again, it will be discussed later. It depends. And another important highlighted that this year there was major updates in terms of technical depth and dependencies. There were many topics like SG security extreme which we are afraid to touch for years. But this year we finally did it. So extreme jQuery screen security also enabled dependable and there were dozens of library updates within the project. It helps with security scans. It also helps this functionality and allows the project up to date. So thanks to everyone who contributed and it's great to be the rest of this topic. Also we removed a bunch of dependencies, which is also good to think. Another important effort is code quality and smells. So there is a number of contributors who work on various statistical analysis. Some of these efforts do not always get to change logs. Some efforts are too minor. Some are so different. But actually they also help to keep the code base up to date. And thanks to all contributors. I put some names on the list but this list is not complete. And if I missed something, sorry, someone. Yeah, I hope we will finally have a list of contributors directly in the change logs like we planted some point. Okay. Okay. There are some changes in the maintenance. So firstly we finally got release automation for LCS and weekly releases. So there is new release automation infrastructure which builds tests and sends and ships releases. It's a major enhancement compared to the city in 2019. Then we've got a new release officer. We also onboarded a number of new main core maintainers so that there are more people who have conditions who can review and merge changes. Thanks to everyone who does it in the regular phases. We currently maintain around six pull requests in the open state. It's an improvement compared to previous years and a few dozen pull requests every week. So it's a good balance for now. And now it's dependable. So many of these pull requests actually artificial ones. Then of course core infrastructure initiative compliance so now our maintenance policies and documentation and security policies all of them are aligned with the Linux foundation requirements. And they also documented so that users can discover these policies. And potentially unblocks additional opportunities like security analysis funding. And yeah, dependable. We talked about it briefly, but finally dependable is also part of the Jenkins core. So now the year. Now we can update dependencies in a much more relaxed state than it used to do to be before whenever it was manual. Okay, what's next. Basically, there will be a new LCS soon. And there was a blog post by Mark about changes upcoming in this release. And one specific change which we need to highlight once and once again it's a configuration you are able to use. So if you use complex configurations, please take a look at the current victim. Releases or release candidate and try them out to see whether your plugins are compatible and if not please report issues because this is a completely breaking change. We know what many plugins affected and be interested to utilize it as much as possible before the general availability of the LCS. And securing the Jenkins delivery by climate will be a separate track where we will be discussing any kind of security issues with our built infrastructure and the delivery infrastructure. And that this is about what's next, because there is no other specific initiatives for the Jenkins core at the moment. And if you see any major initiative, let's discuss it during the summit. Thanks Oleg. Thanks very much. So Oleg, maybe you'd be willing to continue driving for this piece. Daniel, I was going to drive for for Daniel. But since you're already on the on shared screen, why don't you just go ahead and bring this up and we'll let Daniel take the next voice. Daniel, thank you very much. Daniel, our Jenkins security officer. Thanks Mark. Thanks Oleg for driving. Next slide please. So 2020 has been quite a busy year as many past years have been for Jenkins and Jenkins security and the Jenkins security team. So to get the stats out of the way first, we delivered 19 Jenkins security advisories, five Jenkins core security updates, fixing 19 vulnerabilities. And in terms of plugins, we announced 200 vulnerabilities in about 150 plugins, of which two thirds had fixes, which means about one third of the vulnerabilities that we announced were in plugins that are un-maintained or whose maintainers were otherwise not, we were unable to contact. And in that case, as you surely know, we published the advisory and set up the warning to inform the administrators about that. Last year, we've late last year, we've started a trial run of using CodeQL a recently by GitHub acquired technology for security scans. The problem that we've always had in the past with security scans is that a lot of the things that we do in Jenkins are fairly unusual. For example, using the stable web framework, so other security scanners always often didn't have really useful results. And with the custom rules that we wrote for this, for Jenkins specific problems, we've been able to identify several vulnerabilities in plugins that we fixed. And of course, the idea is to expand that even further. So like already mentioned, we updated some dependencies in core, most notably extreme and replacing a security with spring security. Those are not immediately useful for security, but this limits risk. If we're tracking the upstream project and the releases more closely, we will not have substantial problems when a vulnerability is discovered if we are on a re-outdated release. So that indirectly also benefits security. Of course, two steps forward, one step back. Last Friday, we delivered a security update for recent Jenkins weekly releases because this update of spring security introduced a security vulnerability. Oleg, you're still sharing your screen? Yeah, I was just showing the security advisory. Yeah, so this only affects the Jenkins weekly releases because previously published LTS releases do not yet have spring security, but will in a few weeks. On the UI UX side for security, we made the security warnings more visible in the plugin manager inside Jenkins, which allows administrators to more easily understand which updates relate to which security issues they want to fix. And finally, the most exciting entry in this list, unfortunately, you will not be able to tell is the internal tool improvements. So the Jenkins security team is a very small team and we publish quite a lot of security advisories, help maintainers deliver security updates. And we've massively improved our internal automation over the last year for advisory authoring, for delivering updates, for merging security fixes into Jenkins. Obviously, very little of that is visible to the outside, but you may already have seen the new Jenkins security logo or avatar that is also on the slide on the right. In the commit history of the early January core security update, that is the avatar of our release for our security bot. Please next slide. So what's next? Obviously, we're going to continue delivering security fixes security advisories to inform administrators that they need to keep their software updated. But beyond that, we want to improve the developer tooling to make it easier for maintainers to keep their plugins secured and to do the right thing in the first place. In particular, making the Jenkins security scan based on CodeQL available publicly and to roll it out to all Jenkins plugins hosted in the Jenkins project. Then securing the Jenkins delivery pipeline. This is kind of a theme of this continue to summit. We're all about automation, but maintainers release plugins from their laptops. That's not quite where we want to be. So there has been a lot of automation work in the past by Olivier Bernard and others to automate the core releases and Jesse Glick has done some work, gotten started with it to automate the releases of Jenkins plugins. And ideally, we will be able to take that developer laptop out of the equation entirely. And finally, we want to get more people involved, more contributors involved in Jenkins security. Now, it's, I cannot just make everyone who asks nicely of a full member of the security team with access to information about unresolved security vulnerabilities in a variety of components. But as I hopefully demonstrated, not everything is just fixing security issues. There are a lot of ways for people to contribute to Jenkins security to the ecosystem, to the documentation to the UI UX of security. Even if they don't have access to the poison cabinet. And so if this is something that interests you, just let me know. And we'll figure this out. Thank you. Thanks Daniel. Next up is Olivier Bernin. It sounds like it's my round. Next place. So basically, I want to start with that. Basically last year has been tough in terms of service outages, but we also drastically improved the reliability on other services. The reason why I want to mention this year is we had few issues with the service that we rely on which help us to identify gaps gaps we had in our processes. So we drastically improve the monitoring with just drastically improve our process around managing infrastructure. And yeah, that's that basically come with increasing the Jenkins infrastructure basically can you go to the next slide please. So I can't really, I mean, I don't really have one way to either to highlight how the infrastructure is used because we run many different websites, but this one is just Google Analytics get a Google Analytics that shows you the traffic we had on the main website. And as you can see here, we have users from everywhere in the world, and the traffic increased by 30%. So if you know, if you understand what's happening on the main website, just imagine what happened on Tira, the plugin site, the update center, and many, many other services. So that's what I mean by we had few scalability issues to keep up with the demands. But overall, I think, in terms of reliability, the last year has been really great. Can you move to the next slide please. So we're in the main areas that we work on over the last year. So we already mentioned the release environments. So we now have a secure way to trigger release the community can see when we do a release what's the input. So obviously it increased the feedback loops. If something goes wrong. So we've been working on the new since April. We also worked a lot on the mirror infrastructure. So the mirror infrastructure are the services that people use each time they want to data plugin they want to install the check in score whatever. So we've had a lot of schedule scalability issues in the past, and it's now getting way better. We work as well on documentation, we may create Tira to the Linux foundation so that was also a major initiatives. So the idea is, we don't have to maintain that service anymore so we don't care about version of data and so on. That was something really great that happened over the past year, which helped us focusing on other services and something major that happened as well was cost cutting, because we have to keep, we have to keep control on the way we spend the we're spending money in the Jenkins infra but I mentioned that in one in the coming slides so next please. Next slide. Yep. Thanks. So just something that I want to highlight is the number of contribution done to the Jenkins infra project so people. I mean, we had quite a lot of contributors. Some are just recommendations, some are specifically like prepared communities or whatever. But basically we had a lot of traction in the project we had a really stable amount of weekly meetings with on average three to five people attending each time. So, I mean, that was a really great idea, great year in terms of contribution specifically to Jenkins infra projects. Something also that I like to see in this graph is how the contributor shifted from contributing from the United States to Europe. I mean, from, from my point of view, it's definitely easier to connect with the people but yeah. Next slide please next. Something that I mean I don't often share is how much the Jenkins infra project costs and basically what happened over the past year. Something really specific to us is we don't have a credit card. So we don't really have a budget. So when we want to bring more services to the community, we have to find sponsoring. Which is great when we have sponsors but obviously sponsors come and goes and sometimes we also have to make choices about what are the services that we can keep. Not every sponsors provides us so we have different kind of sponsors, those who just provide us services for free. And we don't know how much we are spending. So an example of that is reported Jenkins here that are sponsored by G frog. It's quite critical critical components of our infrastructure but I mean we have no insight of how much we would have to pay for that machine. But on the other side we have sponsors that just give us credits, which allow us to spend the credit the way we want to spend it. And that's where this number come from. I just look at every cloud, every account that we have, how we are spending the money and basically to identify if it's worthwhile to use more of a specific service to identify other different sponsors and so on. So if you look at the left diagrams, those are a percentage of the $200,000 spent over the last year but obviously this is the minimum number because, as I said that the IBM chief for a page or duty offer a services that we don't have to pay and so we don't have any insight on how much we would have to pay for those. And so what happened when we don't have a sponsor anymore, then the CDF paid the bill. It's, it's like the last solution. So it's really nice but on long term we have to increase that that numbers and so over the last year we went from spending 20, 20 k per month on the Azure account to less than 10 k 10,000. So right now in terms of our objective it's fine, but it also says that we cannot easily increase the usage so we have to find other options to increase, I mean, to increase the number of machines in the future. So yeah, right now we have 40% of the, that's money, which is sponsored and then we have to find solution for the rest makes next slide please. The way the way I want to finish this is it's quite difficult to define a rule might for the Jenkins infra because we are even, I mean we even depend on provider that we have sponsors that we have and the ecosystem the way it evolves. But the main the main ideas here is to keep working on sponsoring. We are definitely looking for sponsors, we can sponsor us for years. The reason for that is because they time to me create between cloud vendors. And that energy could be spent somewhere else than just me creating between cloud vendors so if you have any ideas of suggestions that would be really nice. Another major area that I think we will have to work is the plug in release environments. If we have to put something in place that we already mentioned that we have an environment for releasing Jenkins car. We may have to put in place something for the plugin ecosystem as well, which has different needs. So this is something that I would like to work in the coming year. So over the past year we spent quite a lot of time migrating the documentation from conference to either the Jenkins that are your website or the plugin sites. That conference machine is still something that we have to maintain. And ideally I would like to see moving to see it go as far as we can. So I think it would be nice to focus on what's missing to stop that service, definitely. And we have some work to do on the update center, not the service itself, but where it's running so we have something to do the Amazon accounts and so that service is running on that on the Amazon account so we have, I mean, it's a critical component to our infrastructure. And so yeah, we cannot, we cannot easily modify the way it's deployed and managed. So that's something that we'll have to clearly look at. And finally, yeah, we have few maintenance tasks that happen every year. This time, I think we'll have to focus on the perpetrator from codes to just do some updates we brought those codes years ago. And so now it will be some time to do that. So yeah, that's all for me. Any questions. I mean, the roadmap is not something fix. So if you want to work on something, particularly, yeah, feel free to make suggestions. We have a roadmap but it changed depending on the needs. Thanks Olivier. Oh like let's go to the next slide then. Thank you very much. So Tim Jacob, our Jenkins release officer. Next topic, Tim, go ahead. Thank you everyone. Next slide. Cool. So your last year was the year that we finally got core release automation working, which is basically completely automated building, building testing and deploying and releasing the Jenkins was to the to the world. And it was June, July ish weekly release was completed and we started doing weekly releases. And so that's all completely hands off triggered automatically every Tuesday at around 1030 am usually see I think roughly then. And yeah so that's completely hands off. And then we have LTS and security releases as well. So that's a huge. It's a huge milestone for the Jenkins project previously. Because he had to release every single version of Jenkins back from the very first one until whichever version was that we stopped at. And I think he had it semi automated but it's sometimes failed and he wasn't around it could take a while. And a huge, huge benefit as we can now, if there's something seriously wrong in an existing version we can quickly release a new one. And there's a number of contributors that are able to trigger a release. So you have taken over the release officer, mostly just trying to make sure it's not centralized, grow the team a bit and get other people involved and so started that off with some documentation of the full end to end LTS release process. And developed a checklist and we're trying to answer marks helped out on the last couple of releases. And I think it's been quite good. So Mark was coordinating some of the two to six, three LTS releases. Next slide. Cool. So what's next and releases. So you heard quite a few lines there the only line that we don't have automated and are still running on my machine is the LTS release candidate builds which I really would like to get off my machine. So some progress was made last year but we weren't didn't get it fully working. So we just, yeah, we need to finish off that part. So Jesse's plugin release automation is already being talked about. But it's quite good and the few plugins using it already and this documentation on jinkers.io for how you can change your plugin over to using it. I'm not sure what that line was Mark checked in there. More dependency management automation and this the Jenkins bot the Jenkins plug and bomb is going well. And it's getting widely used and it's in the archetypes for every new plugin that gets created. And so I talked about the build test deployment of the Jenkins release earlier. There's more than that that goes on. The things like things like change log and some testing that's done outside of the Jenkins core process. So there's a number of manual steps that are done, especially for LTS releases. The weekly release manual checklist is a lot shorter, but the LTS one has quite a lot on it. And there's a number of things that we can be done to automate that. Even yesterday Garrett just did a progress which should help, which is automatically updating the LTS version and the helm chart. So it's the public community helm chart. But yeah, there's a number of areas where that would be useful to just automatically update. And so I put a few ideas out there for anyone who wants to get involved and help out. But basically pretty much every step on the LTS checklist is up for automation. Ideally, it's very hands off and just happens as much as possible. That's it for me. Great. So the special interest groups are the next topic. Oleg, if you want to go to the next slide. Ah, yes, Felix, could you take us on the user experience? Yeah, definitely. Thank you, Mark. Hi everybody. Can you go to the next one please. So 2020, I'm happy to say that it has been a rather big year regarding UI changes. I started with the latest one, which is stable so different configuration you guys. So, almost a year ago, Josh sort of approached the UXC asking for help driving these. The already year old PR team has been working especially has been working really, really hard on it. So thank you, Tim. And it's coming after much work on community on plugins after much a bit of pain. It's coming it's happening. It's being released in weeks or maybe. I think it's really big. I think it's a nice step for accessibility and good improvement overall. We expect some problems though. We are monitoring the back reports, of course, there will be back reports. So saving improvements. You know, the UXC started with the, with some list of items we want to improve, which we are having a heavy on footer typography, hypermines, platforms, table styles. So we achieved all of the of those issues, all of those items, except the iconography, which thankfully, I will talk about it after all. The thing is right, I think, in my opinion, definitely has a more modern look at the field. And this is tiny changes also brought again by team, almost many of these are writing. It's a possibility to improve theming. Team created a dark theme, and I think Daniel created a polarized thing, which I'm a very big fan of. Yeah, there's that. There's a theme manager themes are incubated, and they will let me break with updates. So there's that but you can try them out in the blogging manager, a plugin manager, which has been much improved as well. I was to buy Daniel a team. And now there's categorization with some nice levels for each line. There's a more much more performance search. And don't go on section available that pretty good stuff. There's also read only configuration for users without permission. It's, it's really handy. The query was upgraded because the whole plan ecosystem, there were some several, several CV is raised regarding the versions with a query using the, in the Jenkins ecosystem. So we asleep across the game is ecosystem, and we updated many and secure the query instances are or we did remove them when possible. The way regarding a safe version of jquery is only half nurse plugin jquery three API that's updated to a secure version. Next one please. What's coming next, I can improvements. I just created a PR I will try to add these lights after this to remember this remind me of this key to change iconography, it's, it's going to be a big topic on this new idea cycle, the new idea cycle, we're starting small with mostly with weather icons and the build status indicators. We encourage everybody to try them out and progressively, we can expect that everybody's welcome to contribute the new icon updates, there are lots of items that need to be changed, and it's a huge effort. And we need more developers and designers to be involved. This is an area where we sort of need community contributions. So, and we welcome everybody, we will help every, every need, every and all need contributed out. Everybody's welcome to do we appreciate any contributions here. So, next one please. Blue Ocean we have talked about Blue Ocean before the status is, and there is no new development on Blue Ocean. By cloud wise, we still monitor it for security for security issues and defects, those will be addressed. Any, any important community contribution will be revealed on March, of course. So yeah, I think this is it right. Okay, thank you. Thanks. Thanks, Felix. So platform see next topic. Next slide please. So, in 2020 we we cemented the support for Java 11. We've upgraded our Docker images to use Debian 10 centos eight Alpine 312 to use latest versions of the JDK both for eight and 11. We now get proposed image upgrades from depend about we like that very much. We've added additional experimental Docker images, including the open J9 support for system 390 mainframes. Interesting and fun things continue in the platform. Next, next slide Oleg. Oh dear, did I get the what's next slide. I apologize apparently the what next slide is the same thing. That's just wrong. Sorry everybody, we've got more work to do on Docker image maintenance we've got lots of work to do around how we handle and improve the experience for users of our Docker images. And we've got lots of interest in the in the world in general about arm. Next, next topic is great like I must have made a mistake on the slide I apologize. That's will be grateful that the platform topic is brief documentation sick likewise should be brief next slide there. Delighted with the work from Gavin Morgan and from Oleg on helping us get plug in documentation migrated. We are now at over 50% of plugins have migrated the documentation to GitHub. Thank you plug in authors thank you documentation authors. Zenub was our Jenkins on Kubernetes author for Google season of docs, and did a great job there mentored by Kristen whetstone by me and by others great experience thank you very much to Google for funding that. The next project is progressing slowly, and we are having successful documentation office hours twice a week with regular attendees, both from the European side, and Zenub in Africa and from the US West Coast. Thanks very much. Next slide. In documentation the crucial things are we need site search for Jenkins.io. And we've got an active project right now that Gavin Morgan is running to improve the plug in site search. In addition, we'd like to join Google season of docs 2021 like we did in 2020. It's a different program this year we'll need to look at it a little more carefully understand how to approach it, but we think we can we can join it and have benefit from it. We've also got a new initiative from Zenub proposing that the Jenkins project proposed project ideas to she code Africa, she code Africa is a an initiative. Zenub is a member of this group that attempts to assist women in Africa in becoming more involved in technology. And we look forward to this we're going to plan for it it's an upcoming event in April. And yes, we need to improve our contributor onboarding experience both for she code Africa and for other contributors as they arrive. And the next slide or like I think that's it for documentation. Oh, no, no, we've got other concepts, sorry. We want to inventory the current documentation on Jenkins.io the wiki and other locations and then propose destinations one of the weaknesses we have is we've got an awful lot of content on the wiki. We also would love to continue our efforts on changelog automation right now the changelogs for core releases are generated with tooling, but hand curated and we'd like to consider how can we improve and further refine that. And that's it for documentation like next slide. Alyssa would you like to take on advocacy and outreach. Yes, hi everybody. So next slide like please. So in 2020 the advocacy and outreach sick rolled out a few fun outreach programs with the goal to promote and bring Jenkins in good light. So one program that we did was called Jenkins is the way. So this basically is an initiative to collect document and share how users uses Jenkins. We've documented their challenges their goals and their results. And then we published this on a website dedicated to all these stories and which is Jenkins is the way.io that you see there. And the industries that we were able to capture these stories includes just to mention a few health care financial services gaming travel science. And of course we received over hundreds of submissions. And of those, just last year alone, we published 70 users stories and users stories are an abbreviated version of a case study. We also published six case studies. Five testimonial videos which can be found on the homepage there oh leg. Yeah, thank you. And then we published one ebook and sent out over 200 Jenkins is the way t shirts. Again, the link is Jenkins Jenkins is the way.io. Next slide oh leg. Another another fun item that we pushed out last year was a cartoon video that explains why Jenkins is powerful and flexible tool for CI CD. And we, once we pushed this out and it attracted over 14,000 views within about three months. Next slide. We also teamed up with comment strip to create Jenkins comic just to give some humor to a day in the life of a developer automation and Mr Jenkins and we also tried to relate it to, you know the stuff that's taking place at the moment, the programs that we were rolling out so like the Jenkins graduation with CDF, and then Jenkins is the way theme on the right hand side there. Next slide please. The events that we were, we had a presence at in 2020 includes foster scale DevOps world CD con and we participated in the October fast CD con notes sorry DevOps world was the largest event that we attended last year with over 20,000 registrants. Next slide please. So what is next for this year. We've completed the online foster event earlier this month. We will have a presence at CD con which is taking place in June. So in case anyone is interested in speaking at the conference the CFP is open until March 5. This will be a virtual event. The DevOps world will also be a virtual event, which is taking place in September. This is the largest Jenkins event of the year. There will be lots of Jenkins content and expertise so please keep an eye out for the CFP if you're if you're interested in speaking and that will be available sometime beginning of March. Next for Jenkins is the way outreach we will continue with this program in 2021. We want to continue to collect more stories. Specifically, we want stories from the open source foundations that are using Jenkins so if you know of anyone who are in this space please reach out to me and we like to write write up stories about them how they're using Jenkins within their foundations. And lastly, we would love to do an education outreach. Basically, this is a program that will allow for college students to learn and adopt Jenkins as part of their college curriculum. If anyone is interested in building this program please reach out to me via the advocacy and outreach SIG. That's it for me. Thank you. And the next is Google summer of code. Great Google summer of code. Next slide please. This is our fifth year for the Jenkins project to participate in Google summer of code. And we're very excited about it last year was an amazing year we had seven projects all completed successfully really great work was done. That was very fun, and there were over 40 participants it was a very large GSOC participation. We have weekly office hours for GSOC. Please do join. I put a link to the event calendar. And then you, you will find the time you said there on Wednesdays at 1400 UTC. So tomorrow. Everyone is welcome jump on find out more about GSOC how you can get involved either as a student a mentor and we have, we have our projects listed but even though our GSOC application is submitted. We are still open for project proposals. So if you have an idea you can feel free to bring it up at GSOC office hours and and or PR our repo for where the project listings are. Thank you for so these are the projects we have now all of the draft project ideas are will be moved to accept it. And that's that that will be done very very very shortly. I would like more mentors we've had a lot of mentors step forward so thank you so much to all of our mentors, and all those who have suggested project ideas, having more mentors is always welcome. This year, GSOC is going to be slightly less coding hours than usual usually it's 350 coding hours. This year will be 175 coding hours. What that means is that there may very well be slightly less like say code reviews required for mentors but we do want students to have a really good experience so we do want to support them fully. Which means that we still need loads and loads of mentors, and we don't want to overwhelm you as a mentor so the more mentors we have the more the work is spread out the more support students get so this is what we're looking for. I can go into the next page. And this is just a shout out to all our GSOC 2020 projects which we're super proud of. Please go read more about them. They're they're awesome. So thank you to everyone who was involved in this initiative last year because it was a huge success. Next page. And these were awesome students who contributed to Jenkins last year as part of GSOC. So thank you very much to our students. It's quite, quite an honor for us to have all these students participate and become involved in the community. And, you know, we GSOC is its own project and in and of itself it's a great body of work and we're really happy to be involved in it but it is always very validating and we're always very excited when when students continue to be involved in the Jenkins project. So just quick shout out for Sladen, who was a GSOC student last year did a fantastic job. And this year has come back and volunteering to mentor on three of our listed GSOC project ideas. So next next page. So our project ideas. Just quick, which link through to their listings on our website. Just quick, quick note on Sladen volunteering three times for three, three projects to mentor on for this summer. If you do so that doesn't necessarily mean we expect you to mentor on all three projects if students pick them up and they go forward as GSOC projects. You know we will work out your your schedule but the mentors should put their names down for any of the project ideas that interest them. So you, it's not a commitment it's a statement of interest and engagement. These are the ones that we have so far seven of them we have a potential eighth one in the pipeline which is very cool. And last week saying, oh, you know you submitted the GSOC application but I have an idea that's come to me can I still submit it to the website. The answer to that question is yes. These project ideas are fantastic for applying to Google Summer of Code. So they actually form the basis of our organizational application to Google Summer of Code so they are essential to us thank you to everyone who submitted them. But, but we can still accept more project ideas now. Okay, next page. Okay, great. So we've applied to Google Summer of Code this year, it's a little bit different as part of the continuous delivery foundation. And we're really part of, we're really excited to be part of the CDS GSOC org, because it's already enabling us to benefit from being part of the continuous delivery foundation for example. I've already been having conversations with the folks of the continuous delivery foundation who are organizing CD con which is their conference, and we will likely have our Google Summer of Code students be able to give little updates at that conference pretty cool to speak at a conference when you're still a student and participating in Google Summer of Code. So that's really nice. The other really nice thing is, it's become that much more natural for us to, I guess, work and mentor between projects. So we have one of our project ideas is the Tecton client is increased work being done on the Tecton client plugin for Jenkins. And it's very likely fingers crossed that we will have some Tecton folks also mentoring on that which I think is a really cool collaboration between Tecton and will benefit the students in other ways. This is nice is that being so much part of the continuous delivery foundation, we can get more resources to students or have, have grab sort of like other unofficial mentors and get them a little more access to resources. For example, one of our projects is on cloud events, a cloud events plugin for Jenkins. And there is a cloud events sake at the CDF so we're very much encouraging interested students as well as mentors to engage with that sake. And you will learn a lot more that way and be able to ask us a question so that's quite nice. Okay, so I briefly mentioned before GSOC has a shorter coding phase this year 175 hours versus the, the usual, the more usual form or way of 350 hours, and there will only be two review periods, instead of the usual three, but we're still very excited for students to have a great summer and contribute to Jenkins and get involved with open source and join our community so this should be very, very, very good, good summer. Again, additional mention mentors please sign up more than Maria same with project ideas. And last, there are a few links there for joining our GSOC office hours, every single week, you can drop in and out of them and ask your questions and find out more about the projects, those links to our GSOC meeting notes and blog posts on call for mentors how to sign your name up also this information on that post on how to propose project ideas. So, yeah, we will we hope to hear more from you is the short of that. Thanks Cara. Next. So that was a question in the chat about this projects on the for young students or how young other students being targeted. So that that too actually this is really interesting with GSOC for this year. GSOC is, I guess traditionally is how you would say it, it's been for for students who are involved in computer science programs. So that it's for actual students. And, and I think the age cut up maybe 25 but in general, it was for students I matter to read those those links in the blog post on the exact criteria. This year that criteria that has really opened up in a nice way. So, you just have to have been a student on sort of an official coding program so it opens up Jake GSOC to students who are engaged in boot camps recently, just graduated from boot camps. So that's quite nice actually I like that broadening of the potential base. Okay, which was mentioning that it's not on there for coding specialties. It's for any official student, including each the students. So it was always like that but you know they had an official programs because this year not everybody was able to access education because of COVID disruption. And that is one of the reasons they're also having the short time frame is just an acknowledgement that our lives have been just up to this year. Thanks very much Kara. Thank you, thank you. So, I'm Rick who would normally present this material is probably asleep right now. Just be aware that the Chinese localization SIG is very active. They continue to translate the the product they continue to translate change logs they continue to make progress there and Rick has been coordinating wonderfully. There is a Chinese localization SIG track identified, likely meeting during working hours for the Chinese teams. Next slide Oleg. Cloud native SIG. Okay, great. We have a weekly cloud native SIG. There's a link in this slide for for all those who would like to join on Fridays at 1400 UTC. During the client native SIG we discuss sort of initiatives and projects that are in that space of making Jenkins more cloud native work better on different platforms and different things. The three projects we are discussing the most right now are all are all actually they've become proposed to suck project ideas which I'm very excited about. So we have the Kubernetes operator for Jenkins, which there's actually more than one Kubernetes operator for Jenkins within the wider Jenkins community, but this is the one that's been contributed by just labs and they are volunteering to mentor for do something as well. What they would like what the proposal for do something what we're discussing actually in cloud native SIG is having greater security feature for for this plugin. And the idea is that actually there are warnings that are given for different plugins if there's a security concern. And what this will, what the GSoc project enables is that the students would write a check essentially so that the users could decide which plugins they would like to inside whether or not they're wanting when using the Kubernetes operator for Jenkins. But, but in general we in the client of SIG we we discuss all sorts of things Kubernetes and cloud native vis-a-vis Jenkins. The other two projects which are getting a lot of airtime during the cloud native SIG right now are the text on client plugin, which again is an aspect of that has formed GSoc proposal and the cloud events plugin. The cloud events plugin is super exciting because right now Jenkins doesn't really have a way it's not it's not discoverable for cloud event and that's kind of a shame because cloud events are being used for interoperability between tools, between CI CD tools, and even possibly between platforms. So it is quite nice to be able to make cloud events discoverable and subscriberable so that's a really cool initiative in terms of greater our ability. But, but these are just like a smattering of kind of ideas what we talked about in the client of SIG, you're more than welcome to bring your own proposals of how you think Jenkins can be more cloud native or what you would like to see, or if you would like to help with any these initiatives we would love to see you at the cloud native SIG meeting. Again, a link to the events calendar so you can add it to your calendar. And we have meeting recordings and meeting notes. We look forward to seeing you there. Thank you very much. Next slide, Oleg. All right, so here I'm going to actually stop the sharing. If I remember right. Yeah, there we go. Now the session, the intent we'd like to take now is to take your time to have you join the breakout rooms that are interesting to you. You can, you can choose to navigate from one breakout room to another. I've made some preliminary assignments please do not consider those preliminary assignments as a mandate that you're only allowed to investigate that topic. Many of you had provided a list of which topics were interesting to you. I've attached you to those lists. Most of you will go first to the securing Jenkins delivery pipeline session led by Oleg several will be in the cloud native session led by Kara. And there's just one or two in the documentation session that I've got. I'm going to open the rooms now, hoping that your experience with the breakout rooms will be positive. And let's get those tracks scheduled so that you know when you'll be meeting. Rooms are opening. All right, so now you should be navigating away, except those of you that I did not assign to a room. So, Andrew, Roman and Runcia. Is there a particular one that you Chris, I thought I had assigned you one. Oh, you've been in cloud night. Oh, okay, so then let's move you should be able to move on your own but I can certainly move you to cloud native there you go. And I'm trying to move myself. I see now. Yeah, I know how to do it. Mark, thanks. Big, big win. Okay. And Russia is there a particular track that that is most of interest to you. You're muted. Sorry, I was on mute. I wanted to go to the securing Jenkins delivery pipeline breakout. Oh, good. Okay, so I'm going to, I'll do the assigned for you then, because sometimes the UI has come up complicated it should prompt you would you like to join or some such thing. And Felix, is there a particular session you would like to join or would you rather, if you would be willing to act sit here at the top level, watching for people and possibly chatting to me that would be great. Because then I could join some of the other rooms and not have to be the top level referee. Hello. I'm leaving as well. Good. Well, well, I create the meetings, etc. If you have any questions or comments related to Jenkins, just think them up so we can have use of this time for whatever informal discussion. Right. So, so I see people back in the in the main that's good. If you would like to join other sessions, what you do is join their breakout room and negotiate with them for their the time to attend their track that track. So, one item I started a Google Doc, which can be used for notes for the tracks. But it was that hope so I'm not sure whether they will be using it or not. But for our track everything there. Thank you. Thanks very much. And what I was thinking is I should probably get the scheduled track meeting times and send the announcement and announcement to all of the registered participants of each track scheduled meeting time. So did the did cloud native decide on a time when everyone would meet together in the next two days. Yes, you need to ask cloud native. I'm sorry, I'm asking the right cloud. Did your track. I'm sorry, Oleg. Okay, great. All right. Yeah, the Jenkins calendar already. Perfect. Oh, that's a good point. I will do the same thing I should have thought of that. Excellent. Yes. So, so one of the others was we were having a conversation in events and advocacy, wondering how, how we assure there, the times that we're working best for them look like they were relatively late in the day. For you so we may need to do two sessions for events and advocacy or accept that, hey, we won't be able to have everybody who wants to attend every session. That's okay too. Oleg, if it would be okay. I would any suggestions on how we might do a gather people's insights should I just send email to all of the people that registered saying hey share your retrospective on it what could we do better what what should we do differently if we ever do this again that kind of thing. If you do it again, it's better to start from introducing rules of engagement in the beginning. So that everybody knows where to put notes etc before they speed tools. Now what you can send a follow up message. Firstly to track leaders. Then, once you get all the information, put it to the calendar and send another mail is a summary. It's basically everyone who registered or just pointed them to the calendar. Good. Very good. Thanks. Yeah, so second level share the screen. They see it. Yeah, so do yes. So this is my calendar. The easiest way you can just point people to this page, because here you can see that what we have planned by now. Office hours. I'm not sure whether they will happen or not. But they saw course hours, so they will happen thank his governance meeting it will happen security Jenkins pipeline and a few years on. So basically, you can just point to people here and they can find this information. Good. I like that. And that's, that's easy for me to do and the docs track has already agreed on the two times that they want to meet so I can put that into the into the calendar. The, the events and advocacy has agreed on a time as well. Good. Excellent. Okay. So, you will need. So we want the sessions to be recorded right. Yes, prefer it. If, if the facility they use doesn't record but in, in the case where we're using zoom, yes, we should record. Yeah, I'm not sure what they all have access to. I know that Kara does I know that you do and I know that I do. So I think that covers. And I don't know on Alyssa but I intend to join the events and advocacy. Oh, she does. Oh, good. Okay, great. So we've got, we've got what we need then. Excellent. So you're so slow. And I'm sure that Andrew as well, or at least he can. I'm sorry I've been only listening with happening or what was that. I'm making a joke Andrew that you probably also have access to the, to the CDF zoom account as needed. I'm sure I know the right people to be able to get said access, but I do not directly. I'm, I don't even have a paid account. Yeah, actually, oh, like you're showing the right pattern I need to go ahead and I'm going to go ahead and schedule the zoom meetings for the, for the other, the other the tracks that we've already got agreement on and get those published. Get those ready to be published to the calendar. Well, it's not a pattern. It's just while we're here and waiting for somebody to maybe join us questions. Right. Okay, and he becomes difficult because it's both came right. No need to see. We can use it. Okay, should be good enough. King. So other other topics to discuss. Okay, I'm not aware of any. So I've got the Docs track, the Europe and Africa Docs track, Docs track scheduled now invite there and I'll put it into the Jenkins calendar shortly to shorten it 30 minutes. So in terms of safety, is it okay to for me to embed the, the, the, the zoom link into the Jenkins calendar I assume it is, but I don't, I always have to check to be sure that. Let's see if. Okay. So it's, it's, I wouldn't say it's totally safe. However, however, it's hard not to do something where you embed the password. Honestly, for an open source kind of thing. If you expect people to just kind of join the issue you have you run into is there's still the potential for resume bombings because of it. Right. There is some risk, but yeah, we are not UK cabinet of ministers and until we don't post it on Twitter and whatever. Commonly we are safe. Commonly I wouldn't say we're totally safe. The LFN tack. Was it the tack. Yeah, the technical advisory board committee for all of the LFN project actually had somebody zoom bomb them once. And it was apparently really bad. Like they joined and they just started dropping all sorts of nasty. I wasn't on the call. But yeah, they actually provided psychologists to help people with that one. Yeah. And we're trying to avoid that with within reason. Yep. So, no, I get it, but you got to do what you got to do. Oh, like, can you, can you see that I posted the docs track onto the, it's right, right before the governance meeting in the Jenkins calendar. And then I've got another one to add which is after. Oh, right. I have to show my own calendar to see when. Okay, good. So, did you mention that there were one session about she cuts Africa. What she called Africa. I was just wondering if you said that there was a session about she got Africa or not. So it will actually happen during the docs track of the contributor summit tomorrow. So, so that one is, is definitely and we'll have, we'll have Zenab share. We're going to have to do some planning around that because they need project ideas and I've got a few that I've started. But we need more project ideas and we're also looking for corporate sponsors. So if you know any corporations that would like to sponsor she called Africa. The sponsorship is 1000 2000 or 3000 if I remember it up to 5000 for their very sponsorship levels. I've already asked a certain company that employs me. So don't bother asking that company I've already asked them. Good. I'm not sponsorships. We have some money. Right now, not that much. Okay, so that was and, and so that I thought that the Jenkins projects key contribution would be project ideas. But if we have funds. Is that something I should bring to the governance board Oleg as a, as a possible or to be honest, I don't think that one open source organization sponsoring another one is. Oh, okay, I see that's relatively unhealthy sponsorships should come from companies that makes sense. Yeah. Well, it's technically doable, but in such case we can host community bridge of electric project and umbrella. Right. Okay. Now I apologize I have a hard stop in two minutes I could assign someone else as the host if you would like to continue or we just accept that this will end. All right. Thanks everyone. Thank you very very much I'm going to go ahead and close all the rooms there will be grumbling and flinching about well. Yeah I'm going to close all the room so that they've come back here. Olivier, thank you very much Andrew thanks for joining Daniel as well thank you thank you. Thank you. Forgive the ending of the of the breakout rooms I know you're in the middle of conversations you really did not want to interrupt, but I have a meeting that stops in one starts in one minute that I have to leave for. Sorry. Thank you very much Mark, and I will see the cloud native group tomorrow. All right, thanks everybody. Thank you again for joining. I'll send out separate email to everyone that registered that I have email addresses for asking for your insights and suggestions of what we should do to make this better next time. What things went well what things went poorly etc will basically invite you to do an online retrospective. Thank you. Thank you for participating and see you. So next meeting is two days from now.