 Hello everyone, welcome to the platform SIG meeting, the kind of regular one, every two weeks in general, but I think it's been slightly less in the last past weeks for reasons. So we are going to discuss today a few things. I'm going to share my screen right away about the agenda. Now people should be seeing my screen. So the agenda for today is to do a Brazilian action item recap and then we will probably cover indeed some Java 11 related subjects and then random issues around various subjects. So let's dig into that right away. Before we start, anyone has anything to say or to ask for? I'll take that for a no, I suppose. So just a reminder before maybe we start, please feel free to join. We are very following and hanging out in the platform SIG channel on Gitter under the organization. So feel free to ask questions there and we generally are trying to follow. And so also maybe another reminder, this is an open source project. So when I'm saying we, I'm really talking about anyone who's willing to dedicate some time, some effort in that initiative, there, there's we welcome anyone in that regard. So back to the agenda. So Oleg wanted to poke the list on the Jeff three, two and seven. All right. You want to explain or discuss that? Yeah. So we had a discussion in the platform SIG meeting, but we didn't have a discussion in the developer mailing list. So in the threat, I added Jenkins developer mailing list to the threat as well. So I assume that the section item is done. Yeah, right. And so I didn't remember we had a lot of feedback about that, but yeah, basically it's so for anyone watching, it's about that. And also, I think there was an action probably since last time by Olivier Verna who created the setup and the variables inside jetci.io and trusted.ci. That would actually enable us, that's kind of the gist of the of the JEP, correct me if I'm wrong, to enable us kind of automatically to just use that variable to automatically deploy either to the Jenkins slash Jenkins CI slash. That thing. Yeah. It's either there or either experimental or the Jenkins four. I think it's been changed once I don't remember if he decided finally the name, but yeah, basically changing variabilizing here. Quick update on that. We have patched the libraries for that and we also updated JEP. So current I have pasted into the chat and the current version of the JEP reflects these variables. So it's available for evaluation and now we are waiting mostly for evaluation feedback and we agreed that Olivier will be delivered. So we are waiting for Kiki to officially attend him. So this is where in our publication script that basically we've variabilized this and that makes that automatically on CI which is the public instance for anyone that can kind of use it is going to deploy things. And that's also kind of why maybe for people watching you want, we want to remind that nobody should be using that for production purpose, the Jenkins experimental thing because it could be easy more easily maybe taken over hacked. So that's why only the Jenkins slash Jenkins should be ever used for production because that one is generated from a more security segregated instance. So yeah. Yeah, so I think we covered your meeting notes done Olivier. Right. Okay. So you're doing a great job. I think Mark thinks so. Yeah. So that's that's by the way action item but relates to Java 11 work. Right. Great. We've really covered that a bit later. I mean, when we cover this, but basically the global sterilization issue has been tackled. Done. Right. What's that one? I think and what about the status about that one? It's still open. Right. So I'm going to, by the way, we definitely need to scrap it. And it would be nice to have Java 11 label or maybe Java 11 compatibility so that we see it in our common queries. Oh, we need to push the public comments. Yeah, this one does need a label. You're right. This one was the problem actually during upgrading JBoss marshalling itself, right? Not upgrading Jenkins. Not it was it was a change in the underlying JBoss package. Yeah. By the way, unrelated comment, but you're not presenting to everyone. So you're not pinned and in YouTube likely we see Mark's face now. Unless I messed up something. But yeah, let's check YouTube right now. Yeah. Really? Really? Okay. Let me see. Oh, my dear. I messed it up. No, I thought I was doing the right thing. But so that's the thing now. So you should be seeing that I'm pinging Jen, Bryden and everybody. Could this issue has surfaced during the platform meeting? Could we please be triaged? Yeah. Could options? Yeah, and probably we need to add a stack trace from configuration as a code plugin chart. Just a second. I'll repaste it in the platform seek. Sorry, what? So yesterday we got one stranger report about a program that serialization, which is maybe related to this issue. You mean that one? Yeah, this one. Probably it's related. It's, I mean, yeah, I commented in answer here. We didn't get an answer. But basically I'm suspecting that maybe that person, we started in the middle of a running pipeline, which would be a documented fader. So yeah, we probably need, I mean, I'm not going to worry too much until this person actually files a report. But until then I'm going to suspect that it's just because it was restarted in the middle of this. And we do know that even the serialization format did change. This is a one-shot issue that anyone is going to have to go with. But yeah, it's kind of a small one. You just have, when you go from workflow support pre-3.0 to post-3.0, to make sure that you have no running pipeline for that very upgrade. And then you can do business as usual basically. So yeah, you're right that that's a concern. But for now we have no ping back or anything else since. So we'll see if it goes back or if it's confirmed. But even that person, if I remember correctly, said that basically, I think he, yeah, you're right. Apparently, basically the issue is gone. So it's really looking, that's why or so, that's what made me think, well, it's probably that kind of issue that something was running. And then next time it just never will be visible again because then the format is upgraded and that's it. Because that's a nothing for people watching that has nothing to do with the Jenkins version itself, but more about the workflow support version when you upgrade from pre-3.0 to post-3.0 again. So yeah, nice point. Did I by the way, I'm not even sure I didn't add. So yeah, great. Devin discuss upgrade worrying. I'm wondering what that means. So that was, he needed to discuss how that they were okay with putting a warning inside the workflow support 3.0 plug-in. They were okay with it. He did it. You're showing it on the screen. Yeah. So it's only the change log. So then I understand it's not like in an admin monitor or something, but I guess it's already enough. Yeah, we have compatible since warning. So upgrading users. Yeah, right. All users upgrade from a web UI. You will see a warning. Yeah, absolutely. So for people that are relatable about that thing, it's Jenkins plug-in. We can document the fact that a given update is compatible since only something specific versions. And so in such case, it's going to trigger warning when a user is going from something that's lower than that to that thing or higher, basically. So yeah, it's going to also surface from the update manager itself. So that's just great. That's the case. And the next one is kind of, I guess, related to that. Yeah, it's done. Yeah, right. Mark raised a Docker issue, unnecessary, blah, blah, blah. Okay, that's because indeed we realize after the fact that only OpenJDK11 was using CID for a reason we didn't understand really. But Mark, do you have some notes to that or do you think? The only point there was that we were, for whatever reason, generating with an old version of the JDK11 image. The JDK11 image on Docker was newer. And the act of constructing a new one switched us from Debian CID to Debian Stretch. So we're now on an official, a released and supported version of Debian instead of unstable. Yeah, but only for Java 11 packages, right? We didn't change Java 8 packages. Well, Java 8 was already on Debian Stretch. So you're correct that we didn't alter the base operating, in fact, what we did was Java 11 now uses the same base operating system, major version as Java 8 does. Yeah, and for anyone having a look, indeed Mark still did change in the Docker file for the Java 8 package, but it's like going from latest to Stretch, which currently means the same thing. But the good thing is that now it's not going to update automatically, you know, randomly at some point. Instead, it's going to stay on Stretch until we decide otherwise. Until we decide otherwise, sorry. But is it the case? Am I correct, Mark? You expressed it correctly. Yeah, all I did was widen the declaration from OpenJDK8 to OpenJDK8-Stretch, and it turns out they point to exactly the same thing at tested point, and it makes explicit that we are based on, for now, Debian Stretch. Some day in the future, we may as a project choose to base ourselves on another Debian version, but right now it's Debian Stretch. That's the thing we were referring to, right? Correct, that top, that top. Currently, currently that is synonymous to that. So it might not be the case in the future, but at least we won't see any upgrade that, you know, what happens when we didn't plan it, and something starts screwing up everything. Right. Right. Mark has opened a chip for Docker, not the chip protection, right. Indeed, that's the discussion that last time we had, that we probably would at some point to try and clarify the kind of target platform we support and the thing we don't, because right now it's more like, correct me if I'm wrong, like an organic growth and like de facto growth that that's been happening along the years, that we added like Slim, Alpine, blah, blah, blah, anything, but some things like Alpine finally proved to be problematic recently, and that's kind of the trigger for this. Correct, and I will open that, Jeff. The idea is let's define some rules that we'll use as a project to select the operating system, operating system we do and don't support, at least start the discussion. I don't know how they will ultimately end, but start the discussion using a JEP. I had an action item to do the same for Windows. Oh, oh, good. It might be. I mean, I'm not wondering if we should take that action item from you so that we should just put it in this, in the list of action items for this meeting. Well, you can create an action item. I need to clarify some bits before I go forward with Windows support. Yeah, but I think indeed that probably would not make sense to have a JEP now, and I'm reading it like more precisely. I think we probably would want, don't we want to have a single JEP for like, you know, the Jenkins project proposed kind of supported, if there's anything like support on the open source side, platforms. And I guess it would be easier and clearer that we have only one instead of like one for Windows, one for Docker or whatever. There are two parts. We may have separate JEPs, but it definitely makes sense to have a single operating systems support page. Yes. Now we don't have exclusive definition of what we support, at least on Jenkins.io. Maybe we have some obsolete wiki pages. As a part of Hackathon in June, we created one page for Java support before that we didn't even have official Java support policy. Yeah, requirements. Yes, so yeah, creating and cooperating system support would be definitely helpful for Jenkins users. Yeah, it's hard to say away in current run Jenkins now. Yeah, I mean, yeah, it's always hard because I'm always a bit stretched about the phrasing in like, because support is like there, there is like, you know, SLA or whatever. It's not really the same thing. Like it's like when we're helping and not supporting people on the user's list or something. No, well, I wouldn't worry much about that because Debian certainly declares things that they will, configurations they support in the sense of that. I think we're no worse than they are in using the word support. Don't panic about the word. So we will definitely need to write something, but that's why we have JEPs. We can discuss it. Exactly that, because yeah, the process is also kind of, the final thing is interesting, but the journey, the journey, the process, you know, triggering emails and devlies having people discuss of a specific issue is also a very important part of this. Even if in the end, we know we end up writing anything, but it's already something interesting. Right, anything else? I guess we did the kind of action item part, and we are... Yeah, time is still correct. We've done like half of the meeting time, so we are good for now. We should move on. Yeah, absolutely. So Java 11, blocking issue status reports. Do you want anyone wants to cover that? Well, I just returned from vacation. I have no idea. Really? Surprise. I have disabled general notifications. I have a few thousands of notifications, which I'm not going to read. Really? Yeah, I need some time to catch up. No, no, no, no problem. That's absolutely expected and normal. Just mark everything as read now, so that you can start from start new. Yeah, so the status is right now looking good. For instance, the really outstanding thing. So last time was really about the workflow support plugin, which was kind of a mess last time. We had a version that was, you know, specifically released for Java 11, one that was specifically... So the previous one that would only work on Java 8. But in the end, Devin Nussbaum found a way to fix that for everything. And so it ended up being an upgrade for Jebus Marshaller. And that's the reason why I was explaining earlier that you have to kind of suffer a one-shot issue when you're upgrading to that version. And it's already doable right now, even because it's been released already and already a dateable tool for Java 8. Jenkins is running on Java 8 already. So the good thing about that, and so it's that, you know, the workflow support 3.0 is going to be something that that's going to be already handled and deployed in new kind of battle tested already, away even before we reached the point of the Java 11 GA. So that that's really a nice thing because that was really the outstanding issue we had because basically pipeline would just immediately crush after a startup. So yeah, that's great. The the rest of the I guess the main things are probably the Jenkins issue that's about, so right now for anyone wanting to run Java 11, you have to pass a variety of, it did summarize here in that entry. Yeah, so you have when you run Java 11, Jenkins on Java 11, you have to pass those options if you want to have no issues. It's actually a bit more, the situation is even slightly better than that because even if you don't pass those, you are going to probably be able to run Jenkins without any issue for a substantial number of Jenkins plugins. The thing is, you could at some point install a plugin that's using actually Jaxby or depending on some extracted models from the JDK after Jaxby 11 and then everything we start scratching at least for that plugin. So that's the thing we are trying to work on right now and making add models unnecessary anymore. In the JAP 2.1.1, which is the one describing Java 11, that's been written by our own Oleg, our super champion. Basically it's given, it's said there that we are going to try to remove those but it's not really a goal. It's a might. We may be able to remove these but it's not going to be considered a blocker if I remember correctly. So just to explain why it was stated in such way, we are really interested to retain full compatibility and to retain full compatibility of CLI so that users can migrate to Java 11 without even noticing and that we don't need to rework all packages packaging flows, which also integrated Java 11. So our current state that we updated Docker so all Docker users just do not notice so that we do something to attach these libraries. But immediately we would like to have something in the Word file and there are multiple ways to do that but we haven't fully investigated these ways yet. There were some experiments which didn't work. There are still some options which may work so if one of these experiments work well my preference would be to have full compatibility and to avoid inclusion of models in such way. But if it doesn't work, then yeah we can probably say that for Word files you have to specify the components externally. And actually for us, JAX is just beginning because there are more models which may require explicit definition and we expect more models to be excluded from Java in a few of the versions Java 12 and so on. So easily we would need to have an engine to prevent that. But if we cannot find any workable solution for now then yeah we may go with GE with such a breaking change. Yep, so that's the Jenkins issue already five I'm already looking into. I've been digging into completing or analyzing more building on top of the work already done by Ole, Kosuke and Jesse I remember correctly. Especially during the hackfest that happened last June about Java 9 plus work basically. So to summarize the situation as I was kind of hinting about a few seconds ago is still looking good because if when I analyze this basically close to no plugins I would say I mean yeah there's a handful of those but compared to the 1500 plugins there's like no plugins impacted because even in that list there are things like here that have no so that actually have the phrase Java XML bind but it's actually not something like a plugin so not even the full list is relevant. So we don't have a lot of issues basically I was first having a hard time actually to trigger an issue on Jaxby. So I ended up having one after a recommendation from Oleg trying out the sloc count plugin for instance which I'm working on right now to see what's the best way to fix it but basically there are like we have many options to fix it I already fixed it in two minutes just by adding Jaxby in many locations and every single tests I did was working. So that's kind of I'm generally pretty optimistic about that but I'm generally too optimistic so I'm trying to be as focused. Yeah so the situation is looking good kind of getting back to the thing we are supposed to discuss. The status is that we don't see we don't envision a lot of blockers we are about to be able to run the full ATH and PCT runs under these Java 11 peeps. Don't you want to run ATH? Yeah we run ATH but we didn't run like you know I think we so yeah we run a variety of PCT runs on a dozen of plugins but not like you know hundreds at least and so there was the OTSS ATH runs which I think went probably quite fine but I don't think we analyzed a lot of this so overall we probably need to rerun a full run you know and get a hold of this and there is a document by the way I don't have the link handy about the PCT status so the PCT is plug-in compatibility tester is a tool that basically tests plug-in together at the test level which is kind of a complementary to ATH accepting test harness which is a Selenium best framework used in Jenkins project so yeah we found a few issues but right now I would say correct me again if I'm wrong that the most of the time is now spent on adapting tooling but we like do not see blocking or or concerning issues surfacing anymore I would say we have some reports for plug-in compatibility which we'll likely need to fix before the GE but we need to explore these options and yeah if we decide to go without the Jax B probably the scope of fixing plugins will be much wider because there are plugins like TFS plug-in test complete plug-in HP quality center and effectively many plugins which use XML parsing use Jax B and in this case we will have to fix a lot of plugins I believe well I already provided the list so I don't know why you are I just reference popular plugins in this list and many of those so and that's something I was going to propose maybe in to do in Fosden by the way most of those usage are for instance using the data type converter that was something that got fixed in the instance identity module here so basically it's a one-liner and most of the usages I found in the Jenkins community is exactly that usage basically this thing in Jax B is something that that provides a small API to to convert into base 64 thing so basically that's kind of a an example of the removal from removing Jax B here and I was like not a one-liner but almost because well removing replacing basically this by this and then everything works fine and I already fixed a few things this way in a few plugins so obviously there are going to be cases like in sLock.com plugin that's not that obvious because in sLock.com plugin it's just using Jax B to serialize which is the goal of Jax B serialize an object into XML and back but in such case I would say well and that's what I've written I've wrote in the report I think probably it could be quite simply replaced by an extreme serialization for the same you know result so yeah in my case yes yeah there are some potential issues on that but yeah I propose to discuss offline because we have limited time at this meeting absolutely I'm just watching the time we have still a bit less than 10 minutes so that's why we are right for now because I think we were reaching the end of the status the meeting notes so is this the place for me to ask about operating system installers whether they're required or not or should we do that offline depends I mean we can probably discuss the status but I guess yeah as Oleg was hinting I think we are not going to be likely solutionizing here it's more like discussing or trying to summarize for anyone watching what's the status okay skip then thanks okay so I propose to have a wider discussion about compatibility at the next meeting because if we agree that we need to discuss something for Debian something for Docker something for Windows probably we should run a separate session about that thank you yep so ATH is now as far as I know fully supporting Java 11 thanks to a lot of work from at least I'm going to forget people so at least I know Oliver and Ramon hasn't been doing a lot of work but many many other people including people from the current meeting but yeah PCT has been fixed too as far as I know but we surfaced a lot of issues here and there but in most cases I've seen for instance I add that what I have in mind is pipeline utility steps the issue that was surfacing in PCT was never reproducible in the normal usage from Jenkins itself PCT itself has a lot of limitations so yeah it's an attempt to to meet testing so it's just an advanced version of setting up some system properties that tries to automatically resolve dependencies etc but PCT itself is not guaranteed to work in all cases yeah exactly yeah there was a lot of changes in the term of class loading in Java 9 plus and indeed for instance things like Java SQL are definitely not in the same class loader anymore so that's probably why he's surfacing there and not in the normal usage yeah most probably we'll need to have a patch on the Jenkins core site for it because it's safer to have a patch than to risk and go and resolve this patch for example we may get into the same issues when we deploy to webcam containers so I was thinking about reviewing this issue later it's not recorded in GA but yeah a little bit yeah that's a complex issue because then what are we going to do about every like Java EE thingy that got extracted from the JDK tenders that's quite that's probably the most blurry and difficult part because we don't know off issues yet with with regard to what we tested but as Oleg was concerned about we could indeed later on find some weird use ages of Jenkins because we know how much it's used in many situations where people would do something some weird things with class loading and you know build on top of implicit behaviors which was never documented and weren't it work so we have to probably decide in such case what we want to do for instance break compatibility like the JDK itself did so that's a hard issue indeed mm-hmm so Oleg uh you want to discuss that what exactly I'm trying um yeah it would make sense to discuss that but we are running out of time and there was a topic about windows installers and I'm not sure why this topic is missing in the agenda but I believe that Alex is here on the call is it the same the second the next one no it's not the same okay anyway we can just add something and let's discuss that now to have a discuss with Alex so we do all the trouble we discussed everything in action items so I believe we can skip that for now it was something about using chocolatey right no it's not chocolate not only chocolatey but also about windows installer msa1 anyway so let's just give the stage to Alex I think you're still here yeah I'm here you guys hear me yeah okay cool sorry I have a cold so I'll be coughing I apologize so yeah I've uploaded the single repository which has the the chocolatey packaging as well as the msi with the updates that I've made that's I posted a link in the um platform sig getter channel people can take a look I don't know what the next step in terms of what people want to see I can create a binary version of it that people can test if that's desired I marked it a little bit of testing when we were at Jenkins world but I have made some updates since then so I do need to also take into account Java 11 right now the installer looks for Java 8 installation so I need to understand what is needed for Java 11 in terms of if there are any environment variables need to be set or things like that to run under Java 11 that would probably be useful to add into the installer as well so it's a good experience for the user but you firstly need to have automatic discovery somehow yeah there's a registry search that it goes and it will find Java right now it's only looking for for Oracle's Java that may need to be updated depending on like the Amazon installer and stuff like that because the new licensing for the Oracle JDK and JRE could we just add an option to specify Java home when you run the installer because it would be a the most straightforward fix yeah so I was kind of aligning with the Tomcat installer which I like for Windows and it does have a capability it does do a search and then it will allow you to override that so we could definitely do something like that to allow people to override whatever was found as the the default if there was one yeah it would be nice that would be something we could definitely do and then also in terms of chocolatey I got in contact with the author of the current chocolatey package and he actually works for chocolatey so it's like someone requested the the the package and chocolatey went out and created one and he was completely open to turning over maintainership we just need to provide some sort of credentials to show that yes we are from the Jenkins project and you know so on and so forth so I didn't know specifically what we wanted to do with that I don't know if maybe a core maintainer emailing him I can forward his email address to someone but if someone with core maintainer writes and can link to their their access or whatever on GitHub or something I don't know something like that but that should be pretty easy so that the the repository I uploaded is it has a Jenkins file that will build the MSI and then it'll take that MSI and get the shahash information that's required for chocolatey and then build the chocolatey package I don't I know how to publish chocolatey packages I filed an infra ticket to have Jenkins org account created on the chocolatey page so we can get an API key to be able to upload packages under that account I didn't see anybody on that yet if I can so yeah lots of information sorry it's kind of a brain dump that's nice I think you're probably the best position to handle that so if that last question was who should request access I guess if you're ready or willing to do it I guess it's very fine if you do it yourself and we can just provide help or work together to get this done I guess okay I can do that great thanks a lot and feel free to just include plot from seek to cc all of us and please and yeah if you need special get help organization permissions I have admin ones or we can just get key key what Tyler from Jenkins boards to confirm the request so multiple options available okay and then at some point I need to probably have a a good email conversation with Olivier about the CI builds for the installer for the trusted environment for signing and that sort of thing because and how to publish like the MSI for instance to the mirrors things like that and then how we would kick off the builds when a release is being done for the main you know like warp file and stuff like that could we take inspiration for what has been done for Docker like creating a special organization and chocolate tea that would be for experimental packages so that we can you know try it right away test deployment from you know the public facing instance of CI and then once he's proofed to work then it's kind of easy because then we make sure we secure it and push things the same way from the trusted CI server would it make sense yeah we can definitely do something like that I can do that I'll take a look at doing that today well not today but this week yeah because we can really tell you that trying to test thing an interested CI is generally a pain because for a reason that nobody has access for for for the reason for the very good reason so yeah the iteration loop is really long so if you can make sure you know to iron out crap before trying in behind the VPN basically it's pretty best place for everyone and even mostly for you right okay great so anything else I think that's I think that's all for now great thanks a lot Alex so aka slide so windows service wrapper improvements was something different then so what is that I don't remember okay who on this call don't know what is a Windows service wrapper is if no I can briefly explain yeah probably I should just screen share okay I'm closing windows and try not to exit the call at the same time just a second okay the same to try to not stop the call at the same time I have locked use another account yeah there is a way to prevent stopping the broadcast okay do you see my screen yep no I'm saying yep it's not yet I think we lost okay if you make me present or it would be okay so long story short in Jenkins we have we do support windows and actually we allow installing Jenkins masters and Jenkins agents as Windows services for example MSI installer installs Jenkins as Windows service by default but there are also ways to install it after the installation for example Jenkins offers a menu when you start the agent where you can install the agent as service and similarly you can install Jenkins master service from its web UI and actually all these flows are based on the Windows service wrapper is a it's a project started by KK region that I took over its ownership maybe five years ago so this is a project implemented in .NET mostly in C sharp which actually just wraps the service and offers installation logic like install uninstall so you can manage services from CLI here there is a configuration file and many of you call it know it as Jenkins XML but yeah there is a configuration file which actually supports adding a lot of options and these options allow to alter the behavior in Jenkins we have the default behavior for example there is a component called Windows yeah there is also Windows agents plugin but I wanted to show Windows slave and storage plugin so this is a component which offers UI option to install as a service and it also has a sample for for Jenkins slave XML which defines the default configuration like that so this is an XML file and I have a GSOC project ID for this year to actually do some updates in order to stop using XMLs there are multiple issues we have currently in Windows service wrapper one of the issues that the configuration is not being imported per se it's been read on demand so it means that all configuration entries are being read only when they are needed and for example there is onfailure behavior so it will be parsed only when the failure actually happens and it means that when failure happens if you have wrong configuration file here it will be just it will just blow up there will be some attempts to include validation of inputs but not everything has been done in this project I have a GSOC ID which would actually focus on two things one is updating configuration to support YAML so instead of XML maybe we could do something more friendly to users nowadays and YAMLs generally briefly if you want to start for example have packaging in chocolate tea there is also Windows service packaging for chocolatey available nowadays and it's YAML based and a second part of the project is actually to improve validation and to improve diagnoses ability of the component and yeah currently I'm looking for potential maintainers but the project is there and if somebody is interested to be a stakeholder so please let me know so the scope is firstly updating the Windows service wrapper component but also updating Jenkins components it's a Windows agent installer maybe VMI Windows agents which also uses Windows service wrapper and of course Jenkins quarter itself so this is the project and if you want there is also a bunch of not a bunch of but some feature requests so if somebody likes C-sharp or wants to study that you can also contribute to this project and you may see that it has actually more stars that the most of Jenkins sub-projects maybe even more than Jenkins X who knows okay so that's what I wanted to say why I say it say it in platform seek I hope it's more or less obvious because yeah it's a part of Windows support for Jenkins okay thank you so any questions I don't think so I don't have any and for me thanks a lot thanks a lot I think we covered everything maybe just I don't have to switch to the other window let me see yeah I wanted to check what yeah I'll stop the sharing of the screen if I still share you're really sure I stopped I have either yeah so I wanted to know what is Alex opinion about this project whether it makes sense because he's probably one of the Windows users my microphone is muted so I don't play a lot with the XML files so I haven't had any issues in terms of configuration or anything like that so I've kind of used the default settings I don't really have as much input there I know with the MSI installer modifying a YAML file will will not be as easy as modifying XML because there is not a a custom action already in Wix which allows you to modify YAML files there is custom actions to modify XML files and I'm using that now to modify like the path to the Jerry and the port that's selected and things like that so we have to look at how that would have to be updated and done maybe we can write our own custom action in order to modify YAML files for something similar but I mean if if I mean YAML seems like a pretty common format so if it makes it easier to manage and have better features than I'm all for it yeah obviously we will retain XML compatibility whatever we do and yeah even if we do support YAML part of this project is to improve validation which would also apply to XML and all other configurations like we have a serious issue with agent installation flow because in order to install agent as a service currently you have to be system administrator actually you have to be running Jenkins agent as a system admin which is totally not a key so maybe some rework of this installation logic to YAML maybe not would be reasonable but let's see sounds good so there was a last point or last last last point about okay that's here for me you wanted I don't know who had it that but the platform Sieg and embedded Sieg discussion I think it's Oleg yeah it was also me so the story behind that we are going to start a new embedded special interest group which would focus on common interest cases like just embedded IOT automotive whatever whatever it will be mostly user group focusing on user stories so use cases how to address them with Jenkins but yeah when we talk about embedded one of the most common questions is embedded platforms so for example running on ARM not server ARM but there is a lot of use cases when people just run Jenkins agents and even masters so on embedded configurations and my question for discussion today was how would we align that because yes some of topics definitely um yeah they will be relevant to platform Siegs some will be relevant only for embedded Sieg but I definitely see some topics where they will be overflows and my question to you guys is how would we approach that let's take them in the embedded Sieg I would propose take the most specialized first and then only hoist things that we think are more general case up if needed so go with embedded first and and discuss them in most depth there if we since you're in both places and several other people in the group who probably also be in both places I see no risk no problem with that okay should be fine I believe we will have stories at least docker packaging soon because yeah we have ARM 64 discussion well and ARM 64 is currently an embedded platform as well I would say so yeah I believe we already in this state but yeah I'm getting more user feedback and embedded Sieg will be targeting users will be helpful for platform Sieg as well okay so that's what I wanted to discuss and yeah if somebody wants to join there is a link in the menu please and we will be officially announcing this Sieg in a few weeks I guess and there was a last point thanks Oleg about handling meeting agendas which is probably circling back to the discussion and the point we said at the beginning I guess given we run out of time I suppose we can just decide in a few seconds or not I mean will it make sense to have a single document instead of at once for meeting notes and what for I mean maybe I'm the only one who has been for it and then I'm fine with keeping this the current way I think Mark maybe you're probably the one that's been who's been creating lastly the documents and then the new instances what do you think about that one it's like we don't care you think it's it's already good as is right now or so I like having two dark I like having separate documents one per meeting because it helps me track things easier but I'm okay with whatever the group decides my personal preferences put the agenda only into the meeting notes and have the agenda document just have links to the various meeting notes documents I really I'm hesitant to have a single document which includes all notes from all meetings just because of the size that I think they'll grow to that was my concern but I'm open to any I am happy to record things and track things however you'd like fine Oleg do you have a particular particular strength opinion one way or the other no preference we use different approaches in different seeks so in JSOC we have a single status document well in other meetings or like platform we have separate ones both options work and even you've been doing the the heavy lifting about that mark I'm not being qualified to have an opinion in about that so great thanks everyone we're going to we've run out of time a bit so see you next time and thanks bye bye