 Hello everyone. Welcome to our second Jenkins Enhancement Proposal Office Hours. This would probably be a pretty small one this week. Koski won't be joining us. I know Sam Van Orp had some interesting, had some topics to discuss, but he's busy this week. But we do have Oleg the Machev and sorry Stefano, actually this. What brings you here this week? Just looking to say hello. Yeah, just watching. Okay. I just knew you. I just work in Jenkins at the office and so I was curious and just to take a look and working there not to have enough. Okay. Well, if you have any questions, just fire them on as we go. Okay, cool. All right, so great. Could you please share the link to this document? That is interesting. I don't know why I didn't already do that. Let me put the so where would you like it? Just Hangout Chat. Okay. So it's linked in the public page. Hold on just a second. There it is. I was trying to get to the right spot. There we go. Here is the document in the chat. There we go. And I should actually put this visibly here. I don't know how that would help anyone, but at least I can get to it. So if you want to post any items to discuss, suggest that them to agenda, right? Right, exactly. So I don't know if you have a pose or edit rights. Yeah, there you go. Yep. I'll, I'll, cool. I've placed some items. Okay, cool. Well, let's, let's dig into those. So, I mean, I think all of these are interesting ideas. There's, there's, I'm sort of, I'm not sure, I want to make sure that, that what I'm, we're talking here, I'm, I'm going to, I'll be clear if I'm speaking as something other than just a regular contributor. So, yeah. So in, in terms of each of these, they're, they're interesting ideas. I, I feel like we've actually done a lot. I mean, I know both you and Sam have been throwing a lot of like, Hey, can we do this? Can we do that? Can we do this other thing? And I feel like we've actually, like it's time to sort of settle for a little bit and note, Hey, this would be useful. And then come back to these later. We've got a lot of things in motion. And I, I mean, I think these are all, they're, they're interesting, but it's also like, you know, why don't we try using what we have for a bit? We, we've already done one, I mean, we, we took several months to get the, the first thing out. We took a, we did another significant, you know, revision set a couple of months later. It hasn't even been a couple of months since that. And it's like, you know, let's, let's try and use what we have for a little bit. There's nothing. So for example, like with the rollout plan to the JEP requirements, I mean, that's, that's reasonable to expect it to be in the specification, but I don't really think it needs to be another top level thing. In fact, I mean, if anything, I would be like, okay, maybe we want to take the, the, the, the, those four sections that we have and move them into something else. Like it might be actually better to, to reduce the number of top flow sections that people don't have the extra crux, right? So there's, there's, there's a bunch to discuss in this, in that area, right? But I don't know about you, but I, you know, I, I don't necessarily have a lot of bandwidth to, to cover, you know, continuing to upgrade, you know, update the process. I'd rather just use it for a bit and maybe note, hey, this would be an idea or that would be an idea. And then come back to things later. But yeah, but yeah, as a JEP editor, I probably can post process changes on my own. Yeah, the problem is how we review them. So if you don't have time to implement the process, of course, it's perfectly fine. Because yeah, you are not the one on the hook for implementing everything. But yeah, for, for the reviews in discussion, I would rather prefer to have small incremental changes. So I think that for that, it would make sense to proceed now. So there is a demand. Why don't we start a discussion somewhere? Sure. Like I said, so to be clear, I don't have to require you to implement anything for JEPs. Fair. It's not a question of me. It's more a question. It's not just me. It's like the whole community is actually using this and continually moving, having a moving target actually makes things harder for everyone. Yeah, but on the other hand, things like rollout plan may be really required for those ones who consume the JEP. Because now, for example, we have a discussion about Ruby runtime. It's a build. Yeah, so the discussion is not very active now. But the last time I checked with Daniel, we had a misunderstanding of how it would be rolled out. And the problem that it's not really documented in JEP for now. So setting up such a requirement would just set expectations to JEP sponsors. Because yeah, now it's just a community feedback and we stay there. Thanks. So for JEPs, which really require breaking changes, I would really require a rollout plan for any breaking change. Sure. Let me just see something here. So if we're looking at the template here just as an example. So we have this delegate abstract infrastructure by compatibility. Yep. So what I propose to do is to just another section for a rollout plan. We describe that it's optional for non-breaking JEPs and for breaking JEPs. Yeah, I think it's mandatory. Well, I mean, it's an interesting idea. You should definitely raise it and let's see what people say. Yeah. Okay, so just pull request. Well, I was going to say a discussion, but pull request also makes sense. This comes back to that other point. We were having a sort of the discussion around how we can have open questions and comments sort of stored in JEPs in a way that makes it possible for us to commit, sort of get to address what Sam was discussing this week. Actually, I should probably catch up people that are on the video. There was a JEP proposed here. Let me wait for my page to refresh. There was this external logging API plugin that got proposed and Sam had a bunch of open questions for it, which due to sort of random oversight on my part, I merged while those questions were still open. That's partly, I mean, it's partly mistake on my part. I just didn't refresh the page to see his comments. But at the same time, it's also you, Oleg, requested that this be approved as draft. And in the way that we have the structure right now, the first PR, usually that is of a submission, is not really meant to be the point at which people ask design questions and more detailed stuff. It's more a conformance check to say, yes, you have all the sections. You've started filling out all the things appropriately. It's a minimal conformance check, not a design review. And Sam was sort of asking more design level questions. So they weren't really the sort of not quite the right context for those questions. So by accident, I merged without addressing them, which meant that his questions sort of looked ended up looking like this, where we didn't have anything to in that. Actually, we have the same problem in almost every draft. Yeah, exactly. Most people, they jump in and they're like, oh, I have design questions. Like, people, come on. So part of that is communication, I think, in saying, hey, this is not the time or this is not the PR for you to do design discussion. It's certainly interesting to do them there. But the point is to move things into draft, at least in the way that it's been described in the in the one was, hey, this is this is the point at which we do just a conformance check. So then the question becomes, how do I how do people ask those design questions or make design comments? Once something is not in a PR, because GitHub doesn't really support making comments, and you can make comments on commits, but they're sort of wedged off somewhere else that they're not they're easy to get lost. So I ran a little experiment this week of what something an alternative might look like to allow people to start to sort of store their questions in the JEP. And at least one of them looked a bit like this, where I added, I think they're warning sections, or important, which tag I used. Anyways, these are blocks. And I took Sam's comments that had otherwise been comments and questions and added them here as text that would go into the JEP. Also suggesting that we could merge this directly without this, without you as sponsor having to answer them right away, we could just merge them and then come back and address them later in another PR, which would give us a sort of a history of what questions were asked and also discussion along those PR lines. If we didn't want to merge them, we could also simply have the discussion and then edit the PR, add more commits to the PR, to remove these blocks as they're addressed more fully. So that's what that, yeah, they're warning blocks like that. So this was a one, let me just pull this, no, not larger, a little smaller, there we go. So this was just one idea that I had. This also brings up having a sort of an FAQ for some of these things where it's like, this is not something that I would feel would need to go into a change in the process, but it was more something that someone, that we sort of agreed to know how to do, that wouldn't it be an informational JEP that sort of talks about, that we talked about last time actually, that would be covering who the default BDFL delegates are for various areas and also how to go about sort of doing various communications within a JEP. Yeah, so my question would be is, so do we consider using any external services to do the reviews? Because yeah, in the current state, we rather battle with the fact that GitHub is just not very helpful for reviews in the current state, because we decided to use such process. So maybe if we find a service which works it around, it would be preferable, or another option would be to review the branching policy, but it would be a lot more complicated, I think. Yeah, I'm not sure what that would look like either. Yeah, because one pretty straightforward approach is just to create branches for every non-finalized JEP. We create a standard pull request from this branch against master, and we accept all commands there. And by the time it's integrated, we expect all changes to be merged. But yeah, the main problem that it requires standard branches, it increases overhead on JEP and it has to do that. And then it also, the other problem there is that it makes it harder to find the JEPs. Part of the having them all in the master branch means that if someone comes in, they don't have to go, okay, well, where would I find, you know, unless we like create a branch for all drafts or a branch for all, like, I'm not sure how this would play out exactly, right? One of the ways that you have already created, read me on agente.ci slash JEP. So I mean, there is a listing of all JEPs, and this listing has been auto-generated by the script. Sure, yeah. So we could modify this script in order to provide references to branches or pull requests for non-accepted JEPs. So in such case, they will be still, would be still a dashboard with all JEPs, independent of whether they are in branches or in the final version. And yeah, it still doesn't exactly address your concern, but at least from user's perspective, there would be a source of information. True. I don't know. I just think that we're, as I said, I think that we're trying to solve things that are with technical solutions where it's like, look, this is not as, this is adding more layers of technical levels to something where it's like, you know, the point of this is to have a way to store these and have history on them. The adding more, adding more layers and adding more, this is how we do it in more process around All right. I mean, that's my opinion, right? That's me. That's not to say that it can't be done. I'm just saying like, this is something that you that you'd want to bring up in the dev list and have more feedback from the community, because the adding more layers, I'm just saying for me, it seems like that would be more of a barrier for entry, right? Yeah, the lowest barrier for entry would be to just move for the entire process to something like Google Doc, but yeah, it's We lose that. Yeah. And then we lose that history point, right? Yeah, right. So there is a reason why it's not in the Google Doc. Right. And this reason is pretty important for the Jenkins community. Right. But yeah, for our users standpoint, maybe if we create a standing pull request, integrate them with services like Revuable, so that we can have reviewed threads, it would be better. But yeah, it's a subject for much long discussion. Yeah, exactly. But I mean, these are all interesting points. The question then becomes like with with ideas like that, like, what do we how do we track those? Do we just put those into into JIRA bugs? Do we do something like with the the notes that I had, like this one where we add the warning things to say, hey, this is an open question. What do we want to do here? Yeah, right. But we don't want to do that on active or final JEPs really, do we? So it's sort of a Yeah, right. Plus, the problem is with number of comments, because when you create a long design, you may have several dozens of comments in the first iteration. So managing all these things is quite complicated. Yeah, I would rather prefer to somehow avoid that. Because the current process, it sounds like a reasonable approach, because comments become explicit. So I'm perfectly fine if such warnings get added to my JEPs. Okay. Yeah, the problem is that if we require people to make comments in such way, or if we require JEP sponsors to process all comments and the developer mailing list and put them in such way, it becomes insane. Yeah, no, that's definitely, yeah. This was more, what I was trying to do here was sort of figure out a way to address the point that Sam made, which was here, in terms of people wanting to be able to make line level comments, right, on JEPs. And really, it's more about, I don't know. So there's a couple of ways to do this. One is, okay, I have a question. The questions definitely are ones where if someone really just has like, which do you mean by this? I don't know. That'd be one thing. For things that are more comments or something that someone has an opinion on, the other way to go about this would be to suggest that people actually submit a PR that rather than doing this to say, hey, why don't we and then actually submit a PR with the changes that they think should be made. And then you can discuss that PR. It puts a little more onus on people, on the person suggesting the change, right? To actually stop and have an opinion, formulate what they wouldn't mean, want the solution to be and make a, you know, propose a change. But at the same point, that means that it's not the sponsor's job to try and integrate that. It's an individual's, right? Which is a fair point. I mean, I think that it's not the sponsor's responsibility to, is there a responsibility to try and, you know, build consensus and make sure that everyone's views are represented. But it's also, but it's not necessarily their responsibility to make the edits to the document themselves. So, yeah, so yeah, regarding this pull request, I'm perfectly fine. You would get smashed, actually, most versions. So that's right. So I had this shown as warnings, and I also tried it as comments, which don't show up in the, that aren't visible when you go and look at the view. So that as a comment, when you're looking at the document, it doesn't get in the way, but it is in the codes that people can go and look at it. Do you have any preference either direction on this or are there cases? I mean, there's probably cases where either one works, right? Right. So the main problem is comments that they're not really visible to those ones who just take a look at the text. And since the main purpose of JEP is to get feedback from people, I would rather bite the bullet and go after public comments. Okay. So I guess what I'll do is, since you just said yes, I will merge the comments one. Actually, can you approve that? And then I'll merge it. 160. Yeah. And just say that this is what that you'd rather see on this one. We can see how this goes. Anyways, so we'll do that and then see how that uses as a test test bed to kind of see how that works. And I will close the other one after this meeting, I guess, for just get there. Okay. So that's cool. Let's see here. So Okay. So can I just merge it? Yeah, sure. Yeah. Okay. I'm the sponsor anyway. Yeah, exactly. I'll go back and add the notes in here after the meeting. So what else? So then the rights, then adding the SIGs. So what was the SIGs as a field in the summary table? So yeah, we haven't done this yet, but we'll just talk about it a bit. Right. So the the idea behind that is that if you open a table for any job, yeah, so there is a number of standard metadata fields and those other fields like discussions too. Yeah. So what I did in my pull request is that I had magnified the discussions to fields in order to point to the SIG mailing list. Well, that totally makes sense. That's that's exactly how that should be used. Yeah, right. How it's how it's indicated that should be used currently. Yeah, it's totally aligned with JEP 1. Right. Yeah. So my thought was that maybe for particular things, it's rather preferable to link to a special interest group instead of linking developer melodies. Because in such case, readers go to the SIG page. They see when there are meetings, which they can join to discuss that, they can see charts, which they can also join and discuss in runtime. So my thought was that in addition to discussions to field, maybe it would be reasonable to have another field reference and parent SIG or something like that. So we say that this particular... So rather than pointing to a, sorry, so rather than pointing to a mailing list, as in the discussion too, it would be a, I don't know. Yeah, so a little quote. Or general SIG information. I see what you're saying. Yeah. Yeah, right. So it could be this field. It could be two fields. So for example, we can say discussions to always go to the mailing list, because it sounds reasonable from the history standpoint, but we could add another field like parent SIG or whatever, which just references all other information if needed. But I just think it may be useful. I don't have strong opinion on how it would be implemented, but I would rather implement it as a separate metadata field. So yeah, so either like as a SIG, I mean, like for example, the Jenkins Essentials has its own Gitter channel, right? Right. So Jenkins Essentials has its own sub-project, right? Yeah, you would think that it would almost, and they're actually basically already doing weekly meetings and they have their own Gitter. What they don't have is their own mailing list. That's the only thing they would, that's the only criteria that they don't have to meet, that they don't meet for being a SIG, right? Right. Yeah, there are also formal changes like assigning an official chair, but generally... Little things, but the basic structure is already kind of there. They're already in that space, so... It applies to almost every sub-project actually, right? So all the projects have SIG like structure anyway now. So yeah, maybe if we allow reference in SIG or project. Yeah, that's another, that's an interesting change. So I mean, that would definitely be useful to have in the field, as one of those metadata fields as something early for someone to sort of like, oh, right, you can go to this SIG and that gives you a whole bunch of different information. Right. So if you're finding with that approach, I will just propose a pull request with additional metadata fields. PR and discussion on the dev list, that's the thing. It just needs to be socialized and visible. And give it a week or so for people to respond. Yeah, no hurry at all. Right. But yeah, it seems reasonable to me. I mean, like I said, even if I disagree on these, I'm interested in seeing what the community says about them. Yeah, right. Maybe in a developer discussion, I would go even further and introduce proposal to allow making SIGs BDFL delegates. But yeah, maybe it's too early for that. Yeah, maybe, maybe too early for that. I don't know what that. Yeah, it's still good to have a discussion on the developer manifest. Yeah, exactly. That's an interesting, so all right, let me just add this is a... Yeah, so SIG as BDFL delegate. So you think basically that SIG as a whole would have a consensus on it before the thing is merged? Right. SIG is eligible to define the process it likes. So we could just default to the process when SIG chair makes a decision. So I mean, he or she is responsible to discuss that. Yeah, finally, SIG chair access BDFL delegate in this case. But yeah, SIGs could opt out to different process, for example, define their voting criteria, et cetera. Okay, it's interesting. Maybe moonshot, but it looks reasonable and it also allows to default particular decisions to SIGs, so that you don't... To a group rather than an individual. Yeah, right. Yeah, I still think that the delegate should be approved by BDFL, but yeah, maybe in some cases we could relax at this requirement. So I mean that if you propose a job for Jenkins Essentials, I'd guess that Jenkins Essentials team can make a decision on its own. Yeah, it's a separate... Yeah, the main thing about the BDFL delegate being a single person, I think it's the same reason that we have the BDFL as an individual is so that we have that situation where generally we're run by consensus, but if you have to have one person make a decision, this would be the person, right? Yeah, right. But it'll be interesting to have that discussion and see what people say. So yeah, a bunch of different ideas here. What else? So we had the discussion about the commenting and I still need to create that sort of informational JEP that we had listed down here for the JEP process FAQ. Yeah, maybe not even JEP, but maybe WikiPage. So JEPs are fine, but yeah, this JEP may be changing pretty often. Yeah, the nice thing about an informational JEP is they don't have to be consensus in there, it's okay for them to change, right? I mean, it's basically, the point is to disseminate information not necessarily to... So they never become final? Well, it would become active, I believe, but it really depends on the JEP, right? Yeah, right. So yeah, or we just have it as part of the read me. I just wanted to, yeah, we'll see how it goes. I'll see what I, maybe you're right. Maybe I'll just, I'd rather keep it in the repository so I might make it like a read me at the, or actually have an FAQ document in the root or something. So, in any ways, anything else from your side? How's the, I mean, obviously there have been some little rough edges that we've been figuring out other than that going well? Yeah, I have a number of JEPs, so I mean pull requests. I'm not blocked anywhere, so yeah, there are some action items which have been discussed, so for now I'm good, just need to write a lot of text. Yeah, right. There it is. Well, cool. Let's see, I don't think I have anything else for this week. So, I think that's, that'll do it. I was this review process sync up? I, it's what we already discussed that. Okay, cool. Yeah, I mean, this. Oh, that, okay. Okay, cool. So, yeah, that's. All right, well, thanks. And I'll talk to you again next week on this. Okay. Or if not, not sooner, right? Yeah, let's see. So, thank you very much. All right, cool.