 Okay, so we are live now, recording this for posterity. Thank you for joining. We have some people already. This is going to be the first meeting of 2018 for the Planet FC. So if you want to add yourself to the list of participants there, we know later on who is being on the call. At the end, if you have a chance to read through the doc, I'd like to talk about the proposal on the cloud native side. We can start. So for those of you that have read this Kosuke's blog, Shifting Gears, here he talks about the future of Jenkins and 12 challenges and one important piece of it is the cloud native Jenkins. So he works both in Kubernetes as the runtime and creating new extensibility mechanisms and using cloud services more than just file system resources and things like that. And he's calling out Jenkins X as the pinning Jenkins on Kubernetes. And so with that, I went ahead and created a proposal on what it means to this next cloud native Jenkins. So I linked it from here, got the link here. Yeah, so you can read that. I'll go through the main points here. So basically, me and other folks at CloudBees, we are suggesting that we invest heavily on Kubernetes in the platform of choice for this cloud native Jenkins. And so with that, taking advantage of what Jenkins X has already built and there's a couple of ways to extend Jenkins X that has been part of the Kosuke's document. I've written them up explicitly here. There's these two extensibility ideas, build packs for different programming languages. So this is Jenkins file example calls and then other files like home charts, Docker files and things like that. If you install Jenkins X today, you can see that happening. How you can create new projects for Golang, for Node.js, for Maven, all of that are very easy. Anybody can create their own apps where you can extend and configure the platform. There's a few apps today and more coming, but it basically allows to take the model that was very successful is of letting people build their own plugins and extending this to building new services that run out of process and do other things or more complex things in Kubernetes. Any questions so far? Okay. Sorry. So we want to continue operating, we would like to continue operating Jenkins X or we would like Jenkins X to continue operating as a sister project to Jenkins and having this fast pace of development and basically copying the same ideas of the Jenkins project and community app like core goes one way but plugins follow their own pace. So Jenkins X, that's also happening. Anybody can create their own apps or build bugs to extend Jenkins X for different stacks. That's the accessibility model. And Jenkins X is basically distributed as a platform where people can add these apps on top like Kubernetes apps to build Kubernetes applications to deploy to Kubernetes. That was the first one that was included on Jenkins X. So we would like to bet on Jenkins X in this cloud native next generation Jenkins and obviously there's a lot of room for work that needs to be done. I mean, you can say it makes heavy use now of the Jenkins file runner to run server-less workloads and there's still some work to be done there to make it more efficient, more production ready. And there's a list of other things that can be improved and we went through some of those and I'll see just if you'd like to comment here. So how to make Jenkins run nicely in a cloud native for Kubernetes as well. So with that, I would like to open the mic for questions if anybody has. Jesse, your question here about remoting over the exec API. These are things that came up talking to different people. So we talked about how agents today, basically the GNLP persistent connection is not ideal in a containerized world where you have different services running. So there's an idea of using Kubernetes APIs to run these remote commands. It's just an idea and there's obviously there needs to be some work and whoever is doing it on how to design this it's up to them to design this in a way that works. But yeah, the idea of like deprecating GNLP and making, there was also I think remoting over Docker exec or something like that that could allow you to run remote commands without having to have a persistent connection or something. Does that make the clear? Yeah, I just wanted to clarify whether this was talking about agents in the Jenkins sense as things connected over a remoting channel or if you were talking about some sort of broader notion of agents as containers to which you can send instructions to build somehow. Yeah, that's still in there but the idea that for this to work better I mean something needs to be done with remoting. There was also the other I have here the idea of using sidecars as agents so maybe you don't need to run agents as a bot in Kubernetes in a separate bot but just run everything on the same called as different containers and just do some sort of like local communications so there's no network. So there's some opportunities there to explore and make it better. I mean there's also some open questions about what would happen with external agents if you have Windows agents that don't run on Kubernetes or things that don't run or you need some machine running in a data center or something, how do you connect those agents to a serverless Jenkins? Obviously that's still in there. Things like taking advantage of external engines like CoShip or AWS Cloud Wheel or Google Cloud Wheel or any of these cloud provided build services for things like Docker image builds if you want to do it in a secure way. This is not an idea of... The goal was not to make a design here just to expose a few of the future areas of work in order to make this more robust. So today we will continue having these meetings and continue to discuss here the future of Planetive Jenkins. There's also Jenkins X Office Hours and other channels for Jenkins X only. So you can... If you're interested you can jump into those channels. A channel in the Kubernetes Slack. So you can work the committers hang out and you can find our... You can ask questions there if you want about Jenkins X specifically. No questions about Jenkins X, cloud native Jenkins. Okay. So Jeff, do you have the agenda topic here for the big Google Summer of Code? Yeah. Can you hear me okay? Yeah. Okay. So I wanted to chat briefly about the Google Summer of Code. I'm one of the admins on the Jenkins project for Google Summer of Code and it's something that we've been doing for a few years. We're hoping to have more students this year. So briefly, if you're not familiar with GSOC, it's something that's sponsored by Google and the goal of it is to get students interested in the open source. So it's something that helps both the open source community and also can help get work done. We had a couple of pretty successful projects last year and we're hoping for some others. So basically, what we're hoping for out of the SIG is some ideas of projects because the way it works is we have a list of projects and students come and they make proposals for how they would implement a project and then it goes through an acceptance process both with us and Google and it's accepted then there's a mentor from our community, actually one or more mentors that would work with them and make sure that it gets done and they actually get paid as stipend from Google. So I just kind of wanted to throw that idea out there and see if anybody had any ideas or was interested in mentoring some of these projects because one of the success metrics is also having lots of people that are willing to mentor, obviously. I did this last year before I was an admin. I think it was probably two to four hours a week mentoring. It's mostly holding office hours, making sure that the project's on track and doing pull requests. So I put a couple of links in the document if you want to get involved and if you have any questions, let me know. What is the timeframe? So this starts, it's over next summer but we're putting together a list of projects now so I think students probably in like the January or February timeframe will start seriously trying to find projects that they're interested in and then there's kind of a community bonding phase so there's sort of a build up towards the actual coding which happens over the summer. Yeah, it's a great opportunity. I was a mentor a few years ago and it's great for the students, definitely. I mean, yeah, we have, I guess, a big list of things. It's a matter of finding mentors that are willing to cooperate. Yeah, well, mentors and also project ideas. I think for me personally working in the industry I'm interested in this stuff because we use Kubernetes day to day and we're looking at ways to make Jenkins more effective and so I think that this is probably an area where we should be able to come up with several projects that we can have students do to kind of push it forward and then we can find mentors. Yes, sir. No, sorry. I said great. Oh, sorry. Yeah, any questions for Jeff? I have here other topics. Next meeting I guess I'll give some time for folks to go through the reading and then we can talk again in February. Oleg is out on paternity leave so that's why I'm picking up these meetings for now and maybe get up to speed for the next one. Maybe there's some updates from configs code or other projects. I don't know if anybody is going to be at FOSDM. There's going to be a couple of events. Yeah, there's a pre FOSDM, I think this is a dinner, office and happy hour and there's a post FOSDM hackathon. I don't know yet if I'll be there but I guess a bunch of people from the community is going to be there. Yeah, there's the hackfest on Monday and this is going to be on Brussels on the first weekend of February. If you have any topics to show, to discuss for the next meeting, just ping me on Gitter. We'll add them to the next agenda. I know there's been folks here working on new plugins for cloud services so maybe they can give us an update for the next meeting or something and I'm not putting any pressure. Any questions or topics you're going to talk about today? I guess we'll do a short one today and I'll talk to you in the next one. Thank you for coming. Thanks for setting us up, Carlos. Thank you very much.