 Okay. So, hello. I'm BDL. The purpose of the session that we're having right now is for there to be an opportunity for Debian developers who are present here at Debconf to get a chance to meet the members of the technical committee who are present and for us to have some conversation about any topics related to interactions with the technical committee that you think might be more productive to do in person at Debconf than through all of the other modes of communication that are at various times available to us. This is something we've been doing now at Debconf every year for a lot of years. I know it goes back at least as far as Edinburgh, because I remember that session distinctly for several reasons. I think we started that. That might be the first time we did it. So that certainly means, you know, eight-ish years. And some years have been much more interesting than others. I think it has something to do with what the current topics of interest are in front of the committee. I was intrigued as I was in the last few minutes before we got started, because I hadn't noticed that this was happening today until someone asked me 20 or so minutes ago if I was planning to come. And so I perhaps feel slightly less prepared than sometimes. But that's okay. I am currently the longest standing member of the technical committee, which means thanks to the general resolution that we all collectively passed last year. December 31st this year will be my last day as a participant on the technical committee. And Steve, I believe you are the second most length of service person at this point. I think that's correct. I don't remember the tie breaking rule. Well, from the terms of the general resolution, he is actually, we are both the same time of mount as a committee. But for the resolution, he is a bit longer than I by whatever, non-time. So the good news is you get the benefit that those of us who are actually present at DEBCONF this year represent long lengths of service in the technical committee and can therefore speak reasonably authoritatively about things that have happened for quite a while. The bad news is that your credit cards will only go so far with us, because after the end of this year, Steve and I will no longer be members of the technical committee. By the way, that was a joke. That's right. The credit cards still work. You just don't get much for it. Right. Or something like that. So this is the list of people who are currently members of the technical committee. Those whose names are italicized, I believe are not present this year. And did he is, will be present but is not in the room yet. Okay, fine. Keith Packard sends his regrets. Unfortunately, his employer suggested that he give a keynote at LinuxCon in North America this week instead of being here. Sorry, Keith. And yeah, Don Armstrong is now the tech committee chairman and unfortunately also could not be here. In fact, somebody pointed out to me, I think it was about nine years ish that I served as chair of the technical committee and I decided early this year that in light of the fact that the end of December would be the end of my tenure on the tech committee because of the term limiting resolution that in order to make sure we had a nice smooth transition letting someone else have a chance to take over as chairman before I was off the committee entirely. I was a good thing to do. And Don has suggested that that's probably a good pattern for the future at the beginning of the year that would be the last year of someone's term. It might be a good time for there to be a transition of the committee chairmanship and we'll just see how this all works going forward. Not a big deal. So what is the technical committee about the technical committee is one of the entities within the Debian project whose existence is defined within our Constitution specifically section six. The members of the committee are appointed by the Debian project leader and the existing committee members. The way this has worked in practice for the last few years is that the committee has come up with a list of proposed new members whenever there was a vacancy or a need to add people and has proposed that list of candidates to the project leader who in effect has well so far the project leaders always agreed with the technical committee and that's how we've gotten new members. There has been for those of you who've been paying attention there has been more change in the membership of the committee in the last year than at any time in at least a decade and not surprisingly this is because of the consequences of the stress level that was imposed on the committee by you know the events of the preceding year system D. I'm you know at some point I think all of us who participate in the technical committee understand that these are things that we agree to do not so much because they're exciting or fun but because somebody has to be willing to be the place where decisions happen and somebody has to be willing to take on the things that other people in the project can't somehow successfully resolve on their own and that is in effect what the Constitution defines. I'm not going to go through all of this we've talked about it a bunch before if anyone has questions about sort of the constitutional bounding of the roles of the committee feel free to ask and we can go into that when we start the discussion part. The committee has since the DEB Conf that was held in Banyuluka attempted to have roughly monthly regular meetings on IRC to discuss open issues and frankly to sort of go to each other into action. It's just a reality that without deadlines nothing ever gets done and so the notion that people have to-do list items they can report on in a monthly IRC meeting has in some ways helped us to make progress on items which would otherwise perhaps not get as much attention. The difficulty of course is that when I went to pull up the list of open issues before the committee at this time it was really simple I copied last year's list and added one more at the bottom and so on some level while there have been things that have been discussed and some items that have been closed in the last year I can't say that I feel terribly great about what's been accomplished. The bug is still open in the BTS. Decisions been made the process hasn't been run to completion the point that I'm trying to make is that there are some things that have been open issues for some time in all honesty the first item here you know the proposed constitutional fix for the tech committee supermajority we collectively agreed that the right thing to do was to not act on that in the heat of passion after the internet system discussion that what we should do instead since the combination of the intensity of that discussion leading to some changes in tech committee membership and the fact that the term limit resolution was at that time already being discussed and was headed for general resolution we decided the right answer was to let some of these things be dealt with after the dust settled. I don't know whether though that particular item is one that will try to come to any closure on the first one is one of those which I'm going to tackle in the second half of this year which is now started but yeah it's not good to make such discussions in the heat basically we have an off by one in our constitution for any supermajority decision because as the constitution says if you want to have something by majority of n to 1 you need to have n to 1 plus 1 vote which is not bad because they have been developed as large because we are so many people voting but in a small body like the tech committee it means that if you say you just see to one majority and 6 people vote then it needs to have 5 people for 0 to 1 majority which is yeah so it's literally just off by one error which we could fix yeah and in the same context there have been discussions about other things that we might want to address regarding the composition of the technical committee in particular the point has been made that there are some simple cases of voting where having an odd number of members might lead to less likelihood of an even tie than having an even number of members but since we all understand that condorsed voting behavior means that if there are more than two choices on a ballot the it gets combinatoric very quickly I don't know that that's something that anyone feels in a particular urgency about dealing with. Peter in frankly speaking we have had many votes in recent year I can just say I'm a 1 vote where we were split a bit about everything else. It's actually two votes but one issue. So I would say it's 3 votes but anyways. Okay fine can you tell we all feel like that was but but in fact for for most issues when we have a resolution we said we conduct one or two ways to solve it and then it's very soon very obvious what the majority is yeah so it's not so important and with the one I whatever rules we had we need to come to a decision which we did yes that's that's that we are I think the situation honestly is that the majority of topics that are brought to the technical committee do end up having a sense of consensus form around them regardless of what the boundary conditions are in the constitutional voting rules. The problem is that when we have an issue that is as contentious as the one we dealt with a year or so ago the the the the the the anxiety about those boundary conditions just makes the whole thing harder. So these are things that we will eventually fix because we'd like to not ever have any of our successors go through quite the same degree of stress that we had to go through and frankly that's kind of where that list. Yeah the menu system one I'm not sure where that currently stands with that one is that there is a draft ballot in the last IRC meeting I raised concerns so basically there's there's two views within the committee at the moment. Obviously there's you know there's a fraught social issue with regards to was this the right way for to be handled and then there's also the question of what the technical policy should be and different members of the technical committee come down in different directions on what what the committee as a whole should be focused on when addressing this question and so it was kind of left at the end of that IRC meeting that I have the opportunity to draft a ballot option that draws on Keith's proposed technical solution and get that on the ballot. I also made it clear during that meeting that I couldn't promise I would get to that in a timely manner in which case the vote may go ahead with the current set of ballot options. Yeah I you know I don't know how we'll come down this this is probably one of those topics about which if there are folks in the room that have strong opinions it could be an interesting thing for us to have some conversation about here not that we haven't already had some and then I guess the new item that was not present on the list last year was the plan for cross-toolchain packages. I've lost track of the current status of that. We have provided advice and mediation. I don't think that I believe at the moment this is going to lead to the tech committee actually voting on something but I'm not certain that what the current status is. Well I would say we have made some progress. I believe that at the end probably we will be voting on something like that we just to formally answer a topic saying that we said we are happy to see some blockers or something like that. So but not a decision voting. Right. Okay. So with that I think we're more than happy to open things up to questions and I hope that you have some interesting ones for us. Hi hi this is Andre. I have actually a question related to past past issue. What to do if the other party is open hostile after the decision is made because if you remember we did a lot of who jumping before the Jesse release with the LibJPEG transition because the decision didn't list exactly what to do and when I made it the most reasonable thing it was not met with success and we had to rename the packages and and do a lot of weird stuff because because the other party was not well very warm in regards of the decision. When you guys want to try and tackle that what happens when the party on the losing side of a decision if you want to call it that is not amenable to actually implementing what was directed. I mean that's kind of what yeah. So I mean if we're clear about what we've decided as a committee then no developing developer has the authority to act against such a decision and any member of the technical committee can do an NMU to implement a decision and we've said that before that like in some cases if there's a maintainer override that maybe we should just be prepared to do the NMU for it. I think we probably haven't followed through on that necessarily. Basically I mean in cases in cases where the committee a committee actually decides what will a maintainer of course we don't do that light or just just easily it's hard for us to do but if we do we think that our decision then is that we have a very good decision to do so and what I think what we ask every developer to say OK this is now a policy which is set by the committee and send these extents as policy in an basically there are reasons for it and so please try to to see what we or try to follow it up reasonably so we don't have or there could be there could be parts we didn't spell out in other solution but basically just interpreted meaningfully and not oh yes this is exactly the law and if and there's a small passage I could go through without being punished because that's not the way we write our text write our text more attention specification and not so please yeah try to read it as it you think it's sensible that I mean if you say well you think something is very wrong in our solution for example you think we need to do this and be a forbidden to do that in a specific way that doesn't mean that you could should do it now another way but that's that we don't want to have it except except if you specified otherwise and if you have doubts please ask us first so I think there wasn't an issue in the past every explicitly forbid something and then was done in a similar but not not directly forbidden way which is of course not what we meant so so that of course speaks to the case of a maintainer being show is a unconstructive either in their interpretation of yeah I think from a maintainer point of view it's not unconstructive but I think the question here was about well or at least one aspect of the question is you know the technical committee can say what the policy should be for the archive the technical committee cannot make any member of the Debian project do the work to implement that right and so ultimately if we make a decision that does effectively authorize the other party to do an NMU if they are inclined to do so or they can ask the technical committee to actually do the archive upload but I think in some cases where the resolution of the issue sort of involved providing advice and guidance to the archive maintainers on what to accept or not accept or you know something like that so yeah I think Steve makes a really excellent point here and this is something that we had a lot of discussion about within the committee during the in its system debate and that is that there's sort of a distinction between making a decision about what the right solution is or the thing that we would most like to see happen and the fact that we don't really have the authority to make anybody do any actual work because we are all in Debian volunteers we're here for lots of different reasons lots of different motivations some of us get paid more than others to do the things that we do for Debian but nobody in Debian has the right to tell somebody else what to do you can say this is the right solution that one's the wrong solution and if the only thing that you want to do is the thing that was the wrong solution sorry you lose but we can't make people do work and given that it does put some constraints on this it means that any solution that's proposed somebody has to willing be willing to actually do the work to implement it and you know if we run into situations where a decision is rendered and one of the folks involved believes that somebody's being actively obstructionist about it then we ought to have some further conversation about that there's certainly other things the project can do to try and correct situations where somebody's actively obstructing progress in the archive but I'm not really sure what else we would say productively about that yeah so the obvious follow-up question would be should I well continue discussion for the issue before or should I open a new issue if I want to clean up the mess that was created during the transition like having lip-jpeg turbo instead of prox instead of just lip-jpeg prox and and the other stuff that was created so the preferred resolution would always be that you come up with some plan to do that kind of clean up straightening up making things right again without having to come to the tech committee for decision right and if it's possible to work with other people in the project to achieve those objectives great if you can't then yes if the situation is different now but there's a new issue that ought to be resolved open a new new bug and let's have that conversation in the committee there's no problem with that at all if the issue if the underlying issue really is fundamentally one or more individuals trying to obstruct the decision a decision that the committee has already taken then that's something that we probably need to have a conversation with the DPL about and or you know the remedies provided by our Constitution are sort of interesting you know if we we have somebody who's really behaving badly and the ultimate choice is to evict them from the project that's a pretty big hammer it's been used a couple of times in the past we don't use that one lightly that's a much harder hammer to swing than even making a tech committee decision so honestly and and so I think sometimes we have to think a little bit about what is it we really want to accomplish and in your case if there is some path to achieving you know the right technical solution without having to jump through a lot of procedural hoops IE without having to come to the tech committee or go to the DPL to complain about somebody's behavior or something like this great but if there are things that are getting in the way of your being able to make progress in Debian and be successful then don't be afraid to come get help because that's what we're here for other questions should Debian have a technical property that although engages in designing and planning stuff and something that is currently forbidden by the constitution I seem to have an opinion as it's just a question it's a question with the idea of we can't make people do something idea so I've always personally thought that there is definitely room for leadership within a project like Debian when I was running for and successfully elected to be DPL I spent a lot of time thinking about who ought to sort of have what roles and responsibilities where and I articulated at that time that I thought one of the things the DPL could do is to shine a light on areas that they thought needed more attention or where more hands would make things work well way back in the day when I was running for DPL the big issues were internationalization in the installer and I forget what else that there were several issues where I thought okay if I talk about this and I talk about it being important and more people want to work on it that would cause a positive thing to happen I believe that we have spent a lot of time trying to figure out how to think of the technical committee as an organization that exists only to sort of make decisions of last resort because if you get really proactive about trying to sort of make decisions in advance you really constrain the sense of what people think they can work on and in a place like Debian that is as much a duocracy as we are meaning the people who are actually willing to do the work get to sort of in some way define what the technical direction is it's it's it's dispiriting if the thing you care about turns out to not be one of the things that gets laid out as part of a vision or articulated so I personally have gone back and forth on this I don't know whether it's important for the technical committee to be the place where you know the sort of big design decisions about the future get made but I would like somehow somewhere in the project there to be some sense of what the objectives are what the vision is what the opportunities are what the things are that we could do if we just cared enough to go work on them. Actually I think it's really a feature that the technical committee doesn't do the sign work because if you do the sign work and then have ideas that are not popular in the project and then who should do the decisions the ones who like the new design not a good idea on the other hand there are places in the project where we could do the sign work for example as a policy team which could be more involved if they would have time and would like to do it there are lots of other places so if somebody says okay or a group of people says you want to do more design work and it shows that it's helpful for the project I'm quite sure they get support of them all over the project and they could do influence the project but I don't think this is a committee book place for that. Yeah so I'll say that I have never interpreted the constitutions wording about detailed design work as a prohibition as opposed to a statement that this is not the work that the project should expect from the committee so I think there has been a view that at various points I feel has hamstrung the committee in resolving some issues where there was a contentious issue and it needed somebody to actually dig into it and suss out the true technical right answer to the extent that there is such a thing. There have been times when the question was should we do A or B and the members of the technical committee looked at it and went that's a bad choice to have to make because neither one of those is really good it would be better if we did something else and the temptation then is to go start thinking about what the right answer is and I think this is where the tension exists in the actual existing practices of the committee is when is it okay for us to think beyond the question that was actually asked of us and when things get complicated and messy my tendency always is to want to step back and say okay what was the question that we were originally asked what are we actually supposed to be making a decision about and sometimes that helps simplify things sometimes it really doesn't but in this case I think we're really it sort of depends on what you mean I don't there are there's sort of a distinction in my mind between engaging in some design activity in the process of answering a question that's brought to the committee versus a situation of gee you know who's the body that's supposed to sort of provide the vision for the future I will admit that I've been disappointed in the last several DPL election cycles that our platforms haven't had more long range vision content I am of course really pleased every time I read somebody's platform and recognize verbiage that I authored in 2002 because I like thinking that you know ideas that I had or collected from other people and took as my own have you know become part of the culture of the project but when I don't see something new and shiny to aspire to I'm a little disappointed and so you know maybe in the future folks writing DPL platforms might think about you know what would cause BDL to get enthusiastic again and you know add that to your list of things to worry about or not I'm only one vote right but I don't know it's a really good question if you have an opinion or others in the room if you have an opinion about this speak up and of course I read the constitution similar to you so it's not that I that I personally must not do the same but that's definitely not in it and also we as committee we sometimes we do take a deeper look at things and say okay now this is wrong and that is wrong for another reason and isn't there another way to do it but I don't think that we should be the group of people who actively drive the vision how they're going to look like that's the wrong group for it but sometimes there is an overlap who are in the committee who would do another role to that and that's great right and also when you get right down to it even even if the folks who were on the committee had the desire to try to impose some sort of top-down vision for Debian which I don't think anybody who's ever been elected to the committee has viewed it that way most of the time the people who are sitting on the committee find it enough work to keep up with the issues that are actually brought to the committee without going looking for more work as the committee you know you might have individual members who are still out there participating in design discussions in the mailing lists in Debian Develop and on Wikis and having conversations with developers as peers which is quite a different thing than trying to get a resolution passed by the committee to say that this is a thing that Debian should do which is just that's just overhead I would also like to suggest that those of you that have a strong interest in the technical committee and have been around the project for a while and done some useful things take note of the fact that at the end of this calendar year there will be two positions on the committee that are becoming open so that means that sometime this fall we'll put out a call for you know nominations self-nominations whatever of people who might be interested in serving on the technical committee committee starting in January I certainly hope the committee rest of the committee doesn't decide to wait until January to start that process and so I would encourage all of you to have conversations with your friends and peers here at Dubcon about what do you think is important what would you like to see happen differently I don't want to sort of specifically speak for anybody else but I know that Sam Hartman has been very clear about the fact that he thinks there are some things about how their current committee membership has behaved that he'd like to see us do differently and he's been very willing to engage in conversation and I really have welcomed his input into those discussions even if sometimes we're approaching a situation from very different viewpoints and maybe once your term has expired you can run for DPL again I told somebody once that the problem with me running for DPL is that the two times I ran and was not elected each time I got a newer bigger job at HP and now you're back at HP so it would work again Yeah, but I'm already a fellow in the office of the CTO that anything I could do up from here just is too much responsibility so I don't know that feels dangerous You took a much more laid-back approach to this question of thinking about the nominations I was going to say I was going to let people know that the doors are going to be locked at the end of 45 minutes and nobody's allowed out until they come up with four nominees for the technical committee and you'd be allowed to nominate people not in the room by the way too So the process we've used the last couple times just you know for those who haven't been paying attention the process we've used as we've put out a call for nominations people have nominated themselves or others the people who did not nominate themselves we've checked with them to find out if they were okay with being nominated and then and interestingly a number of people who were nominated said nope not on your life for different reasons and that's fine and then the technical committees had a private discussion about the merits of including each of those individuals on the committee while as a project we are intensely focused on being open about all the things we do in all honesty the kinds of conversations we're having about people who were nominated are just not appropriate for a public list and so that's the way that process has worked we then always take the slate of candidates that we are considering and put them to a publicly visible vote before they're taken to the project leader for review and approval and so I think that combination has worked out pretty well but again I would strongly encourage any of you who think you might have something to consider nominating yourself or nominating somebody else who thinks appropriate it's honestly not a lot of work for us to contact people and ask if they're willing to be considered as nominees we're more than happy to do that so if you have a list of people you think might be interesting to see on the committee don't be afraid to give us the list just something in addition to what you said at least in the last time we had more people and our that's that's a basically a list of people we are discussing about the self-nominated Sam or accept us a nomination and then not the list of people who were now added to the committee is not the full list of people who were consigned acceptable so don't think because we are nominated and not accepted that we consigned you as non acceptable so but we don't want to make the distinction public which nominees we consigned acceptable which not and I hope that is okay or I personally wouldn't like to do that there's not the common I'll add there tech committee your nominations but also if there are people that you think would be good on the technical committee don't be afraid to talk to them yes about it as well because if if they only see that from from the technical committee I think it's possibly they view it differently than if they get it from their peers and I think actually in the last cycle the folks who said no had strong reasons for saying no that were unrelated to where the nomination was coming from but this is this is we are in devion a social organization on some level and people understanding the sense of value that you place on their opinions and interests and you know in fact bolstering their willingness to take one for the team and go do something that is at best some work and at worst really really stressful is probably a great thing to do and frankly I suspect that in the next few years I hope we don't have any more situations like we did around the unit system discussion that was that was the single most unusual and contentious issue the technical committee has ever dealt with and I it's very very worse than the other ones so it's not just a bit but it's much worse order of magnitude difference really we need to ask if we should switch from a Linux to a BSD kernel by default do you think that would be much easier question yeah I suspect the committee would come to consensus on that fairly quickly but feel free you know I'm sure I'm sure you know nope sorry I won't still be around next April well sorry any other questions oh finish it early while we can but okay I have seen that question from an X member not actually 20 minutes we're supposed to end early and let the camera people go home I had a so I noticed there was this business with the the cross toolchain stuff I read that bug report and it it really it was the the initial referral to the TC was was a beautiful piece of writing and really in other circumstances you would have been you know uplifted by it but the facts that were revealed in that bug report were disturbing and I worry that males like that are sent not generally sent to the TC because the person who would want to send such a male fears that the relationship with the maintainer that they're complaining about will be even further damaged by it and I would like to ask the TC members what suggestions they have for people who are in that position and what they are going to do to make that problem easier well if you have an issue that might belong before front of tail committee of basically where you need help you could contact any of us of lists with a private email there is also a non-public mailing list for the committee so we could forward things there so please if you if you say okay it's a difficult issue in that back report it's basically in disagreement between the maintainer group of other people on how to behave on how to address certain topics which I agree with you the male is not so nice so yeah and you will provide other means of communications when where we hope to make it as less difficult with a maintainer as possible of course as soon as somebody else starts speaking with a maintainer yeah I mean that is basically a social conflict involved not only taking it but a social in some cases in social conflicts we can try to help as good as we could but none of us is now is is now in let's say none of us works as a social conflict whatsoever but we all have those technical those so yeah we can try to do our best but and if you want to discuss it off-list you can you can of course I was just going to say that the reality is that this has been happening a lot for a long time there are a lot of things at least I've had people come and ask me questions about gee how do you think I should handle this you know do you have some advice or guidance that you could give me about this on topics many of which have never ended up you know being publicly surfaced in fact I realized at the end of the one-year term that I spent as Debian project leader that one of the problems was so many of the things that had been brought to me during that year were things that we found some quiet resolution to that I think people looking at my term in office went well he didn't do a damn thing now did he and there's a tension there somehow because it would be really good if everyone in the project understood that there were avenues that you could pursue to have you know get some advice and guidance and maybe help resolve a problem but it's hard to know how to sort of publicize quiet resolutions being successful at least I've never really figured out a good way to do it without somehow seeming horribly self-serving in the process and so you know we've certainly talked about and I know over the last two or three years we've a couple times in Tech Committee Boffson and other venues espoused the opinion that people want to approach us as Andy just said and in other ways we're happy to have that happen I'm happy to just say that here again today if any of you have some frustration that's you know bubbling up and you just don't really know how to make things better instead of making things worse with an email come find of one of us this week and let's have a conversation and see if we can't help you figure out how to make some progress but I where the discussion ended up in a special Boffson that on a Deppcom failed by one of the Tech Committee members to moderated by one of them to get both parties starting to agree at least a bit yeah we could do that if it's so and we have we have in fact approach third party sometime where we knew the two folks in question who were having some kind of conflict we're going to be at the same event that wasn't a Debbie an event and have asked somebody else to would they be willing to sit and sort of moderate a face-to-face conversation between those folks and I certainly have personally offered to throw some cash on the table to cover the cost to some beers or something if that would help lubricate the conversation and you know things like that do help sometimes because again you know part of the reason that I have for so long been such a strong supporter of the idea of getting good corporate sponsorship I know that those of us who have a chance to come to events like this and get to know each other and have some meals together have some drinks together you know form personal social relationships just don't have the ability to fight with each other in the same way as people who've never met in any way other than an online communication I think that's really important and so part of what I've certainly tried to do over the years is look for as many opportunities as possible to get people to communicate with each other better and sometimes you know that's by asking you know a calm third party to invite them both to go to dinner somewhere or something and sometimes it's been by sending an email to somebody saying do you really have any idea just how what you're saying publicly is being perceived you know have you thought about sort of how the other person feels about this and why what you're saying is making things worse instead of better we do a lot of that and I guess it's probably thanks for the question because I think it's probably worth saying out loud here that you know I know I do and I know that that any and Steve have talked about examples too I think I think all of us on the committee at one time or another have those sorts of interactions with people and we hope they make things better and honestly well I'm totally happy for us to have more items come to the committee that need to be addressed by the committee every bit is happy maybe even happier if the project just works well without issues having to be brought to the committee because that's what we all want we want somehow to be able to collaborate in an efficient and effective way with each other to make the world a better place other questions yeah so can I by next step conf be policy compliant by ignoring the devian menu I'm sorry I didn't quite understand the question can I by next step kind of be policy compliant by ignoring the devian menu good question we will see that we voted about it have you looked over the draft policy language that Keith had started putting together on this? I haven't reviewed it recently myself so I can't I don't think yet send it by me correct it's in it's in the get it's it's in the technical committee's get repository as a draft it's not been sent to any mailing list yet I have been waiting for it to be posted to I mean you you you only is he it should be published so so he's when waiting for that I'm just saying that in terms of of what the answer to your specific question is I don't recall what it was that Keith recommended there to address the the particulars I do think that ultimately yes the answer should be that yes you should not have to interact with two menu systems in your package however there's details about how the system should treat those two menu systems to ensure compatibility and ensure that the system can use working for our users and not just I understand the viewpoint that the menu system is is not something that maintainers of packages that interface with the free desktop system want to be dealing with however just dropping it on the floor has impact for other places where we have integration today so but and it's a part I think it would be helpful if you could review what is what is in the draft and if you don't find it please send an email to I say to me I told you to any of us and we can send you the text because it's actually smelling action item here we should probably go to the tech committees page in the WN dot org stuff and make sure there's a explicit pointer to our repo and an invitation to people to review drafts there because it was the obvious way to collaborate on creating drafts of new documents but even I sometimes have to stop and go oh yeah right it's probably in the repo so we could probably make that a little more on the webpage here yeah I'll I'll try and remember to do that this evening any other questions okay then thank you all for showing up yes thank you very much