 Welcome, everyone. This is the Jenkins governance meeting. It's 20th of March 2023. We have a claim to GitHub trust and safety is one of the items on the agenda, news, action items. JIRA license changes, CDF topics, community activity and as a final item, possibly adjusting our meeting time for the European change to daylight saving time. Any other topics that need to go on the agenda. Okay, then let's get started first. Maybe Daniel would you be willing to give some background on this claim from BNC BMC or Alexander whichever one of the two of you. So, late last week, I think on Friday, we, the admins of the Jenkins CI GitHub organization owners, I think is the term received the notification from get that trust and safety that BMC software ink claimed publication of private data. It was posted without consent copyrighted source code or password of BMC software ink. If it's a password if it refers to the string computer where so that's a bit awkward. So, I know that Tim reached out to the committers to understand what's going on at the same time. I filed a poll request, because I mean, I don't know where this is going but I would rather not get us kicked out of GitHub, because they file a bunch of claims. I don't know whether the comparison holds but I had her high effort horror stories of YouTube copyright claims. So, then we received a message from one of the maintainers of the plugin in question that they were going to fix it and they did so today by rewriting the repo history. In some manner, I think, so a bunch of commits changed, which obviously isn't ideal. And I pointed out to them. Well, while the immediate notification from BMC was addressed it would not address the general problem of an organization claiming its own published source code as private information and messing with our organization based on that. We haven't heard back from them since. And Alex printed out like half an hour ago or so that they recently re licensed several of their plugins under a non free free license they were previously MIT and our now some proprietary 100 page thing that I'm having and bothered reading, which is against our hosting guidelines. So now the question is how do we proceed here. My preferred, although, of course, quite disruptive approach would be suspend everything from BMC and figure out how to proceed from there. Whether they even want to remain hosted what's going on with the automated copyright claim to get up trust and safety and so on. Do we maybe even need to delete or move artifacts out of the way. That's another concern. In this case the copyrighted source code location was in tests. And we were to claim source code in production code. While it's not GitHub. I mean our artifactory host source charts. And then they say, well, you're, or might say well you're not supposed to publish that right. Maybe not a lawyer, but I would say it seems safer to just look everything and figure out where to go from there. Let me ask a quick question. And when did we receive the mail what that last week or some sort of Friday or Saturday, I think Friday. Okay, but it was Friday and they stayed three business days and include Friday that would mean we need to act until tomorrow which seems a bit short but definitely in favor of this approach because if this is one of those DMCA claims you can find on GitHub, get up is pretty eager to take down these repositories pretty fast. Right. And so, for full transparency. This plugin is published by a BMC, we get copyright claims by BMC. So, I mean, I would just delete it out of principle and let their customers yell at them and maybe then they change their position. Good timing to join. Great timing. Hi, Oleg. Hi, I commented on the ticket but I guess I agree with Daniel because the station is loud and clear. So the message then is it's a request. The simplest response for us is we suspend distribution of all BMC computer plugins until this is resolved. And unless it's resolved in an acceptable fashion, OSI compliant alliance, they stay suspended. Now Daniel you mentioned deleting more things so Right so what we can also do is we can block further plugin releases until the situation is resolved. So basically messing with the permission files. And the third thing we can be doing is we can delete all previously published releases of these plugins from artifactory. And when I say delete I mean create a private repository and move the artifacts over. They're being non destructive, except it appears gone. And if the situation is resolved, we can always move things back this is not very different from how we published staged artifacts during a security release, where we move them from a private or copy them from a private repository to a public one. That way then they appear. So that would be a more complete removal of all of their stuff. Obviously a lot more or some more effort that we may not even need because so far, as nobody has complained about artifactory as far as I know. So for me, it looks like quite a drastic measure. So, first of all, if you removed on the artifact series license can valuation. Then I am plus one for that. But removing all the versions that are I see I compliant. I think it would be too much. And for me actually, as Daniel said, we have never had complaints regarding artifactory so for me removing non compliant artifacts should be enough. But actually, the trick is that the complaint is filed against the data repository. So, unless we mitigate the data repository. I think we may stay red flagged. Okay, so so we may need to make the repository private. Just to keep from being being sure about what they should be private or what they should be transferred to another github organization for now. Sorry, like, like Jenkins transfer or something like that. Maybe as a holding area. BMC. Who knows. Yeah, for me, the concern that if we keep it in the main repository, though, the fuck itself won't go. Which is also for me for to restore publication. I would like a resolution of the GitHub trust and safety issue right because if they change the license file around and say yeah we'll we really resolve the situation by rewriting repo history. Although I haven't looked into detail what exactly they did there. That still might mean we have sort of a strike against us or however GitHub tracks these things. So personally, I would just transfer it to BMC. I'm not sure how, how would we do that we don't have permission to transfer to a BMC owned. Yeah, so there are two questions. Firstly, do they own the whole code coming to do that repository. So we can just say that means that okay we can transfer it to your github organization, then you do whatever you want, and then file new hosting request, once you addressed all concerns. So what you're saying so what you're saying is transfer the repository to the meat to an organization designated by the maintainers, and they say BMC they say whatever their own personal account. Got it okay to the to an organization defined by the maintainers. So basically it becomes theirs, and then they have to submit to rehost it if we have and we then decide if we want to host it. I think we want to once all the issues are solved. But yeah I'm not sure that it's going to happen, because yeah from what I saw in the comment history. Right now it's not given that they would revert to the license. And if even if so it may take ages because of legal involvement. But what would moving the repository accomplish compared to making it private so github suggests in their email that the sensitive information which is the string computer and the Java doc opening comment start with sensitive information that, well, we can just to make it private right and then go from there. Of course, because in both cases the problem is, it needs to be resolved in some manner, preferably by them telling github Oh, our bad we didn't mean to send this email. Yeah. And then I was thinking if we make the repository private as recommended by github, we resolve github's concern right the their concern is private information as as non sensitive as the word copyware is should not be disclosed so it's the repository private if then we want to transfer that private repository to the plug in maintainers we can do that to their organization we can do that as well. But if we make it private initially that seems like an immediate win. Right. Because, if I understood only correctly, the transfer would also only be temporary unless they resolve their stuff right so. Transfer will be permanent, as well as the publishing if they do not fix the licensing. The computer where flagging. Yeah, for me it's rather less important thing, because it's no brainer that they can reverse this claim because there is no sensitive content except the Java string. For me, the biggest concern is the fact that it's no longer OCI licensed. So maybe I mean to concerns but yeah for me it would be nice if you can just give it to them and then we host. I mean, the OSI thing. A major immediate concern for me as I mentioned the GitHub trust and safety thing because if I don't know how this sort of situation can escalate against us in a manner that affects the larger tank and say I organization. Right. They have like a 10 plugin repose they file a GitHub trust and safety issue against each of them and GitHub says yep we're not going to deal with these criminals anymore and then there has been Jenkins CI organization in the past. And so for me that's sort of the immediate concern now obviously be per our hosting guidelines we don't want to. We don't want to publish OSI stuff which was where the suspension comes in but to protect the Jenkins project, the trust and safety thing seems the more urgent one. So that we could make this one repository private and we've resolved it now computer where may then file a claim against another repository. And we'd have to make it private as well or we could just admit we're going to do all all of the BMC repositories we can detect as private right now. Right. The next problem is if we make the repository private. It detaches everything else from the network. So they lose the fork relationships, which will make development more annoying for the BMC folks because clicking on create pull request becomes more difficult but that's probably going to be their problem. documentation on the plug inside, I guess so. Yeah, because it wouldn't well I think it wouldn't be readable anymore right. Yeah, and it will already be listed as suspended suspend the plug in assuming that Daniels pull request is suspend is merged. I'm sorry go ahead Daniel you should answer all like question not me. No that seems correct yeah so the documentation would be gone, but at the same time we would suspend the plug in so that would those would be gone anyway. The question is in my pull request I suggest the suspension of all of the computer and BMC stuff. Basically I looked at the maintain your email addresses and everyone with a BMC email address got their stuff suspended. But that's more than we need because so far it seems both the license thing and obviously get up just in safety so far as only interested in one plugin. It seems limited to do the things previously owned by computer where whether we should make the scope of this pull request smaller or whether we should just remove everything. I think it's an attempt to perhaps get them to more quickly resolve the situation. So the public shoulder plugins that part seems clear. Remove personally I don't have strong preference. I mean, the amount of work for GitHub work that means is basically the same. You create a repository to private you created team to grant the access. And then you revert everything once I fixed. So for me, just one repository maybe. Or maybe we could act practically if there are strings. So if they are really concerned about computer where string. So we basically take private all the repositories weights mentioned. It's an attempt to protect us because if this was filed by some kind of corporate effort that was hunting down strings and filing these complaints. Then I'm sure that's not the only string in their database they would, they would likely have a large set of passwords that they're searching for. So I don't, I don't think that the single string copy where is the only thing that they would be looking for. Yeah, I think that makes sense. I certainly would not expect that to be the only password to be that would be a problem. So, oh like back to your, your suggestion it was, we could proactively search for, or search for suspect strings in the BMC or BMC and computer repositories and if we detect them then decide to make those private as well. I think so. I mean, the problem with that is, where do we go from there, right? What can the maintainers do to make us make the repositories public again. Right. Well, mostly they revert their own claim, then probably write us written information that they have no legal concerns about the content of these repositories so that we can save it for the future should they both go crazy again. Basically, you want a proactive confirmation that the other repositories they have not yet complained about are fine. Yeah. And that would be a prerequisite to resume hosting. I think so. And I thought I was harsh. Well, if they send complaints. I think it would be perfect. I have three proposals that we could discuss one for GitHub repositories one for future releases and one for past releases. I think those are the three, the three things that we've been talking about. So, here's, here's one proposal for each of those topics, we can, we can modify this proposal but I'm kind of just collecting what we've been discussing so far. Do we no longer consider the artifacts to be relevant, at least for now. Not. I don't know. I guess I get you mean for past releases. Right, because suspension is just a flag in the tool that generates JSON metadata. Right, so the artifacts would still be. I'm in favor of that. Can we let me see. Let me change that then to say, spend distribution of all copyware BNC plugins. Is that does that work Daniel. No, so those are two independent axis so suspend distribution means they don't show up any more in the JSON and on plugins Jenkins IO and different axes is that that implies the first indirectly is remove the public artifacts and Artifactory. So we no longer distribute the maven artifacts of these plugins. Yeah. I think there's, yeah, so for the for. And for each of those two items there's two ways we could go there's removing all or moving only non OSI licensed. So I guess for bullets three and four there's there's two alternatives. We can actually identify which releases happen with the non free license. And just to spend those releases. Now just suspend on the compliant things. Yeah, the same applies for the artifact repository right. The two alternatives. We don't have so many users of these plugins but the remover and everything is going to be a problem. So we don't want to trigger left party with our own infrastructure right. Which of these two things going to be easiest to get agreement on. We'll start with that one. Where do you see left pad happening. This, this, this isn't workflow API. I didn't, I didn't understand your question Daniel could you ask your question again. Right so one of the topics was removing all artifacts and all like mentioned left pad happening in our infrastructure but realistically, we're discussing computer where plugins and not, you know workflow API or mailer. So I don't really see left pad happening and the additional problem is the plugin repository with the claim was computer common configuration, which is the dependency of a lot of the computer where plugins. So there's already a necessary mini left pad happening because of that alone. I forgive my not knowing what left pad is, could you give me a high level summary, I, I, it was. A package on npm that half of other npm packages dependent on. Basically to let to various kinds of built issues, even, and also dependency issues for those pulling campaigns. I think the impact that one of the companies starting. Okay. Got it. Thank you thanks for the summary. So back to back to Basel's question which of these is the easiest one for the most likely for us to get agreement on let's, let's talk to that one first. Well I think, I think it from my point of view it's the first one because we only have three business days to deal with it. So it seems obvious to me that we need to address that as soon as possible. So I hope that we could agree on that. Also three business days is for the one repository they complained about. Fair enough. Yeah, so I guess I guess we've got another which would be even even smaller and they're make one comp you are BMC repository private. But it's the common that you said Daniel has multiple dependencies above it, multiple things that depend upon it. Dependencies are realistically at the level of maybe not effects or okay. plugins rather than get up repositories. Yeah, one could be done fairly easily with little side effects. Got it. Thank you. Thanks for the clarity. Okay. It feels like we do have these, these proposals for discussion agreement that the first is the is this likely the simplest one for us to get agreement on what show how we show process how shall we proceed. Any further discussion needed on this one I'm prone to say let's call for a here people's objections or vote. Technically there is alternative three check whether there are offending clients in plugins and take private all of them or that have the same computer where reference. But. The problem is that the complaint looks the complaint looks invalid. To me, and the other problem is that one of the maintainers said they fixed it so they rewrote repo history to do something. And I don't know whether what they did is sufficient because the complaint is so bad. So, at this point we can take it private but if the maintainers says it's cool we've done the thing. We basically have no way of confirming it. And if we tell a GitHub trust and safety a we did the thing but we took the repo also private they will tell us well we cannot look at it if it's private. So, seems like a catch 22 situation, if we make it private and then tell the maintainers to figure it out. Okay. Transferring to be MC. Because after that, they basically own it. And we don't care. But the it requires action from their side, which is not given. So transfer the plugin repository. To the maintainers. One or more of the maintainers. We can make it private now and then move. So that we that it's never public in our org. Right. Yeah. Alternatively, we can make it private and then do the thing below where we say, oh, well, it was mentioned earlier we need a confirmation from them that they have no objections to the repositories that they maintain. It could also be a next action so that we can basically say yeah it's cool that you rewrote history, but it's not good enough we need you to get us official confirmation that we're okay hosting this otherwise it's never going to be restored. Right, that might also be a position we can take. Okay, so are we ready to call for. I'm sorry I'm still not seeing exactly the path forward so Daniel do you have a recommended path forward it's make just the specific repose private make them all private. I don't think these alternate seven of detail for me to vote on them yet because they don't, they don't specify. They don't have a pending clause to talk about when we would undo the action. Maybe get to talk about the other three things back to this. The second proposal about blocking future releases pending restoration of OSI compatible license, are there any is there anything to discuss there, or is that proposal pretty clear. We only block releases for the plugins that have adopted a non free license or do we plug everything. There's no alternative it would be it would be just future releases of non OSI. I could add that word to it. Right, but then we also need to monitor there are plugins because if they change the license then it's kind of a mini welcome all situation. We assume that people aren't going to act in bad faith so I think if we do it for one it should be. I don't feel I need to monitor. We block one will give them warning in the pull request. So I think it should be enough. When you say one, do you mean that there are four plugins that currently have a non free license 405. So, basically that the repository permission update request that blocks all of them. So basically this is the warning for the rest of the plugins. Okay, anything that anything else to change in that second bullet point. Okay, so I think that was ready to that was ready to vote on or whatever. What about for the last two as the are the are the last two proposals either with including both alternatives. Are they are they clear enough or do we need to clarify it and do we need to clarify them further. One question. So what was the license before they changed it. MIT. Okay, so with MIT we are fine because we are not committed to providing the code and demand. So even if they wrote the history it's not our problem. But I think they're rolling a phrase. Go ahead Daniel, excuse me. What was your point with MIT. So basically the point is if the plugins were distributed under GPL. Like it happens for a few plugins within our system, that the fact that they wrote the history, means us to remove all the artifacts because we cannot be remain compliant with the GPL license. But for MIT license. I think that alternative to would be enough. No, because the source jar still have the sources. It doesn't matter whether the repo exists or not so yeah you're right. Alex that's related to one of your open poll request to update sender to. We have a few plugins that have no SCM. And but there are source charge so as far as I'm concerned that's no problem but you know just a side note. Anyway, we have only a handful of GPL plugins. Great. So back to back to Basel's question. Are the alternatives as phrased for suspend distribution and for remove copyware from remove from artifact repository are those sufficient. Are they well enough to scribe for us to decide which one we want to do to mute myself sorry I forgot to mute myself while I was typing. I think I've clarified the first one enough for me to be able to understand it. So there's actually six few consider the idea of transfer of transferring because it would be transferring. But in addition to making it private. I think that's what I was saying earlier. And I think my complaint was invalid because I forgot that I wrote up at the top that would be pending blah blah blah so above all those six alternatives there is a pending statement so I think I think these are all I think these proposals are all sufficient for me. They all seem complete in my mind. Okay, so in this case then the pending clause here is saying that the way for them to undo these changes would be they have to provide us confirmation that the claims have been rescinded and future claims won't be made. Yeah, I think that would apply to all six of the alternatives. Right. Okay. The point is that this is not pending an OSI license because the issue of marking the repositories private has nothing to do with OSI and purely to do with GitHub trust and safety, whereas for the bottom to the distribution and removing from Artifactory. The confirmation is dependent on both the trust and safety issue and the OSI compatible license at least for alternative one. Right. Yeah these proposals look complete to me. Are we ready to go ahead with which which which one does each of the each person recommend or prefer for a vote are we ready for a vote. Do you want to vote on each one or do you want to do we want to write down first which ones each person prefers doesn't matter or maybe doesn't matter. No, I think that's a good idea so if there are preferences. I'm, I'm certainly easily swayed for Daniels preferences in many cases so I would love to hear preferences from others. I have a strong preference for alternative to on the repositories private and as far as blocking future releases. I'm in favor of that. I guess this would be my vote if you want to consider it that for the second bullet point I'm in favor of that. And as far as suspending distribution, I'm in favor of alternative one. And as far as removing from Artifactory I'm in favor of alternative to so for what it's worth. Thanks, Daniel. Are you willing to share you have preferences. I do nothing is a valid alternative. Yes. Okay, or it is an alternative good. Let's note that thank you. Good. I agree with basil on suspending distribution. Suspending distribution so the okay got it. Thanks. Block future releases. Yep, definitely because otherwise they just create more trash that I need to delete. I would like to abstain on the artifact repository one because I would vote for alternative one because alternative to is way more annoying to implement. I'm the one who needs to click the buttons. I vote for clicking fewer buttons which is perhaps not the purest motivation. But that's a motivation. I like it. So you're saying alternative one is fewer button clicks for you. Yeah, I can basically move over all of the top level artifact directories rather than the versions that we don't like individually. Okay. And do you have a preference on the make repost present private alternative one until we get a second complaint and once there's a second complaint everything. So alternative 1.5. Okay, unless okay so 1.5 is is I get it is halfway between one and two in the sense of somebody else is typing a good. Yeah, I'm okay with that as well. Right that makes that that says hey if they don't fix it. It has more severe consequences. Okay. You can say I'm, you can put my name down as being okay with that as well. Yeah. Okay. All right. Fine with me. So, well, basically I take everything except alternative zero. Okay, so you're okay with any one of them. Yeah, so I lean towards. 1.5. And okay and good lock future releases do you have a preference there. I hear one, of course, and for everything else. I think to, I would prefer to take it safely. But yeah, so did I did I represent that correctly. Okay, Alex. And for the first one, I go with alternative 1.5. Okay. Yeah, for the second one. All that alternative one. Okay. Artifacts as, you know, suspend distribution, I go with alternative one. And for artifact re removal I have no strong preference. Okay. So you also do not wish to exclude one option like, like Oleg did with not alternative zero. Alternative zero. You can include me into alternative one if it's just less work but I have no strong preference there, given GitHub doesn't control that part. So you like both one and two. Yeah. Yes, I'm fine with both ones. So we need to add Alex to number two right. Oh yes, got it. Okay. All right and for me. Yeah, I think alternative 1.5 lock future releases yes, suspend distribution. Yeah, I'm alternative one I think there. And then I'm prone to alternative one here as well and I admit it. It's because I like it easier. So what we've got then based on that is we've got a split Bruno did you want to give voice to any of these items. Yeah, thank you Mark. So for the first part alternative five. I'm sorry I'm the only one. Okay. Next one alternative one. And then alternative two for this one. Okay. All right, next and for the last part alternative to do so. Thank you. All right. Okay so let's go from top to bottom I think we've got some that are clear winners. So here, that one wins, right. Sounds good to me. Okay. And Daniel I assume you're the person who would actually implement that, or is this what do we need to talk to somebody else. I don't know who the org admins are for that one. I think I can do that. Okay, great. All right, the next one. This one we have. Oh, I should put the action item here just a minute. Daniel back. I'm taking the note further down. Oh, good. You're taking action. So I don't have to put it there. Thank you. Thanks very much. Perfect. Okay, good. Next block future releases pending restoration of OSI compatible lion license that one's a clear winner. I think that's already expressed in your know it's not expressed in an artifact permissions update or yet but is this one that you would get the action of Daniel or is it something else. Any one of us could do you have a preference alone. Just read. Okay, great. All right. Suspend distribution of compiware BMC plugins we've got a four, four to two preference for alternative one. Oleg and Bruno, would you be okay with alternative one. Yeah, sure. Oh legs. Okay. Yes. Okay. It should at least get their attention right. No, I was paying attention attention actually. No, I mean, it should get the attention of copyware and BMC if we do alternative one. Yeah. I agree that it would get the attention. Yeah, I'm not sure what, well, it may happen that they move out and hosted the plugins on my own but let's see. Yeah. So, like just to be for sure confirmation you're okay with alternative one that I make this one bold and we set an action. Yeah, I'm okay. If I wasn't a decision just on my own, I would rather go for two. Because it's less destructive. But yeah, taking the votes. Okay, we go with one. So just for the record, these plugins have a combined total of around 200 installations that we are aware of. So it's not, again, this is not workflow API. This is not major email X anything like that. So it's rather important to have a common process and policy for cases like that in the future. So taking the votes. Yeah, it seems to be the choice of one. Okay, great. And then the last one has a much more a split for three in favor of alternative to I'm not volunteering to implement this. I would be okay with alternative one given that it's easier to implement so I don't want to make things more difficult for the implementers. Okay, I will I will attempt let's say I will attempt alternative to and if it becomes a non unreasonable mess. I'll check in with you again. I would like to check in with me I'm okay either way. Yeah, yeah, I would think if you find alternative to is an unreasonable mess. I think we should call for alternative one is an acceptable fallback. That makes sense to me. Okay, thank you I doubt I really doubt that becomes necessary. But it's nice to have that safety net thank you. All right, any other any other comments or discussion on the topic we've got the four actions Daniel thanks very much for capturing those got it. Okay. How do we reach out to maintainers and explain the situation to them and what we expect from them as follow up. So I sent email to the maintainers earlier this morning I sent email to Dave dresser one of the maintainers and I think I was going I had assumed somebody from the board and I'm happy to volunteer sends them an email saying, here are the decisions we've made based on this. Here you're you're, you're, you're pending these actions. This is what we've done. And, and you need to take actions, or this will be the ongoing state. Right so based on what we decided. We are now about to suspend distribution of around 10 plugins. So there's probably a few more people who inform should be contacted and informed about this and where you can also request further action be taken. So the way I would, the way I'll, I think I would do that is, I will look in repository permissions updater for the, the maintainers of those plugins. Look in accounts dot Jenkins that I offer their email addresses I'm an administrator there so I can read those and send email to those email addresses saying this is what we're doing. This is what we have done. But does that does that seem sensible so mark to send here I'm going to put it here mark, just to notify maintainers of the approximately 10 plugins, what actions we've taken, and we'll take. And how they can have us restore distribution. As a, as a quick side note, when I've previously reached out to maintainers about security vulnerabilities I've always also, I've often also checked the account up. I don't know whether a desync of conduct information is still a problem based on the current jira configuration but it was in the past. So that the jira email address was invalid and they would not get information emails from there, but they had a correct contact address in the account. I was intended to only use the account app because that's the one that they have to use for password reset I wasn't even going to look at jira. Is that okay that's that was my thought because that's where I frequently go if I need to convert a Jenkins account name to an email address. Seems seems fine now. Okay, based on email. And if they have a bogus email address. Well, address in accounts dot Jenkins that I own. Okay, good. All right. Daniel, could you gently provide the list of the specific plugins. That way I'm not guessing which ones are owned and you and I risk having. Oh, perfect. It's already in the poll request. Okay. I just propose to spending everything and have them figure it out. Okay, excellent. All right, so that's, that's perfect. If you've listed them. I can just use your list and I'm set. Great. Which also goes beyond for the record also goes beyond computer. There are also a few the BMC plugins specifically that look maintained by BMC folks. And I mean that was just, you know, not immediately related but same org. So, right. And that that makes sense to me. Okay, thank you. All right, so I think we've got those five action items any objections or concerns about those action items. Okay, thank you. Thanks for the work Daniel is driving to preserve our access to the GitHub organization. That would be disastrous. We got locked out of GitHub. Anything else on the on this plugin suspension topic. Okay, we're up against only four more minutes till our hour. I propose to skip news and action items. Unless there are items that you want to specifically highlight in them. Okay, next then your license changes are complete. Nothing else to say there except thanks to Atlassian and thanks to the Linux foundation. For the topics, I'm going to I've scheduled to do a presentation to the CDF technical oversight committee April 12 on the status of the Jenkins project. I'll create the presentation share with all of you so that you can see it, give comments, etc. And I specifically asked in the last meeting for confirmation they're okay with it being a wider project review not just a technical topics review and they specifically wanted it, a wider help to the project review. Next item then was LFX tools working group, Oleg and I both attended an exercise session there today. Next meeting in a month. LFX insights is the next generation of what we use today as dev stats. And sorry about that. There we go. Next topic then was on community activity just to be have people aware. Artifactory bandwidth reduction project keeps going I finally gave up and publicly disclose the abusing IP address. And still not made significant progress on it but artifact is going to attempt to block at the IP level. Google summer of code we've got 22 draft proposals now up for review. Thanks everybody. April four is when proposal submit. And the last topic for this group was the one that I most wanted to be sure. Usually in the past we changed the meeting time for daylight saving so that we would keep a consistent time of day for our European contributors. Is that is that a preference Oleg for you, Alex for you Daniel for you Bruno for you or would are you okay with a staying at UTC and really isn't here so I can't ask him he was the one who had the biggest challenge with it I think. For me, it's okay. So plus or minus one hour for Mondays is okay. Okay, Alex. Oleg here, plus or minus one hour doesn't affect me too much. Okay. Daniel, any change for you in terms of if we stick to a time of day or stay with DST. I'm not around enough to get an opinion on this. Okay, great. So I'll double check with Uli Hoffner consider the question opened and not resolved at this point. Daylight saving is invoked in Europe a week or two from now is that right next Sunday, next Sunday. Okay. Alright and Bruno, do you have a preference that you wanted to know as Daniel I don't come often enough to have a voice on this. Okay, great. Any other topics before we conclude for today. Alright, thanks everyone.