 The next thing is on. Welcome everyone this is May the fifth 2023 it's the get lab plug-in modernization. Welcome to the community meeting. All right, so first stop was a meeting with all team members to be sure we know each other and show personal expectations and goals. Let's start that so harsh you want to go first. Think about yourself. Currently a freshman at an Institute of Technology Kanpur, and I'm actually going to code. I actually started learning Java from January, during the midst of my exams, and I started finding organizations, a little bit of books, and I found Jenkins, and I thought that it would be better to learn it. And then I started contributing and I got into GSOC somehow I was not even expecting it but yeah, grateful. Great. Welcome to the project we're delighted to have you frame you want to go next. Right, I would just like to find out that I love his enthusiasm as well, you know, the fact that like he's so excited to be here. And at the same time. Yeah, so who am I, I'm frame, I'm going to be in this project as well. I don't really have any expectations from you I mean I obviously do have some those days and expectations that like, you should fall in love with open source that you have to complete the project within the set amount of time. But at the same time I have this one very specific expectation that is just communicate with us because I think this is the most important about the entire project and this is something which is going to help you throughout the career it's not just for the next two months it's also going to help you throughout your whole life. So yeah, that's kind of about it if you ever have any like, even the smallest of the patients feel free to ask any of us. Thanks for him. Chris, do you want to go ahead next. Yep, sure. So my name is Chris, I'm based in Hong Kong currently and I'm a software engineer. I've been a software engineer for at least I think three years. And I think for expectations, I just want to have a successful outcome, and I'll do anything possible to assist in that goal. Thank you, thanks very much Chris. So I'm Mark, I'm, I've been doing software for a while, and I'm very interested in get. I have some interest in the get hosting providers because of my interest in get, and not as deeply experienced with get lab as I'd like to be so I'm going to use this project to be sure that I learn more that I understand better that I've done some exploration. I'm going to be sure that I'm configured with interesting configurations in my Jenkins test environments, so that harsh when you create some change. I'll be able to look at that change read it from the code perspective and then deploy it into my production environment, and complain to you if it's broken. And that's okay we're going to have those conversations. The primary role will be one code read code review, so that we can see and discussion review on things that you how you're approaching things which things you're doing when etc. You're the implementer, and we're here to help. But that help from my case will probably be strongly oriented on testing to be sure that I understand what you're doing. On code review where code review is is vital and healthy. Chris has also got lots of experience with the get the get lab plugin, and we'll rely on his help there as well, looking for defray I'm also being part of that review process. Any any questions from anyone on any of the things that have been said so far. So what would you like to do. First, the code base that I'm going to write is it going to be test driven development or is, or should I try to make the thing work in production first and then adapt those tests. Oh I love questions like that that's the way you're trying to seduce me with really good questions very good harsh way to go. I am, I am strongly in favor of test driven development and have been repeatedly proven that I probably don't do enough of it. So, so even as strongly as I believe in test driven development I want to do more of it. However, and this is the dangerous however, I have to confess openly that the Jenkins code base sometimes is not well suited to test driven development. And it is our ultimate goal is deliver real value to users. So that's the first thing we want to be sure it works. I love having tests I love having I grumble if we get new code that has no tests to check it. Right because that that makes me worry oh now I've got to test interactively and I have to test it interactively every time we release a new version. And so I like tests, because they give us confidence that we can release the next version and the next version and the next version and we didn't regress it. Now, that was kind of a cheat answer harsh because when I say, I like test driven development and I've done presentations on test driven development and I live test driven development personally. But still sometimes you may find in the Jenkins code base. That's really uncomfortable. And, and you have to ask for help or say, Hey, I don't know what to do with this. How do I test this thing and we as mentors may have to do some research as well to find ways to do test driven development in what is fundamentally an integration machine right Jenkins is an integration engine. The word integration hints that there's a lot of integration tests that happen right it's, it's not well oftentimes well suited to just simple unit testing you've got to do integration or I have tests in the get plugin that I maintain that actively call production servers, right, I call right to get hub calm and ask questions. And that is a total cheat in test driven development but I do it anyway because I need it. Did that answer your question. Yeah, pretty much interactive testing that's for sure. Well yeah yeah so so test driven development is certainly I considered test driven development necessary, but not sufficient. Right, you must have checked interactively. It's the Jenkins code base is just too complicated for us to think that we can do something purely with automated tests and it will just magically work. Now I guess one other area is, I really like having online help with every single change. So with every, every addition of a new capability we need to be sure it has online help for it because users read it. And we need to be sure that we documented. So, so again those are places where it's surprisingly important that we document this because other people are going to want to use it. So a design document has to be treated or something. I'm not as worried about a design document. I think you're you'll, your design document has already been been very nicely started in your project plan. And that's that's great. I'm not worried about individual design documents for steps along the way. The working code is much more important than than writing about code. Yeah. Does does that answer your question. Yeah, pretty much yes. Chris or Fram, do you want to give a different opinion or an alternate opinion? I'm actually a pro test driven as well. I just feel that it just makes it very easy in the long term as well I think like as your code that actually evolves throughout the years. It just, it just keeps minutes is easy to keep track of all the changes and all the updates that are happening all the time. Yeah, so I'm also pro test driven. But yeah, at the same time, at the same just one more thing. At the same time, as you said, it is quite uncomfortable at times. So I think there's a straight up as well to keep in mind. But I guess like overall, if I think we should always just like a try it out first and then if it if it actually creates this fiction. In that case, then you can just like adopt a much simpler way at that point. Good. Very good. Chris, you're next. Okay, so I think like unit tasks are definitely necessary, but for integration tasks we should try to do just what's needed, because like, otherwise, it might slow down the whole application. So that's not what we want. Good point. Also, could you actually share the document with us. So like even we will have access to it. Can I ask your question again frame I hear it. I was asking for the access for the document. Good. Oh, this one. Absolutely. Oh, yes. Sorry. Absolutely. Yeah, sorry, I thought that I had obviously I had not let's get this. So I really like for these documents to be public. So let's make it first that anyone can read it. So grant for a harsh Chris. Each of you will be made there. Good. Thank you. So, and you're welcome to edit it during the meeting even. All right, so communication channels next topic. I assume everyone's okay if we go ahead with get her chat in the get lab plugins in the get lab plug in chat channel where we've been chatting already. Okay. Great next clarify sync and asynchronous communication methods so harsh I think ask a question, ask questions in the in the in the chat channel. Right, if they are and if they are even remotely close to being workable publicly asked them there that way others can learn from them. And we'll answer there. That way we don't have a rigorous requirement for synchronous communication. I prefer to have at least one session a week where we're synchronous that we can so that we can meet together to be sure that we talk and discuss. Is that okay for the rest of you. Yeah. And let's look for a time does this time work for everyone in general or is this a bad time for Friday maybe a time when you wish you were having a beverage or something and so I, I don't know if you're your your character is like mine so does this time work would you prefer a different time and day. No this time is actually fine for me because I have classes in the morning. So, it's actually pretty good timing. Okay, all right so. And Chris frame for you. It works for us. It works for me as well. Okay, great. So, I will schedule Friday at this time. At same time. Mark schedule the session, the repeating session. Great. Excellent. Now, unavailability so holidays, exams, etc. So harsh, I believe you started this in the in the project plan and we should continue it there. I actually mentioned all those are the breaks which I'll require in the project proposal. And it's not like I won't be working on that on these times but my workload will be reduced, like from 35 to 40 hours to around 20 hours because I won't be able to give up my full time to it because of exam. That's and that's fine. That is very reasonable. Okay, good. If you could grab me a link to the project proposal I'd love to paste or you could paste it in there. Okay, so I think we're ready now for on the what side agree and define the tasks and deliverables. So this is where I think harsh we look to you to during this next two or three week period. And one more round of looking at using your project proposal to identify exactly what will happen when. Right. Oh, very good. Okay. Perfect. Okay, so now the, there are some key some key things here in terms of deliverables. John Mark in this original document called them soft deliverables. I'm not comfortable calling them soft at all. The mandatory deliverables that we absolutely must have during this time. It's, it's kind of him to use the word soft but it's crucial for me. And I think for you harsh that you do, you complete these pieces because it's very becomes very clear to everyone that they know who you are that you're that you're getting started here's what you've got. And these first two in particular, I'd like to see within the next week, if your time will allow it. Yeah. Okay, so, so now the challenge here is let's see if I can find this this one is actually not the right link so I'm going to put a link to the page because we allowed an empty page to go in as part of the G SOC announcement. We actually don't want that page to stay empty for any extended period. So this page, I think is the one that will show up as empty. Yes. Okay, good. So harsh. This is the one your, your task is to assure that this thing is current up to date, etc. Oh, and it's already got the project. Perfect. Thank you for him. Thanks very much. I need you to update date your create and update a page for your contributor. So this, this thing needs to be replaced by a real author page that talks about who you are your picture, etc. Comfortable with those two. Yeah. Okay, great. All right. Okay, and then stretch goals. This is when I feel like, could we set our goal that next week in our meeting, we will review the project plan in detail with you harsh, giving you a chance to prepare to do one review of it before we're ready for before we review it next Friday. And we will talk it in depth next Friday as make that the primary focus of next Friday's meeting. I don't have a problem with this because I have my exams from next Friday actually starting from a I wrote in the proposal from seventh to I guess 14th, like so it can be a bit messy there. Okay, so well then let's not let's shall we are the other mentors okay let's push that out one more week you knew you were going to be in exams. Let's not put your you've already got enough pressure with exam so review in two weeks. That's a bit fine actually. Should we plan to skip next week's meeting so that we're not disrupting your exam schedule. No, no, that's not you're okay meeting meeting. Yeah. All right. All right, good so meet next week. Except that harsh. Harsh is focused on exams this week. Will you be able to complete these two items the. Yeah, those things are able to complete these two you can do those this week. Yeah, or before we meet next week. Yeah. Great. All right. Okay. Okay, so two weeks. Very, very good. All right. Anything else in the what section that we need to discuss the blog posts should I write it now or at the end of the community morning period. So, let's see so the actually that. So this is the starting. This is the blog post that John Mark. No, no. Maybe. Well, let's see. Chris help me with this one. I think we've had contributors do a midterm blog post and an end but not a start blog post, or did we also do a start blog post I don't remember harsh. Good question. I don't think it's a start box. It should be an end. Yeah, let me let me do a quick check to see is he on on some of some past ones for instance. Where is, let's do this one. I think no, no, that's not. Oh, there's an author's page isn't there Chris. Yep. So if I click this, and instead of there go like this. Oh, and isn't this good looking somebody has done a very good job. Yeah. Okay, so let's let's look for reshab. Nope. Okay, how should Chopra so let's see what what how should wrote. So, how should only did one blog post. So, go ahead Chris. One last year to Okay, so others. Let's see shruti I think was another one. One blog post. Okay, and others, others, others. You can try yiming. Oh, yiming. Yes, yiming is an excellent choice right yiming may have done to that's very good. So, yiming. Oh, g o n g. Ah, okay, good. And where is I like the one. Ah, there it is. Okay, got it. Again, okay, one. All right, so I think the answer there is that would be an end of blog end of a wrap up blog post at the end so no need for a blog post immediately. Now I think it would be healthy if we had you do a midterm blog post but yiming is the end of blog and you'll you'll absolutely have to do a midterm presentation and absolutely do an end of end of cycle blog post. If you did a midterm blog post it can help you organize your presentation. Okay. Any other questions on the what. All right, next topic then is the how we will go ahead Chris. Is it like, is it your my suggestion that we add like a before we start post this year. I wonder if I had assumed what he meant here was that we need him to update his author page. Yep. And the present the present the project page, but I wasn't assuming of before we start blog post but I guess we could. Should we ask john mark. Yeah, we should ask but I think his ideas are just to make sure we have like the contributor page and the presentation. Oh, just a project page. Okay. So two pages. That was my assumption. So but, but I think it's worth asking let's ask, ask him if he wants a starting blog if he if he not wants he may say yes I want it. If he requires a starting yep, he would say he wants it. Yeah. Okay, good. Anything else on the what topics. Okay, then on the how topics so define and put in place the technical logistics so issue tracker. Thus far the get lab plug in has been tracking its issues in get GitHub if I remember correctly Chris is that right yes here we go and it has lots of them. So, I propose we continue that any objections. Good, good choice, get repository to use the same. Okay, work environment. So harsh, I assume you've got a development environment, at least Linux based or windows based one of the two help the rest of us which is it are you Linux windows or macOS user macOS. Oh, very good. Okay. So, and Mark is using windows and Linux frame what's your preferred development. We have all three as well. I have all three of them. I use all of them at once. Okay, and Chris is Mike. Good. All right, so we have we have a nice platform mix that's very healthy. Great. All right. Now harsh. I assume you have Docker on your macOS machine is that correct. Yeah. Okay, good. All right. And I've got Docker on all of mine I assume frame and Chris likewise. Okay, good. All right. Okay, how and where meeting notes or recording or recordings are kept. So I propose meeting notes in this document. And if you're okay with it recordings posted to the Jenkins YouTube channel. Oh, yeah. After meetings are complete. Mark to post them Mark has a bunch that he hasn't posted yet I've got a lot to do is that okay for the rest of you. Yeah. Great. Okay. All right. Okay, so bonding period deliverables. G sock biographies on Jenkins.io. So yes this is with a picture please. Right so it should look something like well something like this one. This one. Okay this one has a picture harsher okay with that I assume. Yep. All right and project page on Jenkins data updated yes link to the biography. I'm going to upgrade the update the to be described section so that's this, all of this. And this is effectively a transposing and possibly simplification of your project plan. And if you could put in there that we will be meeting every Friday at the time we've agreed to, that's great. I'm going to go back to the Gitter channel and the project proposal. Oh yes. Notice here it's the submitted project proposal so if, if we have to archive a copy of the PDF that's, that's great I don't remember how that's been done in the past harsh. It may be simplest to to save an archive copy of the PDF of your proposal. Leave it up to you to decide. And then the current project project plan okay and this one. How shall we do what's the. In the past, I've preferred to have project plans that we're in a Google doc that we could revise and refine. But that doesn't make for a really easy way to track history. Are you okay if we use Google doc for that or do you want to do something more formal put it in the GitHub repository etc. Yeah, we can use the wiki. Oh, oh, interesting. Yeah, is there a wiki enabled on Oh, there is. I think. Before someone has used it before so that we have migration guides and set up example. Yeah. Okay, so shall we. Shall we agree that we'll use, we'll use the wiki on the GitLab plugin repository now. Harsh, do you have permission to create new pages on this on this repository or is it only maintainers they're allowed to could you check that you can create a. I'm going to try it. Not creating something. You say you cannot create something there. I don't see any option of doing that. So the new page button in the top right is not available for you. Okay, all right, so wiki won't work. Okay. I just changed the settings because I restricted access to earlier. So I just changed it. Oh, okay, so you can we can grant permission to harsh without making him a maintainer. It's like, if I give permission, it would be for everyone, not just to harsh. Yeah, and I'm not I'm not sure we want to go that far. I haven't looked to see what the permissions are on the wiki so the, the. Yeah, I. Before joined before it become a maintain it was public before. Oh, it was. Yeah. Oh, okay. Well, so then if it was public before and it wasn't being spammed horribly. Then why don't we go ahead and make it public again. In, if it becomes a problem we, we, we bring we reduce the permissions. Yeah, sure. So harsh. Let's have Chris make that change now. How do you make that change Chris is that in settings. So it's like, yeah, it's exciting. So as I go to John Noel, and you scroll down to features. The first one should be wiki. Here, it's good. No, we're inside. We're inside. So we go down right inside general scroll down to so features. Oh, oh, there we go. Okay. Okay, so you, you clicked this checkbox to allow others to edit. Yep, you can do it. Perfect. Okay, so harsh. Could you try now to see if you can create a page on the wiki. I'm probably paid for the project. Yeah, I got a new bid option. Great. Okay, so your task then is to let's let's try it this way I've never used a GitHub wiki before let's try it and see how it works for us. Okay, so here's the wiki. Great. Very good. Okay, if that didn't work for us we can always switch to a Google Doc. Yep. All right. And then oh, okay, nope. So John Mark has answered our question. He really is expecting a blog post to present the project and the contributors. So I assume this is an end of end of community bonding deliverable so community bonding period. Help me with the timeline Chris when does it end. Now so let me check again. 28th. Yeah. Okay, so, so post the blog before the end of community bonding. That gives you plenty of time harsh without, without crushing you under the load of exams that you've got coming up. Great. Okay. All right, so we've answered one of our questions and very good. Where was the question it was. What, here we go. Okay, we're set. Any other topics we want to discuss today. Yeah, so I had a question about get workflow so how are the branches going to be set up like, are they going to be released branches feature branches and master branch on the GitHub. Good question so get work so let's let's put it in as a question questions right. How what is the what is the branching pattern. That's a good question for us to discuss here because I've got an opinion but I wanted to check with Chris and and what is the release pattern. All right so on the branching pattern right now the working assumption is, is the master branch is the source branch for all releases. As far as I can tell Chris right and pull requests are submitted from personal repos to the master branch on the central repo. Okay Chris. Yep, it's correct. So I would prefer to retain that branching pattern harsh where we keep it nice and simple. No, no extra branches, just we merge to master when we believe it's ready. And we try to do merges to master very frequently. So we want you to do small chunks of work that we can we can roll out so that we can do incremental releases as well. No, for this project like for the replay, like for replacing one of the likes that the West. Hang on. What's the code. I always remember what's called rest easy. Yeah, the West easy, like for a very basic SDC. Well, is it feasible if we open a new branch and commit to that one and continuously pulling from the master branch that be more workable or would that be more advisable to just submit PR to master branch way away. My, my preference personally is to not have long live branches, because they tempt me to make other choices which are flawed. So I, I, it's, it's, it's hard work to find ways to assure that each step is incremental and can be released but I think it's worth the hard work, because at least in the past when I've chosen to use long live branches. I've had very poor experiences with the results from it. Okay. Okay, cool. Yeah. So and it's so it's a series of small steps. Each making some small progress towards the final goal. Okay. And as a matter of operating plan, no breaking compatibility, don't break compatibility, right. Don't just don't destroy functionality. You know, those are very famous words to say and they're very as far as I can tell, very challenging to do there's a lot of learning to go through that process and so harsh. Don't be shy as we as we talk through these things together we're going to have to find together what what sequence of steps should be taken to do this. The most reasonably anything else on the branching pattern. So the next question, what's the release pattern today we're using semantic versioning. So, so that means X dot Y dot Z, where the X version means we were breaking the Y version means we did a bug fix or functional change and the Z is no, no change in functionality but otherwise an improvement. Is it okay if we continue semantic versioning the other alternative alternative would be continuous delivery. What's called JEP 229, which uses a uses a single version number. What is the count of commits in the poll request. Plus a Shaw one hash. I'm biased towards this one but Chris I know you haven't haven't transitioned the repository to it. Was there a reason you chose not to do it felt like hey not ready to do that. I'm used to semantic versioning that's why. Okay, all right. We could change it though. That's what you prefer. I'm, I'm, I'm open to I'm open to either so harsh harsh this is a this is a fun software engineering question I'd say, let's, let's leave it as it is for today. How it evolves in our discussions that way harsh you'll hear us as Mark and Chris have the discussion back and forth who I like it for this reason I don't like it for that reason. And then as a group will decide as we go forward will stay with the current pattern for now. Hi. Great. Any other questions before we end. So the GitLab plugin currently supports it lab version API version three also so does it requires to be removed during the migration or we are keeping the version three. Because the warnings, the GitLab has some warnings written there that this thing the version three will be discontinued so what's your thought about the good good thing so which GitLab API version will we support. And I think there. Let's put that as a separate question, because I need to have some do some more research to to understand so the Jenkins project has a general a general pattern that Jenkins does not support. The component does not. Yes, so butter support a component. If the upstream vendor does not support it. And therefore, if GitLab is dropping support for. What's that. Actually it has already dropped by thing from 2019 I guess. Okay, all right. Then, then Jenkins should transition away from it. Right. So we should be using, we should be using GitLab API v4 or v5 whatever their, their API. Great. So are you are you okay with that and Chris does that work for you all right. Yeah, sure. So, so that feels like that's part of this project to be sure that we as part of this transition use the current the new API not the old API. Yeah, so the code related to ordinal thing which was set up by the author, which actually decided the order that the GitLab version four will be implemented first and then the GitLab API version three will be tested. So I think that code will be ripped off from the code base. Great. Is there any other purpose for this ordinal thing that I saw in the code base. That detail I don't know I'll have to look at that separately it's a that's a that's a question I don't have an answer for it Chris if you've got an answer you're welcome to share it. No, not yet. Okay. That's fine most probably it was for that order so great. We've run out of time is there anything else before we conclude. I'm not left with any questions now. Alright, so you've got your actions items harsh I've got my action items will meet again in a week. Yeah. Thanks everybody. Bye bye.