 Welcome everyone. This is the Jenkins platform special interest group and let's take a look at the agenda for today. So this is what I've got. Is this readable enough for everyone on your screens? I'm using a tiny size screen and I'm not sure what works for you and what doesn't. Yeah, looks good to me. Great. All right. Super. So what we'll do is we'll review the open action items. Oleg had suggested we might put a quality outreach program topic on. I would hold that if he's here and leave it. If he's not, we can talk briefly about it, but then adopt open JDK for Docker on Debian. Retirement plan for stretch is the topic. What other topics would you like to add to the agenda? Jim, I believe you had one with regard to simplified labeling. Yeah, Mark, I was actually just unmuting myself. Simplified labeling, I actually got down my action items, so I need people to review the PR, but we can talk about that. Oh, good. I see it. Great. All right. Any other topics? Alex, any topics from you? No. Gareth, I suspect we need to talk about Windows and Docker images for Windows Docker images for LTSC 2019? Yep, sure. Okay, great. All right. Any other topics? Okay, then let's proceed. Hello. Oh, go ahead. Yes, go ahead and be back. Sir, can you add a topic for Docker file in detail a little bit? Sure, sure. So is this a discussion about its structure or what's the topic? Yes, sir. Sir, by taking one example, you can show me the Docker file. Oh, all right. Sure. All right. So Docker file content tutoring for Vivec. Okay, good. Yes, let's put that there. Okay, anything else? Okay, then let's go ahead. So I still have the action item for the JEP for Docker operating system support and platform selection. I did the sampling of the data for the Docker image, so for the controller image, the various agents, and those samples told us that we are relatively okay right now for operating system support. The big gaps or the big danger zones are Docker Debian 9. Ends, end of life is coming in 2021. And we've got some outdated Java version on the Debian 9 image. It's JDK8u242 instead of 272. So the proposal will be to, and I think I mentioned it here, the proposal is that we run the current JDK on each image. And we want to run the, let me put it in the list here, proposal. Current JDK on each image and loss of the current JDK support would officially drop the platform. And a supported or platform supports, let's say specifically the operating system supports security patches still. So that would cause Debian 9 to automatically drop early next year when they stop security patching it. Any questions there on that action item? And I suspect I'm still one to two weeks away from getting that submitted as a JEP. Okay, Alex, we had a topic investigate CentOS options for adopt. Yeah, so I looked this because we're currently just using the M repository directly that comes directly forced into us and it's using just open JDK. So if we wanted to make sure that we're using the same version on all images, we would need to update the install and use the adopt open JDK YAMR repository. We're checking the together PR form. And now does, does adopt provide a YAMR repository? We would just install it as a GZIP as a tar file. I, they do have a YAMR repository, so we can do either method. I guess we should probably start using adoptium instead of adopt open JDK, but that's not a big deal. All right, great. They changed their name. Oh, right, right. Exactly. Sorry. I should, I should use the correct name adoptium. Thank you. Okay. Any questions from others on the CentOS plan? Looks good. Okay. All right. Next topic was Alex submit a pull request with a deprecation notice for install plugins.sh. Yeah, that's been done. It was merged. Oh, and, and actually I should report on that. The plugin installation manager tool is now used for, for the standard install instructions. It's also used in the, all the windows controller images. There's no install plugins script. It's just the plugin installation manager tool. Oh, this, I missed it. Alex, where is it used also? The windows controller images. Oh, good. Okay. All right. So windows controller images. It's also used in the tutorial, the build tools tutorials. Very good. Okay. Yeah, it raises importance of fixing the remaining regressions in plugin installation manager because there are bugs in this tool. Yeah, yes. And so they become, it becomes official. Once we ship all tests with this version, it might lead to some problems. So, and are those bugs worse than the limitations of install plugins.sh or, or just critically impacting the, or critically impacting the, No, critically issues have been fixed. So there is one issue with determining the target version property because in some conditions, plugin installation manager selects a wrong question for installation and it pulls dependencies from wrong question. So basically, you may end up with a desired plugin set. Thank you. Thanks for the clarity. Okay. Imple dependencies from the wrong version. Yeah. So how important is it? Well, the users who are running install plugins.sh, they will get different behavior in some cases. So for example, the residual 193, which is still open, I guess. Yeah. Tim has assigned it to himself, but it's still there. Thank you. So should we, is there a, is there a reason for us to delay further the, the widespread use of plugin installation manager or rather we just accept that we need to, if, that we continue with issue 193 open and hope. I would recommend to at least have opt out option. So if users are unhappy with how plugin installation manager tool works, they can switch to install plugins.sh. The downside is that plugin installation manager tool doesn't fully verify the dependency tree. So it means that in some conditions, you may end up with a broken Jenkins instance. It'll stop and cup. So if you change the default behavior of install plugins.sh. Okay. Thanks very much for that clarification. So it might result in a broken Jenkins install. Great. Yeah, not great. Well, right. Thank you. Okay. I'm just raising the flag so that the team is careful with updating the version. Sorry, I was unable to follow Dr. E. Mitchell. Well, and it's important, important point that you know, that may lobby that we should not add, we should not obsolete install dash plugins.sh until we're, we have more confidence that all the use cases are covered well enough with plugin installation manager. We may make plugin installation manager the preferred choice, but better that it we use, we have it still available to use install dash plugins.sh. Great. All right. Okay. I had the action item. Oh, anything else on install plugins.sh. Alex or Ola? Nope. No. Oh, actually, yes. One thing. As part of that deprecation, we did remove the old, old plugins.sh. It was used a long time ago. That has been removed. It was more deprecated for some time. It's now been removed. And have we seen any, any shouting outrage or concern red flags raised? Okay. Yeah, this script was deprecated in 2015 or 16. It hasn't been really updated for a while. So I don't think there are any legitimate usages at the moment. Great. Okay. Thank you. All right. So anything else on plugins.sh or install dash plugins.sh. Okay. Next topic then. Mark has, I have the option action item to prep a, a blog post on plugin installation manager and update center. Still pending. I'm delighted with the, with the results we've got with the number of places we're using it. It's likely not likely for one to two weeks at least due to other, other load and, and holiday time. If someone else feels like they would like to take that instead, I could pass it to them. Otherwise, I'm just going to get to it as I can. Maybe for these topics that make sense to create tickets, for example, on Jenkins Ion, that somebody else could potentially pick them up working. I'm not sure that it's that efficient. It's a good suggestion. I think it's, it's an interesting one to allow others to yeah, good. I like that. Jim, you want to take us through refinements for parallelization and multi-arch. Yep. I've been working on a PR for the last couple weeks. I actually just submitted it yesterday afternoon. The PR rewrites some of the build scripts. Yeah, the build images, build tags and build manifests. And then you have a wrapper around those three scripts. The wrapper is really utilized for CI, CD implementations. It's pretty easy. You just say, hey, I want to build Debian images. And it will handle all the tagging, all the, you know, both tagging, scanning the Docker scan, the repo for Docker files and doing all that for you. It's pretty simple to use. I have documentation in the CI folder that kind of goes over each script, the parameters that you can pass in, and a couple of examples. Excellent. Thank you. And you say this was submitted just a day or two ago, so it needs, needs review and yes, now does this include the new tagging, the new tagging, the clear, simpler tagging proposal that you've had been talking about? Yes, yes it does. Includes the reverse tagging and then keeping pretty much all the same tags that you got off right now. I mentioned this in the PR. The only tag I didn't carry over was slim. I opted more for just clarifying it's Debian slim. So, you know, you can see the difference. But it's easy enough just to go in there and add in slim. It's just one if statement that I need to add in if we want that. Yeah, the only other thing I would need help from Alex probably on the parallelization. I did not touch the Jenkins file as I'm not really that verse in groovy that much. So, I would need some help kind of adding the parallelization to the Jenkins file and pointing to the right scripts to call. And I mentioned these two points in the PR as places I need help to kind of finish up the PR. Excellent, thank you. So, Alex, any any insights that you want to share with regard to the verbose tagging? I believe you and Jim have worked together on this. Are there incompatibilities other than the Debian, the slim to Debian slip transitions that it introduces? Jim has done all the work. I've done some talking through things on data and stuff. I need to review the PR, so I'll do that today. There shouldn't be any incompatibilities. I tested it pretty well. It's just the the only tag that doesn't exist or carried over or the the slim tags. Can you add the the Docker repository you're pushing to just so we can review that as well if you add that to these notes? So the Docker destination repository, is that what you're saying? But I think you've been testing pushing to like a personal Docker hub. Is that right, Jim? Oh, yes, yeah. I can add that in the PR. So you guys can take a look at that. And now will this alter how we do how we do our actual our production builds? I assume it will. Yes, it will. And and does it I assume it continues the the push to Jenkins for eval of the S390X image, the power PC image. Is it also pushing an arm image? Yes, these these. So the scripts you can run images and tags, the published images, published tags on well, they need to be run on arch to generate the S390 arm or power images. The manifests can be run on any arch actually constructing the the manifest is for manifest, you're just pulling down all the images. They don't actually need to be ran or anything like that. I think technically tagging you don't need to run on a different arch to put. Excellent. Okay. So so and just for my benefit then so target architectures that we're talking about right now there's AMD 64 S390X arm 64 power PC 64. Have I missed one? No, no, those are those are the four I target. And just to know I did not touch just kind of like have the build structure before I did not touch the windows images. I kind of left those separate. Okay, but but that is currently separate. Okay, and that's a good one for for Gareth to report for us on how his progress is going there. I'm not sure what it would mean yet because don't I do I remember correctly that the windows images are generated from PowerShell scripts not really from make files? Correct. So the windows I believe already matches the tagging that Jim is proposing for the site images. So I think we're okay in terms of the naming and the tagging there, but it could use a review. Another feature I did add in that might be of interest to you guys from seeing the email chains on Docker Hub is new limitations and stuff like that. I know I think you guys got sponsoring right for for Docker Hub. Yes. Okay, so the one thing I did add was there is an environment variable and I mentioned this in PR you could you can actually override changing the the image repository you guys pushed to. So if you ever want to start publishing for multiple repositories like QuayIO or GitHub's Docker repository that is possible with scripts too. Excellent. Okay. Anything else on that action item then? Nope. Now, Oleg you mentioned multi-arch image supporting custom warpackager. Did you want to give us an overview of that? Yeah, it's just a related thing. So Rick today submitted a pull request yesterday which allows building multiple platform images with custom warpackager. So now once you have a base image which supports multiple platforms you can give the custom image which would also support these platforms. Basically that's it. So that would conceptually then that would allow custom warpackager to be used to build an S390X or an ARM based custom war packaged for that specific architecture. Exactly. Okay, so it allows the user to combine controller and plugins into a custom war that is platform what would we say generated specific is focused is targeting a platform? Yeah, so basically you can add additional parameters to custom warpackager definition and it will be built for this sections. That's it. You can open pull request other examples and them added by Rick. So it's not strictly related to this story but well I guess it's contribute to the overall distance. Yeah, that seems very nice. Thank you. Okay, excellent. Jim, anything else on the topic for parallelization and improvements in CI? No, just need some reviews. Make sure that there's no issues. Great. Thank you. All right, next topic Oracle JDK Quality Outreach Program, Ole? Yeah, so a few weeks ago the Oracle team, Open JDK Jigsaw team reached out to me to check the status of our quality outreach membership. So just to clarify, Kiki added the Jenkins project to quality outreach when we were doing Java 10 plus support hackathon. So it was 2017 or 2018. We had quite productive discussions with Open JDK Jigsaw team at that moment. We basically were able to support Java 10 then Java 11. But we haven't been really active with regards to supporting the higher Java versions. And this topic might become actual when the new Java LCS is released. So far the plan is that it will be Java 17. So half a year from now we should be able to test the upcoming LCS. The problem with that and basically what quality outreach team raises that we as a project, we haven't been really active in quality outreach program. So there are some expectations and there are some benefits. We haven't been using any benefits like direct access to Open JDK team, troubleshooting calls for regressions, etc. And at the same time, we also do not contribute to this program because we expected to provide testing results. We expected to release candidates and final versions and eventually to provide support. So we are doing none of that. And hence there was a pretty valid question is whether the Jenkins project wants to remain in the program. And I think at least as I consider that I don't think we should remain in the program because we're not contributing towards it. Do you have a strong opinion one way or the other? So for me concern is the next Java LCS version. What we currently see that adoption of Java 11 is extremely slow. And even if there was Java 17 or Java whatever LCS on the market, I'm not sure which percent of our user base would really stick in the move there. So we could greatly increase adoption by making Java 11 by default in the Jenkins project. But even in 2020, it still looks like a nuclear option. So does it make sense to support Java 17? Probably yes. But it means that we would be supporting three LCS baselines. You would need someone to actually add support at testing. You would need to create CI CD pipelines, increase cost of all testing across the CI Jenkins organization. And if it happens like this Java 11, when we have less than 2% of users running this version, I'm not sure what's at the point. Yeah. And that's I think you've got an excellent question there is what would compel us to use Java 17 to make Java 17 supported with the increased cost that go with that when when low adoption is probably predictable. Yeah. Well, Java evolves new features really improve performance. They really improve stability of Java. So there is a reason to update. For example, we run CI Jenkins on Java 11. And if you're using newer versions, we would have even better the garbage collector, we would have even better diagnostics tools. So in principle, it makes sense to update, especially if you run your own service. And when cost of operating with service is something important to you. But if you ship on premise version so that others run it, basically others, yeah, if performance of Jenkins is 10% better on Java 11, I'm not sure that many users would upgrade because 10% isn't noticeable for them. I see. Okay, right. So for service provider, 10% is quite visible for end users, especially on premise. And yeah, this 10% I just made up a number. But yeah, the principle that while there is considerable improvement, it's still not a point for instances which just work at the moment. Right. It's not likely to be enough that they would detect dramatic changes and say, oh, wow, this is perceivably better for me as an individual user. Got it. I think I understand your point. Thank you. Yeah. So yeah, that's why I wanted to discuss it in the platform seek because although support for Java 11 is interesting in principle, for example, official support for ARM and for other platforms, it seems to be much higher on priorities. And that's a good point. For example, we can't fundamentally support the adopt OpenJDK JDK8 on system 390Z because it doesn't use just-in-time compilation. But Java 11 does use it and is great. You've got a good point that there is a motivation on S390Z and other places that Java 11 just behaves better. All right. Anything else, Oleg? Should we call for a decision here? Call for it because I think we've got the right people on the call to decide if we should if we should continue being part of the quality outreach program and just then give them the answer accordingly. Would that be okay or do we need the governance board to get involved in that? I don't think the governance board was involved in the initial joining of it. I'm not sure that the governance board is needed because firstly, we have support for modern Java versions on our road map. I guess it's common sense that if somebody wants to contribute, yes, of course, let's do that. The problem is whether somebody wants to contribute. Even when we were doing Java 10, Java 11 support, we organized the hack fest. We also used other events. We had more than 30 contributors in total. But at the same time, a significant part of changes came from Cloud Visa Bitpoint. I'm not sure whether there would be investment in Java 17 support at the moment. I'm not a product management manager, I cannot say. I do not expect Java 17 investment from anybody that I know of. Except Oracle Media. And they've expressed their interest. But again, the interest we got from Oracle was Oracle Cloud, not the Oracle Java team. So even they may not be that focused on Java 17 support. Good. Okay. So yeah, at some point, I wanted to just poke recent Java versions to see what are the obstacles. But I can confirm that Jenkins doesn't just work. So we will again go through all these Jbos marshalling, through ISM updates with many potential regressions because we use ISM pretty much everywhere across the project. So in principle, having, let's say, a hack fest like we did in 2017 for Java 10 would be nice just to crunch and see what are the issues. Like for Java 11, many things will work out of the box after some patches. But still, it requires time. Got it. Very good. All right. And that feels like we can do that independent of whether or not we're part of the Java quality outreach program. Yeah. So Java quality outreach basically helps us to get support. But to do that, it should be a win-win. So it's not something like we are not doing test automation. We are not really helping quality outreach team, but we request support. It would be quite unfair. So I think what I'd like to do is propose just a poll here of those on the call. Should we remain members of Java quality outreach and attempt to increase our efforts? And if so, who? Or should we step away from Java quality outreach and admit that we're not able to participate? Whoops. Just a minute. I think if we're not actively participating, we should just step away. So plus one from Mark to step away. I should state it differently to officially state that we are dropping. Because I don't want the Java quality outreach people to think that we're somehow going to step up and do more, or rather, let's just step out. So Alex, I took that from plus one from you as well. Oleg, your feeling? Plus one. I think I'm not always through term if needed. Okay. Jim, any objections from you? Nope, plus one. I agree with Oleg. We always can just come back if we want to join in that time. Any others that would like to voice their plus one or minus one? Okay. All right. Then that's resolved, decided. Oleg, is that something you would notify them of? Do we need to notify them of this? I can take an extra item for that. Thank you. All right. Anything else on Java quality outreach? Okay. Next topic then. Adopt Open JDK for Docker on Debian. So this was one that Alex and I had taken on because right now we ship the open JDK image on our Debian, our most popular Debian distributions. Isn't that correct, Alex? Did I do I remember that right? I think now we only do that on stretch. I think on the buster we are doing adopt open JDK but I double check. Good. So that's on stretch and stretch is the one that is used for latest? Currently, yeah. And I think we decided not to do it for stretch just because we're going to be deprecating stretch soon. Right. Okay. Yeah, I was going to actually ask about that. It was the end of life stretch I think kind of came. Maybe not for LDS but the basic versions. And I don't think adopt Open JDK or adoptium produces for stretch. I think they moved on to buster for the LTS support. And I think that makes perfect sense. I don't think we should spend the energy, let's spend the energy to transitioning the latest label from stretch to buster so that it gets on to a version that has another year or two of life at least. So any objections to that? So we just allow the stretch image to retire as its current configuration using Open JDK and it's currently using Open JDK 8u242 currently and it will just stay there until we obsolete it. It remains until stretch is obsolete or they upgrade JDK. They do the upgrade themselves inside the stretch base image. Is there a date we want to have set in mind for that? I think for me it needs to be by, I would assume by March 2021 seems like a likely release date for the next version stretch or the next Debian release of bullseye. Of bullseye and with that stretches is dead or stretches then unsupported completely. So for me that would be and sooner than that is better. Now the March number I checked if they had published an estimated date and the Debian project has not actually published an estimated date. They just say 2021. Does that answer your question Jim? Yep. So I think that anything else on the DOP Open JDK for Docker on Debian? Alex any any concerns there or places where this is this is a bad plan something like that? No sounds good to me. So retire and so I just to be sure I think what that means is we will the label latest will switch at some point in the future from stretch based to Buster. That way I mean we can't we can't continue supporting stretch after the operating system support for this stop security patches we're not going to do them to Debian for sure. Mark if I'm not wrong I thought the the latest actually points to Buster right now. I don't think it happens for me when I ran my test. We updated the latest to Buster this summer. Did we? At least for agents. I'm not 100% sure for controller images. For agents we updated them when we were cleaning up the terminology at the same time Alex submitted a pull request for Buster so it was also integrated and later we retrospectively we added stretch bike. But yeah they believe that we immigrated everything to Buster by default. Yeah I'm reasonably confident that the controller images are still are still shipping stretch but I'll have to double check. The Debian so the like the make Debian in the make file is using the Buster directory. Interesting because at least I'm quite confident that my image that's derived from the LTS the LTS latest so 2.249.3 dash LTS is in fact based on stretch so all that we may have this may indicate that we've already solved our problem I didn't realize that I'll have to I thought that when I ran my test I had we had a quite we had several operating system several tags that are still using the stretch image but I'll double check. Great excellent thank you so that's we've made more progress than I realize that's really good. Okay so next topic was retirement plan for Debian stretch in our docker images and I was I would like to do that just as part of the docker platform support JEP. The thought was we declare inside that JEP some rules operating rules and the operating rules that I was considering was supportive and operating system ends when up being secure upstream security fixes and or when we have and now this is one I would like to suggest that we use an adopt adopt an image image program similar to the adopt a plug-in program that we use and that we have the concept of a maintainer for each image what I've seen is that I don't monitor the sentos images for instance because they just aren't relevant to my use cases but there are probably people who do and so we would like I think we need the concept of a maintainer for each image and I believe the github code owners concept may help us there I'm open to the comments though is that with clearly communicating who's who the image owners are or the image maintainers are it should be good enough all right any any objections to that those any of those concepts while I'm getting this JEP ready no I think okay okay great let's submit the JEP right and submit the JEP great next topic simplified labeling of docker images Jim um yeah so the like I mentioned before the PR has been submitted the whole point of this is to add a couple more verbose tags uh the idea is you publish the super verbose tags uh which include the JDK JVM OS name OS version Jenkins version um yeah I think that's actually it's um and you publish those and then you re-tag those with the the tags you guys are all used to like slim uh Debian latest LTS um and basically that way if someone needs a super specific image like if you want to pull like an open J9 image where we don't have a super simplistic tag for open J9 I would be able to pull down a super verbose tag and still get the the configuration I want and the the new proposed scripts do all that plus keep all the tags except the one I mentioned slim which that's an easy fix if that is needed excellent and now was that that PR just as you were describing it that submitted to the to the controller I assume it probably was not submitted to the that we'll do it on the controller first and then consider adding it to the various agents or is that the agents don't particularly need this as much as the controller does um I don't really use the agents that much so I probably can't speak for that uh but my assumption is the agents probably don't need it as much unless uh there is a very big uh case where you know the agent you know JDK JVM and OS actually matter um a lot yeah well like you've got lots of experience with the agent images um what's your sense there in terms of adoption or of operating system preferences do I think that for agents we can keep it simple for now okay yeah so if you have a maintainer it's already a great start for agents and active maintainers because right now we have a dozen of maintainers but all of them will have so many other things to do and so I think that if somebody wants to step up and maintain a particular image for now we can just grant access to all images and so be great okay well and and I like that that's that has we can we can certainly use the controller naming pattern if someone says hey I need this support for this type of agent great we can use the we can at least use the naming pattern that Jim's created if we needed to be more verbose in the agent I think oh like wasn't there a couple pr's to the agents uh get every vote to kind of organize them uh into their folders like 8 11 and then the os isn't stuff like that yeah all of them have been already organized okay because the if and when you guys did want to uh do the verbose naming uh the scripts are written in a way where it scans those folders so as long as that like folder structure is the same on the controller or on the agents uh repose the scripts should be pretty easy actually just to carry over uh slight modification not a whole rewrite or anything like that so great excellent thank you very much for your work on that Jim thank you thank you anything else on simplified labeling of docker images uh no okay next topic gareth windows docker images for LTSC 2019 sure yeah um not too much to update since last week on this so um the pack of builds for 2019 LTSC will suit your work nicely um all those images have been published and all of those Jenkins instances are updated and running with the updated images they have some tests in them to validate docker and the disk size is correct which is some common failures that we seem to have on those which is I think it's quite good and when those updates are installed as part of the build so then it's on to the Jenkins so the actual docker images so adopt reforged the adopt open JDK repo to add support for 2019 LTSC images they're currently being published under the Jenkins for eval org until they can be sort of officially supported and I think it's Alex's PR to be merged um so that seems to be they look like they're going in nicely and then there's a PR for Jenkins to add 2019 LTSC as a sort of docker variant that's where I'm up to I think that's the I think that's the last PR but it's yeah it's currently timing out and validating stuff all right so Jim is that so the here I missed one that you said so the test of agent capability includes installation of oh windows updates yeah that's okay all right so so right now we're based on a copy of Alex's PR that is being deployed into the Jenkins or in the Jenkins organization we would eventually like adopt them adopt open JDK to own that it's just like they do the others Alex have you had any feedback from them on that PR I've not seen any um no I know they have a problem with build machines like they don't have a lot of infrastructure they're building windows uh images um so I'm I'm not sure how things uh how that will get resolved okay I think they're currently using I think they're currently using GitHub Actions to build on the Windows ones because there is a Windows 2019 um runner so when you fork the repo at the moment it and modify the GitHub Actions files it does actually build quite nice um those images I'll ping them on that PR they have it labeled as November 2020 so I don't know what that means so Gareth can you give us give give us a next steps we've got we've still got our we do we have images yet that are based on LTSC 2019 we've got more to come so um the next step is there's a Jenkins CO Docker um poor request which I'll pop in the chat um that's the one that is currently timing out I think it has a 60 minute time out and I think by adding the extra images on Windows we need a bit more time oh okay I see so time's out after 60 minutes but it's still actively building at the time out yeah it's not that no I've watched it a few times it is it's it's definitely still doing stuff um I've I've tried extending the time out but uh it doesn't have any effect for me when I push the change up I think I think that's a permissions piece Alex any objections if we were to extend the time out for or is that is that a time out that is system-wide no job on on ci.jankins.io is to be allowed more than 60 minutes no it's in the Jenkins file it would be ideal if we could parallelize the Windows builds like we have for the Linux builds but I just haven't had the time to look at it okay great all right because we actually do build um we're building uh eight images and testing them so it I think it's eight I may be wrong on that so it does take some time so if we could parallelize that it would be good great okay all right anything else on the Windows Docker images topic then okay last topic was Dockerfile content tutoring for Vivec Vivec what was what was what was your question what was this well or yeah let's let's check to see Vivec is this something that needs just one-on-one contact or that you'd like to talk with the platform specialist group as a whole I feel we may have lost Vivec huh no we did okay sorry about that everyone all right given that I think that stops us today any other topics we should bring to the group before we end the meeting okay thanks everyone enjoy your day I'll post the recording it will probably be several days it won't be until next week when I likely post recording if needed I can post a recording because I have other recordings to post so it won't be a big deal for me oh that would be if if that works for you all like that would be great and if not no problem yeah I'll go with it thank you very much all right thanks everybody thanks thanks all