 Hello, everyone. Welcome to the first platform special interest group meeting. This is a group which focuses on various kinds of platform support and Jenkins, including Java integrations, separating systems, all kinds of packaging, et cetera, et cetera. So something like two months ago, when we were working on Java 10 support prototyping, we discussed options to have a separate interest group, because it's a major activity which requires some dedicated effort and some coordination between contributors. So we have created this special interest group in order to facilitate these discussions. If you're interested to find more information about the special interest group, there is a page on Jenkins IOLO. So Jenkins IOLO 6, and here's a platform 6 here. And here you can find links to all our resources. The members link list needs to be updated, but at least you can find everything here. And there is also a link to the current recording and to the meeting agenda. So if you want to join the meeting, just join our GitHub chat. And here's a participant in the post. And here's again, this meeting notes document, which we will be using. By the way, Mark, you have permissions to edit the document. So we have several people on the call. My name is Alekvin Nachov. I'm a SIG chair. And we also have Tracy Miranda, Mark White, Devin Nussbaum and Alex Earl on the call. Maybe we will get more people later. So this is the current list of participants. And we have several topics in our agenda. So maybe we could start from really, really quick introductions just to understand why people would join this special interest group. So in my case, it's easy. I'm really interested in all kinds of platform support. I started to work in these embedded hardware use cases. And yet I'm really interested to have some low level features integrated in Jenkins to support platforms better. And of course, Java as well. Okay. Does anybody want to introduce himself? Yeah, I'll say I'll introduce myself. Hi, everybody. I'm Tracy Miranda. And I'd say I got interested in the platform SIG back at the Java 10 hackathon. And yeah, just driving Jenkins forward in terms of using new platforms of Java. And from the open source community perspective as well, I'm interested in driving any collaborations with other communities and what we can do on that front. Patricia, Mark. I'm Mark White. I'm interested in platforms because of the complexities that are introduced by many different external environments where we run like Docker, like Alpine, like AIX or Solaris or variants of Linux. And it's sort of driven by a plugin I maintain. The Git plugin has some surprising dependencies on Git versions. And we have a wide range of Git versions from 1.8, in CentOS 6, all the way to 2.18 on Windows. So lots of differences that cause me to be very interested in platforms. Yeah, for me, it's similar to Mark. I mean, I see that in Jenkins, a lot of the complexity, you know, and tricky bits and things come from having support so many different platforms. So to me, it's interesting to kind of stay on top of that discussion to make sure that, you know, I can review code better and help make Jenkins better and more reliable. Alex. I'm interested in this, just from the front of helping better the user experience. I notice that, you know, people come in to either Git or IRC and kind of complain about things and hopefully it can help improve some of those things. Yeah, that's for sure. Yeah, there are several people who reach the most of requests in Jenkins Jira and Alex Earl is one of them. So yeah, we face a lot of various platform-related issues coming to Jenkins Jira. Yeah. So do we have anybody else on the call? I guess no. So we can just continue the meeting then. Okay. So we have several topics in the agenda. So maybe we could briefly discuss Tracy's proposal about not proposal. There is Jenkins online meetup scheduled to August 23rd, if I recall correctly. And it's about open J9 support for Jenkins. So maybe Tracy, you could briefly describe what is this meeting because it looks to be really related to the platform's interests. Yes. Yes. So for those who perhaps have maybe heard of IBM J9 in 2017, that was donated to open source and became part of the Eclipse Foundation and it's now known as Eclipse Open J9 and it's a VM equivalent to hotspot but really focused on running applications very cost effectively in the cloud. So I've met part of the team and they're quite interested in seeing whether Jenkins, well, first of all, we could run Jenkins using it as a VM instead of hotspot. And secondly, whether it would have some performance improvements. So there's lots of performance improvements being spoken about with Java coming from Java 10 and 11. But what Open J9 is touting is that you could get some significant sort of memory footprint improvements and performance improvements using Java 8. So the idea with the webinar next Thursday is to invite the Open J9 folks to give us a rundown of the VM, tell us what it is and where their thinking is in terms of how they've designed it. Go through a quick demo and with any luck, we might like to try it with a Jenkins Docker container and sort of see if we can get it first to run and second to see if there's any sort of startup time improvements or any other optimizations we could start thinking about doing. So my understanding is that this might not necessarily be straightforward because Jenkins already has some sort of AOT optimizations but I think we're just going to take it as a bit of an exploratory session and get folks discussing it and see what happens. There are not so many optimizations in Jenkins official images. So there is a lot of optimizations in some packaging flows contributed by Semvanor but regarding the Docker image, it has almost no optimizations configured for Java. And if I remember correctly too, I thought it was like Open J9 tries to do some ahead of time compilation but for Jenkins it's not necessarily possible to do that for all cases just because of how Jenkins does things dynamically. Do they already provide a Docker container for Open J9 in general? Sorry, do they provide a didn't quite catch question? Do they have a Docker image for Open J9 in general that we could use in a Docker compose or? Yes, there is. I'll try and find your link. So I think if you look on adopt Open JDK, that's where you can mostly get a distribution of Open JDK with Open J9 and I believe there's some Docker containers there but if not, I'll find your link and you can come to the webinar next Thursday. So Tracy when we had, if I recall correctly, J9 is the virtual machine that was actually defaulted on AIX if I remember right and I think we had had attempts to run on AIX previously with some surprises. So I expect some surprises as has been noted but it sounds like cool technology. Right, so in Jenkins Jitter we have a label called IBM Java, actually Java IBM and it contains a lot of issues and most likely they apply to Open J9 as well. That's good. I cannot show it right now because when I search for issues, I usually see a lot of security issues as well. I'm working on this Jenkins infrastructure team but so far I cannot easily browse during the meetings. Actually Docker packaging is a serious question for us because the next topic is about Java 10 plus support but when Oracle stops providing Open JDK images and it's going to happen in generally of February of 2019, we may have issues with our current official Jenkins images. So yeah, maybe it's a good time to start looking at alternatives. Yeah, so nothing more for me to add other than if you're available please come join next week and hoping from off the back of that we can find ways to collaborate, certainly we could look at the issues that have already been opened on J9 and see if we can bring those communities closer together. Yeah, it would be really nice. So yeah, I will make sure that this meeting is also referenced from Platform Sieg. Yeah, so it wouldn't hurt to have it and let's see what we can get there. Yeah, just a second. It was here. Okay. So anything else about this topic? I guess no. Thanks a lot, Tracy. Yeah, it would be really nice to have such kind of discussion and demos. Looking forward to that. Okay. And the next topic, Java again. It's Java 211 status. So back to what we had in June, we had Jenkins Java 10 plus and we had something like 26 participants and we did a lot in order to verify Jenkins behavior on these Java versions and we were pretty successful. So there was a series of blog posts on Jenkins.io describing how to run Jenkins with Java 10 plus. For example, here's a blog post for that. We also did not update it. We created Java support pages during the hackathon. We created some prototypes. But the problem with that, the patches we delivered, they are not all available in Jenkins. We can release it so far. So we have a separate feature branch for Java 10 support and separate feature branch for Java 11 support. They are automatically published in Docker. We haven't made it generally available in victory releases. So this is a continuation of the hackathon story. Regarding the hackathon, there was a lot of blog posts. And I was about creating another summary. But it gets that there was a blog post from Tracy which summarizes the hackathon results well. It might take a while to find it. Yeah, this one. And if you're interested to know more about the hackathon, there are also YouTube videos with all summer presentations. Probably I have this video in this product. It's Google Chrome, I guess. So this is a summer presentation from the hackathon which summarizes all the activities. But everybody on the call has participated in this hackathon. So my question is, do we want to briefly summarize the status in detail with this introduction finally with you? Actually, it would help me to have another summary, Oleg. If you don't mind giving a brief summary. In particular, the thing that I'm not clear on yet is what's the upcoming big picture for the Java 11 plan? Really, in next year, does Oracle stop distributing Java 8? That kind of thing. So I can speak for Oracle. What I can say is, yeah, there is Java 10 support page. Yeah, Oracle Java AC support roadmap. So this document changes pretty much frequently. But what you can see here is that now commercial user end of public updates is January 2019. So before end of July, it was September 2018. So this date moved and there are just a number of stars which says that this date may be changed again. But yeah, anyway, whatever happens, at some point Java 8 is going to be deprecated and the first security release not provided by Oracle for Java 8 will be a problem for Jenkins community because all our official packages transit level depend on OpenGDK. Thanks for that clarity. Thank you very much. All right, so we package OpenGDK on our own. It's Docker packages and it's also Windows packages. So for Windows packages, we will have a discussion a bit later because yeah, there is Windows installers for 60-bit platforms which is also quite related. For Docker packages, yeah, once you lose official English, you may have a problem. It doesn't mean that it's an immediate problem, but even now, we get a lot of requests from users who try to run Jenkins with Java 10. Obviously, Jenkins fails because you need to configure the model pass to run it correctly. So what we did, we disabled running of it by default in weekly releases. We offered a flag-enabled future Java and we offered the guidelines. So here's this blog post which describes how to actually oh, no, it's a Java support page and here's a link to the guidelines. So effectively now, in order to run with Java 10, you need a command line like that. And if you run for weekly release, you get everything except in pipeline working. For Java 11, it's even more tricky now. So this is the current state. You can run, but that's it. And we keep getting issue reports from users because users still try to run old Jenkins versions before to the 27. So currently for LCS, you can still run on Java 10 and you won't get a link to this guideline. So it confuses users. Once we get a new LCS released in September, it will be a bit better. But I think we still need to work towards Java 11 support in Jenkins Core. Regarding Java 10, now we will care about it since September. So yeah, this is the current state. We have JAP 211 for Java 10 and 11 support. So this JAP was created as a part of the hackathon. I mean not as a part of the hackathon, but as a follow-up. And yeah, there is a discussion thread in the platform sick mailing list. So it will actually be nice to get some feedback about this JAP. I've got some internal feedback already, but yeah, I think that we need to start discussing it. Currently I'm at the BDFL delegate. So one of the reasons why I proposed this meeting is to discuss this JAP. And yeah, if somebody went through it and can provide feedback, I would really appreciate that. Or I can just summarize it so it simplifies the review. What would you prefer, guys? So I will certainly do a review of it myself. One of the thoughts that came to my mind was, is this a thing that we could take as a topic for the hackfest after Jenkins World while we're all together and actively attack this thing to get. So end of September, I certainly will review the document, give feedback as time allows. Yeah, so I think we could do that. So the amount of effort needed to get it over the fence isn't that big. So I mean Jenkins core patches are pretty much staged. And probably I should just show you epics. So what I did in this JAP, I've tried to create a minimal list of things we need to do in order to make Java 11 now support official. So firstly, there is a special epic for that in Jenkins Jira. This epic list only must have tasks, must have tasks from a mind point of view. Just a second. Okay, so here's this list. And effectively, the most of this list is about test automation because yeah, we get Jenkins running in Java already. So we know about particular meta space leaks causing cases in pipeline. So it's related to this task upstream groovy update to the master branch. So when we make this update, there are memory leaks in pipeline, job, the sale, et cetera. And we need some plug-in patches. So this is one of the critical issues we need to address, but the rest are rather about testing. So yeah, you may see that support of specific Java levels in ATH, in PCT. Generally, we just need a test automation flow in order to run test automation at all because now we don't do any kinds of auto tests for Java 10 or 11 even in our development branches. So what our current Docker files in feature branches do, they just run a spot check against Java 8, actually. So Jenkins file is here, but yeah, there is nothing specific to Java 11 now. So this is what we need to do. And if we agree to reduce number of test automation, we could definitely get it over the fence during the hack time. Whether we want it, it's a subject for discussion. So given the audience, that's typically at the hack test is not a bunch of testers, it's more commonly a bunch of developers. I'm a little worried if we're test heavy here, that the only way to get it over the bar at the hack fist is to reduce the amount of testing that we're going to set as our required. Yeah. So, I think we could do at least some bits at the hackathon. So, I mean, we still need to park some core patches. We need to update branches. The current tasks don't require much coding. They mostly require integration of changes. So they will need some core maintenance, maybe me or Daniel Beck on standby mode so that we can review and integrate changes and other search bits. But if we are ready to organize that, why not? If you ask me, I do not think that hackathon is the best format for getting it over the fence. It is not. The work needs a broader set of people than maybe attending there. Yeah. So, firstly, it's not a coding project in general now. It requires some coding, but mostly reviews, integration. Of course, all kinds of test automation need coding, but it's everything. Hacking pipeline during the hackathon is a bit tricky. And the second part is that it's not a kind of joint project. It's a number of smaller projects which are not really linked to each other. So you do not get much community during the hackathon. Thank you. That's a good point. So we could try, but I think that maybe we need to take particular bits from this list. Because in addition to must-have things, we also have a lot of things. I mean, for example, there is a whole topic for gelatin compatibility. There are still a lot of different reflective cleanups. There are other features we need to deliver. There are things which needs to be detached from Jenkins core or re-documented. So there is still some work we could do. Okay. So, does anybody or participants want to work on that during the hackathon? I plan to work on it during the hackathon, but I'm mostly a testing kind of role, so it's a good fit for what you were describing as the task. That's my big picture for the hackfest is this will be my focus. Okay. So, I will like to join the party. Unless I have some critical things to do this pluggable storage at the Jenkins world. So, yeah, I think we can park the hackathon apart for now. Are there any other questions about this job? So, maybe it's an interesting part to discuss then. So, regarding the timeline. So, of course, the most ideal thing we could ever do is to make Java 11 available shortly after Java 11 release. But, yeah, in the JEP, I didn't define any specific timing so that it's done when it's done. And, yeah, when it's done, it gets into LTS maybe a few months later. So, for assuming that you work on that during the hackathon continue after the hackathon and let's say get it over the fence by Jenkins vault in Nice. Yeah, it's a bolt-assumption but okay. Then it will land in the LTS which will be delivered in December. And I'd say this is the most optimistic timeline for Java 11 support now. And, yeah, if we get it later then yeah, I don't see much problem but, yeah, I would definitely prefer to get it landed by January in LTS because if Oracle follows the current policy starting from January, we will start having issues with that. Okay. That sounds wonderful. So the idea then is we work at trying to get the changes that are currently not in weekly but are sitting on the separate branches into weeklies so that they are well enough that by the December LTS that those changes will be in LTS even if the LTS does not officially support Java 11 it gives us the facility then after the release of Java 11 to do verification with LTS. So actually we already landed the most critical changes so if you take a look at Jenkins so let's take should be here so there should be Java 10 support branch and the the div from the master is actually only few changes so what we really miss in master now we miss groovy update as I described and there is also one significant change which we haven't addressed yet and is this one just second what is it it's from Kiki I'm not signed up so I don't have automatic filters maybe search Jaxby yeah Jaxby I found it so Jaxby is one of the issues why we need to provide such crappy guidelines because Jaxby I think which have been moved to a model in Java 9 and then in Java 11 it has been completely removed from the default Java distribution so if you want to run on Java 11 now you need to download Jaxby components then you need to bundle them somehow or reference them in class pass so there is the current command call obviously it's not a problem for Docker because we just implied in our packaging we provide but for all other usages it's not a bit it's not comfortable so Kiki has evaluated multiple options during the hackathon and firstly he tried to do it in a plugin with that there are some issues because we still have core components depending on these libraries we started the training at the top but there are still some bits to do but a class loading from plugins didn't work correctly and the experiments jcbleak has commented on that and maybe it still works but we still have an option to just bundle versions into the war file so this is the current proposal we haven't tested it yet so I just verified it works well on java 8 or java 11 but yeah the problem is that it bundles particular versions these versions are created for java 8 and actually these versions stuff are behind from what is offered now for java 11 so I'm not 100% sure that it's a correct way to go but somebody needs to relate it to test it to discover downsides our proposal from opengdk.exe project participants was to do that just to bundle that but yeah it's a bit tricky for us but yeah if we go after java 11 supporting LCS I would definitely want to get something like that landed so that it happens transparently to users because yeah staying in this mode isn't something comfortable okay so this is what we have now but yeah I believe that if there is some interest from community we could deliver that it just needs some time but again that is not a topic that's well suited that's a single, a mostly testing effort or a single person experimenting not something at the hackfest where we've got all together in the same space okay yeah so we did a lot of such exploratory testing during the hackathon yeah I'm pretty confident that the patch will work but yeah I think that testing of this thing is not hackathon friendly it rather needs somebody to set up all kinds of test automation and run Jenkins war files through that so yeah generally it just ends up with resources so probably we should move on to the next topics so what I really expect from C participants is to get some feedback regarding the JEP regarding the proposal so that we can understand whether this scope is enough to just to get it in the weekly and yeah any feedback would be appreciated because here I did some bold assumptions for example saying that you do not need to build Jenkins on JDK 11 and yeah some proofreading for the points in the document would be really useful is there any preferred place for feedback is it still a PR as a JEP or is it so pull requests if you want to propose a change so no developer platform seek mailing list you can just comment in this thread okay okay thank you let's move to the next topic so the next topic is quality outreach so there was some activity in the background but actually what we did is that this project has been added to the quality outreach program list so you can go through the document and here is Jenkins actually there are lots of Jenkinses because many projects are on CI here for verification I think but yeah so this is the current state here so we are listed as and there is something like preliminary exploratory testing for Java 9 for Java 10, Java 11 and Java 12 yeah right so yeah this is the current stage so we have started doing something but we haven't started automated testing which is actually expected from quality outreach participants so currently we have KK as a contract in this list we could potentially change the contract to platform C but here it tells a question of what is expected so it's work in progress but what I wanted to say in this meeting is that actually we are here and maybe if we hit some issues for example if we discover that some of upstream libraries are not compatible with Java 10 or 11 we could use quality outreach resources to reach out to these library maintainers and probably to do something so yeah it was just a brief status update so it's work in progress any questions about that yeah I guess no okay so and then we can switch to a more interesting topic about Windows installers Alex are you still on the call it's here yeah sorry okay so surprisingly it's also related to Java but not exactly related so yeah currently we have an issue with Jenkins project because in the download page you can download installer for Windows what does it mean that we have a packaging which packages every LCS so we created this for Windows but just to be clear it's Windows 32 bit so it means that this installer is built for Windows 32 bit in bundles 32 bit Java and when you install it goes to program files x86 and yeah it's not exactly a bit problem but it's still a bit confusing the problem is that we know that Jenkins cannot work in 32 bit mode when you run on 64 bit operating system there are several reasons for that but one of the main reasons is that we have Windows process management component and this component explicitly required to be running in 64 bit DLL when you run it on a 64 bit system why it doesn't matter this library is being used for termination of processes when you abort a build in Windows for example due to some design specifics of Jenkins it checks environment variables when it terminates processes and in order to check environment variables it needs to directly read process memory parse it and yeah then retrieve some flags from there it's just one of the issues of Windows API but a short summary that if you run Jenkins in 32 bit mode or if you run an agent in 32 bit mode on a 64 bit system it's not going to work and our packaging for 64 bit machines actually does it by default so it means that if you install Jenkins on a Windows server without Java installed then you just get a broken configuration out of the box and yeah there are several ways to resolve that one would be to follow approach used by the most of projects is to offer separate packages for 32 or 64 bit systems then we could just duplicate 32 bit packaging at all or maybe remove Java from Windows packaging so that it cannot be self installed easily Java would be the prerequisite but at least it wouldn't have such behavior issues and yeah the last option just remove Windows installers at all probably because yeah I do not know so many people who really use Windows installers nowadays they would be rather preferable to just replace it by bare metal war file or maybe chocolate cake distribution like Alex proposed so yeah there are several options and I wanted to discuss these options because yeah we need to do something and all these options have their own disadvantages so it would be great to get some feedback from you guys and then you probably would create a joke for that so there was some feedback in the mailing list but yeah I guess the feedback was to firstly duplicate 32 bit probably unless we can support that and yeah then other distribution management I mean that's the way Oracle is going is only releasing a 64 bit Java right so I don't think there's any problem myself in deprecating and only going with 64 bit releases of Jenkins even Windows in newer versions I think I don't think they're really releasing 32 bit versions we're supporting them anyway yeah when you say yeah newer versions 2008 R2 right which was probably 2010 or 2012 so yeah newer versions like 7 years old I was a trade-in condition on a Windows embedded just three weeks ago and it was 32 bit and Windows embedded is I think which runs almost all pos terminals in the world so I would say that it's still pretty popular but on the other hand even if we deprecate 32 bit support it's not a showstopper because everybody will be able to install it just by downloading core file there's really much state of art things in the packaging itself I guess one of my big questions is how beneficial is the installer versus just running the war directly so what installer does it automatically installs Jenkins as a Windows service this is the first difference and yeah I guess this is and yeah another difference is update float so with installer you can install Jenkins and also update Jenkins and when you update Jenkins installer is smart enough to terminate the process update and then restart the process something like that if I recall correctly on Windows inside of Jenkins there's like a button somewhere that lets you install it as a service is that right, is this the installer we're talking about or is that different it's I think it's different yeah so there are two kinds of installer in Jenkins for Windows so one you can just go to the download page click here and here you just download zip file and this zip file contains MSI so it's Microsoft installer it does the job there is automatic packaging it's located here yeah so here you can find what this installer actually does so yeah all the stuff this is one way of installation and another way of installation that Jenkins itself offers an option to install Jenkins as a service so if I recall correctly it's in the Windows core Jenkins core yeah so this option what it does yeah Windows installer link so when you start Jenkins from the word file it checks whether it runs on Windows and if it runs on Windows it offers a button in the web interface which offers to install as a Windows service and then you click this button and the installation fails because on all modern Windows versions when you run installation of a service you have to run with local administrator permissions so you would either need to run Jenkins core as administrator or when the installation fails you get all Windows service wrapper files and you can restart the installation from the CLI as administrator so there are a few options but yeah generally you can install Windows service in the same way in such way yeah so if we duplicate MSI for 32-bit systems then we still retain this flow so you will be still able to install Jenkins as a service yeah from WebUI but yeah whether it's comfortable enough or not it's less comfortable but if you took only about 32-bit systems I think that it's fine and yeah actually one of the main concerns of supporting 32-bit systems that currently we have Jenkins weekly and LTS release flow this flow is being driven by Kiki and actually if we make him to release two versions of Windows it increases the effort to ship every release and it also increases a chance of mistakes and versions may be updated improperly or whatever so I would rather prefer to have on the single installation of the available on the Jenkins site and if we agree that 64-bit installation is fine I would rather replace it and create a JEP to document the Windows 32-bit supported duplication but if we have a full support to deprecate 32-bit MSI packaging, ship 64-bit only we can deprecate 32-bit as MSI we could choose instead to say yeah so deprecate 32-bit is yes for me absolutely yeah I agree and this is for the master right it's not even for agents so agents can still be 32-bit master can still be 32-bit so we need to be installed nothing else right so I could still for whatever reason choose to run Jenkins.war on a 32-bit Windows platform and it should should continue to work the thing I don't have is an MSI based installer for me the MSI installer has so many other challenges hiding it yeah I'd rather just deprecate 32-bit what do you think Alex? I agree I think what we're going to find is the majority of masters are going to be 64-bit regardless I think people may have agents that are 32-bit but if you're running a Jenkins master it's most likely you're using a server OS and so I think most server OS is now our 64-bit so I think I'm fully in support of deprecating the 32-bit okay so yeah I think we have a plan here so I will just write a short JEP to document of it and I'll try to submit it by the next meeting okay the other alternatives are not exclusive of that alternative you're going to take us through those conversations great I think we really need to discuss so just to provide some context Chocolaty is one of the package managers for Windows so it's pretty similar to Brew in Mac or to whatever I would get in yeah in Unix platforms and actually if you take a look at the Chocolaty it's actually yeah Nougat but package manager so Nougat is a package manager for libraries, codependences and Chocolaty is just a thing which uses Nougat and which offers installation flows at least it's my elevator pitch for Chocolaty but maybe Alex could clarify it a bit more yeah so it allows you to kind of wrap up different installs so you can do X copy type deployment which is basically just you have like a zip file and you unzip it locally it also supports installing from MSIs so there are a lot of things I kind of started putting together a version of a Chocolaty package for Jenkins there's one out there already it's not the it's not done by an official channel so if there are it's not going to be controlled or updated from Jenkins project which I think is important to the lost security release right exactly so I think it'd be important to have as part of the weekly release the ability to upload that the new Chocolaty package and so forth so that's kind of what I'm looking at is how it could incorporate into the Jenkins build alternative way to have a trigger for example we think that we can have a web hook for Jenkins release in the current state but yeah I hid it when I was doing Jenkins experimental docker packaging prototypes but what we can do is we can create we can have a web hook from docker hub so when docker package get deployed we can invoke a hook somewhere in order to trigger the build of Chocolaty and it can be not even a trusted CI but something like up there for example if you have if you want to have a shortcut so the benefit that would be that Kosuke wouldn't have to do anything himself yeah right well and it appears from reading that Chocolaty page that package is up for adoption so that the maintainer of the Chocolaty package that's out there in the community would love to have it adopted apparently I can see that we also had a maintainer on another open source project we had kind of a community member that had put together an iron python Chocolaty package and basically I went in and provided details that I was the maintainer of that and they allowed me to take over that so that shouldn't be a problem either in terms of taking over the Jenkins package on Chocolaty I think KK would probably just have to do some work to show that he's a maintainer or someone from the core team or something would have to do that but I don't think it would be a problem we could probably take ownership of this package for now and add others or you Alex could do the same so yeah and then we can figure out what would be the ownership model one thing that as I was looking at the Chocolaty package you can have dependencies and so I was looking at having a dependency on the GRE8 what would be nice and this is probably an improvement to the MSI the other thing that we would wrap with this Chocolaty is to check for an existing GRE and ask the user if they want to use that rather than installing the versions with the MSI so that's something I can take a look at as well it's something like when you're installing like Tomcat for instance Tomcat will go and look and try and find an existing GRE and use that rather than using it it does prepackage one as well but if it finds one it allows you to use that one which I think you know would be a good enhancement to the MSI right so this is this thing and I can create a ticket for that so I think that we could probably do it as a separate change but yeah I think it's something we could also do but yeah the problem is that this bit may be actually breaking one and maybe we don't just remove it at first maybe what we can do is add in a search for an existing one and if an existing one is there ask the user if they want to use the existing one or the packaged one and it could be we could also make it into an option for the MSI so that it can be a silent install from things like Choclity we can specify we want to use the existing GRE that will be installed by Choclity itself because of dependencies so I mean there are a couple of things we could do to mitigate any breaking changes for users to make it less breaking so go ahead or excuse my interruption no I was I just wanted to say that yeah of course we can do all of these options so they might have it so for me it sounds like Alex you have already experienced with Choclity that would lobby that at least for me that he should be the de facto leader on that exercise I'd be delighted to learn more but I'm a novice whereas he's got prior experience so I think Alex if you're willing let's put that on your shoulders yeah that's fine I've done a few Chocly packages for internal things that work so I have a bit of experience there's some stuff that I don't know and I've also worked with Wix which is the Windows framework that the MSI has built using which is a fun technology it can be pretty tough to work with but I do have experience there so I'd be happy to help in that front for sure let me make you happy what, 8 weeks? yeah it's my euphemism detector went off when you said fun Alex that was great, very nice yeah the word for trust meaning for fun I guess Alex, does this action item look good to you? yeah it looks great I'm happy to do that I don't know that it's worth an action item but Alex I would love to have access to a Chocly package so that I could simplify my regression test infrastructure maintenance on my Windows machines so if you need a tester pick me, pick me okay yeah I'll definitely involve people I'll probably post something to the developers mailing list once I have something I'll probably create essentially that could probably be rolled into the Jenkins infra or wherever the packaging stuff is so it could be kicked off and run and stuff like that if you have any feedback in terms of like options that you would want to be able to specify for the Jenkins install because Chocly allows you to pass parameters to the install so I don't know what's available in terms of what the MSI supports in terms of parameters and stuff like that but I'll look at that but if there's anything in addition to what might be there let me know and I can take that into account as well okay regarding the infrastructure requirements doing you something for that because our main problem is that we don't have infrastructure to test Windows installed or think within CI Jenkins Ion how I work it around currently I'm a maintainer of a Windows service wrapper or what I do I do testing in a peer actually yep and all kinds of release automation there as well so it's one of the ways how you could automate service testing if you really need that maybe not the ideal thing but at least it does the job so Oleg because we certainly have Windows machines on CI.jenkins.io it's that we're not allowed to damage them by installing services for test purposes so currently our Windows machines are being provisioned from Asia but if I understand this stuff correctly there are no single short machines so it means that one machine is connected another job may pick it up and obviously in order to run anything for Windows installer testing you need to run Jenkins agent as administrator and yeah there are so many reasons why it's wrong so yeah it's something we shouldn't exist on the default installation do they have docker support on azure for Windows docker images? no I guess I can ask Olivier because there was a question about that recently do you really want the services in docker? my answer no just because I'm skeptical of Windows docker is hard it's a very different model for me and so I wasn't sure we wanted to do that but we would require getting permission from Olivier and yeah I'm open to others yeah if you want to do service testing in whatever Jenkins instance we will likely have to try Windows docker or we will need to somehow configure provisioning of single short VMs from Asia probably doable but it definitely requires sign-off from infrastructure team before we even start planning it I think that it's something we could do if needed I think there are probably other various people who would like Windows docker support on CI Jenkins I also avoid our justification I'm sure like Jesse has mentioned before pipeline team could do the various things okay so I can check availability I have never thought that it may be possible to run to test services in Windows docker maybe we could try okay so yeah I guess that's it so I believe that having chocolatey packaging would be reasonable anyway I'm not sure how many I don't so here 4,000 downloads since December it's still a pretty big chunk especially since this version was probably insecure by December okay so yeah something we could yeah extra adoption would definitely help okay so just short action item recap open gdavid g9 to platform seek then for installers I think we still need to duplicate 32-bit installer version anyway yeah then chocolatey and Windows docker availability and yeah one item that I thought was potentially separable is removing java from the windows packaging or is that a breaking change Oleg and therefore it needs a separate exercise as Alex said it may be done in a non-breaking mode okay so in the context of the chocolatey work that'd be the place where we look at a way to do that non-breaking okay yeah so yeah I can add action I can for that okay does it look good to you yes so yeah regarding java 11 do we want to do something before the hackathon or do we park the discussion for now yeah I will definitely appreciate feedback in the job but yeah yeah I can't do anything before the hackathon myself I can't do any feedback on the JEP that I think I can do but I can't provide any substantial time before Jenkins world yeah same for me so we can just start preparing this activity so by the time we meet there we have some plan of action so anything else to discuss today we have a time slot for regular meetings but I think it makes sense to take it offline so we will just create a thread and yeah I think that yet the next meeting so we have Eclipse Open J9 next week so I think it would it's 23rd of August my Firefox doesn't localize to English so yeah this will be the meeting and then we could schedule something maybe when we have updates on these topics and this one because it seems that we can iterate here even now does it work for you? yes okay so yeah maybe we meet in two or three weeks then let's follow up on the discussion list sounds good okay then everybody? yep so just to repeat this discussion has been recorded so it will be published in YouTube and if you have any questions just join our GitterChat so that we can discuss the things then so yeah then thanks everybody who participated in the call and thanks to everyone who watched it I'll just stop the broadcast bye