 Welcome to Jenkins documentation office hours. It's the 17th of January. Let's go through our topics we've got news, the change log PR. Yes, and that is not just a question mark that's a yes we need to do it. And then your last time I put this in and it was like you thought that I wanted this to be the first stuff and I wanted to make sure you've got all your other stuff in first. And I think, I think we owe it to ourselves to the weekly change log very first one because it's a relatively contained task and if we don't do it. Then we've got a much bigger task when the release happens tomorrow morning. Absolutely. And then open poll requests, and we could probably talk briefly about the improve a plug in tutorial. But it's basically say no progress in the last week. We should plan for how we could start releasing pieces of that, because they're that are ready to go or is that not going to be. Yeah, I think we it's just a matter of, of the work, the work that's there is finished the piece that's ready and publish it. Absolutely. Okay. Okay, so she could Africa contribute on. I still need to next steps. So that's a talk to it. And yeah, I think those are the topics. Anything else from you Meg. Nope, I don't think so. Okay, great so. And welcome to dirage she's joining us that's great. Hey, dear. Thanks for joining dirage. Thank you. So we were just reviewing agenda. Are there any agenda topics you needed to add dirage. I think I do but I'm wondering whether discussing technical things in Docs office or we create idea or not. It is a good idea. We've done it we've done we've on a in the past spent entire the entire Docs office hours on one or two technical topics so if you've got technical questions let's let's answer them. Yes, so it would be around the required upper bound depth error. Oh, yes. Discuss on that. Good good this is a good chance to read some documentation talk about it and then use specific experience on something you're you're actively researching to see okay how did the documentation meet or not meet the needs. Good. Okay, so, and which plugin. parameterized trigger plugin. Good. Okay, good. Yes, parameterized trigger plugin. Excellent. Okay, so this is a this is part of the improve a plugin exercise. Yes. And it will highlight for us one of the challenges that sometimes what we would like to be a trivial task is not a trivial task because there's complication there are complications. Good. All right. Any other agenda items you want to add dirage. Discuss the same thing about another plugin, the build, build time out plugin. Oh, good. So you've got two examples that you'd like to use as part of that. Okay, good. That's all. Welcome. So yeah, you didn't expect me to see this meeting but It's great that you're here. Thank you. Yeah. I'll, we haven't meant for quite a while I guess. Yeah, it's nice that you're here. Thanks very much. So, so we were just reviewing agenda like the topics we've got on the agenda right now include brief news and then we'll do a review of the weekly changelog. Dirage has an upper bound dependent upper bounds dependencies question that we're going to use to test the existing documentation and the improve a plugin tutorial. And then make has prepared a number of reviews of existing pull requests that we can use for an open PR topic review. Are there any topics you want to add to the agenda like I guess it's already packed. And the kitchen couple is all the stuff because I was basically absent for a few months. Great. Okay, well, so then by way of news, the 2.319.2 security release has been delivered. The 2.330 security release was delivered so that was LTS. The weekly security release was delivered. And that one had a complication complication due to an unexpected. Automated build of 2.329. That was the security med do some quick scrambling we had a Tuesday build launched when it was thought to have been stopped and so working to fix the root problem that allowed that build to run on schedule when it had been intended that it would not run. That's it that I've got for news. I guess we should do heads up there are discussions on Java end of life. There are discussions on Internet Explorer 11 end of life and of support. Rest in peace. Exactly, or just rest maybe not even yeah I don't care if it's peaceful or not just go away. Exactly. And those are continuing the plan right on Java eight end of life is marked to write the gap. We discussed it in the platform sick last Friday with Tim Jacome, and we'll use the jet process to lay out a plan that we can then discuss alternatives etc. All right, so next topic then is in this meeting we like to do a review of the weekly changelog. And it's we use the automated changelog that's been generated and then we sanity check the contents of that automated changelog. And then we look at the automated changelog for 2.331. Okay, so we've got unified labels in plug in manager, remove deprecated terminology labels from the plug in manager. That looks pretty good to me it's an RFE any objections to the phrasing. Okay, and then we've got the next which is a bug fix increase the width of the forms. And this one is a bug fix that's quite important on the UI improvements, we very much want to get it in the only thing I see it's missing is it doesn't have a full stop at the end of the line but that's easy to fix. Also, the most one. It would be also nice to clarify what other forms exactly. So, so well so let's let's read the let's look at the pull request then. And let's get the ideas for improvements so it was. It was just a minute it ups wrong wrong repository sorry we got a quote to the core not to. Okay, so the pull request is just borrow that. Okay, so the bug that it's fixing is described here. And it's one of the most popular bugs in the rating system. So the job configuration dialogue is too small and if we look at the image that they show notice how it lays out right it's it's not using the full width of the editable area, or the working area. But what recommendations you have in terms of improving the, the description. Well, I would rather start from looking into the code of each particular form say improved. Because, yeah, this is a key but we need to understand whether on the job configuration forms were changed or any configuration form. Yes, the description here says it's the job configuration dialogue we certainly look at. So this is a problems statement so basically what only experienced as a user. But, for example, the fix have included actually all forms in Jenkins. So I would recommend to just open file changes and to confirm that the scope of the fix was actually what is reported. So this is job configuration, then top bar, which is available for everyone and theme. I guess, so theme is likely up like to all forms. So if this just said increase with the forms on job configuration page is that do it. So basically any Jenkins config continue reference would have the same behavior, but the class was introduced only for one entry for job configuration so I think that the issue description is correct. Okay, all right. So, so what we bet seems like then it should be something like increase with the job configuration forms. Like screens. Ah screens okay all right. So is, is that what you're thinking like. Is that going to be on all devices. I mean on my phone that that might not be a good thing. Yeah, well it's, it's the code change was such that it's smart about device widths and if I remember it was using percentages so I think it should be even okay on the phone. So me and yeah this way I actually suggested in white screens explicitly because this is what the scope does. Okay so job configuration on wide screens. Okay so is it increased job configuring, or is it. Let me try an alternate loops alternate phrasing, expand job configuration to better use wide screens. No that's not not saying it page to display better on wide screens. Okay. I think I'm fine with it. Okay. Great. So make you okay and do you're as you're okay with first entry, the one that's highlighted. Yeah, yes. Okay, great. All right, so we'll save that when we do we want to say job configuration screen. Increase duration seems like not a screen. Okay. There. Okay, now I'm happy. Okay now I've got redundant use of the word screen on screens. Oh, is it should be job configuration page or work to me. But I'm careless with these matters form that works. Is that good with your leg. Okay. All right. Great. So let's go back to the change log then there were two items in the change log and then there are these that are comments so documentation is no longer in the wiki so rephrase labor so that label that's a documentation or a an online help update. Let me show you the content if there's worry should it be in it was intentionally excluded by the maintainer or the review the person who submitted it or the yeah Daniel Beck said this is too minor to to include in the change log. It's not like we have a big change log for the speaker. Yes, to two items so far. And then Jenkins test harness we typically don't include that friend for users they don't see it. Likewise the build tool for spotless. And this is a test fix. And this one is a dependency update so for me it looks like those two for right now are the right things to say yes to. I'm going to show you extra spaces before the world and move. Where do you see the word in the first in the first entry, the first entry. Somehow I'm not deprecated. Oh, okay. And in that case, it's, it's harmless because it will be rendered whether it has single space or two spaces. It will be rendered as an end of sentence by the web browser. Okay. Okay. All right so then I'm going to go ahead and mark this as approved. Okay, great. And in order to get the next chain that change that we just made. We have to run an action that changes lock so I'm going to go ahead and start that now. We don't have to wait for it to finish. But this way, it will update it. Okay, so change log reviewed and approved. All right so next topic then was dirage and upper balance dependencies testing our documentation and the ideas for improve a plug in your eyes you want to share your screen and look at it together how would you like to Yes, I will share my screen in some time. I'm just compiling it and reproducing the error. So, in the meantime, I can describe it. So can you go to get her and open the Jenkins channel. Oh, oh sure you bet. Oh, so here, you're okay if I share my screen and we'll look at the Gitter channel. Great. Yes, here we go. So here's the Gitter channel. And which which which of the feeds which of the channels. This one only is you need to scroll up. Okay, there's an image. The first image you see that is the message we're looking for. Okay, Jenkins slash Jenkins this one. Okay, yes, this one. Yes, and can you look at the messages which are in this thread. Sure. Okay, switch to Gitter and in the fire applies. And yes, this is the one. Okay, long message. So it talks and there's a pull request and it will direct you to the error that I'm seeing. Good. Okay, so let's take a look at that. Yes. And the error is in the console output. Yeah, here we go. Okay. Yes, this one exactly. So first of all, it looked alien to me. So then I read some articles to understand how to read this. So I found out that there is some transitive dependency problem going on some dependent on one other. So there's like two dependencies are causing the problem. First one is JNA platform with whose version version is 4.1.0. And if you look at all those trees that are there. It is pointing out to this version called 5.8.0 as well. So there's like different version for the same dependency. So maybe, so I'm just wondering maybe that's the problem. And the second dependency if you scroll down, it's for Java X annotation API. So it has a 1.2 version provided and then 1.3.2 as well mentioned in the below trees. So there's like similar problem, same dependency, but different versions. So then I read about how to fix it. Then it talked about that we need to give it like the maximum of the ones mentioned here. And then I was wondering where should I mention them because I was hoping to find the mention of these. Dependency in the form that XML file, but I was not able to find them. So the question comes back to whether my observations are correct. And if they are, then how do we fix the upgrade the versions of these dependencies so we don't see the problem. Right. Okay. So, so the Jenkins documentation that talks about upper bounds, let's look at that. Because I'm accustomed to doing a certain thing, but I think it'd be helpful for us if we look at what the docs say just to be sure. Okay, so sometimes you will encounter Maven enforcer errors. Your plugin depends on a component in another plugin. So, yeah, so this is a case where one plugin says it needs version X and another says no it needs X plus two or three or some, some more. Yes. And then the solution. Okay, so now it says talks about what the what the dependencies are. I get it's talking about what the classes of failures are. But here it says the fix is to update the get client plugin version and I think that's the most common thing that I've seen is the usual solution for me in these cases is not to reference where let's see let's go back and find that log. It's not to include a reference to this final thing in my palm if I can avoid it, but rather do my best to upgrade the other components that I'm directly dependent on to current versions. And that upgrade often will resolve the problem for me. So in this case you're talking about the plugins subversion to point one five point one. So assistant update this. At least that's been that's been my experience of, okay, when I do that. That's, that's the that's usually a desirable thing to do anyway. And when I do that it can I can get past so that it doesn't give me these upper bound dependencies errors. The other is I can use sometimes I've been able to use the plugin bill of materials as a way to resolve these kinds of error errors, because it uses a consistent set of versions that have been determined by the plugin bill of materials development process. So, so, are you okay if we do some experiments here or Oleg any guidance you want to give Oleg's much more expert guidance that currently plugin bill of materials should be used by default, because it actually results a lot of issues. I'm not sure about this particular one but the scope looks promising. Yes, that's a version plugin isn't in the best maintenance state. But there was a time to try to plug in bomb. I'm not sure why it ended. So, so, so I think Oleg's Oleg suggestion matches with my experience that. Now, now, dear, I was one of the challenges here is sometimes I'll encounter these messages when I'm trying to upgrade the parent palm version, doing something I think is relatively simple. And in order to get that relatively simple thing, I have to also use the plugin bomb and the plugin bill of materials. And so it's, it's sometimes I've had to do combinations of things in order to resolve these. And I think that's okay. Would you be okay if we, if we tried that as an experiment with with yours. Yes. So, are you at a point where you could we could switch and do some editing in your in your in your shared screen or would you like me to bring up the plug in and do editing on mine what's your preference. I think I can share my screen. Okay, great. So I'm joined from another laptop and I'm working on a personal one. So I'm sharing my personal laptop screen. Okay. Yes. So about the plugin bomb you were saying, did you explain it on the habit of this session as well. Yeah, I did. We at least we tried to explain it. We've tried to explain it in several different places. Darren, Darren Pope and I did a modernizing Jenkins plugins. Yes, I think. So the screen that I'm seeing right now is has has a camera view. So, so the, the screen that you're sharing looks like it may not be the one with your editor on it. Right. So it's, so this is the one with built on or plugin. Very good. Yes. So this is exactly where I was getting the error. And it's, this is the far maximum file for that plugin. Perfect. Okay, so now if we, if in your in your web browser, if you're willing to open, well, and I assume this does not have the plugin bill of materials in it. So open up a web browser on this same shared screen to Jenkins.io. And let's go find the instructions for the plugin bill of materials. Okay. See, I think it might be really slow. So if it is, can I request you after some time to do it on your screen. Sure, I am happy to do it from mine as well. If you would rather that's no problem is parameterized trigger trigger plugin. Yes. So plugin form Jenkins. Yeah, so, so depend that dependency management the second link down should be I think the one we want. The garage, the, it was the, the, it's a scrolled off the screen up above. Oh, no, yeah, up above. Actually, it's a, it's low. Oh, oh, I see. Open that one. Got it. Now, you might be able to not. It's still there. I'm actually on dependency management page. Okay, great. So. Yes. Okay, so this is the Jenkins core bomb. So scroll downwards Jenkins plugin bomb so click the hyperlink that's in that the C Jenkins CI slash bomb. Yes. Okay, and here I believe it's in the read me. Yeah, notice that that copy and paste is what we need. Copy that. Yes. So it's very slow. That's okay. Well, so, so while while we're waiting for it, if you're okay, I'll do some, some dialogue describing so what the plugin bill of materials provides us is a, a set of versions that have been evaluated together through a series of automated tests to be sure that they are, they work together with each other. And so that set of versions that the plugin bill of materials provides means you can simplify your management of versions to reduce the number of places where you have to declare a particular version of a dependency. Okay, so then maybe clean install command that we were running to check if everything works well or not. So even that runs some tests as well right. It does but for the purposes of this you can skip the tests by using minus capital big D skip tests. Because the that we don't need to run the tests for two in order to evaluate the, the plugin bill of materials. Okay. So should I paste this up to the properties. Yeah, I need to look to see where it belongs just a minute. I don't think it can go after the properties but I, I'm just lazy I go look at examples from others and use, figure out their placement. Okay yeah so it's a freestanding section that you could put right after the properties there. And there will be one thing that we need to replace online 229. We need a version with three dots, delete that. And we need to put in a different version number and I'll, I'm just going to paste the version number I'm using at the moment into the chat, so that we don't have to go do the look up. So. Oh. Okay, and be sure you get all of that string including that that very last underscore. Yeah, well he's doing that would you repeat that succinct little sentence that you gave about what the bomb is doing. Yeah, so well so the, it's probably best if I use the text as it's described so let me go there just a minute, because I suspect I'm probably describing it imperfectly. So, what doesn't actually. What the plugin bill of materials does is, it provides us a way to simplify the management of dependencies for common plugins. As an example, sometimes I want to use a pipeline plugin to create some tests for pipeline, but it's actually requires five or six plugins to do it. I have to then manage a set of version numbers that match to those things and work to get them all to combine together. What the plugin bill of materials does is gives us a predefined set of version numbers that are maintained and monitored and cared for by automated tooling that maintains the plugin bill of materials. So I'm basically delegating the hard work of finding a set of matching version numbers to somebody else. Have you been able to paste that number into that field and describe to me this for what you're putting in for the version I'm getting I'm going to do a PR when we're done here and fix that documentation. That's why I'm taking notes. Okay yeah so that that number comes from the, the releases page on the plugin bill of materials. So it's that number is just a plugin bill of materials release number. Okay, yes. You can check the PR and see what I screwed up. So now that I've pasted the version. What should we do next. Okay, so now we're ready to so search in the file for other tags of version, so less than version greater than. Oh, yeah so exactly so you're looking for that. And let's walk through each of them taking a look at them. Okay that one we won't touch. This is that one that when we keep that one stays the same that's the parent palm version and it's current. Then that one stays the same. So this is one that we can probably just in week, I think we can just delete that line 29 completely. Let the plug in palm, manage the version number for the plug in bill of materials, manage it for us so delete that line 29 completely. Search promoted builds. I think is included. Let's, let's comment this one out because we may need to come back to it. Okay, keep going. Conditional build step. And I don't think that one is covered so I'd leave it. So what do you think about this one. So the screens not keeping up you said it's a waitility. Yes, yes. So, I would try leaving that one. Well, I don't know. Try leaving it for now and let's see we'll we'll see if we one of the exercises I do when I when I'm doing these kind of things is I will typically. Oh, this this already has a plug in bill of materials. Okay, good. All right. So then then we were going to get compilation years let's continue looking. Then there's common land three. Don't know on that one is agent proxy connected factory. And I'm confident those are most likely not covered so keep going. And this is our. Okay, and notice that it's, it's alerting us there. So take take copy lines 227 and 228. And let's put those up earlier in the file. Okay. Keep going no no it's we need to find the reference to the bill of materials. What it is is there's already a plug in bill of materials referenced here. Yes, this one. So instead of bomb dash to start to 63.x, we want to put in there the 2.289 version that you had. So we're going to use a newer version. And, and now this means we've got to go look at the Jenkins dot version value. Yes, so it's still. Yeah, so change that to 2.289.1. And should we delete this dependency. Yes, yes. Now that section that we added, we absolutely want to delete. So I think the bomb is correct. Correct. The bomb is the bomb is 2.289.x but the Jenkins that version has to be a number. And so it's 2.289.1. So dear us let's try compiling this and see if it already resolves the upper bounds dependency errors. I'm just sharing my take time. So do you want to just leave this on compile? Yeah, why don't why don't you can go ahead and stop your screen share and go ahead and do the compile. And we'll switch to a different task. We'll look at the pull request that Meg has reviewed, and we'll come back to this is that's okay. Exactly. That's totally fine. Yes. Nice. Great. Okay. So then O legs. Oh, I'm sorry. Go ahead Meg. I was gonna say, when you're back to looking at the PRs, since O legs here. Let's jump down the list a little bit. There's two related to terminology. Oh, good. Okay. I know there's history and all sorts of fun things in there. I saw Tyler's name and. Okay, which of those would you like to look at first then this. 3362 and 2926. Okay, so 3362. I used the wrong, I used the files, but that's okay. Okay, so. So this is terminology and the question was, so is it. Oh, right. While it was blocked. We discussed it at the governance meeting at the time. I believe Mark was present there. Maybe not. It was long ago. So, basically what we concluded that we cannot say what is the official terminology in Jenkins, because there has been connected between Tyler's opinions and factor state in the code. We asked the documentation seek to review the case and come up with the terminology. This is why it was put on hold. Okay, so it's left to left to our recommendation as hey let's let's use this or that. So, one generally question we have basically two terminology matrices. One is on Jenkins glossary another one on the CDF glossary. And there is a mismatch between these terminologies. And, well, practically speaking I have never. Yeah, I mostly see people using job than projects, even though project seems to be more official taking the history of events. So, basically, the idea was that the documentation seek and the condition officer would take care about that and come up with a decision. So, so help, help me understand this so like the, the more common usage is the word job, I think is what you said right. I don't have statistics for that. And that's something we could we could test, but your your initial perception is it's probably, and now you mentioned the CDF terminology is there. Is there a one of these two that's preferred and the CDF terminology, one that's not or Well, the story of the CF terminology is actually so basically the continuous delivery foundation interoperability seek I believe they tried to modify the terminology. They created a matrix of different terms across multiple projects including CDF members and other CD tools. And the for Jenkins that are jobs, etc. And I believe it's basically because of me because when I was asked what is the Jenkins technology I provided the terminology we use the factor. And so there was a disconnect ever since. Okay, so, but, and so I'm interpreting from that that you would be okay with the switch from the word, the, the, the word project to the word job, because that's the common usage that you perceive and if we could have data to support that, that would be even better. It would be my preference, we can also give documentation to explicitly reference the synonym. For example, if you open the job term, it could reference project as a commonly used synonym. Okay. So basically, it's up to. Good. Okay. Mark, it's basically something for you to coordinate because it's documentation, it's maybe just making a call. Because I guess 99% of the community doesn't really care. But for users that might be beneficial to have. Good. All right, so but, and so it feels like this is something where my recollection of, I think it was Tim Jacomo observed that it's he agreed with your observation that job is the more commonly used term, and that project while it may be quote, more precise in the code or whatever, people say job and they understand each other more clearly when they use the word job. So that that makes sense advocate are they being careless. I've been, I've been, you know, and there's religious issues here, but I've seen a fair number where job refers to a freestyle job versus pipeline is a pipeline also a job. And that project is either a freestyle or a pipeline. I'm not necessarily arguing for that, but here you're looking at the class structure. Because in theory job is high level entity compared to project. But there is actually an interesting case because there is project interface which is inherited by job and then there is abstract project inherited from job. So, yeah, we just, we're just used to abstract project as a class because it's everywhere, especially in the security matrix we have a whole bunch of items that are grouped under job. Do those apply equally to freestyle and pipeline. I've never figured that out. It's because all rankings extensions so they can actually take the filter themselves to be sure so they apply. So, for example, yeah, there are many properties etc apply on the abstract projects on pipeline to both of them. We still have a lot of other project types which are less widely used. I wouldn't rely on the code structures source. I mean, that's the problem I think the terminology is really sloppy and it's. I don't know how we fix that without. Well, so, so Meg to the to your point on terminology. So I, I was I am quite willing to ignore the class structure, because I think users in general are not aware of the class structure developers maybe. I think are not and for me. I'm that's why I'm still biased towards job, even if the worry is oh that may be sloppy now, Meg to your example to your question here's, here's an exact text so in the downstream item here it's giving a definition of downstream. It's saying a configured pipeline or job which is triggered as part of the execution of a separate pipeline or job and so in that case it seems like it is acting as though pipeline and job are two distinct entities so I think it may be lobbying for what you were saying that this may job may mean freestyle or matrix or Maven and pipeline is distinct so, but wouldn't the correction here be to just converge these and say a configured job which is triggered as part of the execution of a separate job. And job means pipeline or freestyle or matrix or Maven. Or another option again not sure I'm arguing for this just it's a theoretic is that we could put in, we could make the glossary use the proper to my terminology of project and say that in common discussions project is often used to be synonymous to pipeline or job, or job or pipeline. I don't know if I like that or not. Yeah, I don't have my senses. Well, well for me job means the union of pipeline and I'm exactly opposite to what this is saying so this is probably me being wrong but job is the union of pipeline freestyle matrix Maven, even external job type is is a job. Oh like you're grinning and that usually means I've made a mistake. Go ahead. There is an edge case, because for example multi configuration job isn't a job. Multi configuration pipeline isn't a job. And in that case you're you're what you're describing I think is the inheritance tree right. You're describing the job inheritance where what all I'm doing is describing a conceptual thing the word job means something that So conceptually engine because we have basically job folder item as a generic case because you can put whatever crap you want tonight and basically that's it. Yeah, okay and and you just described it the way the way my mental model is that there there are folders, and there are jobs. Now you mentioned one other and I dropped it what was the. So there is item. So, for example, yes, so it's a generic abstraction level, which actually has multiple users. So for example, top level item. Again, speaking code is the item that can be put on basically the job list can be created as a job. And there are a few examples for that. So, for example, in Docker traceability plugin you can create an item for monitoring containers. What use case maybe closer to mark and make there is a vision inspiration center which actually does a lot of the things through items. And it's enter connect the controllers, share integration, all of the things implemented as items. So basically what it means that you can have them on the, on the list, but they need the folders, no jobs. And they can be buildable to make it fun. But yeah, it's a separate story. Okay, so so this one then needs. If if I take the conceptual model of Jenkins has jobs folders and items where items may be a folder is an item, a job is an item and there are other things that are items as well right so items is is a is a super set of both folders and and jobs and other things did I say that correctly. Yeah, that's correct. Then what's an object. Then it was fire. It's honest. No, make the right that there is object in class section, but I have never seen object as a term being used anywhere in documentation. Yeah, and I don't, I hope it's not even not mentioned on this page because I've, I that's, at least in my Java mind, that's such a generic thing that it's, it's almost a content free word it's a word that has no meaning it is so general purpose. Whoops, I know somebody who's used it all over the place. Okay, alright. You've had me cool late early on you know and I just strength whatever they handed me well and and good for you that's will we learn from it and go onward. Yeah, so that's why it would be nice to have terminology because yeah there are some misconnects and reducing the terminology just to three terms seems to be beneficial. Yeah, class structure in Jenkins is a pain. Some of the classes have never been touched for years. Well, and I think from from user comprehension, they don't they largely don't care about the class structure right they have, they have a relatively simple conceptual model and, and if we can use correct terms to describe that model, all the better. I still have one challenging case is abstract project, because we need a term to explain non pipeline jobs, but actually other non classic job types to. But there it wouldn't be enough to just say, say the specific job type this is a freestyle job or a, it's also matrix project, literally project, maybe in project, etc, etc. Yeah, in my presentations, I can find it, but basically I just do comparison so pipeline job type is what is not tied to the workspace in the particular node, while abstract project is tied to workspace and the node. And this is the key difference in terms of APIs. But again, it's API doesn't say much to users, and we often struggle answering the questions, even into 722. So I guess it's okay, what the plugin type or job type, the property applies to, and, for example, time out. It supports abstract projects and pipeline, but it wasn't the case before and every time you hit something unsupported or is limited support and documentation like and project, you start strongly explaining to users would actually can do. Okay, so thank you. I would really like to put abstract project here, I use a disclaimer, but it's a slang term or whatever, programming term, but yet I think that it's widely used in documentation. Hmm. Okay. All right, and that's because a plugin may support ways of modifying behaviors of a freestyle project but not a pipeline project, and it not a pipeline it may support ways of modifying a maven, maven project type, but not a pipeline. Exactly. Okay. All right. API extensions, they're specific, and we still do have many extensions in the Jenkins core, which you don't properly support pipeline because pipeline engine also doesn't properly involve them. So there are some decennials, etc. You always discover the case when you start refactoring the old plugin. But speaking of the terminology I think that abstract project, it would be important to include it here to some extent, because we cannot get rid of this term easily. And it's, I'm back to the I would, I was hoping to avoid abstract project is such a programmer concept but I think what you're saying is it's unavoidable because the separation of implementations means that I need a way to describe pipeline matrix project maven project is a literate project, freestyle project, each of those, and there are subgroupings of those and abstract project is a subgrouping that includes all of those except pipeline. Not all. Not all. Okay. All right, so, so, so it's, it's even more complicated than I was trying to describe it. Okay. Well, there are some other types, for example inheritance project, which is also an abstract project pipeline, etc. Yeah, if you want to deep dive, there is a lot of things, but I would like to have abstract project here explicit because it's an edge case. It's used all over the place. And it's really difficult to explain what it is without going into code. Okay, so, so we've got more to do here. And mega I'm afraid, I'm not sure that we've resolved it yet but I think the clarity oh legs given is that it's ours to ours to work the question, and bring it to a proposed. Okay, let's, let's try to describe this in a way that suits users, and, and does not obfuscate or does not hide things that are important. Right. Okay, well like thank you very much. I can't thank you enough for being here at this crazy hour of the night for you. Thank you so much. I would prefer to be asleep. I'm not Mac. Okay. All right. Yeah, but legs really sharp at like four or five in the morning and the only time makes functional that hours if she's still up so. Well, let's talk again tomorrow when I have a lot of meetings to attend. Then I think we can quickly look the second one I think is almost the same as this I'm not sure there's a difference. Okay. 2926 2926 Okay, so let's take a look at it. I guess. Yeah, it's the same basically the same story. It looks, it looks almost exactly the same did I did I thought I was that was exactly what I was seeing before. Yeah. Okay, they are there are two pull requests both touching the same thing in much the same way. Right. Okay. All right. We'll get them and get rid of both of them. Okay. And Oleg's name is mentioned on a couple of other ones do we want to. Oh, right. Yeah, there is a bunch of others. We just have a huge backlog of things, including various hackathons, etc. Which we actually needed to land or close because they stay in cacti if they distract people. They create much conflicts. Nobody actually knows what to do. I think this is some object for the documentation seek to figure out what is that approach. I think here. Yeah, so this, but it looks like makes makes attempting to start down that path of hey let's let's rationalize let's make these sensible. Yeah, so some bits are sensible, but well, generally, it's mostly work. For me, many of these beats are still related to we key immigration, because we still haven't migrated all the content we have the backup side. Now we also try to integrate Jenkins is the way to Jenkins. Which is a supporter of that. But it creates a huge technical depth for us, especially since Jenkins IO website runs on a legacy engine on its own. So we're still using a struct, which is basically not really maintained anymore. We created a pull request prototype, which would mostly move it to gets be but mostly is a keyboard. So finally, we ended up in a situation when we haven't fully migrated to Jenkins IO but we already need to migrate out. So, yeah, this is just something for the documentation thing seek to think about. I don't have advice except current few documentation developers to sort it in one year, which is not the case for doing this community right now. But that's the that's a kind of the kind of idea I think that you're you're right, we do need to just spend a significant time. We're working and yes a switch to Gatsby. That would certainly energize, energize Gavin and make the site more maintainable. So yeah, switching to Gatsby is a kind of controversial topic. Because Gatsby is really nice from the point of view of studying something new. But this is not a technology used by open source projects for documentation by default. They use, they use huger, they use docos hours, they use enter a specific special engines created for documentation management. Enter has a lot of benefits when you go after my old version documentation multi source documentation, because currently we still have an issue that Jenkins IO isn't really documentation is called. It's basically a separate repository and we just keep our fingers crossed that the plugin developers submitted them to purchase when they do something big. Not the keys. So, I, again, I do not really support more than Jenkins IO to Gatsby. You know it's nice prototype. I would rather suggest that we can see the standard documentation engine. Okay, good, good, good feedback. Thank you. But yeah, it's also part of the documentation technical depth. So at some point it's going to bite us because you're currently you see a lot of open pool requests. So in the current state Jenkins IO becomes less and less sustainable. Right. Okay. So, I'm, I'm mostly out of time here but I wanted to come back to dirages situation dirage or make or is there more that we need to do here. No this is just sort of a running list I'll go back in and rework it and. Okay. Okay, go ahead Oleg. I just want to think in the case you missed that race me run list, depending down from the continuous delivery foundation. What it means in practice for the recommendations you can call the Jenkins you that the foundation is basically down to one and a half. At the moment, including call things marketing product management, keeping clients on etc etc, which means that you have the right independence is like vocabulary etc just no product program managers who could take care of these demands. So, it's also something to keep in mind. Yeah, so, so the guidance there seems like we should just operate independently and asynchronously and not panic if CDF is overloaded and unable to help us with something that that we might want to help. The project that we will need to be a part of eventually is the events specification, but CD events specification is all that we accept it as a incubating project to the continuous delivery foundation. Well, I participate in the meetings when I can. I think it's an initial marketing to cloud events plugin created by Google summer of course last year, but it's definitely the topic that we will need, we'll need more attention. If you want to support CD events out of the box. Got it. Okay. It's not a project again, but yet the problem that timeline for specification is also not clear. Well, we want to have preview in one month or two months according to the initial roadmap, but with CDF basically being organized seems to be less probable. Okay. All right. Raj, are you at a point where we would like to switch back or should we conclude the session let everybody disconnect and you and I will just pair program on your, your question how would you like to approach it next. Yes, I think that would be great if we have debug the problem with one on one session that others don't have to go through this unbearable process. Okay. So I'm, I apologize, I need to take a brief break. So if you'd be okay if in about five minutes you and I could reconnect and and we'll just go through it together if that's okay. Okay, and I'm going to write up a little PR later tonight that captures what I saw just a couple of sentences but I this thing of, you know, it's just like see the repository is not really useful documentation. I think a couple sentences there, and then you guys can fix anything that I missed. This is on the plug in bomb. Yeah. Okay, great. So nice to meet you all like this is the first time we are meeting right. Yeah, well this meeting time wasn't particularly convenient for me. It's, it's, it's now 830am in India I don't know what could possibly be bad about that or like. Well, it's 4am in my time zone. Yes. It's time though it's crazy. It's yeah sorry completely insane. My shoulder is just hurts too much so I can fall asleep anyway. So we can continue synchronously. Yeah one thing that currently I receive a lot more GitHub pinks than I can process. So if you need something urgently etc don't hesitate to drop an email. It's, well, not something we usually advise for the drinks community but yeah right now I'm still a bit overloaded. So thank you for all that you do like much appreciated and and good luck in all the things. Okay. Yeah, I'll probably follow up with you later so I guess time for to find this in God. All right, we could say vice versa you're free to just shoot if you don't have to kind of show up to shoot something to us with you guys straighten this out. Absolutely. If you've got a sync email is certainly welcomed. You're no problem. Well they still have Jenkins welcoming to Jen say also likely use of that if it's not urgent. Okay. Okay, so yeah have a nice day evening morning. I'm sure. See you. All right. Okay so dirage you and I will connect what I'll do is I'll probably just send you a message through getter to to a zoom link that I'll establish here in just a few minutes. So we leave this meeting and then we'll rejoin after right we'll end this meeting in about five minutes. I'll, I'll post a link to a new meeting and we can record that new meeting as well so that if, if we find it's helpful. We're welcome to post it later but but I think it'll be more effective if it's just you and me and we, we can then decide okay should we put it on Mark's computer should we put it on yours etc and talk through it. All right. So, thanks everybody Meg thank you very very much. I'm going to go ahead and this and I'll be back with you in about five to 10 minutes dirage. Okay, I have a PR by tomorrow so Thank you Meg. Thanks very much.