 Go. Hello, everyone. So we're on the 26th of June 2023. And this is a GSOC Jenkins Docker base quick start weekly meeting. How was your weekend? It was good. I worked last on Friday. I worked on a lot of things. I don't remember exactly, but today also I created a separate branch for Maven example. I used a lot of your script and inspiration from your buffer file you created. But we'll see because we don't know yet if all the romantles will be okay. Which was that proposed we'll see. Sorry to interrupt. So if you don't mind we'll see quickly what we'll talk about today and we'll see afterwards if there is something else that you would like to add. So I was thinking of course that we should talk about the midterm presentation that will happen on July 6th. Then we'll tell some words about the dog's office hours Asia that happened last week and the week before on Friday. Then we'll talk about the Maven tutorial which we have started working on. We'll also talk about the repo because Jean-Marc wanted something to happen within the repo. So we'll see if we can set it up. Then we'll see that there is no pull request so to speak yet to integrate into the master branch. Well done. And we'll talk about some of the 11 issues that are still open to this day. And if there is still some time we could talk about plugins and anything else that we'd like to address. So sorry I was just asking about your weekend and then you started to talk about the work you were doing. So we'll talk about the midterm presentation first. Jean-Marc would you like to share with us a few introductory words about what is expected on the 6th of July? Well on the 6th of July we expect a retrospective on what has been done in the past six weeks. So what has been achieved? What is the so a demonstration and basically to show and explain what has been done and what is going to happen in the next six weeks. So it's important that we have something to show. It's a 10-minute presentation. Yeah so lots of things to cram into a 10-minute presentation but that should be okay. But the trick is to distill, to have only the essence and to be very very efficient. Not trying to put too many information in it. So Jean-Marc would you like that we rehearse whenever the material is ready to go so we can it must be rehearsed. Yeah on the side but I mean in a semi-public the mentors some of the mentors and actors to see what should be changed what should be kept and things like that. Yes it's fairly obvious. So sorry. Yes but Ashutosh should lead the effort. So have the list of the things he wants to talk to and that he shows and let us interact in the setup of the presentation. Then as I believe he's not a professional presenter and used to these kind of things. It's very important. It's only by rehearsing and fine-tuning the presentation. Have it timed that we will get to something. A good tip, a pro tip especially as we're at different time zones is that once the content the slides have been settled that Ashutosh records himself easy to do with Google Meet and he can play it back. For me the most critical thing and seeing the timeline we have we have only a couple of days left is that we have something to show and currently the demo or the content what has been done is a little bit weak. So we need to work on that, focus now on that and put a deadline on that. Looking at the calendar that or end of the week we need to have content so material and that Ashutosh can think on how am I going to present that. We have the beginning of the week thereafter to fine-tune the demo or we need to fix that. We need to fix that and then there will be two days left to really work on the presentation itself, fine-tune it and so time will be sent. So this is how I personally see the timeline. This means that knowing where to focus the work, what is important, what is not important, what can be done later is critical. So just to come back on Friday I closed quite some pull requests. There were still some glitches, there were still some fine-tuning that was required. When there was still something that was not 100% I preferred to merge the pull request and open an issue that we don't forget. The word issue is something that I have a fundamental problem with just the name. It's not an issue, it's just something to remind it's a task. So I prefer tasks which is much more positive. Issue implies that there is something wrong. It's not something wrong at all, it's things we need to think and keep in focus. So there are many items in the to-do list that have been opened that are just things that we know we need to deal with later. I also started implementing milestones. The milestones give a way to visualize what are the items we need to work on and focus and for what date and you can also see the progress once these items are closed. So how did you implement that? Well we can show that at the end of the meeting and this is why I asked, I don't know who I am because Friday has been a little bit overwhelming. We can continue this meeting one hour afterwards where we do screen sharing and where we really go into the day-to-day. But if you have a shooter's repo open, we can just quickly show the principle. You open the issue tab. There you go. Oh, yes, milestones. There you have milestones and so you have three items. So issues without milestones name is self-explanatory. So the first milestone that I created to be discussed is minimal viable configuration. So iteration zero and this is what we should discuss and review and so the first is doing the minimal to stabilize to have at least something to show. This is where we now still some work to be done but this is the simple setup with the job running with the SSH keys. So what we've experimented up to now, we need to stabilize it, publish it. And there I have some ideas where I can direct. Milestones have deadlines, not deadlines, but target dates. The other milestone that I decided alone on Friday without discussing, I apologize for that, but I wanted to clean up everything that we have a good base to discuss today. The second one is release one is that we have a completed Java Maven project tutorial. Everything ready and this is for me the target that we need to achieve for of July because there the people will understand, will see practically what we want to deliver. What is the added value for the community? Where are we heading? As a termination of the six first weeks and on that we can build and there are several directions we can go for the for the second part. So if you click on minimal viable configuration there you will see what are the items that are I need to always concentrate to use items and not issues but these are the one that I created. So only when you click on you have a progress bar somewhere where you see but here you have it because each time an issue is closed. I also seen that several of these work items were completed but were not closed. So we lose the oversight. We don't see the global picture. Where are we what needs to be done? There's and also I started using labels for the items so that we have better. So it's getting organized so that we can track. I discussed in with Ashutosh and seen things. We did that offline but a lot of time is spent on fixing things that in my opinion are not critical for the the objective we want to achieve and as we're very short on time and time is is really critical here this is what we need to check focus and order say I fix this first then I do that then I do that otherwise it's a huge mountain and we don't see the progress and this is very demotivating. So this is just my my two cents in that in those here. I might sound very directive but it's based on my my experience. So the idea of what we should do so beside following the the meeting but at the end of the meeting where we go into the meet of that is really walk through these tasks and convert them so that we have a view of what's happening and that we can decide minute per minute this is critical this is higher priority this is we should work on on that this is something we can remove from the target of this particular milestone these are my two cents to the conversation. Okay thank you Jean-Marc. Does that make sense or did I lose you because of poor communication? So the first thing is do we have a common understanding of the timeline did I expose? Yes we should be and we should have something we should have presentation ready by the end of next week end of this week. What do you mean with presentation? I mean this slide then I should be I should I should have explained you guys I have showed you should have showed you the demo how I'll do it in the real. I would rephrase that by that time. It is this week we focus on content raw material what you're going to show and you make just a small note rough no slides not not everything and Friday it's fingers of the keyboard and then we start we have three or four days left to do the actual presentation and maybe do a tweak here and there but we need really to work sequentially do we agree there I should also. So for the for the presentation should we just focus on Maven or should we include the and Node.js and Python tutorial? No for me this week is tidy up the existing working example and then switch to Maven if we manage to agree on what should be in Maven tutorial and then on Friday when all of that is finished hopefully we'll be able to work on the presentation itself for the four remaining days. Did I understand correctly Jean-Marc? Well we we share the same opinion so this is my opinion too we we need to have achievable goals and and make them as good as we can so not as good they must be achieved full stop so but adding Python and these kind of things if on Wednesday everything is finished well then you can we can start another milestone and say okay we add the Python example the what we know is that Friday is stop then we need to focus on the presentation so doing several things at the same time is a very bad habit and the method that I'm sharing or explaining right now is called time boxing that means that you give yourself a limited amount of time and you do as much as you can for this particular and you throw everything else out of it. This is time boxing. Did you know that Ashutosh? No I didn't know. So when when you're on free time you want to learn look on time boxing and another interesting keyword to look for later is the Pomodoro yes I've heard of Pomodoro. These are techniques I don't like it that much because I don't work that way but time boxing this is a management practice sorry I get it right back to you. So Ashutosh yes it may look way too much time to spend on the Maven tutorial you know by Friday five full days wow why so much you never know what can happen we'll do something really different from the existing tutorial and even if we have some kind of proof of concept that does work we don't know how many issues we'll encounter while trying to do the tutorials so better safe than sorry I would prefer having a working cleaned up tidied up example with the Maven tutorial by Friday and then start a nice presentation those are four remaining days instead of having a little bit of Python a little bit of node a little bit of Maven not everything is looking all right and not is working perfectly well out of the box and then we make a presentation that won't be outstanding so yes please let's finish up with the base tutorial the Maven tutorial all clean and then work on the documentation cool very very good there is one that will we all agree on what should be on the Maven tutorial and the way we should address it technically we'll see that in a few minutes yeah I'm I just would like to emphasize what you said my calculation so Ashutosh understands the reasoning behind and that we're in a hurry with we did we're not able to make you understand that my estimation at this stage is you will leak about one day so eight hours work globally to finalize the first milestone so to finalize have something clean and so and about two days without really knowing the scope for finishing the Maven all the rest is foreseen for feature creep meaning that oh we forgot this oh we forgot there and risk oh we encounter problem I've seen that you have difficulties for managing get conflicts because now you're getting really in the in the the the hard difficult part of working with gifts together and this you need to master this will take time so rebasing managing conflicts and merge conflicts I mean and this is built into the planning so sorry Bruno go ahead no that's okay yes that's a much more detailed explanation of the why five days for just one example totally makes sense yes within I'm currently still struggling with conflicts from time to time this happens and you have to scratch your head reread the documentation once more try a few tutorials because getting it oh yes that's why I was getting conflict and so on so that's not easy and much more for you because of your past experience with git which is not huge so that's perfectly normal yes a bit of save then sorry as I said before him now on docks office hours I've seen that you had attended the two last Asia docks office hours thanks a lot for that and that you made a very I think of the last two you made a demo on the two weeks and we do love that and if you go on next Friday this will help you rehearse the demo that you could do during the presentation so and you get direct feedback from Mark who is a real stakeholder of this part of the documentation so wonderful idea yeah agrees with what you are proposing you're good to go that's could be cool wonderful and yes Mark seemed to be very excited with what you showed on the last docks office hours so that's a pretty good sign that we are on the right track so yes we should go with a build a Java app with babyn I think if we managed to show him on Friday that it's working on this project he will be super thrilled about that because it's a huge documentation with difficult cryptic docker commands and frankly when I started with that tutorial say why does it have to be so complicated as you can get rid of that let's go ahead your mark yeah sorry I saw it Friday I say how is on earth something like that possible it's a mess so so uh it's it's this is something we absolutely need to do Ashutosh what was your opinion on the reaction how did it go the demo what were the questions I firstly I did work on the proposal I the docker commands are same so I didn't know how to do everything but when first time I encountered the docker command these docker commands while building the proposal I was I was really struggling because it was my first time using Jenkins to docker but when you presented your demo to the docs office hour how did they react what was interesting to them when they say oh they're it's interesting and what were the questions they asked the first thing first most interesting thing was that we were using agent because right now they were built on controller right now so that was good and second point was sh keys and third point was I think yes yeah mark did ask about what we'll do about volumes if fish he was not objecting he was just asking if this will be done that named volumes will be there in the end or not so I told that way we did have discussion about it what we haven't decided and for the end part what it will be yes because if we keep the named volumes if a user is running the first tutorial then the second tutorial and we keep the same volume name then there could be some overlapping of some configuration or something so that could be disturbing for the end user on the other hand if we are using different name volumes we should maybe get rid of them at the end you know with the teardown command in the end anyway we should do it whenever we use the same docker name volume or different docker volume we should get rid of them except if users want to keep working with the same example without losing their added jobs and data we have to discuss that so just sorry sorry that I but so very interesting question so we need to write it down and let's create an issue and tag it as question do we keep using volumes or not just immediately adding my point of view on on that because it's having a named volume will allow a user that interrupts something went wrong he lost his connection while using a git pod or something like that he can restart where he was and but we need to describe that so the so there are cases where name volumes are interesting but as Bruno explained we need to manage them correctly and there are two use cases or two configurations that we're dealing git pod this is not an issue because git pod after an hour or so it disappears from the surface of the of the earth when people are working locally there you can you can trip on your own traces on on what you have so we need to think that so volume or not that's the question would be for me the name of the of the I hate that word issue but you understand what I mean now see the method oh that's interesting we spent just the limited amount on it we write it down so we don't forget it and we can we continue and we listed and afterwards we come back to it and rank it and say okay we're going to think on it assemble information on it and then say okay we're going to say we need to make a note in the documentation about or to have a script that will allow people to restart ongoing presentation so I'm trying to explain the the work method thank you now about the repo so Jean-Marc I don't think you were ever allowed to give us your input of what you were thinking about the repo you told us several times that you wanted to have some tags but you didn't get the time to explain what you had in mind really for the various examples I know you don't want to see the long subdirectory names and you want something much more compact at the root of the repo and using some tags so could you please tell us a few words about what you envision for that now this is about colors and uh writing habits but I have gray hairs and and seen a lot of things so I I know so first thing Hashutosh shows to use a sensible technique or strategy now is that to separate clearly the various experiments that he did and we have this and we have that it's like a file system each time I need to think on where is he working on and and and so so this this brings me the first first problem the second the second one is that the well the advantage of working that way is that Hashutosh avoids conflicts so which is it's very wise uh at that where I change this but then fixing this issue I'm changing that and he experienced that with his uh journal uh there I'd like to come back to the work journal afterwards uh so it makes sense the other thing is that when I come and use because each time there's something published I check out the PR and run it to put myself as the user to see to see how it looks like and I have a bad habit agreed but I'm allowed to do that I don't run uh it's with the dash D because I in my terminal I like to see what is happening because then I see oops didn't connect I see it immediately but this means that about two-third especially that I hear with a small 13 inch screen it takes about 70 percent of my of my screen because it prefixes and and a little bit irritating now the most important thing about that uh or what we're discussing here I want to use the demo the first thing I'm going to say and this is what the documentation going going to say either check out the repository or click on git pods and so on and and then what you need to explain him and then you need to go there and you need to do this and you lose the people it's after 15 seconds it what is this sorry this this nonsense and uh so what we need to aim is something very simple check out repository one command oh marvelous there it is it should take the minimum minimal time so change rectories if necessary should be automated uh one single command that does the setup the preparation and starts the the the the demo and the environment and and things that you did that that worked great were uh like my okay this is the URL you should connect to to open git pod there is also the click people that don't know git pod don't know where to go but this is this is a a discussion we need to have when we try the demo as the end user limited knowledge no time and and so I shove that apart shouldn't start discussing so my point of view to be discussed uh here is that we now we have several examples at different stages that are good and I love the example where we have the the demo job working and does it doing something this for me one of the features of the the minimal viable demonstration we have different directories we should now move them to where they will live uh in in the future where where they built and uh now I'm going to share the complete idea these are just ideas is that um the way I see the demo start is you go and just type demo or Jenkins demo up what we could do is Jenkins demo up eventually with a parameter and saying Jenkins demo up Maven and and you have everything that and at the end I said just connect to that that user interface and enter admin admin or whatever we decide to to add to it uh we can or uh uh Jenkins demo uh or we decide to have a Jenkins demo well uh what you're writing well this is to be discussed so either we try the method uh you're writing there it depends how good or how comfortable Ashutosh feels in writing bash files because now as we're in a hurry we we should avoid putting unnecessary ballasts in Ashutosh Rucksack because now he needs to run so either way at this stage because we can change it afterwards we could make Jenkins demo up Maven.sh do one single and afterwards as reuse is one of the the targets of DevOps we could this is up to you and but we can discuss it here so that we we don't lose too much time I like the idea of just putting word of which tutorial you want to run so after Jenkins up Maven that seems like already I think I can write the script too okay don't don't forget to add the error flag because as soon as something goes wrong it should stop and not going otherwise we're we're going and by using this technique we're going to avoid the problems when somebody stupid like me starts the the docker compose before having executed the setup and things like that we have a single preferred path we we don't allow my grandchildren I need to check that they stay on the road and don't start going all over the place and so I'm okay this is road and you can go on your own but you stay on this road don't start so I am getting on that issue I wanted to ask you that that running SSHK script after docker compose up that issue is solved I thought I solved that issue then you opened the issue again because I've I've seen it I had the impression it didn't work now I came yeah that's what I wanted to ask yeah I don't remember it's been it's been two days ago so I forgot what what I need to get back there but just to expose you the technique I use I look I take a note is it critical for our project is it on the critical path yes no no because if we use the proposed the work around then then we then we can put that aside and solve that afterwards see this prioritization yeah Jean-Marc sorry to interrupt but as you know no no do it do it because otherwise you need to pull a priorization last week we talked about you and I talked about using a Kanban or something but yeah and you now have implemented something with the milestones so should we try to add something Kanban like within the repo or if the milestone feature you implemented enough for time being the Kanban uses also milestone milestones is a simplified Kanban we're going to to see and I don't have the admin rights Ashutosh needs to learn things I thought about that on Friday I experimented yesterday so the Kanban could be useful but Ashutosh is the only one working and we're there watching him work with it is very convenient but it's a good question Bruno my point of view on that is that I proposed a simplified way on for solving it so to see the prioritization because in my opinion this is where we have an issue we forget things to do and we have a massive mental overload and we need really now to focus sharp on where we need to go the milestones could help let's try it if it now I don't remember if milestones allow to order things I'm not sure about that yeah no no but here I can look into the Kanban stuff you need to create a project at your level and then you assign the project to it I need to I I did that before me too I don't want to lose too much time on it right now this is my opinion I don't know what the other things in I'd love to have that but I don't want to lose too much time on that yet because we have the 6th of July target even if that would help with that target I need to go offline for a second I'm still be listening but I need to go okay go ahead Ashutosh is a Kanban something you have already studied at school no I haven't studied Kanban I don't know what it is okay I think it's linked to a giant programming and so on I've been using them for decades now but couldn't even explain where it's coming from anyhow that's not mandatory for the project that could be some kind of help you know because it's a display of the tasks that we have to do it's very useful when you have a group of people and people choose oh I'd like to work on that issue and then we move it to the current milestone and people have to make it work before 15 days or something like that but you're on your own I'm afraid so that's maybe overkill over engineering for what I mean and you haven't practiced it yet so I don't know I think by the 6th of July we are not we don't have to use it just milestone should do the trick the only problem I have with my stone is that we can't we order priorities you know so you will just need okay I have these two issues to do but which one is the most pre-o-tere well I don't know we'll do with what we have if you don't mind but yes keep that in mind for after the midterm evaluation maybe we could use the Kanban for the second part of the project now I wanted to talk about the Maven tutorial because I proposed two things the last weekend but it was all fresh out of my mind and I did not discuss that with Berdient or Jean-Marc or you and Shadosh so I don't know if others will agree with what I proposed and maybe I went overkill because what I proposed the first the very first step which is really complicated on the existing tutorial just fork clone and launch lots of Docker commands my idea was just launch a script that will fork and clone locally just by asking the end user it's GitHub handle and its password or token I think that's worth that GitHub doesn't use password anymore so token yes I think that the token part is already addressed in the existing tutorial but maybe that's I don't know too much automation I don't know what's your thoughts about that I do like this script it works nicely then just ask the credentials then creates the clone version of the port it's nicely working and I've created a separate branch you can let me you already did that you already did that Ashutosh you created the branch you know proposed created a draft PR with the script then I created another branch with that script and custom SSH agent docker file and I was able to perform the whole tutorial with that setup without Docker and Docker that's cool because the main breaking change I had envisioned is to get rid of Docker and Docker for this tutorial because it's way too risky in my point of view to open this kind of world because we could get in so much trouble trying to get it to work correctly and understand what's hiding behind the docker in docker as a security all of that I think we don't have the time for that and frankly I don't think it's mandatory to use docker in docker to just run a Maven tutorial as you had already used a docker file for the controller say why not extend this mechanism and try to define an agent with a docker file and I have a meeting with infra team most of the weeks and we have already discussed that thing because lots of the time in community Jenkins IO people say how come you don't have that software in the docker agent images why doesn't your python image work the way I'd like to why do you provide this and that version of Maven in your image and so on that doesn't work the way to work and the answer is always the same create your own docker image based on the supplied docker agent images do so don't try to do something else always start from the docker agent supplied by the Jenkins team and then do what you have to do to have something working so that's my manifesto somehow that's what I wanted to do with this example I would like to get rid of the docker in docker and just create our own Jenkins agent based Maven image and use it in the agent so it's a dedicated Maven able docker agent so I don't know sorry I talked a lot but my idea was just let's get rid of docker in docker and do something simple I I'm not going I'm going to try not to interrupt anymore just raising my hand go ahead I suppose yes I also think docker is not needed I have then the tutorial and it doesn't it doesn't need docker and docker maybe python one python one can be then without docker and docker too I think but it uses docker and docker more than this and this one doesn't use that that one I'm just going to add some lights as I'm with Jenkins with sometimes I know why it is in the demo it's mention mention it was written before the start of Kubernetes it was at the real start of swarm and Kubernetes and these were experiments a bleeding edge demonstrations and the way the technicians were doing to solve what is now completely transparent with Kubernetes and and so this just things we can get rid of at this stage so focus on on the demo as you as you said and docker in docker Kubernetes and these kind of things there this is another phase of things and we can explain with demos to people what how why is it dangerous what are the things you need to know and this we can do as a second project or a second part of this project this we can discuss Bruno sorry I don't know that's okay it's fine I would I'd love to hear your point of view by the way so that's perfect I was thinking that for the first part of this project we should address the needs of this first persona we described so as simple as possible something that works just works and then in the second part of the project yes of course we should try to dread the issues or what the second person wants to learn about Jenkins and docker for the time being we just want to have a Jenkins instance working it's with docker fine I want to have something working at the click of a button and I think we are approaching this goal yes thank you Debian2 would you have anything to add regarding this Maven tutorial what is your point I have a concern about because we use because we use automation how but when the user face the like errors or maybe some breaking so how we explain the error to the user good point yes very good question to which I don't have the answer well I have the one I have one is we should we should write it down and think this is an important item so the most obvious and stupid ounce answer is our script will never fail but it's something we need to think of now ah how would you solve it Erviento maybe something like uh frequently a frequently asked question uh for example if the user have this error so the solution we profit the solution uh-huh yeah for example uh the user get error in when input the username and we profit the solution yes I was also thinking that we could in this script mention why the error was happening and explain that in documentation if this error comes how to deal with it I think there you two have a good idea uh that we would have the the main demo and the script and then we would do an addendum to the documentation or somewhere what is happening behind the scene and where most common issues and and these kind of things and and where there you can explain this script is doing that and we chose to simplify it and and that would be a very nice feature uh to have and would start feeding the second persona who wants to learn and and see very good point by Erviento very good now I'm come back and doing my project manager again and say and saying is this critical for the milestone of July 6 or not I'm afraid not no but we may not forget it this is a feature that we can create and say this is part of milestone number x for later but we know it and we can then very easily move it up or something like that so cool thank you very good now so no more pull request opened thank you Jean-Marc for merging them before the weekend I like a clean desk I did open one today damn it okay just before the meeting what is it about it's the good party URL issue I solved it this morning oh the the bug yes okay I'll have a very okay I'll I'll I'll have a short look but we need to focus on the you're making my life terrible hash tosh on one side I want to I want to keep the project and everybody's nose to the target but then you made this interesting work let's let's let's see that so but so it's a small change for of one length okay good so issues should be renamed to work items okay word is just speaking I know I know but yeah anyhow so the main one we should focus on this week I guess if the builders have a hat with maven so of course because we'll present it you will present it I should touch on the 6th of July and hopefully choose a google to the docks office hours next Friday so we'll see it's this friday friday yeah this is a nice target because there we have the the first show and we're going to see so this is what we should aim for very good target okay yeah next one into an multi bronze pipeline project creation forget it for the time being we'll see that after the presentation we're going to yeah so bonus no hurry no rush when we yeah build a python with pie installer same thing no rush on this one we'll see that after the presentation we have to figure out I was about to do that just before the meeting if you we still see the issues on market that you had about the ssh key generation no we have to try I don't have that issue I've tried it I never had it but I have to try it nonetheless so no I had it but the using the long form uh and docker compose solve that issue one yeah I've tried it on my local machine and get both both so yes definitely we have to try that one to see if we can close it today or not uh Jean Marc I need more input from you uh on the next one which is ssh key generation git work tree is left dirty when executing the key generation squid which means that we have something which is not committed we should not be committed but which appears like changed in the git tree so yeah what would you like to see no it's just an observation I have my I have my ideas how to solve it but here we're here to discuss it so what happens when we generate the ssh key there when we close this is mainly where it happens also on git pod but locally this is very disturbing at least for me uh and good point we need it will it disturb the uh persona the first persona um when you generate the key the compose file is updated and uh there are two new files in the secret directory and so I get the warning uh they're uncommitted files as they're and I see uh them and and for nitpicking people like me it's uh maybe you could we could find the solutions for that this is by playing with the git ignore so we ignore uh the uh new file the secret the secret uh directory you know you shouldn't ignore the compose no of course not none of the secrets yeah the secret directory and for solving the compose the trick we could use uh is uh to have a git compose skeleton that with the init script and this is to force people to use the init script you know the Jenkins demo up a script the first thing you would do is copy the template where it needs to go do the scd commands to make it work for the environment and then and then go on and when you do the tear down it will delete uh uh all these temporary files that give the impression that and I say why it's important it will happen to me that I'm I run the demos I I check what uh Ashutosh did and and I'm going to do a push by mistake if somebody can do a mistake it will happen this is the definition of Murphy's law Murphy's law yeah so we need to avoid it okay so we could know the story of Murphy's law if we have a second Ashutosh do you know no I don't know just after the second world war when the jets were starting they had to test the ejection seats and the ejection seats and one of the problem is when you go through the canopy there's a big wind that happens and you need to design the seats that the pilot is not hurt by that and so they needed to know what are the forces so what they did was having test pilots and they would slam the test pilot against a wall and see how much he was getting hurt so is it still okay or or so and they would measure that way it was they didn't have all the gimmicks with the the puppets and and all that at that time was very very crude and they would the engineer had measuring the measuring tools for that and one of the plugs that you needed to put on the on the seat could be turned the two ways and so you could put it the wrong way and somebody put it the wrong way a guy called Murphy or the engineer that looked at it at it they made a test the poor guy broke his leg was in hospital and they had to tell him it was useless because we put the plug the wrong way and so Murphy solved the problem by design so if it can go wrong it will go wrong so we need to have a device that avoids that so let's not send the test pilot to hospital for stupid this yes it's kind of pessimistic but yes if something could go wrong it will go wrong later make it safe proof believe me and and another another thing and remember that in your korean bevianto will know something that has not been tested will fail test everything believe me and there is a color corollary to that if the people that wrote the test is the same that wrote the code it will fail too it will fail too okay anyway we're getting so i i still have time i can continue but i i don't know about i think i will stop the recording if you don't mind we saw most of the subjects i wanted to see and then we can make a session about uh oh i forgot my stones come down whatever if you still have a few minutes but i think that for that i have some subjects that we can the technical subjects we can discuss afterwards oh afterwards so we can close the meeting yes yes and then we can okay so if you ever made it you the audience to this point congrats that was one than the Howard meeting uh let me find the right button and stop it yeah go ahead it's also very useful if you didn't write something down you can really quickly go to to that yes and i experienced this morning the twice the speed youtube video of dog's office hours and it's still pretty efficient so if you don't have an hour of your time you can still watch the video in half an hour uh with us the titles it does work uh i should post it to come into Jenkins IO today or tomorrow at worst and it should be on youtube also very very soon let's stop the recording bye bye yeah okay we're without any audience now no i still see the recording going why i clicked on the stop recording good like i didn't see the red button