Merge Request based Collaboration for Debian packages

Uh welcome to the next session of DEPCON 25. Uh now we have Otto who is a Debian developer for a long time and the main maintainer of salsa CI pipelines. Uh it's very important uh infrastructure for Debian. I think most of packages are being um hosted on Zarsa and many of them are using salsa. I'm using also almost for all of my packages instead of those who are building years. And now we have a both merch request basic collaboration for Debian packages. So please welcome Otto here. [applause] All right. Hello everyone. Is the mic working? Hello everyone. Yes. So um I'm not the only maintainer or developer of South Sici but yes I'm one of the um main people there and uh I this talk or uh buff session is about merge requests. So obviously I'm in favor of merge requests. I'm I like code reviews. I don't think people should work on their Debian packages fully alone and and uh on their own all the time. and I like code reviews and in the context of Debian at the moment the way I think they should be done or most efficiently done is through merge request. So that's the topic for today. But I would like to hear like what opinions people have about merge requests. Do you want to use them? Do you want to do something else or how do you want to do them and so forth? And there is also a pad. The address is very long but you can find the link in the schedule. So basically what is a merge request? Let's start what by defining what we're talking about. So 90% of Debian source packages are hosted on salsa.debian.org or at the moment and uh anyone can sign up for an account there and uh for most Debian source packages unless it has been explicitly disabled you can fork it and you can submit a merge request using the GitLab's UI and uh and you you don't have to be a Debian developer anyone can do it and when it's done it's they are also public and you don't have to be the maintainer, but anyone can actually comment on those merge requests and we are already using them to like hugely across Debian. Uh how many here have done a merge request on salsa? How many of you have reviewed one? How many of you have merged one? Yes. So most people are are doing this and indeed just in the Debian group we have over 10,000 merge requests already happened and 800 of them are by the way open if you want to go and review somebody else's and uh also one thing I want to highlight is that by default the settings we have on salsa at the moment are such that if you have a project on salsa you won't get email notifications when somebody files a new merge request. So I just wanted to point out that if you are maintaining something go and check go to the project click on that bell icon dropown thing and make sure you don't have your global settings but you have the watch settings on like in this screenshot so that you will receive an email every time somebody submits a new merge request. What >> project or team? >> This this setting is your own setting. So open all the projects, all the packages you maintain and then do this for yourself. You can also go to your profile and then there's a subpage about notifications which will then list uh all the settings you have at the moment. There there's also uh settings to fiddle with the project ones, but this is the most important because most of the time the packages that you actually upload and maintain, you want to be the person getting a notification when there's a retro request. Uh how many knew this and have this configured? So not everyone but many. Good. All right. So what's the basic mechanism of how a merge request works? So uh the submitter opens it and it's basically they have a branch and they're proposing that branch to be merged to the target branch and anyone can give feedback or comment it and the submitter can at any time update that branch. They can add commits or they can just uh rebase and force push new versions of the stuff. And I I prefer to force push the new version because the merge request is supposed to represent the thing that the recipient can go and merge as is. Uh if salsa CI is active, it will also provide kind of automatic review telling that did the build pass and did auto package test pass and things like that. Uh then in GitLab there's this feature that you can click on approve on merge requests as a token that you approved it and depending how your project is configured it might show up in the merge uh merge git message that who approved it and then there's a you need to have higher permissions to be able to merge it and you can either merge it in the UI by clicking merge or you can just the oldfashioned way you can pull it on your own laptop and push and GitHub will then GitLab will or both of them actually will detect that that exact commit went on the target branch and then mark the merge request as closed. So that's that's the basic mechanism of how it works. And then of course how do you do a code review in general? That's a bigger topic and I have some of my opinions in my own blog if you want want to check that out. Okay. So in the context of of Debian today, what does the project say about merge requests? Well, basically nothing. So if you search the Debian policy with the word salsa, it doesn't it it hasn't isn't actually mentioned anywhere at all, which I think is a little bit surprising. So I did try to submit one change there but it wasn't accepted. So but uh maybe in some future version of the policy we might mention something that we have this salsa thing and it's good to use it. Uh the developers reference does mention salsa in a couple of places but the process is describing on how you contribute a package basically the salvaging process which Andreas was talking about earlier today. Uh that process description today is based on the assumption that when you want to contribute somewhere you basically just do a new version of the package and upload that. And uh in my view that's uh not very collaborative. I think that posting a merge request and then uh having that merge request open for maybe 3 months or something and then seeing if the maintainer will ever respond or or object or something. If they respond and object, then you know that you shouldn't probably go uploading anything and just deal with the or like collaborate in the merge request until it gets merged or rejected. But if it nobody responds anything, then you can probably uh and if there's no other activity on the package either, then that probably could be a sign that it would be okay for you to go and merge it yourself and fix the thing. uh I don't have any proposals for the policy manual or the developers reference at the moment regarding this but I did start last year to draft a DEP 18 to to kind of make it uh explicit that we in Debian do have salsa and we recommend using it for people who want to have a efficient calibration. So it looks like like this. How many have seen it? A couple. So basically I'm I'm proposing that uh Debian packages should by default be hosted on salsa and they should be in git and and uh the merge request feature should be enabled and people should be using it if they want to have collaboration with the assumption that participating in the merge request uh review is is easier than the other alternatives. And then also as a salsa CI uh maintainer and and promoter, I also hope people would run SAC CI at least once before uploading. And obviously if if people are using merge requests, then the SAC CI will give automatic review results on on the basic stuff that things work. Yeah. All right. So this was my introduction to the topic and now I'd like to hear people people's views that uh what should the Debian project say or recommend about merge requests and the one more thing is like why do I think it's important that the Debian project would say something is because I don't want to like u it's not about enforcing that everyone has to do this but to establish I want that there should is some clear guidelines on what is kind of the default process for doing doing things. So that then when for example new people join the project and start contributing it's clear for them what they should be doing and if they do the thing that is clear then the maintainers would uh they would have a less friction with the maintainers because they're doing something that is familiar and makes sense to everyone. Okay. Uh, yeah, please. >> So, at the moment, if you're a new contributor to Debian, you have two choices. You can file a merge request in Salsa or you can send a patch to BTS. Yeah. I'm not very keen on this. I don't know uh like how we can get out of that, but I think it's harmful for the new contributor experience for there to be multiple ways to do things and for maintainers to have different preferences about how they accept contributions. So, I wonder where the room stands on um ideally doing something. I'm not saying get rid of the BTS, but doing something to make that situation better. Any responses? So, I just noticed >> I just noticed that uh for every package that I have in Salsa that I'm a maintainer for, uh the notifications aren't set to send me any notification when a merge request goes in. So, I have to manually go into every package that I that I'm a maintainer for in Salsa and configure it so that it will send me notifications. Whereas with BTS, BTS uses the maintainer field of the package to send information about change requests for that package. So should Salsa be sending notifications to the maintainers instead of having you manually configure all the notification settings? I I think yes, but I think it's also a chicken and egg and that's why I'm like doing this session because if we don't first somehow somewhere establish that people actually like merge requests and are happy using them, then the salsa maintainers don't want to put this as a default setting. >> If I if I'm maintaining a package in salsa, I've already said I want people to be interacting with me through salsa. If I don't want to get notifications from salsa, I should probably not upload something to salsa. >> I I agree. But there is actually people who have packages in salsa who say that they don't want to have any notifications from >> they could go and configure it to turn it off. But by default, a maintainer package >> could be. Yes. >> Yeah. >> Let's let's do that. But >> I just I just realized I had never received a merge request from Salsa. Not because there weren't any merge requests in Salsa, but because I had never manually I had assumed that uploading something into Salsa would make it so that it would talk to me because every other GitHub certainly does. GitHub spams me with email all the time. >> So if if here's enough people that we have consensus on this thing and then we could announce it that let's configure things this way. >> Yeah. >> Then I think the salsa admins would believe that yes, this probably is what the majority wants. But it's not a matter of configuration. >> I don't think it's as simple as a matter of configuration because salsa simply doesn't know who to send it to. >> There's a maintainer field in the package. >> Yeah, I know. But Salsa is not connect is a GitLab instance, right? So it doesn't Salsa could have code that went and looked in the Debian directory. >> The usernames, >> we agree, but I'm saying that's why it's not a configuration. It's going to take some work. >> It it is possible because the usernames are the Debian names as well. And we already have uh some email notification scripts. I think >> you know I'm talking about actually using a maintainer field in the package to figure out who to send the mail to >> if you have the owner of the project. So you can set the order >> but I think the technical details on how to implement this is doable but first there needs to be like the decision somehow made by this group that this is actually what we want and that the emails from salsa are more useful than they're annoying. >> So I think then the onus is on anyone who objects really like we need to hear from the other side. So, who in this room would prefer not to have that? Me not. I wanted to refer to to Keith. Um, I I I I had to I had the safe the same problem with uh forgetting or or not seeing merge request for months until I chance. But you can send the email to owner to the owner of the project because there was someone who created the project and has some interest in it. Um and you can this one has a email the profile so you can send it to them and for for other people they can subscribe. >> Yeah. Okay. >> Okay. Thank you. >> Who was the first? >> Okay. [laughter] No, I would say that most people that are here probably uh agree with our what we are proposing. I don't think we have many people that disagree here. So I don't think we'll find uh anything like thinking differently here but I totally agree just like uh we we do something like that with newcomers in Brazil. It works pretty well. So I think this should be the default is yes. Yes it is. Someone mentioned on IRC that maybe we should uh create a bot to redirect all merge requests to BTS. I don't know if that would be useful and if the the broader community would agree with that. I yeah I I don't think so. But >> yeah, he wants to say something. Yeah. >> And possible we've moved on a little bit for for just a uh on the uh SA merge quest versus patches in the BTS for newcomers idea. There seems to be an assumption that the people who are pushing for change from officially our BTS is the way to do it. um are responsible for making it a perfect 100% solution. Um whereas it'd be nice if we could get to a point where we like enable merge requests to be usable. Um, and if some people aren't getting the right notifications or whatever reason for that as as the maintainer, um, maybe they should write something that integrates between salsa and the BTS and puts the onus on the other way around to say, um, yeah, that was my thought. [snorts and sighs] I think what Otto suggested is the best that we are going to have today. If we want something else that salsa cannot do at the moment, it's it's kind of open source. So people can start doing merge requests against Git against GitLab to implement that. But I would like you to consider that we have a truckload of packages where there is no onetoone relationship between the project owner or or or a project member and salsa and the maintainer or the uploader. We have many teammate packages where the maintainer is a mailing list or the package tracker so that salsa does not does not find the their their relationship to to the salsa user. And I would most certainly not like having a mail message for everything that happens against any package in the Debian project in salsa. >> Yeah. Okay. >> So that's why I'm like as a short-term solution, I'm advocating that people go to your own packages and enable this notifications because like we can't maybe do it on a group level because then everyone in the Debian group would get massive amounts of emails and so forth. And and also we had on the mailing list on Debian Devil, we had some discussions recently about the notification emails and if we dig them up there's links by the salsa admins to the scripts they are using and there is actually some bunch of automation checking the checking like who is who and and stuff. So I think uh further automation in this field is definitely possible but I think it's a chicken and egg that we first need to say that we actually want this and we want to embrace this and not have this as a secondass citizen. >> Um I would like to ask somebody maybe on IRC uh just to document the stuff which we are um document the stuff on other part what we are discussing now just not to lose it. >> Yeah. So >> yeah, a small comment about the notifications is that you can activate them at the group level. So maybe not for the Debian group, but if you're part of a team that has so many packages, it can be useful to activate it at at your team groups level. And another comment I wanted to have is um earlier someone said like if you put your package on GitLab then you're okay with I don't know merge request, notifications, anything. If you put it the other way, it means if you're not okay, you shouldn't put your package on GitLab, which is I think a very wrong message to send. So, we should be careful on the way we phrase things. I think it's beneficial to the project as a whole to have everything in salsa or any git instance whether or not you agree with a particular process. >> Okay, thanks. Uh G, um are there any? Yeah, I think yeah. So, going back to the someone said something about uh it being two different ways to contribute patches either directly on the BTS or through a merge request. I don't have a problem with that except if merge request get ignored. So, that's where we that's why we talked about notifications. But I'd like to point out that there are other ways to notify maintainers. You could get uh the number of merge requests on uh tracker debian or and on the other dashboards used by maintainers. And another area where we are probably uh a bit lacking is that by default merge request are enabled and maintainers are probably not aware that merge request are enabled for their package and that people might submit merge requests that they're not looking at. So UD already has data about uh linking Debian packages to salsa projects and has information about through VCS watch about the number of open merge requests. So it would be probably uh alpha day job to to add information about merge request on uh on tracker and various other dashboards. So I can help with that. But I think on DDPO page there is already some kind of sign that merch request is open or maybe I'm missing something. No. >> Okay. Good. >> Not on track. Okay. I see. Okay. uh doesn't >> also I wanted to remind if people prefer to not use the browser there is like the salsa command line tool and then there's the gab generic gitlab command line tool and you can use this to list uh open merge requests and things like that. So some people don't want to have any emails at all and they are concerned about how they can like access it other ways. So just a reminder about that command line tools exist as well. >> Okay. >> I I have I have one question uh about the merge request uh being fast forward or just having the merge commit on top. Do you do you find anything on that document about about that if we're going to follow a pattern? Because personally I prefer linear history but then in bigger projects it might get difficult and then like if some projects might ask their committers to sign their commits and then you can't rebase them anymore because otherwise the hash won't match anymore. So I I wouldn't at this point recommend anything too strict about that. I I would like just start with let's recommend or like state somewhere that if the maintainer doesn't have like some really good reason the package should be on salsa in git and it should accept merge requests and the maintainer should uh should not be hostile towards merge requests and and since it's easy then also please have si enabled and look at the results. >> Okay. Uh I have I have a small question. Uh is DEP 18 uh in what state is it ready to be reviewed and maybe accepted or you want to add some? >> So it is a draft but uh we I I started it last year and we had a whole bunch of discussions. Some people probably remember this from the meeting lists, but it has been like without changes for maybe four months or five months. So, it's now as a draft and I actually have a merge request on on making it a candidate. So if you want to check this DEP 18 out, you can either file new merge request to change the text or if you think it's fine, then you can go and vote on this one and and express your opinion that way. >> Okay, thank you. >> I just saw of an edge case just trying to think of um not me but who would object and why. Uh there was a package that I um was involved in where I was surprised to see that the VCS field pointed to GitHub. Um but the I think the reason for that was the upstream maintainer in GitHub was also doing the Debian packaging and so they preferred the branch there. And so I don't know if we've got a um an opinion about the trade-off between I really like the idea that everything is in salsa. you tell contributors they can reliably expect you you you train them to look at salsa and I really dislike the idea that um you know Otto onboards a new Debian contributor at devconf and shows them salsa and 3 weeks later the contributor is lost because they're trying to do a contribution to a package and it's not on salsa. So that's my view but I can see the reason that somebody wanted it on GitLab uh sorry GitHub. So where do we stand like so >> do we need to take a position? >> So actually most of the packages that are not on salsa are not using any version control at all. So this is a tiny amount of packages that are on version control or are in git but are hosted somewhere else. Some of the people think GitLab is too proprietary. They don't like the open core model. So they prefer to host it on codeberg or forger or somewhere else. And then some people think that there's not enough of a community there and the main developer community is on GitHub. So they prefer to host it on GitHub to like entice more contributions. But I think both of these are like very marginal at this point. And at least one of the guys with his packages on GitHub uh promised that he's going to mirror everything on salsa as soon as I publish a blog post explaining how to have multiple remotes on your Git repository. Okay. Does anybody want to comment something? Okay. Uh so I I'm one of the soft admins and several of the ideas you guys uh uh suggested here requires automation and that requires code. So if you want to write the code, we are open to it. And if you write the code before the conf ends, we we can deploy it before the conf ends. But like uh linking me Quest to B to the BTS is doable via the uh via either web hooks or the GitLab API. Uh there is a I I experimented with experimented with uh adding a custom issue tracker to GitLab. So we could in theory write a custom issue tracker that will list the bugs in the BTS in the GitLab in in instead of the GitLab issues that's possible as well but requires code. So, so yes, if we we are open to to making things work, changing these defaults. For instance, if you want to notify the owner of the the repository by default, that's easy to do. for new repositories, for the existing ones, we'll have to write the code to go over the API and and change to to whatever we want to change and always allow people to opt out because I mean requiring stuff to be on South at this point is kind of redundant because most of the packages are in salsa. If you look at trends.net that Lucas did on the VCS hosting graph, sure is just dominating everything. everything else is shrinking and yeah >> so actually to that point I'm mentoring a bunch of new people and I actually see many times that they have the package on GitHub and then I tell them that hey you should actually have it on salsa and then they ask why and because I like that but I can't tell that Debian likes that because there's no like backbone for that so are there any uh any people in the policy writers with any views on should salsa be mentioned there in some form >> did you have some comments >> I did but it's not about this maybe I don't know if you can change the subject >> and what what was your name I just put that you were in the room >> they say Antonio So, uh, at the risk of opening yet another controversial can of worms, I I don't think I'm going to get an agreement from many of you here, but I just wanted to grind my axe. Uh, in particular today, my we should be using a patches applied git branch format axe. Now, I know that this is not popular within Debian. Most people are using basically the GBPQ format or you know the same format with manual quilt but I've seen multiple people outside Debian try to deal with code that they got from salsa and end up with very strange things because if you start with the patches unapplied branch you can't if you build the package the Debian patches don't get applied maybe it builds maybe it doesn't dish build package might apply the patches in which case you've got a dirty git tree. Now, um you can't just update the code in the tree where the code is with your editor. You have to do some kind of weird magic thing to turn it into a patch in Debian/patches. Now the tooling we have for maintaining patch cues in git as patches applied is not as mature and there aren't as many like great options and it's not as easy but there is some good tooling for this. If you normally have no patches, then just using git merge is actually really great. Um, then you're not paying much of a price for having like not maintaining your patch queue as a set of diffs because if that set of diffs is normally empty or one tiny hunk, then you kind of know what that thing is. Anyway, I have a tool called Git Debbase which is used by the Zen team to maintain a large patch queue in a large package. It may not be suitable for everybody. I think what I would like to ask here is that we don't nail down that we're doing everything patches unapplied because patches unapplied is deeply weird by external to Debian standards and you know I I had a friend who who built a version of a Debian package and they got the source code from Salsa and they were trying to like debug something and they didn't know to use dpage build package so they used make they ran configure make and what they got was an executable that didn't have Debian security patches applied but ran. And that is kind of the worst case failure of a patches unapplied branch format and it's very easy and it can just happen. Anyway, I think I've made my point. >> Thank you. >> Here here um a couple additional points. Uh first of all, I don't think it's good for um merge requests to be a black hole. you either they should be disabled or they should get yield notifications but they should not be just enabled and go nowhere and also I've I've double checked and um sal itself um supports um mirroring um other repositories so the um maintainers don't need to do any um thing manually they just check the box and then it'll do the right thing >> okay thank you >> actually I think the black hole is also fine because uh yes if you as a maintainer don't respond anything you there's still other people who might respond. So what I see happening in several packages is that the original maintainer is passive or maybe like does something twice a year. But then the bigger the problem is the more people are affected and then those people can discover each other and collaborate and do do something and if you turn off merge requests then makes it harder for them to discover each other and the issue. >> Fair point. Um I have also a comment regarding uh what you said about uh un applied patch. So I think it's good to have patch uh in patches not applied because if you are importing a new version of uh software so you need to be sure that the patches which are in most of cases DBN specific are still can be applied because if you are just importing new version you're just overwriting or what is so just my comment I do not have a hard opinion on that Then uh okay so uh yes Ian I I got your point and uh I I was uh seriously seduced to change my ways. My I think the main problem with uh having a repository with patches applied is that it's a departure from the native Debian packaging uh format and all the tooling is optimized for the for for handling the patches separately and all the error messages and lint reports and everything else is based on the conventional model. So it it would be a a mental conceptual change for for me to retrain myself to use a patches applied uh branch and uh I'm afraid that I I would have to go back anyway because I will eventually have to fix some bug and find out some problem and and all the tooling just uh uses the conventional I mean the quer package format. So I I would have to understand that anyway and in the end at the end of the day I would have to use that package format anyway but I'd like I I'd be happy to get rid of this but I think we would need some deeper >> maintainers that's a bit difficult. >> I I'm sure it does. It's a it's my point of view that uh I finally learned something. I I understand how things fits to fit together. And uh I would have to do it some other way which may be more straightforward for people not involved in Debian packaging but it is not for me. Can I propose that we skip the topic of patches applied because it's uh we're not really discussing like we're I'm proposing that we should use salsa and git but I'm not proposing here explicitly that we should use a specific git format there. >> That's good. I'm glad to say that on the stage but that's not what your document says. Uh yeah, >> the document explicitly mentions GDP. >> Yes. So >> and all I want is for you to >> All right. Uh I I >> uh thank you. So, I'm glad to hear uh that you say that on the stage, but the document that I read earlier today um explicitly mentions GBPQ get bill package and uh assumes and recommends that you're using patches unapplied branch format. If you want to soften that, that would be great. >> Okay. Um, so in this step 18 indeed I do recommend git build package and I recommend it because it's currently the most widely used and if I today like mentor somebody to start Debian packaging I would recommend them to use this and uh you uh you are developing new tooling and and uh >> I developed five years ago. Yeah. Or Yeah. But um in in Debian context it's it's still new. I think this is pretty softly stated already. >> We have one more question here. >> Yeah. Sorry again on the same topic but I have to mention that in some teams we prefer to use Debian only repositories without the upstream source code in Selsa and I think it makes a lot of these topics a lot easier. Basically we work with the upstream repo on the one side not in not in salsa and pure Debian packaging in with just the Debian folder on salsa and I found it much easier to work with than having to dance with all the branches. >> Okay, thank you. Um I want to mention >> I I I think that the the the main problem is that you you're in some kind with this patch in Debian you are distorting the the the way that is standard in GitLab. So that's why it's sometimes uh for newcomer they don't understand why we use patch like this and we don't make branch. >> Yeah. If you do a merge request that updates a patch, you will see a patch of a patch. Yes, that's not very clear. >> And it it has some effect in fact also in the interface when you upload then you you have got some message that uh you can accept the merge request just because you you were pushing two branches. >> I've seen this. >> Yes. So for this is actually on topic on merge requests. So I would use >> when I do a merge request it's or when you anyone does a merge request it's just proposing to merge one branch to another. And when using git build package which most people are using at the moment if you do a new upstream version import you can't really do a merge request which would push all of those branches at once. But I don't think that's a problem because those two other branches, the pristine tar branch and the upstream branch, they are not supposed to contain any changes that you did. So in the review code review process, you can't really get the feedback that you should [clears throat] go and change that because you're not going to change it. It's mechanically inherited from upstream. So for new versions, I I recommend that you only just do one single merge request for the actual branch that has the Debian stuff and that gets reviewed and then when that's done then then uh it merged and the the other branches get merged as well. >> Yes, but but but sorry but you need permissions to do that. If you have a contributing as a new new contributor to a to a repository um and you want to update something and you don't have permission on that web for what whatever reason because you are new and not known and whatever you still need a way to get exactly that upstream and pristine branch into that. You push it to your own fork and then the person merging it will pull from your fork. >> Okay. Okay. Yeah. Yeah. >> Okay. Um any more questions? We have 3 minutes. If not uh I have one more point. I do not know whether it's related to it. Uh what I find annoying. So my most of my packages are on all of my packages on salsa and since the beginning of packaging history and I'm just taking from git making some updates upload the package into Debian and it's been rejected because somebody enued my package which is totally okay but I do not know how to uh motivate the people to uh bring the change back to salsa and not to forget it because uploading to NMU is easy but uh it it takes some time then if you do not have those changes being documented in g so I do not know how can we change this processes maybe just a point which we need to think about but it's really annoying because you need to take uh change from arch heave you need to rebase my it's it's really not a good stuff so my my workflow is to run the git uh build package uh DCS something which will then automatically fetch from unstable whatever is newest if there is something just to check that it's doing this but ideally the tool should be doing that automatically by itself when I do like pull or something else so it's not very ideal and also I'm not a big fan of people doing NMUs so that the way I learn about the NMU that it's already in the archive like I I would much rather have a merge request and Then like if I'm on vacation for 3 months then like still I think it's better that somebody posts a merge request and then I at least have a chance to like discuss the thing before they proceed and then they go and do the NMU or something like that. >> Okay. >> But then of course like the fundamental problem is that the archive is not in Git. So it's possible to bypass git completely but that's so so so also like in these discussions of what should we like recommend in Debian there's like always the discussion that what's the next generation tooling and what could we do in the future and should we have a new package format should we have a monor repo and everything there and so forth maybe in the future but at the same time we need to have like new contributors today and this week joining us and we need to tell them something and we should be able to agree right now that what is the tooling that most people use and then somehow like have consensus that if new contributors are using that tooling then the the maintainers shouldn't like be negative towards him. I mean yes I I think what I'm finding a bit frustrating about this is apparently there are several people who are in this room who don't know about like DG for example which has existed for 12 years that is not new tooling. It's extremely solid and helps solve many of these problems. um merging patches applied workflows don't have an NMU integration problem. Many of these things become a much better if you use the tooling that is not like some kind of blue skies thing that we're doing in the future. It's 12 years old, >> but it still has like [snorts] things that probably needs to be developed into it. No, it's like it's hardly changing. >> Guys, I don't have to interrupt you. We are out of time. Thanks a lot for your productive uh discussion and a lot of comments and questions. And Otto, thanks for bringing this topic. And I would like to ask you to thank Otto also. [applause]