 Welcome, this is the Git Cash Maintenance Project, Google Summer of Code 2022, it's the 24th of May. Thanks for joining. So topics I had on the agenda, goals for community bonding, scheduling, scheduling, and status report on open poll requests. Are there other topics that either of you would like to be sure we add on to the agenda? Okay, then let's go ahead, I think, and get started with the goals. So, Khrushikesh, welcome. We're so thrilled that you're part of the Jenkins Project and congratulations on being accepted by Google Summer of Code with your project. That's really great. Thank you very much, thank you both. I thank all the mentors for giving me this opportunity. Excellent, well, and we're delighted, that's great. And I can vouch for Rishabh as a mentor. He mentored last year and was exceptional. So we're going to have a lot of fun together, I'm sure of it, and we'll look forward to that. You are each welcome to make edits to this document as we go through it, by the way. So I think our goal is that we wanna be sure that you are ready to start coding by June 13th. Now you can start sooner than now, but we wanna be sure that any problems or any surprises that we can predict and can prevent, we should. So we wanna be sure that you're comfortable with us as mentors, comfortable with how we do code review. Rishabh reminded me last year that we need to be sure you're comfortable with test-driven development, because even if I don't tell you about it, I'm going to demand that you practice it. And so it's much more fair if we tell you about it first before we demand that you practice it. And be sure. Is there any way you know to practice or something like any kind of method like where I can learn test-driven development because I've gone through some videos before. Actually, if you've reviewed the videos, that's a great way, that's a great thing to do. So for me, it's, let's see, it's write a failing test, write the code that fixes the failing test, refactor, and they like to use the word mercilessly to simplify the code, commit. Now, you might at that point also push, but at minimum you commit and optionally push so that CI evaluates it. Now, you may say, well, that's odd. Why did we start with a failing test? There's no code written yet, right? There's not. Write just enough code to fail your test. Maybe it's a stub method that does nothing and your test asserts that it should do something and your test therefore starts failing. This right, and the best way to get good at this is to practice, right? It's no one expects that. And I have to admit that the Jenkins code base is frequently not well suited to this methodology. And I wish I could say differently, Ruchakesh, but I can't. Rishabh has lived the experience of, oh my, how do I write a test for this awful thing which is buried deeply in the middle of nowhere? And it's hard work. So don't be dismayed if at times you say, I don't know how to do what Mark was saying I'm supposed to do and you have to explore a little bit. Rishabh, what other counsel would you give on this test-driven development thing where you had the unfortunate privilege of discovering that Mark somewhat fixated on this? I think there are two things to say about test-driven development. First is that while you try to figure out how to fail a test or how to write a successful unit test case for any type of code that you really write, you understand or you realize edge cases that you might not have thought about. So I would say just thinking about the code would never give you the edge cases. You have to write the test, you have to write a test case in order to be able to realize that there might be issues that you may miss while you're just thinking about it mentally. So that is the first thing. Second is that what I realized was when I entered into the development cycle of this particular plugin was that your feature submission to production that is to release to the audience is not just you designing the feature and then ultimately merging your PR. It's going to be thinking about a lot of tests which are going to validate whatever scenarios that you've thought about, you've discussed with us. Essentially, whatever expectations that you have and your mentors would have and would verify those have to be codified in the form of a test case so that it is a real proof of what are the scenarios that we have thought about. And we're sure that would not create an issue when we release this particular piece of code. So it was a really great and different learning experience for me in that sense because I in my personal experience at that time had not worked extensively with this methodology. So to reinforce what Rishabh is noting the Git plugin is installed on 285,000 controllers. Many of those controllers are business critical. Are critical to the business that they support. And if we break it, if we break it, they will shout. And the other, why would we spend all this energy on tests that validate useful scenarios? It's that people expect behavioral compatibility from version to version. It's not just API compatibility. They really expect that we will continue to behave the same way as before and for their use cases. So it made things particularly interesting. Well, in your project, Rishikesh, you're going to change behavior, right? We are going to be doing cash maintenance. And that behavior change, they will want that it's almost invisible to them. They want, they don't wanna know that they just wanna get value from it. They don't wanna know that it had to do something. And so these tests will help. And now this is different than if we were a brand new startup. Sometimes brand new startups don't write a lot of tests initially because they may throw their code away, right? If you're gonna throw it away, you don't ask, especially benefit from tests. But this code, we don't expect to throw away. And because we don't expect to throw it away, we need the insurance policy. We need the added confidence that it is doing what we expect. The other, I guess another benefit of tests is that tests help us check multiple platforms. Windows, Linux, BSD, macOS, et cetera, and multiple command line Git versions. And this one is the, you've already been experiencing this one, right? In your developing every documentation of your plan. It's like, oh, Git 1.8 is a very different Git than Git 2.35, right? They have completely different characteristics and yet both of them are very important in the Jenkins install base. So that's probably a terribly boring thing that we just made you go through, Ruchakesh. Any questions that you have on that? No, no, I've got an idea. So I'll look into it once again. Great, all right. Okay, so then I think now we will need you to be confident sharing updates during office hours because periodically we want you to check in with the office hours and say, hey, project is going okay, or oh no, I've got this problem, I need this help. And office hours is not really the place for technical problems with your specific project. That Rishabh and I will do with you in our own team meetings. But if you've got something where, hey, if Rishabh or I are being inconsiderate to you or unkind or rude or offensive, those are things you would absolutely bring to office hours or bring up separately in another message. So Rishabh will not be rude to you, I promise, I know him. Okay, so next topic then, the checklist from the org admins. So this will give you some experience submitting a pull request to Jenkins.io because we need to get the project details updated on, so here's the PDF I linked to it. Let's make it big enough so that mortal eyes like mine can read it. There we go. Oh no, it says mentors to update project details. Interesting, okay. So Rishabh, do you and I get to do this? Is that what they're saying? Probably. It says mentors to update project details with contributors. Okay, so what we need is we need a combined pull request to Jenkins.io to describe the project. Maybe this is one that it would be healthiest if I did it and Fushakesh, you and Rishabh were reviewers of it because that may allow us to have another voice. You wrote the original draft of the project plan, right, Fushakesh? And because of that, you know it best, but if I describe the project details in a pull request, that gives you a chance to say no, Mark, you misunderstood something. The document says this, you said this other thing. So maybe we do this as they said it with mentors, right? And then in parallel, you're becoming familiar with communication channels, et cetera. We're practicing that good communication that we need. Okay, can we create another channel separately for the deep maintenance project? We can, although given how low volume the Git channel is already, I would be prone to just use the Git plug-ins channel. That's a good question. Let me see if I can find it. I'm not even sure it's, oh yes, here it is. Okay, so good question and let's put it into our notes. Where do we talk to each other? And I think I would suggest is the previously used channel. Now, Rishabh, how did that work for you? Was Git or okay? Or would you prefer Slack? Because we could also do it in Slack if that's easier or, and Rushi likewise for you. What works best for you? I find Git is very comfortable and convenient. I have an app on my phone also, so I keep that profile and the phone also. That's very convenient for me. At my time, Mark, I remember in 2020, we did not have the option to, we were not using Slack. I don't believe we were using Slack and Jenkins. So Git was the primary channel that we used. And it was, I didn't face any problem. Okay, good. So then let's just plan on the Git or channel as our preferred chat channel. Now, in terms of, we probably also should choose an async, how would you say it? A more permanent channel. And I'm not sure if we need it, but I would prefer on the more permanent channel to be something on community.jankins.io. But I'm not sure yet what cases we might need that for maybe for Roshikesh's status reports if we want a periodic status report, those would probably best be done on community. So on community.jankins.io. Now, Roshy, have you registered with, and is Rosh, do you have a preferred way we refer to you? My use of multi-syllable names is pretty weak. Well, Roshy is fine. Okay, Roshy is okay, good, all right. People call me Roshy here because it's a very big name. Okay, great, all right. So if we did a more permanent communications on community.jankins.io, would that be okay with the two of you? I just, I wanted to ask Mark, at community.jankins.io, it's a thread-based communication platform, right? Do you write threads and you post something and then you have threads where people are communicating. It's not a conversation-based platform, right? Have I not explored that yet? No, I think you're correct. For conversation-based, we would tend to use, for chat kind of things, we tend to use Gitter. Okay. And the threading, the thread system now, now we're going to move the documentation SIGS mailing list and the platform SIGS mailing list to community.jankins.io because it has facilities that are actually better than the groups, the Google Groups mailing list system. So for that kind of thing, where if we would have exchanged email about it, I would prefer to use community.jankins.io. Okay. So, yeah, so it's a replacement for, let's talk about what it's a replacement for, replacement for mailing lists. And it's an easier place to post blog-like items. It's much easier to post something to community.jankins.io than to submit a blog post to www.jankins.io. So we don't do that, Magno? Oh, no, no, we will. We will still do that. But that will happen later. That's not a systematic do it every time, right? I think you had to do three blog posts. I was just looking at your blog posts actually. And Prussia will need to do three blog posts to www.jankins.io. So he will have the experience, but I think we can be more effective if we use community.jankins.io even for draft blog posts, say, you know, those kinds of things. It's, hey, I've got this new thing I wanna show you. And here it is, and people could go look at it, or oh, here's a little video clip I recorded that shows this thing, something like that. Or for polls or opinions around that, right? Blog posts related to the project itself, like what I'm going to build, like write a poll. So ask your question again, Prussia, I missed part of the phrasing blog posts related to the project. Like related to the Git maintenance. Do I have to write that? Like how did I process it? Yes, yes. So you'll be, those will be written to www.jankins.io. And it's, you'll get some new experience there because you get to learn what it means to use ASCII Doc and content management with GitHub. Let's get that as a hyperlink. Okay, so I think we're okay here. Any other topics on checklist from the org admins? So there's certainly more to be done there. We need to be sure we discuss how we're going to divide time over the next 10 weeks, breaks and vacations, but that's later in today's agenda. Refine rid of the project plan with deadlines and milestones. I think that's also later in the deadlines or later in the agenda. Yeah, bug reporting. So Prussia, are you comfortable using issues.jankins.io for bug reports? You've already picked up one or more issues from it and used and submitted pull requests related to those issues. Oh, isn't that Jira thing? It is. Exactly. It's the Jira thing. Okay. Yeah, yeah, I'm fine with that. Great. Okay. All right. So I think we've been through the checklist then. Now the next piece then I had on the list was the plan for presentations and this is, this is Prussia can tell you really about it. It's we've, we like to have a phase one presentation for the, about halfway through the project that highlights accomplishments up to that point. Then we like to have a phase two presentation. So this one, I think will likely happen in. Junior in like late June or early July. And this one happens then in, is it late August or early September? And the idea was you show, show, show the results today, share what you've learned, encourage people to use it. And if we're, if we're really fortunate, we will have already released the first version of the plugin that includes some portion of your work. So it's, it's just a way to, so you're going to write a blog as well when your phase ends, right? So it's just a way to say all of that concisely and just advertise what you did in the, in your first phase and all in the second one, whenever the presentations are. Right. Exactly. And, and this presentation I would expect will also be in a Jenkins online meetup where you and each of the others will present their, their, their initial work. Rishabh did it. We, we point to those videos periodically. Hey look, here's a description of what was coming. Great. All right. And localization is the wrong way to say internationalization. Okay. Good. All right. So next topic I had on my list was scheduling. The GSAR timeline. Oh, go ahead. Question. No, no, no, I don't have a question. Okay. Welcome to community bonding. We've got until June 12th to do preparatory things. And then June 13 coding phase one starts. Coding phase one ends and then phase two starts July 25. Then September five is the final week for submission of final work and evaluation and Rishabh and I submit final evaluations by September 19. Any questions on the GSAC timeline? Okay. Good. Meeting dates and time. So this is the crucial one. I'm still embarrassed that we're meeting at 10 30 p.m. your time. What time works for the two of you? For me morning, morning in the morning at around 8 30 to 9 30. Okay. So 8 30 to 9 30 a.m. 8 30 to 10 30 a.m. are good times for, for Hushi Rishi. Rishabh. I assume you're at work during those times. And so those may be really uncomfortable. So I start my work from nine on 9 30, but it depends. 8 30 to 9 30 something that I can manage. But if that is not the case, then this time 10 30 to 11 30 would not be a problem. Any nighttime would not be a problem for me. Okay. So, so hang on. Let me, let me make a note of this. So, so it's 8 30 to 9 30 would work for you. And you say anytime after. So 10 10 10 o'clock p.m. or later. Yes, works for me. I can, you know, even I can have a meeting around and that's like, not an issue. Okay. So you say that again. So which you say. I can, you know, I think we check 10 13 p.m. Okay. 10 p.m. or later is okay for Hushi. All right. Good. Okay. And so for me, the, the, I think actually the 8 30 a.m. to 10 30 a.m. And by the way, we should be very clear on what time we're talking about now. Okay. I think that's a standard time. Because that way. I make sure I'm asking you in your local time. I can do the transition because it just happens that I'm. Almost always 12 hours away from you. Okay. So, so the. For me, it would be, I think it's easier for me if I do. And that would need to be Monday. Tuesday. Or Friday for Mark. If not. So 8 30 a.m. Monday, Tuesday or Friday. Let's see a lady's like, I've got to check. Okay. What, what day of the week is it for you in your time zone? Today is. Is it Wednesday? Today is Tuesday for you. Okay. And so today is, so we are on the same day right now, but when we switched to 8 30 a.m., we're offset by one day. So for me, yeah, so for me, it would be 8 30 a.m. Tuesday. Wednesday. Or Friday is horrible because that's. Yeah. Okay. Wednesday, Tuesday, Wednesday, or. Wednesday. Yeah, skip Thursday, Thursday. Thursday evening, your or Thursday morning, your time. I have a personal appointment that I cannot break. And so I'm unavailable Thursday morning, your time, but I could be available Friday, Tuesday, Wednesday, or Friday. And if we had to, I could be available Monday, Monday, but I started to like to leave your Monday morning available for personal time because it's the end of my weekend. And so, so in terms of would one of these days, 8 30 a.m. Tuesday or Wednesday, be better for the two of you. It's fine with me. All right. Both days, I don't have a problem. I don't know Wednesday is like in between. If that helps you to she case, then probably we could do that. But yeah, I don't have a problem with Tuesday or Wednesday. I don't have a preference for Wednesday because it's exactly the middle of the week. I like that. That's, I think that's a reasonable idea. Okay. So, so for now, then let's let's start with. Let's propose then Wednesday. 8 30 a.m. IST. Now the challenges weekly meeting sometimes aren't enough and we may need to but, but my sense was let's go with one for now and see how things evolve. If that's okay with the two of you. Now I'd already like to start this one this week. So today, now you say it's Tuesday for the two of you. Yes. Okay. And it's Tuesday for me because I was riding a bike yesterday was my birthday. So I went and rode a bicycle yesterday for more kilometers than my age, just to be sure that I'm still tough enough. I'm not going to talk about my age because my children give me a hard time about that, but okay. So you do that in one, one minute without stopping. Yeah. Well, okay. No, I stopped for, I stopped for lunch because it's five hours of riding. Let's not talk about, let's not talk about the number there. The number is a bad thing to discuss. I'm not, I'm not 25 anymore. I haven't been 25 for a very long time. All right. So Wednesday, 830 IST and I propose we already do it this week. So it means we'll meet tomorrow just to test and we'll make sure that whatever topics we've got to discuss, we discuss them. And then each week we meet now, then we need to talk about, is that okay for the two of you? Yes. Yes. All right. Okay, so then outages. So the time off. And this is where we've got an awkward one. I'm planning to be out next week, but I could attend the, the 830 a.m. Wednesday. If you don't mind that I'm dialing in from another location, and that I'll be using my Chromebook. So my sound may not be great, et cetera, et cetera. But I'll be fine by that. But if you want to, if it's a vacation for you, then you should enjoy it, Mark. Well, if, if the two of you are willing to, if I remember right, Rishabh, I don't think we've given you the, the, what do you call it? The zoom, zoom account password for the Jenkins zoom account. Right. So you would have to find some other way to meet or you'd have to meet with just the 40 minute time limit that zoom, zoom does for their free accounts. I have a premium business, whatever they call it. Oh, you do account because of my company. Yes. So I, I couldn't host a meeting. Okay. All right. So Rishabh host, host the meeting next week. Good. Excellent. Okay. Then, then I will, I will plan to not attend and just let the two of you meet. If that's okay. Yes. Great. All right. The next week, I think I can meet because we're choosing to meet at a time that would work. So it's not that I'm unavailable because we've chosen a time that is late evening in the United States. I won't be at the conference. So, so Mark will attend from. Great. Then this one, I promise I am not available because I will be having too much fun with my grandchildren. Okay. Rishabh, any outages you need to help us plan for? I don't have anything right now. At the moment, I don't have anything planned. Yes. Okay. And then Rishi, you've got exams, August one to 12. So we assume that's completely offline. Yeah. And semester exams. Right. Okay. Now, now I think you can easily still fit in the 175 hours expected with this time off. That's not a problem. Just, just be aware of it. That 175 hours is roughly 20 hours a week for the 12 weeks. And, and that I think, well, if it's a problem for you, please let us know. But as far as I can tell. I don't have anything planned for this year with our, our, our participant then. So I don't see any problem with that. All right. Anything else on schedule? Oh, go ahead. No, no, I just said yes. Okay. Great. All right. So anything else on scheduling then before we go to next topic. Okay. Next topic status report on open poll request. This is the shame on mark section. These. These are the poll requests that were. This was before submitting the proposal. Correct. Yes. Right. So, so these are, these are the evidence that Roushakesh knows how to do a poll request and knows how to interact with others in the community. And they, they are very good evidence. Now there's, there are some complications on this one because Roushakesh chose to do some renaming and it's, it's a little more difficult for me to do the code review because of the renaming. But the reality is that's a perfectly fine choice. What he did made the code actually look much more like Java tests than it did before. So it's a nice improvement. It just means that code review is a little more challenging. I think the answer here is this one is actually a fairly easy merge. More challenging code review because I don't want, I want to be sure that we didn't lose any test methods. So this one needs, needs interactive testing, deeper checks, and then should be easy to merge. And I think the browser guess or improvements, there's some design or some breaking. Yeah, that has a breaking change actually. So there was another method suggested, but I haven't gone through that. So that is still pending. But actually, I've completed, I have completed. There's a breaking change. So, right. So, and, and truthfully, this is not, this one is not the focus of our project. So if it never completed, that would still be okay. Right. You, you gained experience from doing it. The experience is beneficial. But if this one, I want to complete just because I very much want it. This one I'm less worried about. And this one I'm not worried about at all. They, they guess we would like to get that one in, but being a, a breaking change is really difficult to do to the get plugin. We've got to be sure that we preserve compatibility at all sorts of levels. All right. So those were the topics that I had. What other topics do we need to be sure we discuss? So then I, I think we don't need to discuss setting up the local and set up for working with the get plugin. Because that Hrishikesh would have already done as he was working with the BR. I have already set up for the, you know, the plugin get line, get client, the only, the only thing that I've even come up with an architectural diagram, you know, a classroom diagram. But, but I'm not sure if that is, you know, know, an efficient way or is it the right way to go ahead with? So I don't know how do I proceed with that? And I have not found class diagrams particularly helpful personally. In this particular case, I'm more concerned, Mark is more concerned at the parts that I don't understand. And that includes things like how to do a lightweight process on the Jenkins controller that isn't a job. And the example is there's this thing called the global build discarder that does something similar. What it does is it iterates over all jobs in the Jenkins controller and applies a build discard rule to them. So it's not a job, but it's doing some work and because of a potentially enormous number of jobs that could be defined on a Jenkins controller, it has to worry about how to keep the load acceptable on the controller and when to schedule it and when not to schedule it. And my thought was maybe we ought to, should we ask the author, the author of the build of global build discarder to talk to us about the problems encountered, the techniques used, etc. Because I'm worried about this. Okay, everything I've done thinks about a job and has a workspace, right? And does has all sorts of infrastructure that the get plug in where the get plug in lives. But this automated cash maintenance really shouldn't be done with jobs because we tell people quite rigorous that you must not run jobs on the controller. And therefore, we've got to have some other method. And my thought was this is one that's worth exploring to be sure we understand. And you may ultimately end up with an architecture and class diagram that describes it because you need to know which classes do you inherit from. But the key question is not what's the class diagram, it's how do we do this lightweight process on the Jenkins controller and do it well. But by jobs, do you mean any kind of process? Or what does job mean? Oh, good question. No, yeah, so I should be very, I should be much more clear when I use that word, right? A Jenkins job in this case is a separate entity that extends from the Jenkins object whose name is abstract project. So when I say job, I mean something like this thing right here, this one master this has a series of executions that are run that I will use the term build to describe those. It's represented in this build history. And this thing at the top called the branch master is a job. And this job is where I do almost all work on my Jenkins controller is in one of these jobs and I have thousands of these configured. But you do anything with the job, like can you run anything with it? Like any kind of process program? I can't build programs. Okay, absolutely. I run this particular job runs the Maven program. I've got other jobs like, let's see this one that runs ant. I've got this one that runs a shell script. I've got this one that runs a power shell script. And they can they can run anything. So so yes, a job, a job is this generic do something for me. So Mark, I had a question. So when you say that this lightweight process, I what I wanted to understand about that is that we is in a Jenkins ecosystem, do we have an extensible, do we have a way a hook or anything that I can, I could extend to and create my own processes apart from a job, like a process. Yes. Yes. And that's the thing that's so important here. So so Rashab, I think you're asking, can I create something that will do work for me without using the concept of a job? Job. Yes. And the answer is yes. And that's this thing here called the global build discarder is the example I have. And I'm sure there are many more, but this was one that I arrived at not long ago. If I look here under manage Jenkins configure system. So build discarder is an example of this lightweight process that can be built within the Jenkins ecosystem. Exactly. And that was the thing I was thinking of is, okay, we've got somebody who has created code that we could review to see how they did it. And we might even after reviewing the code that see how they did it, we might ask them, please come tell us some of the things you learned by heart experience so that we don't have to learn the by heart experience, we can learn them from yours. So so the global build discarders is a concept that what happens is normal build discarders run after a build finishes. So a job, a build runs. And then the build discarder says, do have I got too many records too many builds recorded, if so delete the oldest. This thing says, look at each jobs configured build discarder and apply the changes, even if the build did not run, which means it's executing independent of the build. And I think that's the kind of thing we need for for get cash maintenance is we need something that is independent of any build, but that we can control that who she's code will control and say, I wanted to run roughly weekly, or roughly daily, or roughly hourly, that that kind of thing. But but who she's code will then have to have to do things like roughly hourly, but don't overload the controller. Yes, roughly, roughly weekly, but don't saturate on exactly midnight on Sunday morning, something like that. Good. So this would be a reference point for us to see Yeah, that was my thinking was use this as as an example. Now it does it does something wildly different than what we need, right? It iterates over every job. And we don't need to do that. We will iterate over each cash and decide to do some things. So so it's it's but but the concept is it's scheduling work and doing the work without actually using a Jenkins job to do the work. So I I was under the impression till now that we would use the existing UI infrastructure that we have for a job. And that is somehow where there we would add another option where a user could check the maintenance tasks or whatever is happening. But with this separate process that I see listed here, I don't know if this is can I use the existing UI infrastructure that I have, which the user sees on the Jenkins homepage or at the settings level. Can I use that? Or would I have to create separate views here? Would I have to build those things? Because that hasn't been done. I don't know if Global Build Discarder has its own page. At the job level. Yeah, well, that's that's actually it's a good a good question because and we may need to bring it up tomorrow to get further on it. Because what build what Global Build Discarder is doing is it uses the configuration inside the job to define what it should do. So it does in fact look at the job pages configuration to decide. However, our caches could be used by many, many, many jobs. And it's the same cash in every case, right? We've got a cash for the get plugins repository. And it's used by 25 different jobs that all evaluate the get plugin in different ways. And so my thought was we needed to use to put the configuration of the cash maintenance at this level at configure system, or possibly do our own page here in manage Jenkins like label implication does or like global tool configuration in one of those two locations. And I was sort of biased towards putting it at this top level just because this configure system page is so slow to load and so big. I'd rather not put one more thing on it. But but I'm open to either. But my thinking was it would have to be at somewhere where the system configuration level not at the per job level. Excellent. Now, I have it out here. So assume like now our Jenkins has around 100 repositories, very big repositories. Will this build whatever you have stated, will that automatically decide which cash it has to take and which it should discard so that it doesn't overload the system? I think that's its responsibility is try to find a way to not overload the controller. And I'm not. That's why I thought we might benefit by a conversation with the build discard or implementers because they may have ways of identifying when is the Jenkins controller idle on average. So we could we could cheat and use that information. Oh, it shows up that it's mostly idle for this one hour window every day or it's mostly idle for this four hour window on weekends, those kinds of things. And my hope was they might be able to tell us, hey, we did it this way, or they may say, Mark, you're crazy. We did no such thing. You just set it up to run and let the administrator handle it. That would be, I think, much more smarter way of doing it rather than exposing a schedule for it. Because this in this way, we're doing the operations very intelligently with understanding of the existing state of the system is and then figuring out when we should run the maintenance operations as compared to an administrator would have to then think the same and not maybe not everyone is thinking about this. Yeah, I don't object to us giving scheduling ability to the administrator, but I like the fact that Jenkins very often will give me the option to say schedule at any time in this hour, right? It's it's and it it applies some logic to decide how to avoid piling everything onto a single second when it schedules a whole bunch of work all at once. Because these the optimization, the cash management that Rushi is going to do should be safe, right? It should be safe in the sense that we intend to do no no destructive change to that repository. It's it's cash, it's garbage collection, right? It's fetching without updating the local references. It's those kinds of things that are that should be harmless. And therefore, they're not going to see it as negative. Rather, we made their things faster because it's it's got stuff locally now that we retrieved over the weekend, that kind of thing. I apologize. I'm running out of time here. Does we'll meet again tomorrow and we'll meet tomorrow. I'll get the meeting scheduled for tomorrow as we've agreed at 8 30 a.m. India Standard Time. Okay, if we meet tomorrow and we'll continue the discussions. Yes, ma'am. Rushi Kesh, thank you for joining the Jenkins project. Rishabh, thank you for continuing your contributions to the Jenkins project. Both of you. Thank you very much. Thank you. Thank you. Recording of this will be posted. I'll actually post it to community dot Jenkins dot IO so that we have a top level place to start. And I'll also post a copy of the notes. Thanks to both of you. Thank you, Mark.