 Okay, so I want this to be a bof in the sort of traditional sense of a bof in that I want it to be very interactive questions, answers, talking about things that are important to us, but in order to provide just a little bit of context, I threw three quick slides together which I'll run through. The first one is who are the current technical committee members, both the ones that are here and the ones that could not be here, a quick reminder of the constitutional basis for the committee, which sets sort of the definition of what the committee does and does not do. And then I pulled the current, currently there are five open questions before the committee and I made a quick list of those and with the help of the other folks that are here perhaps we can go through those briefly and see what the current status of those is. And then, yeah, there are four of the seven of us here that does constitute quorum. So if we actually all agree, yeah, yeah, yeah, a two week voting period, getting us all to agree is sometimes the challenging part. Okay, so committee members, me, BDL Garby, the ones that are an italic are the ones that are not able to be here this year, Russ Albury, Don Armstrong, and Nomeno Shravastava. Also here with us though are Andy and Ian and Steve. You guys can all wave if you'd like. The constitution is the basis for the existence of the technical committee. It is section six of the constitution. The things that I thought were worth mentioning are that the number of members is defined as being somewhere in the range of four to eight. With seven right now, it feels like we're in a pretty good place, though we have been having some discussion about the possibility of adding an eighth member. We have in the past found it appropriate to take people who were no longer able to put a reasonable amount of time in and arrange for them to agree to step down so that they could be replaced by more active people. But one of the things that I think is very important to understand about the technical committee is the need for it to have a certain sense of stability or consistency over time and that its views and opinions are because it is often sort of the last place to go for a decision. You don't want it to be something that's going to bounce around a lot following popular opinion. In section six, there are sort of some things that define what the role of the committee is, fundamentally, that it can decide on any matter of technical policy. It's somewhat constrained in that by this notion that the places it should really spend its time and attention are places where developers' jurisdictions overlap. If you have read the constitution, you understand that most of the decision making authority in Debian is left in the hands of individual developers. And so it's the places where individual developers have some conflict that they can't figure out how to resolve themselves, that the technical committee is really supposed to take a role in trying to resolve that. It's also the case that the constitution makes it clear that these decisions should be taken when the committee is asked to do so. And what that means is really that the committee is designed to be responsive to the needs of the developer community and not out trying to push some particular agenda through the developer community. The committee does have the authority to overrule a developer, but to do so, we have to have a supermajority. In other words, we have to have a very strong sense of agreement in the committee that that's the right thing to do. In the past, I have only been a couple of times that I can remember where decision actually overruled a developer and those were always very carefully considered and thought through. It's completely okay for the committee to provide advice. And in fact, many of us individually and collectively have done that over time. But there are a couple of things in the constitutional authority that are fairly clear. One is this notion that the committee should not be engaging in the design of new proposals. In other words, the technical committee in Debian does not exist to try and chart some future course for the project. That's a task much better left to the individuals who are experts on the individual pieces of software and process that make up the project. And the notion then is that the committee is the place to go if there is some unresolvable technical question that needs a decision of last resort. And that's really what the committee is about. So over time, the total number of issues brought before the Debian technical committee is not very large. I did not go back and try to count them up, but it's single digit dozens in the entire history of the project. Not a large number. Right now, it would help actually if that didn't somehow just blow up. It looks okay in preview. Why doesn't it look okay when I go forward to it? Gee whiz. There are five issues that are currently open and one of them is, yeah, what's- I wish the Python maintainership were that easy to solve. That's the one that's being pulled off. Okay, so the five that are currently open question that we've been discussing recently, and by the way, I put these in order of the bug number in the BTS. But of course, bugs are not usually open directly against the technical committee. What normally happens is that some bug in the BTS becomes contentious. And it is then referred to the technical committee by reassigning it to the committee. And so the ordering of them isn't really the order in which the issues came up. Well, it's the order in which the bugs are originally filed, but it's not the order in which they were brought to the committee. And it doesn't really reflect any sort of sense of importance or whatever. We have been having a fairly active discussion about the last one on the list, which is the implementation of the build arch target in Debian rules. This is all about trying to make sure that our auto builders don't have to try and build architecture independent packages if they don't need to. The kernel ABI one has been quiet since I think October of last year. I believe the last action on that was an observation that we had chosen not to over the rule the maintainer in advance of the squeeze release. And it wasn't clear whether that was an issue that we should still be trying to deliver an answer on. I think there was a request for specific proposals and we haven't heard anything since that for a while, or maybe that was more recent. I don't remember the exact timing. The net base mine v6 only cleanup on upgrade is another case where I don't think that we ever achieved sufficient momentum to believe that taking that to a vote was something that we're ready to do yet. That would be specifically a case of overruling a maintainer's decision. The Python Maintainership has been under very lengthy discussion and conversation. It's actually been the topic of questions now and a couple of different interviews that Buxy's done in his series of interviews of interesting people in Debian. And then the hardening build flags. I don't remember exactly what the state on that one is. But these are the issues that are currently assigned to the technical committee pseudo project in the bug tracking system. And if you're curious about them, that's where you can go to read the sort of history of the discussion. There is a technical committee mailing list which ends up being sort of linked to these discussions through the fact that most of these discussions end up being copied to the bug reports. The constitution does allow us to have private deliberations, but I think the majority of us, maybe all of us currently on the committee, believe very strongly that as much as possible things that are written in email and are going to be like that should be part of the public and open record. It's not unusual for there to be lots of private conversations on IRC or even phone calls with the developers that are involved in certain questions. To try and understand what's going on and get to the root of what the real problem is. So that's really all I wanted to say before we dive in to any of you want to add any thoughts or comments before we open up to general questions or. Yeah, it's a technical committee. You can't expect us to understand. Yeah, the technical part of that raises is the more dubious regarding that base bind V6 only wasn't that a pre-squeeze update issue? And perhaps maybe we should just close it as well, it wasn't clear to me. The issue was that for a while the package was delivering a config file or a config option, which was generally considered not a good idea. The question is now that we've had a stable release and that was a pre-release issue, is it now too late to actually worry about it and not worth our time? Worth us doing anything about it? Well, actually the question is really, is it worse to now change the behavior again after people have adjusted to that behavior? So we could have done a pre-release, but I really have very bad feelings to do it post-release now again. I was completely happy at the time to vote against the proposal that was brought to us and leave the maintainer's decision in place and so. We should just do so. I think I will just call for vote today or so. I guess is there anyone here who disagrees with that opinion or? I actually was inclined to overrule the maintainer on that, but I think it's now too late to worry about it because it's not worth doing technically at this point. I agree with that, but we should actually call for vote and then do it and then it's done. Okay, so we will soon have four instead of five open issues. Is it on? There was one other thing that I wanted to say. If you look at the history of the technical committee, we've had a lot of things brought to us, which we haven't formally made a decision on. And well, sometimes that's because it's where we're slack or it's difficult. Sometimes it can be very difficult to produce a coherent agreement. But a lot of the time, and this is where we've, I think most of our successes have been not due to actually resolving intractable problems, but they mean due to, you know, there was just some difficult miscommunication or something that hadn't been properly thought through or and we get the issue. And after a bit of discussion between the different sides, it turns out that actually there's a reasonable agreement and we never actually have to decide the matter at all. We've just kind of somehow now everybody agrees on roughly what the right thing to do is and normally those things have been good successes with the committee. And the ones where we actually had to try to make a decision, we've actually been not very, I would say we've been rather poor. I think it's been, I think it's sort of- Actually, I bit disagree with you because there have been cases where we have made decisions really fast. That really is the cases where it was very obvious that some things were so long that we just had just one option and do it. So for example, if I can remember the bug where they maintain and wanted to remove one of those packages and someone else wanted to adopt it, we decided quite fast that adoption is of course okay. Which I really think is the right decision if, even if I would have preferred the package to die about or something else. So yes, we have done decisions fast in case it was obviously the right thing. In case it was not obviously the right thing, we have been slacking up it. I think part of it too has been that when the problems that are brought to us are straightforward technical questions, that's one thing. But a lot of times the questions that are brought to us are actually very steeped in emotion. People have had a chance to yell at each other and get upset and get mad about it and the first part of the process is actually to try and unwind all of that emotion to get to what the actual core technical basis is. And sometimes there isn't any technical basis left at the end of that discussion. See also a number of bugs that we closed fairly quickly while we were meeting together in Edinburgh. If folks remember what was going on in that period. But yeah, so I think it's been sort of mixed. Yeah, we've certainly also had instances where somebody has petitioned the technical committee and it became very quickly clear that the technical committee opinion was so overwhelmingly against them that they said, okay, I guess I won't do that then and turned around and closed their own bug. So, so yeah, the the the measure of the technical committee is not the wiki page which documents the actual votes that the technical committee has conducted over the years. That's fairly short list and and if you'd like to go look, you're welcome to it's it's under the develop pages under the technical committee. There is a page where we have a sort of historical list of all the things that we've actually decided and how they were decided. But again, it's a fairly short list, a couple dozen entries, something like that. So questions, I guess we get to play musical microphones, but that's fine. So how what is your position about public or private mailing lists? Because I heard that some of the problems that you had to cope with were partly handled privately and we have a promise that we handle everything publicly. So you have to find a compromise between us. What is your position about that? Good. It's not an attack, it's just a question. It's a great question. I would like to respond to that by noting that the the social contract, the the bullet points of the social contract are the title of the the notes of what we have agreed to and that we won't hide problems is merely a short title referring to how we will handle bug tracking. The fact that we sometimes have to deal with social issues in private is the nature of the beast. And you know, it is more important that at the end of the day, we are all able to continue working together as a community and that that we haven't managed to self-destruct as a result of letting social problems, social disputes boil out of control than that we air all of our personal dirty laundry on public mailing lists at all times. And also, I mean, social contracts, we don't hide the problems. That means, of course, the bugs are all public. So if someone says, please decide that this person cannot be longer, I maintain off that package because I think he is socially irresponsible. Of course, that is part of the public bug system. We're not not going to hide it. I think that's obvious. On the other hand, well, of course, I prefer the discussions are public. But sometimes it's better to have a discussion in private and not have a discussion at all. So and then, of course, it's very easy to what to do. I think related to that is this notion that sometimes someone submitting a problem or an issue to the technical committee looks at it and thinks that the answer is so obvious that it should be something that can be decided quickly and we can sort of get past that hurdle and move on. But unfortunately, some of the problems that are handed to the technical committee are of the nature that no matter what decision the technical committee makes, some volunteer in the project who has made a substantial contribution of time on either side of the issue will be unhappy with the result. And so sometimes if we can just slow down for a moment, have some discussions about it publicly and privately, and diffuse the situation a little bit, sometimes it's possible for us to find a path away from a problem that may take a little bit longer to get there, but in the end allows lots of people to remain feeling good about the contributions they make to the project and not be in a situation where someone feels they must leave because everyone hates them and they have to go. Now every once in a while there have been situations where the right answer is to communicate to somebody that everyone hates them and they really should quit bothering us, but that's a rare and unusual situation and it's really not technical. Yeah, so I agree with everything that my colleagues have said. We do have a problem with this, which is that in the Constitution it does say that we're supposed to do everything in public, apart from appointments to the committee itself. And in practice we have found that if the problem is just a technical dispute and you have two or three people who are just disagreeing about how something should be done then and they're being polite about it and they just can't agree, that's fine. We can do that in public and that works well. But normally, you know, Debian has a lot of people who can mostly just behave like adults and work through their disagreements in a good way and that means that when things come to the technical committee, often the reason ultimately that it wasn't resolved is not that there was an irresolvable technical dispute. It's that there's some kind of personal conflict and the resolution of personal conflicts in public discussions has not always had very good results, shall we say. So, you know, I would agree that we're not always doing exactly what it says here, but I think it's probably for the best. And if anybody thinks that we should be, you know, not having a quiet word with people who we, you know, think maybe we should be, you know, trying to calm things down and just generally make things more functional in which is often easier done outside the sort of public glare of, you know, a big row, then, well, maybe you should tell that to us, but I think we're probably not going to change very much. Question from IRC. The technical committee is elected, but how long is the mandate and which qualifications are required? The technical committee is not elected, actually. Okay. It's appointed. And the rules by which it's appointed and how it's appointed are clearly stated in the constitution. They're slightly complicated because it's an attempt, I think, to make sure that when, shall I, since you wrote that part, I can probably do it from memory. I've just opened it here to check what I just said, but I don't think I need it for this bit. So the technical committee is essentially self-perpetuating, but appointments to the technical committee need to be approved by the project leader. So the normal process is that if we, as the committee as a whole, decide that we would like to appoint some particular person or that we're short of new members, we will somehow decide who we think would be a good candidate. We will discuss it normally privately with the project leader to get a feel of the project leader's opinion about who and in the past we have not, you know, we've taken a formal vote to appoint people to the committee, but we've basically never had a big disagreement about anything like that. If the membership of the committee falls low enough, then the project leader can just start appointing people willy-nilly. No, not correctly. We could appoint people without the project leader, but if we fail to do that, the project leader could... Right, depending how short we have been, how small the committee has been for how long, appointments to it become easier and easier, until eventually if it persists being like two, three people for months on end, then the project leader will can just appoint whoever they like. And to the other part of the question, there is no specific duration on appointments. They are until by mutual consent, someone chooses to leave, there is a mechanism by which... We could pick people out. There is a mechanism by which the committee members can vote somebody out in effect, but I'm not sure that's ever been invoked. There have been a couple times where we agreed to convince somebody that they should step down, but I don't know that we've ever actually gone as far as a formal vote. Yeah, I think it's possible that we have formally voted somebody off when it became clear that they just really weren't answering their email anymore. Ah, yes. That was a long time ago. But it was a very long time ago. Only two of the people sitting here today were on the committee at the time. Who was about, they wanted to carry on. I don't know what would happen if we had such a problem. That would be an interesting failure scenario for the technical committee per se if we ever reached that point. That we felt we need to vote somebody off for... Yeah, that would be... It would sound way too much like reality TV. So we can get a close-up of that in a long time. Okay, next. Uh-oh. Our first... Our fearful leader, yeah. So on one end, I'm following the technical committee meeting list and backlog because, as you said, some of the issues which are reported there are really not strictly technical, but social and may have broader implications. And looking through the list, it seems to me that there are some backlog which stays quite for a while, as you said, probably it's always something... It's also something useful to let things settle a bit. And then someone of you or some member of the technical committee take the lead and invokes opinions and votes and go home. And in a very short time, it gets solved. So I was wondering whether you ever considered the possibility to have some sort of periodic meetings on IRC, like a couple of months or something like that. And this idea is some sort of reinforced by the fact that other projects have institutions similar to the technical committee, like technical boards, which have periodic meetings and periodically review all the issue at hand. And if you have thought about something like that, maybe the fact of letting the issue settle can be some explicit action. Like, we meet every two months, this is no, this is still too, you know, too heat, too hot, so we will let it settle a bit for, and we see in two months what's going on. That's a good thought. We've done a couple of related things in the past. We experimented three or four years ago with the notion of trying to explicitly assign responsibility for new incoming issues to particular committee members to sort of shepherd that and let the rest of the committee know when enough information was present, and maybe it was time to go to a vote. That frankly didn't work very well. We actually tried using the owner mechanism and the BTS to keep track of that. And the mechanism was fine, but the social behavior didn't really, you know, work as we had hoped. We a couple of times now have made a point of trying to either review and clear as much of the list as we could before or at a DEBCONF that has been, you know, once a year is probably not as often as would be necessary for the kind of mechanism that you're thinking of, but we certainly have done some of that. But no, I don't think we've ever tried to schedule anything like a regular get-together on IRC or something, and maybe that would be interesting to try. I think we discussed about that in Edinburgh. And at that time, the answer was basically, that we all are, especially you are too very often in an airplane to really do a regular meeting, that might have been changed now. So we might perhaps do that, but actually also there are not so many issues, so I'm not sure if really a regular IRC meeting. I think the real issue is... The real issue isn't... If I do a regular IRC meeting, it means it blocks that point of time in my calendar fully, and even if the meeting is only 10 minutes, it costs some of my time. I'm not sure we even have to have a meeting. The real issue is more one of should we just, you know, whether it's me or someone else in the committee, should we just sort of set a regular trigger for ourselves to go re-evaluate the currently open list? I think it would rather be something like that we say, okay, we do once per whatever month, say, okay, we have these open issues, and I propose that we let this, yes, open for rather a while, and now start to finish it. So that would be a good thing. Just sitting here thinking about it, I think it would be easy for me, for example, to take a trigger at the first of each month or something to just post to the list. Here's the set of currently open bugs. Here's what I think the last heard status was on each one, who's willing to take responsibility for driving one of these to something closer to closure. Dave, for example, has been working recently on one of these issues. Well, one which I assigned to the technical committee. Yes. And one of these were cases where we have gone looking for work. Yes, well. Yeah, but actually, even though you are in the technical committee, I mean, anybody could drive back on the technical committee if he's doing good work on it, and not just saying, oh, I have rights to the bug source. It needs to be voted, but yes. But anyone is free to summarize bugs, to do whatever, as long as it's been helpful and getting us close to a solution. It is interesting that I find myself needing to go read the bug log from time to time to remember what are the still open issues. And so the notion that we turn that into a periodic prod for active discussion is probably worthwhile. Abba, you're right. Everybody can do that. Everyone can post there. But since the technical committee is like the ultimate authority for this matter in the constitution, it's, socially, it's quite unlikely that someone will feel entitled to go there and ping you every two months or something. So if you can have an internal process, it would be way better. Well, I fully agree with you that it would be better if we do an internal process. But still, I wanted, especially as I said, it might be a bit, people might feel difficult about it. If it's an unheated discussion, there's just about summarizing things that have been said and doing it in a way that doesn't look like someone is going to try to force us for a certain opinion. It certainly, at least from my point of view, consider being helpful. But yes, I agree that sometimes you're a bit difficult and I'm happy if someone contacts me privately on IRC or by mail. I would like to do it this and that way. Would you consider it appropriate or not? And I'm certainly willing to give hints on that. That's why I said it in public now, so that not some of the things, Steve is here misusing his position, but that's something that everyone could do as long as it's technically helpful. Well, the interesting thing about that particular bug, which I did assign to the technical committee, is we had a dilemma of choice regarding under which part of the constitution the technical committee had the authority to rule, because there were effectively five different points under which the technical committee could take that on. And it was like, well, one of these requires a three to one, or two to one supermajority and the others are simple majority. So, mm. Come back on that question about IRC. I would be quite happy to try an IRC meeting. I think that would be a worthwhile experiment to see whether it worked well and produced useful progress. And I think that would be something that we should see if it works and then if it works we can do it again. Doesn't have to be very often, even like every three months would be, given our current rate of progress, that would be an improvement. Yeah, I think three months might be a good frequency. From my perspective, the big thing is not about whether we have a scheduled IRC meeting or not. It's, you know, keeping track of these bugs because by the nature of the issues that are brought to us, the bug logs get so long and it's so difficult to actually hold it all in your mind what the current status is. And so I'm actually wondering if something like the BTS does support summaries now for bugs. The idea of tagging a particular message in the bug log as the summary of this issue. And I wonder if we, I'm actually not familiar with, too familiar with the mechanics of that and I have not used that in a workflow. So I don't know if anybody in the audience has experience using bug summaries in the BTS and has opinions on that, but maybe something like that to help us, you know, capture the current status periodically. And so it shows up at the top of the bug log instead of three fifths of the way through the web page. Why not? It's simply a question of I'm not used to the workflow and I've not done it yet. Yeah, I think we should, I think we should, okay. I think we really should just try that one out. Why not? Okay, one, do it. No, not your own one. Not the easy one, huh? For the summary thing, it's just a mail and it will grab you first paragraph of the mail and put it in the summary. So I don't remember the precise tag or comment that you have to use, but it's just that nothing fancy. Does the BTS command have an interface to that in stable? It does have it in stable, okay. My question is for the first issue with the routing build flags. This is a tricky topic because, well, on one side you usually decide on technical issues where you have patches ready because you want people to get involved and have something rocking to decide on. But here we are somewhere on crossing two topics. On one side we need an interface to inject build flags in packages. So we used to have one in DPKG build package with the environment variable. We changed this because people didn't like this interface so we have no DPKG build flags for the program that they've been really supposed to use. And parallel to this, we would like to have hardening build flags so we have to start using them. So of course the right way would be to inject those via DPKG build flags but there's no patch for this. But we have one to modify the GCC. So you don't really have a good choice. Either you use a patch that GCC maintainer doesn't really like or you have to do some other work that is still has to be designed. And well you did not, you can't provide advice. It's also your role and maybe you could do some of the brainstorming in the team to see what would be the best way to achieve the goal. Because well as a DPKG maintainer I would be happy to implement whatever we really decide but there's no clear way to decide how we inject the flags. I think that once an issue is brought to the committee the idea that it's okay for us to contribute to the discussion about what a good solution would be is perfectly okay. I take that other piece of the Constitution is really meaning that we shouldn't be out sort of designing solutions willy nilly. That in the context of evaluating the possible outcomes of a particular question that's brought to us that exactly that kind of what would the right way to be to do this discussion which in fact we're also having now on the on the build arch question an idea got proposed that's not currently represented by a patch that's just sitting there but it seems like something that might be an interesting alternative. I think that's perfectly okay. In the case of the particular hardening build flag ones I don't know that I have a very personally strong opinion on that. Well, actually I disagree a bit of what you said because if we want to change the default for Debbie and I'm asking myself why shouldn't be the compiler be the right place. This is the first question. This is the second question of course. Are we sure or what are we going to break into doing that? So that are two different questions. The one is what is the good way is the second one when do we do that? Because I'm adding that at an unpopular time could have a very negative effect on different parts of Debian. And the second question is of course if you have said that Doku currently doesn't like the patch then the question is what's the reason for not liking the patch of the patch bed? Is it the maintenance cost relative to the patch? So that would be the next question I would like to ask Doku but just a 10 minute sign has been shown. So I think we need to follow up the discussion out of this meeting because it will take more than the last five minutes but if Doku wants to say a word to it I'm of course happy to hear it. Yeah, I do think that's actually been covered in the bug log. So perhaps we're rehashing old material. But I think it would be fair to allow Doku to answer as well now. I think we should delay the decision to a discussion to a BoF this week. Just to get a mic first before we can say something. He just said he wanted to delay the discussion to a BoF later in the week. Yeah, which is okay. I do see that we have all the significant opinion camps on that bug represented in this room at the moment. We have the D-Package, GCC and DevHelper maintainers who I think are the three edges of that triangle. Sorry? You have strong opinions about D-Package injecting. Joey no longer has an opinion. Okay. Actually, I think we should meet a DEPCOV person and try to get forward and say, okay, what are the possible ways to do it but not right now in this room. But I think sometime this week would be a great time for us to get together and have a conversation. Yes, I think we should allow the last questions and go to dinner. Oh, yes. Food. Is there another one online? Okay, sorry. So there was one more question from IOC. It's perhaps not strictly technical committee related but I'll ask in a way. This morning there was a talk about quality assurance and an opinion arose that a documented peer review process before uploading packages would be nice to have and the question would be what would be the opinion of the technical committee if such a question was raised. Was raised. Right, so I mean, that's not, I don't think the technical committee would have an opinion about that. I think we would actually say this is a matter of a process of how the project wants to run, how it decides it wants to do things and that's specifically the kind of thing that we don't want to be deciding. I think that falls under detailed design work. Right, personally if there was like a technical question about exactly the machinery for how that should work and there was some detail or big strategy question or whatever it was, then we would probably answer that but on the question of should we have peer review and who should do it is definitely not one for us. I would agree. Apart from that of course anybody is free to try and to set things up like set, trying if it works, if you have the necessary manpower and then I think it becomes an obvious thing that even we don't need to decide anymore. I think that the other thing that's worth mentioning is that I and I'm sure other members of the committee have in the past been asked our personal opinions or been asked to spend some time reviewing somebody's thoughts or ideas about something that they wanted to propose as a technical change in the project or the way they were thinking about packaging piece software or whatever and I think all of us remain open to those sorts of queries on an individual basis even when they're very certainly not part of the committee. I can't imagine anything more horrible than the thing which immediately popped in my mind when you asked that question which was, gee, somebody thinking that the technical committee ought to peer review all this stuff. And the answer was. It's something that feels that way. The answer was, ah! So. Yeah, yeah, exactly. So I think the thing I want to encourage everyone to understand is that if you have a problem that you believe falls within the mandate of the technical committee to look at and where all other methods of trying to come to a good solution between different developers with different opinions seem to have been tried and failed, please don't hesitate to bring that issue to the committee. We are honestly always happy to have new issues that are things that we really ought to be looking at. We've had a problem in the past at various times with people bringing us piles of issues that were one person's desire to drive some thought or behavior into the project that clearly was not technically motivated or not going to work in the majority view or something like that. We've had other issues like that. But in general, we are all completely willing to look at legitimate disagreements between developers about technical issues where they for whatever reason are not able to resolve them themselves. Just beware that when you invoke the big hammer that is the technical committee, we don't swing it lightly and we don't often swing it quickly. Right, I agree with that completely. If you look at, occasionally, I come across randomly in my work, I come across some bug reports and I look at this bug report and I think this is very strange. Why, you'll read the bug report and it's full of people who are obviously completely at loggerheads and there are a substantial number of people who think, for example, the current behavior of the package is wrong and we've had a very small number of ordinary bug reports where the maintainer thinks it's not a bug and several people think it is a bug. And as a rule of thumb, if you've got like three or four people also in the bug report log who've clearly explained to the maintainer what the problem is and answered the maintainer's questions and so forth and you're not making traction, you should consider whether maybe the technical committee should be asked to give a second opinion on that. I actually have such a bug which I am meaning to refer to the technical committee. I seem to be a source of new bugs for us lately. I don't know what that's about. Yeah, but, but... As long as you close as many as you bring. It's okay. Well, that one I would have to abstain from, so. I think we should have a toy and then for the finish because we have not even five minutes signed. Well, just quickly then, I was just gonna say I've been reluctant to refer bugs to the technical committee because I'm not sure when they'll be dealt with. And if, I mean, it's always somehow time sensitive. And in some case, I'd just rather get a wrong answer as long as it's an answer. Well, actually what also has helped in my experience was in the past that in case I have answered such bug reports like, I really think you should do that. It has been often done, so sometimes it even helps to hint at the committee member on it. It does need to report to the committee. If you want to do that because it doesn't involve decision making. Depends a lot on what the nature of the question is. If it's a simple, do it X way or do it Y way technical thing, then there's a good chance that fairly rapidly we can all weigh in with an opinion whether we actually come to some kind of an official vote on it or not, you would at least then have the opinions of the various committee members of what their initial reactions were on record and maybe that's helpful to you. There's certainly nothing wrong with bringing an issue to the committee and then deciding to take it back again. If you go, oops, okay, now I know what the answer is. I don't need you to run the slow machinery of terrible progress anymore, then that's okay too. So again, don't be afraid, particularly if you have questions. Don't be afraid to approach any of us, the ones that are here or the ones that are not here. Ask us questions. We are all people who care deeply about this project, who have immense personal investments in time and energy over the years. And if there's something we can do to help anyone else in the project do a better job, be more effective and happier with the results of your work, we'd love to try and do that. Thanks very much for your time and attention.