 Welcome to the Jenkins user experience special interest group. It's the 22nd of June 2022. And delighted to have everyone here. Thanks very much. Agenda topics that I've got include June LTS code coverage improvements prevented presented by Uli further discussion on an accessibility assessment. I'd like to move that one down because I think that's much less valuable on the next one on the list. VODX commentary on some specific pull up specific pull request and then a security review of UI related PRs. And I've got this accessibility assessment and if Jan joins us on time we'll look to discuss further UI improvements. Any other topics that need to be on our agenda today. So top item, the June LTS just released so 2.346.1 released with security fixes. UI improvements. Other improvements to core. There were also a number of there was a corresponding 332.4 release with security fixes. Users of the previous LTS baseline aren't ready to accept the UI improvements they can, they could deploy this security fixes. Also 2.356 weekly release includes the security fixes. Thanks to Kevin Martins for the change log and the upgrade guide. And thanks to Basel Crow as well for his contributions there. There are a number of changes in packaging in other things like the Alpine Docker image for instance no longer includes the CFC it's really shrunk to be what closer to what you expect an Alpine image to be those kinds of improvements really positive. Any questions on June LTS. One thing. Now we have a point for release. This means that we said it will not happen so far again, because we have the problem with the baselines for the plug ins what would be the next baseline for the plug ins should be used. The point for release as baseline for plug ins as dependencies. I think this will be a little bit. Hopefully our script will follow this new release. As far as as far as I know it does follow it so when we're when so what Uli's referring to is when setting the minimum Jenkins version that is required by a plugin. The general guidance is, please use the tail end of a preceding LTS. So the basically the endpoint of a preceding LTS release. Usually that's a dot three. 219.3 2.303.3 but 2.332 like a number of preceding ones had one additional release in it. And so when choosing a minimum Jenkins version. Use the final release of that LTS line. And so in this case it would be dot four. Good question really thank you. And as far and so let me put myself in action item mark to check that the, the version page has been updated. And just in case the dot three is not the only thing that we are getting in general the dot four is something exceptional, but we also got even a dot six at some point. So, right, right. That's not the last one that's main message. And thankfully we haven't the mistakes that caused us to do the dot six all that time ago we're mostly mark waits fault and so mark stop making that particular class of mistake. He makes other mistakes now. Yeah, exactly. Great. All right. Anything else on June LTS. Okay next topic then code coverage improvements. You're okay if I have you share your screen. I can't hear you really. Sorry, I didn't find the button now I find it. And I think it would make sense. Is it okay in this way. Do you see the screen and me or is it. Yeah, that's, that's great I just need to change the speaker view so I can see you full size. Yeah, great. And it's a little bit easier for me when I see it here and me on the same page. So, yeah, that maybe just to give a summary of the work we had in the previous session of our UI, where you are sick meeting about the code coverage plugin. The student of our university started to refactor the code and add a new feature that we can only not only show the total coverage of project report, but we now can also see a delta report of a change request. And if someone is changing only three files or so, we can now look at the coverage of the of these three files only, and visualize the results which are actually interesting. So, I don't want to see for a full request how the code coverage of the whole project changes. It's more important I think to see the actual code coverage that your committer has in this will request. So this was the basically the background of the work we added in the code coverage plugin, and to facilitate this new feature, we needed to grab information from get. So we are using the get forensics plugin to look at a pull request which changes we had which files have been modified, and we merged these changes with the coverage information. So we have a mapping of changed files and your code coverage that actually change. So this is a background. And let's see it on the screen. And what we now have is a new code coverage reports or maybe I start here on this build site. Typically, a code coverage report was shown by a trend chart. And this is the old chart. This is not changed yet. We have a trend chart where we see the how the code coverage of the whole project changes from build to build. We see the line coverage the branch coverage and yes, you are not much here in this project but typically you have some ups and downs where you see where the project changes. And now what we have added to the build report is we have the code coverage report for each build. And what I've highlighted now is the previous information that we see the project coverage in one project. And typically, it does not change very much from from commit to commit because if you have a lot of files here in this example I have a code coverage of 90%. And the next commit will not change it to 20%. This is not possible. So what we now have added is this thing here in the bottom, we have a change coverage where we can look at the files that have been changed. Here we have exactly 14 lines that have been changed in one file. In these 14 lines we have now a code coverage of 70% and the branch coverage of 100%. So now we have a better measurement of pull requests. We see how good a pull request is actually for this code coverage. This is one information and let's look at the previous build. So we see how it behaves from build to build. For instance, here we have what I, as in my test instance, I basically built all my releases of the analysis model plugin. I started with release eight, then release nine, release 10 and so on. And every release I created this delta coverage and compare the data coverage to the results of the previous release. And if we look here, we see again, okay, the code coverage actually did not change much only by 0.05 it's almost nothing. Here we see, okay, the change coverage is perfect. We have a line coverage of 100% and a branch coverage of 100% as well. And we have nine lines changed and three files effect. So this is a new overview where we have where we now better see the results for pull requests, for instance. This computation is not only available for pull requests, it's also available if you're just building one build on the master branch and the next build on the master branch, then you can also compare the differences from builds to build as well. So this depends on the reference build we are you are using. This is the same thing I'm using in the warning split. So, let's see. And is there is their source code visualization or really are you okay with questions or would you like to continue before questions please. So the change coverage report. Is there a way for me to see at the statement level which statements were missed in the change coverage is the coverage is there a way for me to look at that at the at the source code level. So let's look at the report. I clicked on the wrong screen. So, this is the new report on the details report and the details report has been rearranged. I'm now using some tabs because there is a lot of additional information I needed to place somewhere. So I'm starting we have some overview, which is the same as in the previous release, but what we now have we have a tap before the file coverage. This is the code coverage of all files of the project. This is similar as we had before. The only thing is that we that we changed visualization that we have now these. Yeah, you can sort and you see the different batches how and see how good your code coverage is. You look at the change coverage and this is the more most important thing I mean, then you can see. When you look here you see the change coverage and in the change coverage you see actually only three files and these are these three files have been changed, and you can now look at the individual lines of these changes and see how it behaves. So, let's see. I think I need to make the screen a little bit smaller. The problem is what we have. We have. Start. I need to read drive. Sorry. Okay, because one problem is where do we show the source code one thing is we can show the source code by clicking into the link and following it. Then we have the source code here. And this currently is the whole source code where you see here is everything is green that means here we have 100% line college. What we also have implemented, but this is only visible on large screens that we have a site by site visualization of this table and the source code. And when you click in the table you see the source code. But I think it's because of zoom change. Let's see if I can make it a little bit. I'm not sure if it will work. Let me see if it. I make the screen a little bit bigger, but I think it will not work. Now we have it okay. Normally on a real screen it looks a little bit better than in zoom it now but what we also have is that we can click here. And then you see on the right as a source code. This does not work on a laptop it's just you need a good monitor, but then you see only of the change what actually so you see it's just one line that has been modified. And this is, yeah, I think a more interesting few for pull requests that you are not interested in everything was what is already here, you will see only the changes which we have in this pull request. And now we have this information we grabbed it from it and combine it with the code coverage information from cobertura order from Chaco. And is this already released and delivery or are you showing us a prototype this looks this looks really beautiful. Yeah, I wanted to release it this weekend, because I need some time for potential bug reports. So, yeah, it's basically it's ready to be released now. I thought to release it today in the morning but then I thought I have no time to fix any bugs that may occur so I thought it's better to release it on the weekend, where I have some more time to fix some things which might not work in all instances. Well, and if the security team doesn't thank you for not releasing it today, I thank you for not releasing it today as a Jenkins administrator who has to update his Jenkins for the security release. I'm delighted not to also have major features arriving in a plug in on the same day. Thank you. So weekend is great with me. Okay, then it's fine. I will release it I think on the weekend. And then everybody can look at it what I also change this we have this this chart here, where we see the line coverage information. This is already part of the last release what we now also have we can look at the same chart. If you look only at the branch coverage. And what we had this chart as well for the data information, but for the data information, it did not make much sense because we only have three or four files so actually I removed it now. But the information would be available if someone is interested. Yeah, and the nature of this chart is that it's showing me based on the size of the box that's the number of files that are in it, or the number of lines. Number of lines is currently used as metric. And then the, then the coloring is used to hint what fraction of coverage is is covered. Yes. For instance, here we have only 55 58% and here we have 83. And this is currently not customizable. But in future releases we can add a customization that projects which have not so good coverage can reduce this information so green is maybe green if we have 80% for instance. But this is not yet possible so one thing after the other. What's also not ready is, you can click here but you can see the source code now what I want to do is linking to the source code as well. So that if you click here then they can see below the table the source code that affect effectively shows you which lines are covered in which not. Just to come back to the data coverage the change coverage. Is it something that is available in the pool request as well. It will be available in the pool request as well. Actually, I did not test it yet for pull requests, but for pull requests we have this so called a reference build, and the reference build is the built in the main branch, where we have information the same information and then we are comparing versus this reference build. Perfect. Thank you. Any other questions. One thing I would like to highlight here is, it's more a question. Well, I had a lot of problems to fill the screen to the entire screen area. And I'm not a JavaScript expert, but I think the problem is that our Jenkins layout is somehow strange because our navigation here is part of the screen. So, do you know why we have this navigation and not separated from the screen that I can scroll the screen and the navigation will stay. Because currently we have just one page which scrolls the navigation and the screen, which no other website is doing. So basically the website you have here a separator, let's say, and then you can scroll the navigation separately from the content. And I thought that was intentional because of, and it's legacy certainly intentional 10 plus years ago, but it was intentional because of the poverty of frame sets right. So that the UI, I think Daniel Daniel's comment in the chat hints that frames frames have had a different set of usability problems. We're actually looking at possibly injecting something like that on to Jenkins.io, WW Jenkins that IO as a way to help the navigation there for large pages, but it's, it's a complicated problem trying to get those left sides, the sidebar stable to hold still while we move around on the right hand side. So just in case it's possible to do that we thought frame with just regular div and the scroll bar being for a specific area, so that we are two separated. Now, I think your example in the current page is a bit particular because we don't expect to have so many items on the left side. It's between 10 and 20 maximum in your case I think you're close to 30. So it's also perhaps part of the issue there that it was not really expected at that point. And it depends a little bit if I'm showing this thing on my laptop screen or if I'm showing it on my monitor and currently, I can say to the browser to JavaScript please fill the screen. For this box here, for instance, but this box, the screen means it go to here to the, the footer and that is not really the screen I want to show only use the place which is free for or visit which is visible. So this would be something would be really helpful for you I design if we can have this navigation bar even typically if the navigation is too big. It is going in an off screen navigation where you can select or deselect it. So maybe this would be something would be very helpful if we can add it in Jenkins. Now, just to fill the page, there are some ways depending of what you're doing exactly potentially with a flexbox, it could be sufficient or perhaps looking at the, I don't know, the sizing vertical of the panel, it could be interesting perhaps if you're trying with VH equal one things like this, meaning it's equal to the full site that is available for the screen. There could be some ways to do like this. Not to exactly what you are using at the moment so we cannot help more I will say. And maybe another thing what we implemented is now we have some responsive design for the tables as well. That means the content of the tables changes. If your screen is going smaller. So if I go smaller, then, yeah, okay, then the package will disappear. So it depends on this is I think very helpful if you have only a laptop or you have your tablet, then you basically see only the file and the line coverage and the branch coverage and the rest is disappearing. And this is something which is automatically provided by the data tables. I'm using here as a back end. And, and that risk that definition of that responsive which thing should be removed that's part of the part of part of how you define this page. Yeah, I'm using a Java model in the background or this is an implementation from my data tables plugin. And this in this you define for each column a priority. The integer number and, for instance, the package has a very high integer number that it means it's not really important, but if you have a place, use it. You can define these numbers and then data tables will automatically hide these things which are not so interesting. This is quite, or I'm using it quite often because on the laptop I don't have so much space and on my monitor I have very much space where I would like to see everything if it's possible. And I'm wondering if we need to use what you're doing in the Google Summer of Code project for automatic get cash maintenance in terms of presenting its results, because there may be lots of, there may be many things we want to show some of the much less important than others. Thank you this is good to know that the capabilities there. Yeah, that's basically what I wanted to show any other questions on this topic. Okay. None from me thanks really thank you very much. So I'm going to go back and share my screen let's switch back to the agenda and you should see the agenda now. So the topic was vatic to two items related to security vatic is there anything that you would like to share your screen with it, or do you want me to just keep the notes up how would you how would you prefer. I'll just open the pull request that's fine. It just a general situation that I have seen recently occurring more and more. It's some people that are not really integrated included in the UX meeting that are trying to do their own improvement on their side. And there is another parallel effort done by the C meeting people that is overriding a bit the effort from the orders, not necessarily. It was the wheel to override the effort from the orders but it's more that for the contributor at the end. It's like, oh, thank you for your job but we have been something else in the meantime, so your code is no longer very valuable for us. It's this kind of thing that is a bit annoying to see there. I'm not saying it's something to someone to blame or things like that not at all. It's really. Is it something that we want to do or not like in this case that person perhaps could be interested to join the C meeting to discuss to show his full request or have other people working with him, instead of doing their own job on the other side. We don't want to open the discussion. No, we don't have a lot of people in this meeting right now so that's why it's a good moment to discuss that, but just to highlight that fact. Thank you so the concern here is in July of last year this was submitted, but in the intervening period there have been changes which made this either not not helpful or no longer necessary or. Do I remember correctly Vadek you have totally missed. Now that's that you can look at the one of the last comments. It's mainly yeah, in the meantime, we have done something that will make your request no longer valuable so that's this kind of thing. And that also with tooltip someone proposed to have some tooltip using the direct to the title or the tooltip inside an attribute. And that was mainly rewritten in a different request by using typing the gist is nothing. It's more about to align the effort from the different people to prevent people, especially like that guy who are spending some time but not a lot on his request. The end is overtaken by someone with more time or more expertise in the project. Thank you. So, so here I think Alexander brand us was suggesting. Hey, it's, it's a bad pattern to have something a relatively small change different diff content wise on on unevaluated for a year and Basel notes. Then there are some additional challenges in this particular one. If it if it actually applies still or not so there there's certainly more to be done here. Good. So I assume we may want to bring this topic again in future meetings just as a reminder, or do we systematically want to look at pending pull requests on UI. Maybe we should be labeling the pull requests for UI and and remind ourselves in this meeting hey which ones are are pending review and we could use people looking at them. It could be a way especially because the meeting is monthly so if we are waiting at most one month before looking at that at least once. I think that's perfectly fine and a lot better than the concentration. Yeah, so I think. Now that means I've got to take some, some initiative and look at the pull requests and identify which ones, which ones are UI and possibly tag them but I think, I think that would be a good thing to, to add to this meeting agenda just. I know it's it's turned really positive in the doc sig when we've done that a little embarrassing and that we look at some really really old pull requests, but we're actually closing them by looking at them. So, good, good idea so let me, let's try it and next month I'll try to put that on the agenda I will put it on the agenda and we'll we'll test drive it to see if it works for us. Thank you very much. All right, anything else on the the long on. There was a phrase that Basel used it was long, long live pull requests that are stalled. There you go. Anything else on stalled pull requests. Okay, next topic then. So the next one is a bit less happy I will say you have perhaps seen we have released especially thank you Daniel for that a new version new security version today as you mentioned before. In that version, we are correcting five vulnerability that were recently introduced in Jenkins core. I will say mainly I'm not totally sure but mainly related to the UI, at least for them. And the issue there is mainly it's very rare in the past history of Jenkins that we have seen such. I will say, newly introduced vulnerability most of the time is things that we are finding from the past. In this case it was things that were recently added by accident of course, but it's just the fact that it was a bit of change of a piece in terms of introduction of some things. That was a bit annoying me to see we had to work on that very quickly urgency in some sense to prevent that to stay for long in the project. So that's a bit painful to see the effort that is needed to correct them after the prerequisites match, compared to correcting that during the progress. So, for that, I would like to block all the UI pull requests until they got an approval from the security team. The goal is not to block them forever to not review them and just to block the process at all. It's not at all the goal. The goal is really that we got someone from security to review the request. I will assign people more resources in general from my team to work on that to put the effort to review the different things, especially when they are close to the mayor. So that we are reducing the likelihood to introduce new vulnerability. That's a bit the idea there. And I wanted to discuss that with you what do you think is it something that you think will be joining what could be the better part of any thought about that aspect. For me so long as security team members are assigned and have the capacity to do it I think it's great the danger, the danger that worries me about those is about that is if they don't have time to do it, then it's just a block on the pull request without any without any progress. But if you're assigning people I think that's that's significant positive, because that means more people are reviewing the pull requests in general, not just for for security. So I think that's great. That's really the goal. If at some point we are no longer able to provide the resources. It's mainly go with us in a sense. I don't want to block the improvement, the different UI revamp, if evolution and Jenkins are very nice very great for the community. It's really not the goal to kill this kind of effort. It just to be there to prevent the vulnerability to be introduced at that point. And most of the time, it's because of a single line that is not written the correct way it is kind of thing. So it's really a quick correction in the pull request, but if we have to do a full security release for that. It just a ton of work that we have to do instead of the client change. Right. Well, so I think you just highlighted it's much better for us to detect and correct a security risk before the merge and before release in Jenkins core. Yeah, exactly. The side effect interesting leader is that we will have more people as you said on the pull request to review the stuff because I don't expect the security people who are doing the review to just look at the code. I expect them to play with the pull request to try with payload everywhere like you can imagine with security people with XSS payload everywhere in the screen to see if something is triggered. So it's also a way to see there are some regression things like that. No, it's not the goal to look at quality only but it's just a potential side effect. That makes sense to me any any concerns from others or any insights that others want to share. I think if we have the resources, it is really good. But currently we have a lot of UI changes. So maybe this is also the problem that we have so many bucks, because we have a lot of new things which appear. And the last 10 years and actually nothing happened on Jenkins UI so I don't think this is a problem. This is just a lot of changes cause a lot of problems. That is, I think, normal thing. Totally. If you are doing nothing, you will not introduce this but it's expected. So yeah, I hope to have at least one person if you bring the pull request fairly soon on these kind of things. Concerning that if there is no, yeah, good. It's fine. That's fine. Yeah, sorry. So if there is no objection to this kind of thing, I will send a message in the group for the developer of Jenkins to mention that new policy in a sense with the blockage of the different pull request related to the UI. So the point you mentioned before concerning the label the tag, but the UI will be more important as well. And also I think basically created a label especially for security review, something like this. It could be also used for this kind of thing to help us knowing which one the UI people would like to get a review, because I don't want to review a pull request that is expected to take, I don't know three months to be completed. The review need to be done, of course, as soon as possible, but if we are constrained in terms of resources and prefer to do that close to the end, instead of doing that multiple times during the work on progress. And of course, you will be revised over time if we are seeing a huge progress in terms of quality, like if we are not able to correct anything because there was nothing wrong in terms of security. We will reuse this kind of requirement policy in the mid long term. The sooner the better I will say from my point of view to prevent resources to be spent there but that's really for the use of the project. Excellent. Thank you. And another question for me. These new your problems we, which have appeared that we have some ways it's possible to use some static checkers that find those security problems or is it just someone needs to look at it. I will say thank you very much for the question but at the same time not thank you. It's a problem in Jenkins in the sense that we are not using regular view templating with jelly. It's particular. So we are not able to find this kind of thing very quickly. We are able to have some custom rules in code, for example, for regular Java code to find all you are lacking these kind of annotation you are lacking this kind of thing. But on jelly it's a lot more complicated, especially these excesses that we have found recently, where I will say complicated to find just by looking at the code. It's a matter of things that are not escape it or escape it but then unescape it some JavaScript that is then passed and executed. It's really a multiple step effort to have the vulnerability really impacting the project. So, that's a very good question we are asking the question or self what we could do to prevent this kind of thing to be introduced. And I'm getting the question also from a lot of other people you can imagine. At the moment, we do not have a good solution. It's something that we can work on trying to find a way, especially with code QL, there are ways to parse a bit more the XML of JV, this kind of thing, but that will also require some additional logic to cover the pure JavaScript part that is more complicated to analyze static games. So some of them could probably be taken care of by having a security policy, but that's a big project so it doesn't help us in the next year or so. I think it would be at least helpful if these five problems we have would be clarified a little bit on the mailing list, for example, that other developers would see what actually was a problem. Currently, I only see we have some vulnerabilities, then I upgrade my Jenkins and everything is fine. But what for me as a developer would help if I see what actually was the problem, what should I avoid in my code. So I'm not sure if we can extract this information at least a little bit for the developers. Don't do this and don't do that. So in this kind of style, maybe that would be helpful as well. We have test cases. So if you're looking, if you're trying to understand a specific vulnerability that we addressed, you can look at the test case testing that it is actually fixed. And that should give you an idea of what not to do. Some of them are kind of artificial necessarily because Jenkins is a framework for plugins in a way. And so it's not immediately visible in all cases how this would be done. But one example is don't build an HTML string that includes user input without properly escaping that user input. So that's really cross-site scripting 101 right there. And just to do some advertisement as well for CSP, so content security policy, it's a project that I would like to put more effort in. I'm waiting perhaps for October Fest again this year to have all the contribution there, but that could be a way to prevent these kind of successes classes in general. That could be nice but as Daniel said, it's a long long project. We need to have a better ways to do security before. Any other question. So looking forward for the accessibility topic. Okay, so this one is just a reminder that at our last session or at a previous session I noted that a company had contacted me saying, Hey, we've done a Jenkins user interface accessibility assessment. It's German language, we'd like to contribute it to the community. What's the most effective way to contribute it to the community. And my thought was should or my questions were things like shall we one get it translated from German language to something I can read as in English. And then to do we create in an epic in Jira that describes these things with individual topics, or do we just create the epic and wait for for people who have capacity you know is it. It's premature to create a bunch of issues in Jira for accessibility improvements. Rather would it be better to think about accessibility in some different way, prioritize differently, etc. This is where I'm, I'm looking for input from others on what's, what's most effective in terms of how we interact with these observations about accessibility that have been made by people as part of their company evaluation of Jenkins. Perhaps do you have an estimation of the number of tasks that you would like to create like is it just five or six or more than 200. Oh, I would guess it's on the order of hundreds. I haven't looked at the report specifically but considering what these these kinds of assessments usually detect. I would expect it to be on the order of hundreds, probably not thousands, but hundreds I could easily see where, hey, missing tab navigation for this, or doesn't have screen reader support for that, or lacks a keyboard shortcut here that could help the user in this way, those kinds of things and, and they they're quite frequent. My recommendation will be to mainly get some tasks more as a spike to analyze the reports and to categorize a bit the issue. Because for example if something is related to the missing text for icon, it's something that could be done at once in the jelly tag directly. So for the tab navigation that will require revamp of different pages, that's something that need to be grouped together as a category in an sub epic this kind of thing that could ease a bit the work there. Okay, so so maybe outline it as stepwise saying hey first step is we need to review and assess. And as part of that review and assessment that probably involves a grouping and a prioritization and possibly a partitioning of here's here are various classes of of interesting things that this report gave. Yeah, okay, review, prioritize, summarize the areas, areas, impacted areas. Sorry, go ahead, but perhaps if you have the opportunity to discuss the topic with Christina, it could be interesting because she has some accessibility sensibility, I will say. She was really interested in the topic. Potentially she could help also in terms of prioritization categorization this kind of thing. Yeah, and Christina's attended these sessions previously so that's, that's a good idea. Excellent. Okay, good. Any other observations or recommendations there. My specific request to the submitters was, I don't want to treat their, their work with disrespect in the sense of putting it into something that then we don't get the benefit out of it. I would like the idea of review prioritize and summarize because that's giving us real value. Great. Thank you. I think it would be really helpful to see this report somewhere publicly. So, I can read it for instance because I'm interested in you I think so. There was such a report about usability a couple of years ago. It was also in German, and it was really helpful for me to read it to see what I'm doing wrong in my plugins. So, I think it will help people if they have the time and interest. It's better than have it just in a box and nobody looks into it so attach it to a Gira and then everybody who's interested can look at it in the first agreed and I think I think that's a that's already a good first step just attaching it and using that as an epic gives us the source document and the source document for those who are already comfortable in German language is already good enough right that's already a great start. And, and those of us who are not comfortable in German language can always apply Google translate and get it get some help with Google translate to generate it in, in other forms. All right, so let me put the action item on on me. And I'll double check that I've actually got the source document. Thanks everybody. All right, and since Jan had not joined us, I'd propose that we delay the UI improvements topic until another time. Any other topics that need to be discussed in UX today. All right, thanks everyone recording will be available in probably 24 hours or less and will post it. So Daniel asked if it's do it's telecom I don't think so but I don't know who it was. So I will certainly look up that document and Daniel I think I'm going to put a link to that document into these notes. Thanks very much because that way I've got a reference to a past historical document. See previous from do it. Thank you. Thanks very much. Any other topics for today. All right, recording will be posted in roughly 24 hours. Thanks again everyone for joining.