 Welcome to the Jenkins Governance meeting. Today is October 14th. We have several contributors on the call. Alex, you have Mark White and me. Today we will go through the common agenda. We have some news to share. Then we will talk about trademark usage requests we received over the past week. We will talk about ongoing Jenkins elections and everything of several definitions and we will schedule the next meeting. Basically, that's it. You might get more topics during the call if somebody else joins. But yeah, let's start from the agenda. So, October 1st. Yeah, actually in the middle of October 1st, so it's a month-long event. We have a number of future projects published there and we need to see if there are contributions in these future projects. So far, so good. Today we had an online meetup to talk specifically about Jenkins documentation and contributing to Jenkins. You've got how many, 20 participants are there in total or so. And we will publish it according to today. So hopefully it will help to participate in the contributions a bit. But compared to the previous year, October 1st remains relatively slow. So if anybody is willing to push particular areas, you're welcome to do that. Still, there are some contributions we expected. So it's going pretty well. If you are watching this recording and if you want to contribute to Jenkins, this is a good time to do so. Okay, CDCon. So last week we had a CDCon conference. We had a few Jenkins talks there. Also, there was Jenkins Birds of Fear session where we discussed Jenkins roadmap. There were other activities in the community in the CDL booths. So thanks to everyone who participated. The conference went well. The recordings should be published by the end of the month. So stay tuned. We also plan to organize a few events to talk about specific topics. Yeah, I guess that's it with CDCon. And we didn't have any major events planned until December from what I know. In December there will be a Jenkins user conference in Japan where we have several speakers. And yeah, this conference will be entirely about Jenkins. So hopefully we will be able to have a remote booth there. Usually it's not an option, but since everything is remote this, yeah, maybe we could do that. Okay, on the technical side, last week we had the LCS release. Mark, would you like to summarize it? Yeah, so 2.249.2 was released last week with a fix for a regression in one area and a few other improvements to Jenkins 2.249.1. The release automation worked without a hitch flawlessly. It was great. Great. Thank you. Yeah, quite a number for a fix. Okay, and the next LCS version. So on October 21, according to our schedule, we will be selecting a new baseline. So if anyone is interested in this identity of feedback, yes, we had a common weekly release. So unless something terrible happens, you'll have only one release until the baseline selection. And what it means is that if you see any regressions, and it looks like there are some regressions reported, it's not working anymore in 2.6.1. I don't know what's broken. Yeah, so some, well, we updated JK. What could possibly go wrong? Yeah, but yeah, that's the point, because next week we'll be doing selection. And if you scroll down the last releases, you're not this stable, I would say. So actually 58, 57 was the last release when you had no regressions reported. So we will have a choice either to take something recent, do backporting, and for that we will need information for the next meeting so that we can make decisions whether we can backport things in time for that one. Or we proceed with conservative way, but yeah, in such case it will exclude a lot of changes. So let's see. Yeah, the decision will be made next week. So I guess Oliver will start for selection, selecting a new baseline soon. Yeah, hopefully we'll be able to stabilize it in the next weekly so that we don't have to worry about the regressions. Okay, any other news, comments? Okay, then we have two trademark usage requests, one from Techmatrix, another one from Websoft9. And basically these requests are Jenkins trademark usage. So currently we don't have specific pre-approved patterns and every request should go through the Jenkins governance meeting to be approved. And yes, there are two requests we've received. So one is for Techmatrix Jenkins support as a trademark and another one is for Jenkins on Ubuntu by Websoft9. So we need to make a decision on that. And yeah, for that, I added additional topic to discuss is whether it's a good time to actually start enforcing Linux foundation patterns. Because yeah, as a part of integration from SPI to Condizion Delivery Foundation, we expect transition trademark to the Linux foundation. And after that, this trademark usage guidelines would apply to the Jenkins project. So the trademark transition hasn't happened yet and we're going to have timeline. It's one of the topics we need to discuss later. But yeah, the principle that at some point we will need to adopt these guidelines. And actually these guidelines are very reasonable. So we will read to these guidelines since 2016 or so. But we haven't been enforcing them. So there is a lot of text. But yeah, important things that there are pre-approved trademark patterns which are considered SPI use. And just it would allow to set common rules how these trademarks should be used. Secondly, these patterns seem to be very reasonable. And my personal preference would be to proceed with adopting this trademark usage guidelines, even if the trademark is not officially transferred to the Linux foundation at the moment. I'm a plus one on that for sure. Yeah. You could reserve a right to make exception if we really see a need to do so. But yeah, as general guidance, I think this rule is fine. I do not see any problem with pre-approving these patterns. All the disclaimers say that to the least. So for me, this would be the preference. It's a good idea, I think as well. So now do any of the proposals contradict or violate the guidelines that Linux foundation offers here? Most contradict both. And yeah, so let me open approved trademarks. Yeah, this list is a bit dated. It's actually my fault because last time when I was approving trademark for Jenkins rule, it was last spring I took an action I can to migrate this page to Jenkins IO, basically somewhere. Then we had a discussion about how to store governance documents and we agreed that we can move these pages to Jenkins IO. And now I have an action I team to actually do that. But if you take a look at the list of these trademarks, we previously approved. So the situation is I guess none of them actually fits the pattern. So there are multiple reasons why it happens. Firstly, because basically if you want to use an existing trademark, you would want to put the popular term in the front. And many trademarks had Jenkins in the beginning. Some trademarks firstly put to the company name, the trademark name, then for example, called these Jenkins, it's popular. And get this how trademarks are usually organized. So that's what we have. And none of that is compliant with Linux foundation trademarks. So for me, firstly, whatever we do, you wouldn't apply this guidance retrospectively. So whatever we have already approved is approved. When Linux foundation started, they had exactly the same case because there is red hot enterprise Linux. But yeah, it also doesn't get these trademarks guidelines. So I think that for us, it's generally good. But if you take a look at these trademarks, you can just break them down. But none of them really is really compliant. So Jenkins on Ubuntu by Websoft. So Jenkins in the front, Ubuntu is additional to this part, which is another trademark being used. And I'm not sure how it should be approved in this case. But I guess it's not our problem. But yeah, this pattern doesn't work. So it could be, for example, yeah, Websoft 9 distribution for Jenkins, Websoft 9 Ubuntu distribution for Jenkins, et cetera, all of that would fit this trademark. But not like it's written now. Pretty much the same for other trademarks. So it's a Techmatrix Jenkins support. So this case is a bit more tricky because even if it doesn't match the trademark as is, we have a precedent when another simple trademark was approved, basically CloudVis Jenkins support and CloudVis Jenkins access. So even if it doesn't fit the trademark guidelines, rather than towards the same plus one for that, even if they prefer this pattern, well, I would still recommend the Linux Foundation pattern. I think if we haven't, go ahead, Mark. After you, Alex. I was just going to say, since we haven't adopted the Linux Foundation usage yet, I think we have to go with what the precedent is. So I think we need to plus one that for now. And then once we adopt the new naming conventions, we can specify that those override previous precedents and new requests should meet the Linux Foundation pre-proof patterns going forward. That's my take. And I think the Techmatrix example, for instance, if I read it correctly, could be pretty easily changed. If they were willing to do Techmatrix support for Jenkins, that fits with at least one pattern that the Linux Foundation seems to use. We shouldn't, we don't get to change their proposed trademark. I understand that I was just thinking, it's, they're not that far from the pattern that seems to be okay with Linux Foundation guidelines. So here my recommendation would be to recommend them to consider the Linux Foundation pattern as our preference, but still approving the current trademark if they want to do so. Yeah, I think that sounds like a good plan. So just to be clear, that would give them approval for Techmatrix, Jenkins support and implicit and approval for, if they chose it, Techmatrix support for Jenkins. Yeah, got it. Thanks. Okay, Techmatrix enterprise support, commercial support, it's basically they own and choose how they promote that and how they choose the name. But yeah, as long as it remains within the pre-approved trademark pattern, they don't even need to agree with us. There are some exceptions, of course, but yeah. Yeah, so they still should avoid confusion, etc. So this pattern might still be a problem, so it's not guaranteed in all cases. But yeah, I think that we should be able to pre-approve it. Everyone was a plus one for that, right? Yes. Yes. Yes, for me, yes. We'll apply a quick one retrospectively, everything remains approved. Yeah, until the transition is over, make exceptions. We'll capture it well. Any additional notes we would like to add there? So that covers the Techmatrix one. Could we go back to the Websoft nine one, or were you planning to do that already? Yeah, so let's finish with them first. I was just making the common notes. So yeah, this is Websoft. Okay. In the approval message, I'll also say, we are looking at adopting these forms. If you could change to this, that would be even better, but we do approve the Techmatrix support, Jake and Sport. Okay. Yeah. I recommend using the LF pattern. Yeah, does it capture it well, Alex? Yep, looks good. Thank you. Okay. Then we go to Websoft nine. Okay. So basically we received this request through Jenkins Government and Sport channels. So basically the original request from them was to confirm whether they need to ask for trademark approval. So basically they reached out to us to confirm and we provided clarification. There is already a hosting query this name. So they open to adjust this name as we read this and hence the request. So the problem with that, that Jenkins on Ubuntu by Websoft nine, it doesn't match existing patterns by Linux Foundation and doesn't really match the precedent. At least, I don't see a trademark which would be clearly referring to the same pattern. Is Jenkins jumpstart by CloudBees a close enough approximation or Jenkins for chosen workshop? I mean, it's not really on. So it's clearly not an exact match. Yes. Yeah. Firstly, these ones here, the trademark usage names, but they're not product names. They're not distributions. They're just workshops and whatever. Yeah, basically they ask permission for product Jenkins on Ubuntu. We have Jenkins on Ubuntu to basically provide official distribution for Ubuntu. What they actually do is provide AWS market place entry where you can get it running. So for me, it's not only, so it's potentially causes confusion. And secondly, it doesn't really represent what they do. So is this what they are asking for right here? How it would appear here? Are they asking to update this to say Jenkins on Ubuntu by as the whole thing at the top? I guess this is one of the options because what we request from other vendors that a trademark must be used as a full name always. Well, the reason I'm asking, so if you go back to the AWS market place thing, right? Yep. So you say Jenkins on Ubuntu by Websoft here. Right. Is that what they're wanting or are they just wanting how it appears here? Because here I think it's confusing, right? Because it just says Jenkins on Ubuntu and it's not like, you know, is this the official image? Is it not the official image? Who's Websoft 9? But if it's, if they change the title, the full title to be Jenkins on Ubuntu by Websoft 9, I think that would differentiate it from being like an official Jenkins on Ubuntu from the Jenkins progress. So that's my question is, is where are they, you know, is that going to be updated or not? I guess it has to be updated because for me, you know, we would vote just for Jenkins on Ubuntu. Jenkins on Ubuntu by Websoft 9. Yeah, I agree with you, Alex, that in this case it provides enough to differentiate at least from our side point of view. Again, it's not our problem whether they conduct canonical to get approval for Ubuntu, etc. Right. It's their job. So yeah, we can request the full name to be used everywhere. So on the approved trademark usage from Linux Foundation, I thought I had seen something where it had the on nomenclature, but maybe I don't know what it was for use with. Yeah, none of these trademarks actually qualifies. So yeah, it could be, let's say, Websoft 9 distribution for Jenkins, which would clarify or Web9 AWS package for Jenkins or whatever these ones will define, but there is no trademark where Jenkins will go to the front. Right. So we don't have a precedent on this one and it doesn't follow the Linux Foundation. So what would be your preference, Alex? So I would say them moving their name first, like is kind of the pattern in the Linux Foundation. So Websoft 9, Jenkins on Ubuntu or something similar. So basically requiring them to follow the Linux Foundation. Yeah. So for adopting those guidelines, are we, now that we've plus one, we're basically now going to apply those going forward, correct? Why not? So we still need to document that. But yeah, I guess it's perfectly fine if we apply it to all the requests we discuss. Yeah, I would say currently a negative one for their current proposal from me based on the Linux Foundation examples. And yeah, so I don't know if we want to come back with suggestions for them or if we just point them to that page and say, please look at these examples and give us another proposal. Okay. Because there is no precedent for that for that pattern. Okay. So would we accept if they were to, or is there one of the existing patterns that might fit more closely than something that complies with Linux Foundation guidelines? You mean one of the patterns we have here? Exactly. Yeah. That would still fit in a cloud. I didn't see any of those patterns that I thought, oh, I could understand how I might use that. So it was like a Linux Foundation. Jenkins distribution for AWS. Is there, so like on Azure and AWS, there are other Jenkins images. What are those patterns? You mean on the AWS market, please? Yeah. Yes, that is quite a lot actually. And yes, you mean this, not all of them follow all the trademark guidelines. Jenkins... Like certified by Bitnami and... Yeah, you can start from here. Jenkins on Ubuntu, Jenkins on Windows Server 2016, Jenkins with CentOS, Jenkins container for the Vine 2s, Jenkins on Ubuntu. So I mean... Yeah. If you want to be... None of those people have... Yeah, exactly. Yeah, none of those people have requested a self-license. So it is, so I think we should show our appreciation for Web... What are there? Web Logic 9, whatever, for actually requesting this self-license. That's very, not nice, but thumbs up to them, right? So at least they are doing that. So I think we don't have to bend over backwards for them, but we can try to help them out with suggestions or something like that. So maybe we maybe that's how we do it. Yeah, that's for sure. There's a ton of images on there. Well, the Linux Foundation has a logo usage guidelines. Actually, it's a good question of what would happen with Jenkins logos after that. But yeah, our logo isn't trademarked from what I know. And our logo is on the Creative Core ones. So it's not a concern for me, I mean, if I see both future. But yeah, cleaning up these things. There are lots of pages there. I have more important things to do. Yeah, yeah. So I mean, so there is some precedent that we haven't, you know, contacted these companies either, right, with their usage of the trademark. So I'm kind of now backpedaling a little bit on my minus one. Yeah, that's fine. Not that it's okay for those other companies to have done that necessarily, but there is a precedent out there. And this company is the only one who's actually contacted us about it. Yeah. So it's no longer minus one. Is it minus data? Yeah, I would say that. I think because there's a bunch of stuff out there already, and we haven't gone and contacted those companies about the trademark, I think we need to be a little bit more lenient. I think going, you know, now that we know this, we either have to go and contact these companies and say, Hey, we have a procedure for requesting to use the Jenkins trademark, you know, and things like that. And but I don't know, that's a lot of work. I don't know if we want to do or not. Well, that's a lot of work, of course, there is a nuclear tactics reaching out to AWS and raising a trademark dispute on the search base. I'm not sure how it goes and to be honest, I don't think it's appropriate. Yeah, I agree. Yeah, because we want more people using Jenkins, right? So we also have to protect the trademark so that there's not a, you know, someone provides a container that totally screws up everything and then someone gets a bad image of Jenkins. So we just have to be careful about both of those things, right? Yeah, I will say I'm a minus zero or plus zero. That's very helpful, I know. Well, I don't have sensors. But yeah, I'm sure. So I also don't have strong minus one about that a bit for sure. If it was Jenkins on Ubuntu by Websoft 9, yeah, I think it would be also okay for me. Will you Mark, what do you think? I'm okay actually with Jenkins on Ubuntu by Websoft 9 for this request. I think I'm plus one for it because they asked. Now, as a general pattern, we know, I think we have already agreed we want to go to Linux guidelines. But for this, they asked, I have no objections to granting it so long as they use the full phrase. I agree with Oleg that Jenkins on Ubuntu as listed there leaves me uncomfortable, just like Jenkins with CentOS 7. It's not clear to me who's providing it in the title. It's not clear to me. I also don't know. Well, at least it's stupid. It's surprising for Windows Server 2019. Yeah, that's what I mentioned. It's T2 Medium. So can you go back one? So there's also, one more, sorry. There's also this, what supported images? Is that an Amazon, that Jenkins on Ubuntu 1804? I guess it's a company. Oh, it is a company? Okay. Okay. So they had a similar thing Jenkins on Ubuntu 1804. Yeah, I'm not sure how many people are in this company, but anyway. So, well, again, it's probably a valid use case on Austin phone. Again, any vendors are welcome to provide their packaging. And the trademark is what we need to secure. Yeah, so like those Jenkins container powered by Intus, I think that's fine usage. Yeah, because, yeah, it's not a Linux foundation trademark, but I wouldn't have concern about that. So as long as there is clear differentiation in the name, or like Jenkins powered by class method, yeah, okay. Jenkins don't get container. No, it's not a case. Right. So it looks like they also have the Amazon as well for Websoft 9, that Jenkins on Amazon Linux. Yeah, we can go far. For example, we can discuss what Microsoft requested the trademark approval for the official images on Asia, but yeah. So anyway, it's something you can figure out as we go. Yeah, I'm not really sure we are ready to invest in cleaning up this mess. Those some images should be just removed because of security concerns. There is, they just treat clear risk to users. Yeah, I'm not sure what's AWS policy on that. I'm definitely not ready to spend time working with vendors directly. Yeah, I'm on plus one now. You guys have convinced me. It's like that movie 12 Angry Men, right? Yeah. But only if there is the company name as last thing. Yes. Yes. We are likely to approve it. Going forward, we can document it. Okay. Sounds good. Yeah, I guess so. And I still have an extra item to create a new trademark page on Jenkins.io. So Mark, since you're interested in doing so, what's your preference? Do you like it on my point or do you like it? Given the burden that you carry, I'd be happy to take it on if you don't mind. So I am happy to do it and willing. That way, you can keep focus on other things. It's hard to reject the software. All right. Yeah, I'll submit the pull request to migrate the trademark page to some place. I assume a dedicated page on Jenkins.io is a good thing, just like we have on the Wiki today. Okay. So you have Jenkins.io? No, we don't. So what I would rather recommend. So firstly, having to under the project, because under the project is protected, which basically requires approval from the board. And here we can just introduce a new trademark section. Then we can take the content of this page, maybe a document, some recommendations, basically taking what Linux foundation documents with proper attribution. And yeah, also you have this governance document, which looks much better than it looked one year ago. But yeah, so there is also a trademark here. So this part will need to be either moved to the duplicated. I believe that all content here is perfectly valid at the moment. But most likely, we will need to migrate a trademark, trademark attribution. Yeah, by the way, yeah. So I guess all this content shouldn't be moved, just in hyperlink. Well, and I need to find a way to do redirects of interior content anyway for another purpose. So this is a great excuse to be sure I can do that here as well. Excellent. Thank you. Okay. Thanks for taking that. Any other comments about this topic? Move it on. One, election status. Yeah, I hope it won't take other 40 minutes. So yeah, the deadline for board and officer eliminations is tomorrow. We've got some eliminations. And most likely we will also have eliminations coming to the last moment, like it happened one year ago. But still we encourage all contributors, including current officers and current board members to submit their eliminations so that we have a diverse list of candidates. Wish we could kind of come from all these candidates and then have a lot of nominees published, but let's see. So we got nominations for overalls. So it's not like we on fire having no nominations somewhere. Minionations still need to be confirmed, but it looks that they are more or less set. Yeah, more nominations would be still good. One problematic topic for us right now is number of voting registrations, because we are quite low there. And since we don't have any announcement, so if you're not subscribed to the Jenkins developer, you may miss notifications. I'm actually thinking about asking the infrastructure team to dump a list of maintainers and at least limited distribution, reminding contributors to register for the actions. Have we done anything on social media as well? Yeah, but still contribution registrations are quite low. Yeah, it's like 20 or something, right? Yeah, one of the reasons is that yeah, firstly it's almost half a month until the deadline. And again, Spike usually comes a few days before the design. But yeah, I would rather start pushing Petrolia. So Mark, what do you think? Is it feasible to get a dump of maintainers, etc., and do distribution through SendGrid? I think so. Olivia certainly did a distribution through SendGrid last year using the entire LDAP database, a subset that our maintainers, where would we ask that? Is that a question we would ask of GitHub through the GitHub APIs to identify maintainers? We have repository permission on data. We have tools to dump lists of maintainers from there. And we can query LDAP to retrieve emails if you have proper access. Right, so given a GitHub ID, we can ask our LDAP for the email address associated with that ID and we can notify that. We do not even need a GitHub ID because we store artifacted IDs. Right, we need their Jenkins login name. Well, no, the Jenkins login name is basically well known. Okay, so there are all those concerns about that because we will be basically identifying a subset of our users. One may argue that identifying through main cases is also identifying a subset of users because not everyone watches them. Sure. Yeah, I'm just thinking about it as an option. We can also do mass distribution, but yeah, I'm sure we want to do that this last time. Yeah, I'm not in favor of the mass distribution again. I think last year's experience was not good enough for us to say let's do mass distribution again, but using the maintainer, generating a list of maintainers seems reasonable. Would you like me to discuss with Olivier and the infrastructure team to see their assessment of it? Yeah, if it's possible, I would appreciate that. Okay. Yeah, we can also do another push through social media because one thing I discovered last week, even if you had a jump-atron here for elections, this jump-atron was broken because URL was incorrect and it was pointing to 404. I have fixed it just one week ago or so. Okay. Well, and the fact that we heard no reports that it was 404 is a bad sign, right? That made me know an attempt to even click it. So ouch. Yeah, right. So basically, I could just fix that a while ago. We can also remove CD-Con and I guess it's no longer relevant. So we could adjust the first jump-atron to open, but yes, I'm open to other suggestions how we could boost the registrations. Is this one of those where we could ask for a list of help to do some community marketing, some things that might help us get the word out in different ways? It would be nice. So I will remove CD-Con and jump-atron. Later, you may just put another CD-Con and jump-atron. But for now, I think it's fine. Alex, will there be any of those? I've never had to deal with an election like this before. So I'm not sure I have any good ideas, but I will definitely think about it. Okay. So we still have some time. Maybe we could ask for street promotion to selections. I'll publish it in the beginning of November. Good timing, yeah. We shouldn't do it. Okay. Yeah. So let's reconvene next week and see where we stand. I think that one of the action items which we need to handle anyway is creating an email announcement mailing list, but just for announcements, low traffic one. So similarly, how to order projects too. So basically it's subscription mailing list where we announce major news, conferences, events like let's say October first, but here is really limited traffic. It won't help us with these elections, but I think that in general it would be nice to have it in the coming income. I think it's a good idea. Income stash announced, yeah, something like that. Yeah. I can take the section item because I was doing it for other projects already. So while it's actually quite easy, the difficult part is to get people subscribed not to having this mailing list again. So I will handle that. I'll do it in official definitions. You should be moving to this topic. Just have several minutes left. Yeah, I think so. Okay. So I have finally pushed a full request which summarizes what was proposed in the mailing list. So basically shifting officer role descriptions more towards cartoonating the things, the reading the teams, not doing everything on their own. Actually, yeah, it was implied expectation for a long time before when we started CX working groups. But the documentation was quite different. So I started the work and quit a bit. Your current state looks like that. So I did some documentation and you can see that the page from Jenkins team leads to team leads and officers. We is assumption that there are two types of roles. Team leads are basically roles appointed by the Jenkins governance meeting leading particular teams. Let's say hosting team like we introduced last summer, etc. And the Jenkins officer is an elected role. So the distinction basically a point from the process, but in principle it also the same is reverse to responsibilities. There are common responsibilities of the work inside the teams and CX that I lead and reporting new contributors, knowledge sharing and share officer rotation. Yeah, wording probably needs to be changed. I just wanted to put it explicitly to highlight that it's not only onboarding new contributors but also implementing a ladder within the team so that contributors could basically adopt other roles and eventually be able to take the key roles in the community. Then facilitating initiatives, maintaining the teams roadmap, ensuring the initiatives are reflected on the public Jenkins roadmap and representing the Jenkins community within their responsibility. It's also something new before that basically the Jenkins board was responsible for representing the project. Well, I think that we should try to assert the de facto state when officers represent the project. For example, Olivier Tolle talks to dozens of vendors handling infrastructure, Daniel handles security contacts. I'm also, yeah, other officers also do such communications here and there. Yeah, basically many contributors sat on behalf of the project, but I see no reason why team needs and officers shouldn't do that. So that's why I put this item and then common responsibilities. This one probably still needs, it still needs to be polished to more focus on continuing the work and leading the work. But yeah, some working changes have been over the applied and the event officer definition has been completely written. As we discussed in the last meeting, this is plus one for the current description. Okay, so I'm not sure whether we are ready to vote for that today, but it would be nice to vote for that next week so that officer terms are finalized when we announce the nominations. Sounds good, I'm good with that. So I would ask everyone to just review the list and if you see any other improvements which we could do or changes we need to make, please highlight that. Again, this document is not something which we need to finalize for one year, we can really improve it after the elections, but I think it would be important to update these expectations before the cycle happens. Sounds good, thank you for doing this update. Well, there is a lot of typos also, I will fix that. Okay, so yeah, needs to be used. Okay, anything on role definitions? So, ProLink it on October 21. Any other topics or just next meeting taking the time? Nope, not for me. So yeah, my proposal would be to have for the next meeting next week. Yeah, I know that the schedule was a bit chaotic already, but actually next week would return us to the normal schedule. Plus it will be LCS baseline selection, so I think it would be important. Sounds good to me. Okay, also an open question about the timing because I'm not sure whether you want to keep this time for governance meetings. I'm not sure how forward you for me this is a bit late, and many other contributors from Europe expressed concern that it's too late. And at the same time it's not too late so that the Asian and Pacific region can participate. I'm fine with moving it up if that would be helpful to you and Uli for sure. Me as well, earlier in the day is better for me. Whatever we do, I suggest to make it effective only in November after summer time or winter time changes are over. But yeah, it would be nice to do whatever and agree on times. And maybe we should wait for the election because different people come in and... Yeah, fair point. They have other ideas. It's totally fair because we have five officers and both members for rotation. So yeah, I agree with you then after elections. I'm good with that. That's it. So thanks everyone, especially for productive discussion about the trademarks. So we have a clear pass there. Let's keep working on the elections and other topics. Thanks everyone. Thank you. Bye.