 And hello, everyone. This is the, I hope you can see the agenda now. Yes? Yes, we can. Cool. So let me see who's here. I'm not sure how else I can get this link any more clear, but there it is. I will paste it into one of the chats. Let's see. How about the Jenkins getter channel? There you go. So Jesse, you in particular have anything you want to talk about? There we go. Which was, and someone want to talk about check 206 as well. OK. So. Yes. So the first thing I just wanted to feel people out about what we should do about these kind of overall JEPs that aren't really proposing something specific. So definitely 300 and 400 are definitely in this category. And I think 203 is also. Yeah, 203 as well. That's right, yeah. So 300 is a good example. It's the overview of the mission and goal JEP of Jenkins Evergreen. And then 400 was Jenkins X, and 302 was talking about the Blue Ocean 203. Sorry, my bad. A little bit of dyslexia. It's a little bit of instability here, but it's a number of JEPs for the JEPs to be submitted. Yeah, so basically my question is, do we want to keep on doing these, or should we use SIGs for that purpose where we're trying to define a set of people interested in a given topic and set out a large scope of work that would cover multiple JEPs? I do not think that these proposals are orthogonal because six are definitely helpful for the discussion. But these JEPs could act as a declaration of intent. So they could be useful to declare the plan. By the way, it makes sense if you present yourself because when I speak, yeah, the screen is not shared. Oh, okay. So what I wanted to say, these JEPs are good declaration of intent. So they document what is the general idea. There we go. We will be documented in downstream JEPs. And for such a purpose, these JEPs are fine. But I'm concerned that all three JEPs mentioned have a standards category. I would rather treat them as informational JEPs. Yeah, so that's one question. And then even when we're talking about the statement of intent, so we've also been using SIGs for cloud native, we don't have an umbrella JEP as far as I know, but we do have a SIG and it has an overview page that describes basically the same kinds of things the JEPs do, which is why we're trying to do the whole thing and what are the particular areas that we wanna cover. Just to provide some context about cloud native SIG, there was a JEP proposal, but after some discussion, it was decided that we are not going to have it as JEP. We still have a description on the SIG page. There was also a blog post which provides more detail. So yeah, this blog post could be posted as declaration of intent JEP if you want. But yeah, I'm not 100% sure what does it contributes to the community. So I think to that aborted PR to have an umbrella JEP. Yeah, and they'll find the blog post then. Well, so here's one thing to look at. The SIGs are, we have this large project, this is our intent, we're covering this area, there's a lot of different things going on. It can be very vague and sort of broad, right? The mission and goals JEPs, even when they're talking about something relatively broad, they're still, I mean, like for example, the JEP 300 actually does have, here is a design. There is some degree of design choices being made there. This is our intent. We're gonna have these particular areas that are gonna be part of this project. The SIGs are like feature area or larger initiative perhaps. The JEPs, even the mission and goal JEPs would be more targeted to, there's gonna be a beginning, middle, and end of this thing. All right, if it's an ongoing, like it might be sort of, there's more sort of a hand wavy, like we'll be doing a lot of this for a while. That's fine for a SIG, but you wouldn't want that in a JEP, right? Well, then in that case, we should resurrect the JEP for Cloud Native because there is a particular scope of work that we expect. Do we expect it to end? And then we will mark ourselves as done and say, okay, we're done with Cloud Native? At least this plan set of stuff. Will we no longer have a cloud-needed SIG? Will there be no... I would rather expect to have a JEP for Plugable Storage because it's a sizable amount of work. Or not sizable, but at least it scopes a bit. Cloud Native SIG is of course an ever-ending story. If we do Plugable Storage, there will be high-valuability stories, whatever, cannery updates and other things we have in this list. Yeah, I guess you could put it that way, at least for the Plugable Storage work that we're actually doing at the moment. Yeah, there is a specific expected set of things that are going into that, which is pretty much what the current SIG overview lists. So yeah, so my thought is that even at the mission and goals JEP level, there's still a kind of a scope set of, there's a scope target that you can talk about, or there are design decisions being made. That's what I would say. I agree that there's some overlap. There's certainly gonna be cases where but I think, yeah, I don't think we would have a Cloud Native JEP, right? That's like, wow, how much can you stuff into that? Everything. There's a lot of space in there. But that's just me. Okay, that's fine. And then there's also the selection of delegates, which you would expect also I mean, basically there's no, there's no formalization right now for the fact that umbrella JEPs even exist, much less how we're supposed to use them and how they relate to SIGs. And then there's the stuff on selecting delegates. So yeah. Yeah, so you're talking about the JEP nine. Yeah, I was about to talk about it. Okay. So selection of delegates, there's this table of initial, here they're called initial JEPs. And then the PDFL delegate that corresponds to it. So, I mean, this seems like if we had a formal notion of what an umbrella JEP was, then part of that would be an indication of who the default delegate was for every, for every JEP in this category. So two weeks ago, we were talking with him about introducing relation between SIGs and JEPs. So one of the topics was moving discussions to and making SIGs explicit there as a separate table and maybe even making SIGs in PDFL delegates instead of particular people. But I have an action item to start a discussion for that. But I guess your concern could be addressed if we say that for whatever cloud native story, we say that cloud native SIG just access a different delegate and decides how it makes decisions. I don't think you can have a SIG as a delegate because then who's in charge of making decisions for the SIG? And each SIG decides how it does on its own. By default, we expect SIG chair to be the delegate or something like that. But for example, we can say that, for example, in cloud SIG, we vote instead of having PDFL delegate. So for the cloud native SIG, it's, let's call this as lead. Yeah, Carlos is chair of cloud native SIG now. Is the idea to abstract away from specific people if the chair changes? For me, yes, it would be the idea or maybe preventing by design bottlenecks. So for example, SIG may define its own process for making decisions and it would do the job. So I don't mind this exactly, but it seems like there's, this has the potential to become like, okay, so each SIG does this their own way. And when someone wants to propose something or do anything else, they basically have to relearn a new culture so if I go to the platform SIG, you guys might end up having a SIG that's not, it's based on, okay, we just do a majority vote and whoever wins, if you guys don't like it, suck it up and deal. And then this other SIG has some other way of making their decisions. And it just, it seems like, I mean, I understand wanting to have groups be able to sort of self manage, but having a core sort of way that we make decisions that we all kind of agree on seems to me, otherwise you end up with confusion and chaos. We're back to chaos again. I think it's clear if there's just a particular person that Koski is defined for that area and if there's some reason, I mean, if they're off on extended leave or something, then Koski can step in and do stuff. So yeah, I don't really want to, and I didn't look at this too carefully because I'm not necessarily the one driving this, but I wouldn't actually say cloud native SIG as the initial JEP here. It's actually just, the area would be cloud native, which could have any number of things, right? At least three, yeah. Yeah, I get that. Yeah, today we had a discussion where the configuration as code is cloud native SIG or not. Yeah, these topics, in these cases, it's not a problem because JEP 2.1 is explicitly mentioned in the list. Right. But yeah, now there may be some cases. So I think that the best approach is that we start defining something. For example, JEP sponsor may explicitly say that he wants it to be discussed in SIG. So for example, how we did for cloud native SIG JEPs, all of them have discussions to refer to the SIG. Right. Which is part of the process that exists. That's good. Right. And this thing plus the delegate, which is set as default. Yeah, it sets the clear path how we establish relation between SIGs and JEPs even now. Maybe not ideal, but at least it does the job. Yeah, I mean, that seems reasonable to me. Hello, what? Discussions too? Oh, yeah. What I wanted to say. Okay, so allow the discussion you to point to a SIG, which we do, right? Sorry, I messed it up. No, that's probably me. Accepting some of your changes before you were done. Anyways. Yeah, so I think that, so if JEP sponsor knows in which SIG he wants to discuss this JEP, I think we have no problem even now. Okay. The other point that you're asking about with the SIGs, SIGs decide separately on BDFL delegate process and we're not... I don't have strong opinion about it. So I think something worth discussing, but yeah, maybe you're right that having a single process across JEPs is preferable. I mean, SIGs can discuss and agree, it doesn't really matter who clicks the button to accept the JEP in such case. Yeah, what? Sorry. Yeah, I'm not sure there was any particular conclusion for the question I originally asked, which is do we want to continue doing umbrella JEPs to indicate yes? So then, I mean these seem to be registered as standard JEPs right now, which doesn't really make sense. Do we want to use informational? Does there need to be a new JEP type? There might need to be a new JEP type. The reason why they're not informational is because there's actual design decisions being made in these. There are decisions being made here. They're not. That would be better to require some consensus on, right? Yeah, what would be a better name? Something like roadmap JEP. I'm not sure. I mean, yeah, umbrella, you used the term mission and goal before. I think that informational would be actually okay. I mean, informational can be anything. And then you understand from the content, what is it? That's true. I don't really see the difficulty, at least with the way that things are described currently is that the informational JEPs don't require any, they don't require consensus. They're explicitly meant to say, you can just sort of throw these up here, okay, I guess that's a fair way to go. I'm concerned that it would be... That's why informational JEPs don't require consensus. So I understand why they don't require reference implementation, et cetera, but they still need discussion and they still need BDFL delegate and they still need acceptance. Fair. It's just, I remember from the... There was a part of the JEP1 that actually talked about this and... Again, some of these things are like, well, that's the way the Python folks wrote it and we didn't really go and change the details on it, right? So... Right now it says users and implementers are free to ignore informational JEPs. Well, it's their own business. But yeah, for example, if you want to define priorities for cloud native SIG, having an informational JEP is okay. Because implementers can ignore them. For example, they can implement other plugable storage if they feel reasonable according to their own priorities, I know. Is that really how we want it to go? Yeah, because I mean, I think, you know, for example, for a cloud native, JEP202 would be a particular thing that we're doing with... with artifact storage. And we expect, you know, this is an actual standard in Jenkins Core. This is how you replace default artifact storage. That's not something optional. I mean, you can decline to implement that, obviously. But we accepted that this is how we expect artifact storage to be. But we don't... we don't block people from, you know, doing other efforts that involve the network that are not aligned with the overall goals of plugable storage. We just don't... The JEPs don't block anyone from doing that anyways. But it would definitely be... If you came along and did some other version of that, you'd probably want to... There'd be some like, hey, why don't we try and get these things together? Why would you have two different... Obviously, if there is a pull request to Jenkins Core, which re-implements the same artifact manager API, we'll likely reject that unless there is a real good justification. So we won't be... Yeah, because this is a standard step. Yeah, right. But we don't foresee, for example, for Evergreen. I mean, we don't... We're not waiting for there to be community consensus on Evergreen. There's no point at which we're going to say, oh yeah, Evergreen is finalized, right? This is just a statement of information about how this particular team is expecting to go about their work and what components they would include in it. So it was their own decision to keep JEPs, but if they have decided to keep it in the documentation it would be also fine. Well, I mean, I guess my question would be what about for something like configuration as code, where there was quite a bit of back and forth in the original discussion. Would you... Would you be... But it wound up being that most of the actual decisions wound up being punted out of 201. We just said, okay, yeah, we're accepting 201, but we're deferring the actual decisions to another JEP. Right. Which is also a solution. Whichever one that was. I mean, I can't... Yeah, so JEP 201 is still not an informational JEP because it defines standards like YAML specification and I'm sure what's left of that. But yeah, it's still a standard JEP in some way. So it's just a plug-in self-documentation. Let's put a soul, but yeah, okay, it's a valid JEP. But would you have been okay with that just being informational and the... having it be simply that team just declaring, we're doing this and... and not being... not being perfectly fine just not taking your feedback? Well, not taking feedback. It's not acceptable for any kind of JEP. Even if Python approaches that. Regarding the rest, if it was informational JEP, which would say that okay, here are our priorities. We want to work on that. I think it would be fine. Okay. I'm just sort of throwing out some questions here in terms of like having them, we could create a new type of JEP. So the question... I think 201 is kind of a weird example because it was originally created as if it were going to be a self-contained JEP, but then it turned out there were enough controversial things that they wound up filing, follow-on JEPs rather than editing the original one. Right. So, yeah, we could take a realistic example. So what Jesse was talking about cloud-native, I think. So let's think about plug-able storage. We had a discussion two years ago on the JEP. What would be the priorities for the stories and what exactly do we need to implement? So if somebody decides to document this priority list and yep, the list of types and JEPs we need to deliver, it would be a good informational JEP in my opinion. Yeah, I think so. I would just move some of the description out of the cloud-native JEP into out of the cloud-native SIG overview into the informational JEP giving those details. Yeah, so what we could leave in a cloud-native SIG, then we could just say plug-able storage and refer to the JEP. Because, yeah, currently I don't like the current state of cloud-native SIG anyway, because it describes several plug-able storage types and then spends something like one sentence on this. So, yeah, we could refactor that for sure. But I don't see any problem with the current process. Informational JEP, no. Okay. Should some of the existing JEPs like 300 be recategorized as informational? Oh. Yeah, I think so. I mean, if the JEP has been already accepted as standard, okay, but if not, can it change to the category? Is there any guidance on whether this X00 numbering scheme is going to continue to be a thing or was that just a one-off? That was just convenience on my part. That was, it was some of those were the first JEPs filed, so it was simply like, well, let's just put these in, since we know there's going to be some follow-ons to these, we'll make it easy to group them together. Okay, so currently we have required. So currently we have starting from 0 for community JEPs, starting from 204 technical changes, then 300 at Evergreen and 400 Jenkins X. Yeah, and there's only one there, so. Yeah, I actually have no idea what is the plan about that. Yeah. Do you like good JEPs for the JEPs? In any case, I don't have a view into that, into the plan there, so, you know. Well, it sounds like these are all interesting questions and points to be raised. It's the kind of thing that we should probably put on the on the dev list as well. In terms of recategorizing the JEPs, that would be something that you definitely want to raise on the dev list. I mean, of course, we're here, we could talk with the BDFL about that, but I don't know. Again, I don't have any, there's no process specifically around this, so it's kind of up to you guys. I think the process is straightforward. JEPs are submitted to get feedback. And there is discussions to section which describes how to provide feedback. So instead of creating one thread for all cases, I would rather in particular, wait for JEP 300, JEP 100 so that the sponsors process this feedback. Because it seems to be more reasonable than a single thread. I don't know, we are talking, it's up to you, but it seems like we're talking about the overall process of how we're going to organize these things, so but again, that's totally your eyes' call. Let's do something. Okay. So and I'm not trying to be dense here, I'm actually like, okay, so what exactly did you guys do, are you guys interested in doing? Well, at least for SIG, I think we agreed that we would like to have an informational JEP which would be a single place where we could point people to the SIG, point people to the overall intent of the work and the overarching goals and point to the particular JEP, so 202, 210, 7, 212, 206 all of those I guess would fall under that category and I'm sure I'm not exactly sure how you mark that, we'd have to put a references section or something because there's no you can set a dependence on a JEP and in the informational JEP you can just keep a table with references to other JEPs because informational JEP can be updated if needed. Sure. Okay, so informational JEP for pluggable storage and I guess we decided 201 was a little bit fuzzier and we would just leave it as is. So, regarding the rest of the JEPs the only problem is 300 because it's already accepted so I would rather keep it as is. Well, I think we're making a material change, this is really just about changing the presentations. Okay, cool, alright. Alright, I think that again like changing 300 to an informational again, we can it is possible to change accepted JEPs, right? It's not, it's more like we need to go through the process of making sure that it's agreed on, right? Yeah, basically just sign off from title or is that that? Yeah, exactly. Anything else? And then same thing for, so the mission and goals JEP, so instead of mission and goals we'll be using informational as that sort of structure, right? Right. I can type today. They'll clear some stuff up. Yeah, we'll have on my to-do list to create an FAQ that'll sort of cover some of these not specifically part of the process but you know, here's what we suggest kind of things and that will be another informational JEP most likely but it's on my list to do, I just haven't gotten to it yet. Anyways so can we, are we moving on to 206? Yeah, I guess probably be quick, I just want to know what's what's going on since it's the list is draft, in fact the code has been merged and released and there's no PDFL delegate. Well if you want to send a mail to the dev list and then see if you can see let's see. So we have any pull requests for this? Yeah, they're all merged and released. Okay, so but I mean pull requests for the JEP there's nothing here, right? No. So you're the sponsor what I'd say is just create a pull request with the change to accept it and tag tag Koski on it to get him to take a look at this and review it and decide if it's accepted. I'm assuming what you're saying though is that the work is basically done it might even go straight to it. Finalized I guess. Yeah, so yeah just all we need is a pull request and then PDFL will look at it. Basically as sponsor you're the one that should trigger the the review. So that's the way that goes. Anything else? For me. Uh, Daniel? Nope, Daniel. Okay, great. Well, thanks. It's been productive and we get 25 minutes back. Alright, thanks. Thank you.