 to have a opportunity for interaction, hopefully reasonably informal interaction between those of you from the project who are interested and the members of the technical committee who are present. Let's start by introducing ourselves. I'm BDL Garvey. And Keith Packard. Ian Jackson. Ross Albury. Colin Watson. Steve Lungeshek. Great. So what I'm going to, so in fact, we have present today a six of the eight current members of the technical committee. Andy Parth could not be here at Dubconf this year and Don was here over the weekend. I understand that I didn't actually get to see him. I understand he's taken off for another event this week. It is Burning Man Week after all. So for those of you who don't, is there anyone who is sort of completely clueless about what the Dubian technical committee is? Okay. There's always a straight man somewhere there. Thanks, Rocky. The technical committee is defined by the Dubian constitution and it has a fairly limited but significant role in the project. There are four to eight members at any given time appointed by a combination of the sitting Dubian project leader and the current members of the committee. Section six of the constitution covers sort of what the behaviors of the committee are expected to be. It's important to understand that the focus of the technical committee is supposed to be on technical policy and in places where action might be taken are things like developers' jurisdictions overlapping and an inability to come to a resolution on which of multiple technical alternatives is the best one to go forward with. We tend to only act when we are explicitly asked to engage in a particular decision process. The committee does have the authority to overrule a developer, though as Steve was pointing out in another session yesterday evening, there's an interesting little loophole where it does not appear that we have the ability to overrule a delegates decision, which means that some infrastructure-related technical decisions could be interesting for us to deal with. We have the right to offer advice in addition to making sort of... But only the technical committee has that right. Sorry. Yes, yes, yes. I think the point is it's possible for us to engage in a conversation with developers and provide some sense of wisdom without necessarily having to make a decision that requires a vote, but this always gets a little weird. There are a couple of interesting sort of limiting features. One is that according to the Constitution, the committee is not really supposed to engage in the design of new proposals. Members of the committee, of course, are also developers and may very well be very involved in helping to design new solutions, and it's almost impossible for a group of technologists to discuss any open question without postulating, wouldn't it be nice if we had a third alternative or a fourth alternative or a fifth alternative? So this is an interesting one that we can be challenged a little bit sometimes in our discussions to remember. And then finally, the technical committee is supposed to be a decision of last resort. In almost all cases, it's better for Debian if the decisions are made by the developers who are working on the particular piece of technology. And in fact, Steve was commenting this morning. It's interesting that we've had a few cases in the last year where issues have been brought to the committee or to some subset of the committee informally or otherwise, and we've been able to provide some advice and things have been able to happen without actually having to bring a formal issue in front of the committee for specific action. That's all cool. It's great. The point is that we're trying to help and to help deal with situations where the normal processes of the project just aren't cutting it. One of the things that we instituted a couple of years ago was actually a suggestion from Zach, which has worked out really well. So we meet roughly monthly on IRC to discuss the currently open issues and go to each other on to do things about them. Don Armstrong has been running those meetings, manages an agenda that we maintain in our shared gift repository. And the minutes of all those meetings are available somewhere. I'm not sure where you look for them, but they are around. And of course, anyone who'd like is welcome to hang out with us on the appropriate IRC channel at the right time and watch the discussion. Over the last year, been kind of an interesting year for the committee. There are five things that were sort of officially brought to the committee and got resolved since Deb Cog from Vomarku last year. That started with adding a new member to the technical committee. Keith was not a member of the TC in Vomarku last year and is now. That concluded a fairly long process, which I must apologize was made longer because of various things that were going on in my life. But we did eventually conclude and we now have a full eight, which is the maximum number of members the committee is currently allowed to have another constitution. I'm sure you'll all be shocked to hear that we spent a little bit of time on our NIP systems in the last year. There was then a follow-up issue that was brought based on behaviors coming out of that decision. We recently finally got around to voting on the question of what the default libJPEG implementation for justice should be. And I put on here as resolved, even though it hasn't actually had a closure email yet, this question of what the appropriate this is of alternate dependencies on non-free things in Maine. We had all eight members of the committee have now cast votes. The result is no longer in doubt. But given everything that was happening in the run-up to Deb Cog here, the closure email on that hasn't actually happened yet. But that's at this point, I think resolved and okay to put on that list. There are four issues sort of officially before the committee right now. The first two have actually been on our list for multiple years. The first one started as a proposed constitutional tweak to fix a technical committee supermajority issue in the Constitution. Given the events of the last year, that has not surprisingly now sort of exploded into I think six-ish about six sub topics all relating to the membership of the committee, what the terms of the duration of terms of service on the technical committee should be, how the tech committee chairman should be chosen, how there's a bunch of logistics things about the committee. There's a suggestion that changing the Constitution to go from eight to nine members, having an odd number, might reduce the frequency with which the casting vote, which has now been used once, might ever have to be used again. All of those are good things. All of them are the sorts of things we want to get right and not rush into. So I'm sure there'll be a lot more conversation before we wrap that up. But there has been a lot of progress on that. The list of decisions on the web page being incomplete, someday somebody will sit down and actually back to that, maybe. There's an open question about menu systems. This has to do with the devian menu versus the free desktop.org menu specification files and why we have sort of two different ways for specifying GUI application menu entries. There's a draft proposal that Keith put together that we've had, I guess a couple of rounds of conversation about in our monthly IRC meetings. There's certainly some more work to do before we're ready to take that to a vote, though I think. And then, relatively recently, the question of the maintenance ship of the aptitude package has been brought to us. And it's been some conversation about that. I don't know that I at least feel like we're very close to any sort of specific decision on that. I guess before we just open up to questions from the floor, is there anything that any of you would like to add in the way of comments about either the things that got resolved in the last year or the things that are open right now, or should we just open up and see what people want to talk about? Okay, so with that, we're open to questions. This mic is loose. I don't know if we have another one in the room or not, but if you would like to ask a question or have something you'd like to say, procedural, technical, whatever, raise a hand or something, and we'll be happy to take questions and converse about things as long as we have time. Questions? Oh, come on. I'll go ahead and I'll vamp for a little bit while. Oh, we've got a questionnaire in the back, and I'll talk as I deliver the microphone. So one thing I'm interested to know... Yeah, one thing I'm interested to know from this group, just as an informal poll, as B Dale mentioned, we did discover that there's an unintended consequence of the fact that so many people are now delegated into their roles in Debian, which is now we've found, and the Secretary has actually ruled on this as a constitutional interpretation, saying that we in fact don't have the authority as the technical committee to overrule delegates in their decisions, which means nobody does, as far as I can tell, other than like doing a straight GR every time. So I'm interested to know, maybe we can get some discussion about that here, but I'll pass the mic first to see whether people think that's something we should fix. How elaborate do you prefer the questions forwarded to the technical committee? Because I have in mind the question of LibAV and FFMPEC, and would you like to have the bug report with just these two words or some reasoning? Because I think this question is imminent that it has to be decided, but... Sure, I think it really helps when the tech committee doesn't have to go do a bunch of investigation that other people already know. One of the reasons LibJpeg took so long was that we had to go, well partly because we were all distracted with certain other extremely long threats, and partly because we had to go chase up a bunch of potential argument for one side or another that had not really been fully presented in the threat. And it's much easier if we actually have the arguments right there in front of us, and then we're not left trying to effectively work out what one side of the argument or the other might be on our own. So I mean if there's something that's causing a problem and it needs to be escalated, it would be better to escalate it sooner when it needs to be than to spend a lot of time trying to write up some kind of summary and have it agreed by everybody. This is particularly true if the thing is very political and very controversial. For a simple technical thing, I'd certainly encourage people to try and write up the dispute in some neutral, friendly, constructive way, but some issues that is more difficult in which case we really we're going to need everybody to put their own side, and in that case just filing a bug against the TC is probably the right approach. That being said, a little bit of expectation management here. The question that's being posed on Debbie and Devel right now is can we have, well there's two questions, can we have FFMPEG back in for Jesse, and can we switch between LeBaevi and FFMPEG for Jesse, and the Jesse freezes coming up. Prospects of the technical committee being able to resolve this in the absence of the wider developer community being able to resolve it on their own in the time required to make a decision for Jesse seems dicey. Also aren't both the security team and the release team delegated? They've only said they don't want both of them in. We could pick a different default without overwriting either team. In practice, while we may not have the constitutional authority to overrule them, our relationship with the delegated teams is in fact very good, and if we suggested to a delegated team that we would like a particular outcome, I think that wouldn't really be too big a problem unless we were completely mad and hopefully we're not. Yeah, I was mostly kidding on that. Hi, is it fine for me to just sit here? Okay, so Sam Hartman, I guess I'd like to really thank you for doing an excellent job over the last year. There's been a lot of mail on the technical committee mailing list, and one of the things I really appreciate is that there actually have been a couple of times when I see red when I read mail from I happened to have a different opinion on. Interestingly, not having to do with the NIT systems, but the thing is that I really appreciate that even then the mail is written from a heartfelt desire to constructively make the project better, and I am really happy at all of the things in a number of threads, especially the NIT system thread, but throughout everything where it's clear that you guys are trying to work together while actually understanding that there are some options that are unacceptable to some members of the TC, and that's okay. Thanks for doing a great job. Thank you. So there's been this trend of trying to organize more sprints, so people who get to meet face to face. I was wondering if, for example, for an issue that took as long as the NIT system, could flying all the TC together in one place would have shortened the resolution period? I think it probably would have done, but it would have other effects that we might not want. The problem we'd run into I think would be the transparency of that kind of thing. It would be problematic. We would have to video the entire meeting or something. Right. Right. I mean, that could be done. It would end up looking more like a UN Security Council session or something. We'd all be stood round a table and there'd be a microphone each, and when we broke for lunch, we wouldn't be allowed to talk about anything. We'd just have to talk about the weather. It says we're already not allowed to. Right. But if we wanted to make that a transparent process, we would have to go to those kinds of lengths. I'm not sure how much fun that would be. Also, some of us travel better than others. I'm not sure I really want to be flying around the country. I was going to say too that the fact that there are six of us here in one place at one time is actually fairly unusual. It's not that it hasn't happened before, but opportunities other than DEBCONF to get us all sufficiently motivated to put the rest of our lives aside, to go somewhere at the same time together, are really difficult to orchestrate, and I think it'd be very hard to do on short notice. The idea that something's getting, escalating to the point where that would be a good process to invoke and that you could actually get all of us to get together in one place quickly. It sounds like a great idea, and I'm sure most of us would actually be happy to try it, particularly if there were good food involved. At the end of the day, as frustrating as it can be sometimes to watch the process, and believe me, it's just as frustrating to be involved in the process sometimes, I have to tell you that the fact that sort of every one of us thinks about the issue about each other and so forth ends up being documented in an email thread that Don says now helps stress test the BTS. These are the sorts of things this generates. It's a documentation record for everybody that comes afterwards understanding how we got to where we were and why we made the decisions we did, and that degree of openness is really, really hard to even contemplate wanting to move away from. The other thing that I would add to that is that I at least think differently when I'm writing things up in email than when I'm discussing them in person. So I find it much easier to reach a shared decision in person in ways that are possibly not good because it's a lot easier to fall into sort of a group think consensus when you're all in the same room, whereas when I'm trying to write up detailed arguments on a thread, it makes me think harder. And sometimes I end up convincing myself of something different in the process of writing the argument. Yeah. And to summary, the arguments we have to present, there's kind of an essay aspect to the work we do to do that, which you don't have in the course of like a stand up sort of face to face spoken meeting. And that's useful in part for the transparency and part because it challenges us to articulate our arguments better. Other questions? Oh, come on. Let's let's use the rest of the time to work through the constitutional issues. We can just use the rest of the box to sit here and on display. We can talk through the constitutional issues. So I'd like to have some informal poll of my own. How many people would think that not having the tech committee would be an improvement? Yeah, I think no, in general, I mean, yeah. Yeah, so how would you like to do that show of hands? Good. What's the alternative? Yeah. Okay. Okay. It's a show of hands. How many people would prefer a Debian project in which there were no technical committee and decisions of last resort went to a GR? The others might not be in the room. That's completely fair. Yeah, I was going to say we didn't hand out rotten fruit in advance. I'm not sure how best to do this, but yes, right show of hands. How many folks think the current constitutional structure with the technical committee to make decisions of last resort is a good system. Okay. Well, certainly the folks in the room, that seems So I guess maybe it's interesting to explore that a little bit. Do you feel that the technical committee, do you feel that way because you think the technical committee has made poor decisions that it's that there's a lack of legitimacy to the decisions that it makes? Or is it just because you like GRs? So I definitely don't like GRs, but I would also fear that the technical committee is, as a self-selected group of people, is not working as well as it could be. It seems like I fear that it's become more tempted to override people for something where it's their area of responsibility. There are the choice that they've made. You might disagree with the choice, but I mean, I think even if you disagree with the choice that somebody's made, and when it's their area of responsibility, the threshold for saying, I disagree with you from saying that two, I overruled your decision should be higher. That's a perfectly valid point of view. BDEL, can you put the list of decisions from this last year back up? Right. So this does not include us having overruled anybody. The previous year, we overruled Gilliam on Multi-Arch. You could argue about whether LibJPEG, we didn't actually formally use the overriding PAR, but it was kind of sketching the edge of it. Well, I mean, that was like two camps. There's the LibJPEG TurboCamp and the LibJPEG 8Camp, and it's a bit, there's a difference between us saying, well, we're going to overturn the status quo when really there are, it's not really obvious that the LibJPEG 8Camp just by having got there first. I mean, maybe you disagree, but it doesn't feel like overruling to me. But the Gilliam's Multi-Arch thing was probably the biggest decision we took in the previous year. The Network Manager was the most contentious decision that we took, and we did overrule there. Now you can, maybe that's what the kind of thing you're thinking of. The decision with the biggest impact on the project was the Multi-Arch decision. Having looked at what's happened since, I think we were, I now think we were probably right to do that. It's not completely clear, but I'm not unhappy that that's what we did. I also wanted to add, you know, I mentioned when we were talking about the open bug about the supermajority fix and so forth, that that's now popped into about a half-dozen subtopics, and a couple of them are specifically about the composition of the committee, whether there should be something like a term limit on participation in the committee. I think the current best idea for managing the chairmanship of the committee was the notion that the committee ought to elect its chairman every time there was a change in the membership or composition of the committee. There are a number of things like that that are currently, that we're currently discussing that might sort of affect the other side of this, which is how do you know that the committee remains sort of vital, responsible, connected to the project, and all of those sorts of things. And this is why I say I don't think we're really quite ready to vote in the large on exactly what the constitutional change should be, because I don't know that we've really gotten to the end of the thought process about how that should work. Inputs today or at other times about, you know, you're thinking about how that should work, particularly if you're willing to go look at some of the discussion we've had, particularly in our IRC meeting logs, about this topic, and let us know what you think of some of the proposals that are floating around. The sort of how people get on the committee, you know, whether it should be a more elected kind of thing, or whether the current process of selection remains the right one with some tweaks around sort of term limiting kind of things or not, I suspect is another topic that we could have some really interesting conversation about. But I would suggest that you think about both sides of that. One side is sort of the how do decisions get made and how does overruling happen and so forth. And the other is the sort of how do you actually decide whether you're able to trust that the people making up the committee, you know, are sort of doing the honorable thing at all times. And those are, I think, both reasonable topics for us to have lots of conversation about. And regarding the actual matter of overruling of maintainers, I know this is a common sentiment. Nobody likes to be overruled. Nobody likes to see their peers overruled. But there's two points that I think we should look at there. One has been pointed out the actual frequency with which overruling, a true overrule happens. And the other is the aspect that even having the question come up is very psychically draining for a maintainer or a developer to even have to go through that process. And yes, when that happens, it's not good. However, the technical committee does not, as a body, initiate that process. Those things, the questions of overruling a maintainer only arise because some developer is concerned that the wrong decision has been made. It's probably also worth pointing out that the only times this ever comes up are essentially when things have already gone badly wrong. You know, somebody is very dissatisfied enough to crank the process up to 11 and bring it to the tech committee. That's maybe been a little more frequent now than it has been in previous years. But it's generally not obvious that doing nothing would be an improvement. There's always some project-wide or at least very large contention involved before it gets anywhere near us. So we essentially only deal with things that are already in a bad state. One more quick thing I wanted to say on that topic, though. The other problem with that whole, with all of that is that while overriding and even discussing an override is hugely psychically draining and hard for the people involved, the other side of that is that not having a decision is also psychically draining. And so one of the things that hopefully the technical committee helps with, and I think that our track record has been mixed in part because it takes us so long to make decisions for other good reasons, is that if you reach some sense of closure, sometimes that's better even if you lose. Right. I mean, what you don't see interestingly on that is we get quite a few incoming issues of one kind or another where the submitter is agreed somehow and usually just like one member of the technical committee writes back and says, really, we're not, we don't think we're going to overall maintain on this. This is just this, you know, you haven't explained what the problem is or this isn't serious enough or whatever the situation is. And essentially that really, you know, that helps the maintainer to not have to deal with that issue anymore because essentially the complainants routes avenues have been closed off. But there's another thing I wanted to say which is, you know, we don't like being overruled. Debian, of course, in theory, we put the needs of our users first. And what that means is that as a maintainer our responsibility is to our users and if a maintainer is failing in that responsibility, it's the responsibility of the project as a whole to set them straight. And obviously that's not necessarily a pleasant experience for the maintainer but most of us are users too, right? So we've been on the other side of a bug report where the maintainer seems not to be listening and behind each one of us who's articulate enough to have a, you know, to try and have that conversation with the maintainer and who understands the process well enough to deal with that, there's probably a bunch of users who are upset and don't know what to do about it. Yeah, fair enough. Yes. So I'm Anuj and I have one comment and a question. The comment is that being overruled by a GR is probably worse than being overruled by the technical committee. They are far more relationship damaged if you are overruled by a GR. So the question that I have for the TC is in the past one of the reasons people didn't bring things before the TC was the lag time before the decision could be reached. I understand that while I have been missing things have improved because the TC never used to have that many decisions in a year. Very true. Is this something that you guys are considering streamlining or are there ways that we could reach consensus faster? I mean flying people together was one of the ways that people are proposing getting there but if that's not the answer what else is. So actually as I mentioned earlier, Zach's suggestion and coupling I guess was actually in Banya Luca that we had that. I think it was then that we had the conversation it took a little while to get started but this business of having a monthly IRC meeting has been I think really helpful because it causes all of us to have sort of a pseudo deadline once a month to go remind ourselves what our action items were and decide whether we have time to do something in the last hour before the meeting. If you grasp my activity, Edward. But honestly I think just reminding ourselves on a regular cadence of what issues are open and where they are and who said they do what who hasn't gotten to it yet and should somebody else try to pick that up has been really helpful. So concretely things have improved if you come to the TC now with a decision that's not enormously politically charged and where most of the TC members agree one way or the other you'll probably have a decision in a month or two or maybe three. Now that sounds like a very long time but given how long it takes to make any other kind of decision in Debian, particularly a decision to change anything, that's that's kind of lightning fast by Debian standards. So and we have sometimes been faster we you know we've managed one week. So sorry a number of things accumulated. One I guess I don't, secondly what Manoj said, don't discount the possibility that the reason you're seeing more overrides is that you're actually effective these days and that basically it's not that people are being more litigious it's that issues that people wouldn't would have just taken the hit to say I'll never get this fixed. I have no recourse they're realizing they have recourse and I think that's a good for the project. Number two I don't know how I feel personally but BDL asked the question of, or no I guess Steve asked the question of should we should the TC be able to override delegates? I'm still pondering this but here's a devil's advocate argument for why not which is that the important thing or an important thing from a government standpoint is to have a check and balance on individual decisions to help keep them in alignment with with the project. For individual maintainers there isn't really a check and balance besides the TC and peer pressure. GRs are an option of even last resort but they're really heavyweight. But for delegates there are a couple of check and balances. First of all we tend to delegate teams rather than individuals. Second of all while the while you can't be undeligated, while the DPL can't revoke it, can't you know do something because of a decision your track record can be considered and whether delegation is removed and so there are other checks and balances and you know it would be and it would also be good from a government standpoint not to have a body having too much power. One thing that would be interesting to look at is do a retrospective on some of your issues that you raised and how effective it has been. I will call two to mind. One is network manager. You know I'll note that there was a lot of effort and hard eggs spent on network manager and yet the way it ended up pretty much you get network manager if you install Gnome and it really is kind of hard not to get it and it's still the case that you can get into situations where your networking doesn't work. If you install a system and you know network manager thinks it's supposed to be managing it and yet there's net etsy interfaces involved. I've actually seen particularly on live DVD installs getting into some kind of impressive network manager fights with the rest of the system issues. So you know was it actually worth the pain there and I don't know what the answer is but it might be worth going back and thinking about that and then I'll get on system D. You know it's really hard to install a system without a Jesse system without system D as PID 1 if you install any significant set of software and I don't think that was quite what was envisioned during the discussions. It was exactly what you asked. No no no okay excuse me I'm sorry I'm sorry Ian. I do not believe that that was what the people voting for system D quite envisioned at the end of that TC discussion. Yeah right um okay but but okay but anyway um and one final note is you talk about how painful it is to override a maintainer. There are skills in terms of empathic communication and working with people to actually communicate with them in less painful ways that it actually would probably be worth the TC spending time learning. Because we actually as a project could work to make disagreements less painful and you as leaders could help lead the way. Interesting thoughts Sam thanks. Yeah it is not I don't know if it's true. Is that working? Okay cool. One one one comment on the system D thing and like what's happened subsequently um well it was something that we discussed as a possible thing that could happen during the discussion. I at least was completely surprised by the speed at which canonical essentially moved away from upstart and that significantly changes the the what it looks like going forward in the archive for multiple net systems because that was like the other big one right. So I think that some of the some of the reason why now it looks like system D all the time was because canonical made this decision like almost immediately after the decision and Steve probably has more insight into that but that was at least to me that was that was significant surprise. The reason it looks like system D all the time is because of some of these questions of how good does the compatibility have to be for things like log in D to allow it as an alternative have led to the desktop systems which do require a D bus interface which is provided by system D and they're pulling in system D by default. We're at the point today where I think even now testing I think if you install known it pulls in system D as PID 1 and there's some some a little bit of work that we may have to do to to clean that up yet. I don't know exactly where that stands I think I think system D in the in the archive in testing has the necessary or dependency but that the version of system D shim that has made it into testing isn't at a level that provides that compatibility so that's actually that's that's my fail for not following through on that and I'm working with the FTP team to fix that. Can I can I stand up and have a show of hands can I do it? Sure go ahead. Okay um my name's Martin I just wanted to follow up on something that Russ said earlier um he I'm gonna quote you not verbatim but he said that sometimes closure is worthwhile to work for and you don't necessarily need consensus for everything. I would like to put you in a situation that we are in we are a group of people that are volunteers and working on a common goal. We also have a technical committee that we have all voted early on to be the sort of like neutral objective body to make final decisions in case we can't come up with them. I would really like to see a show of hands in this very representative crowd of the Debian project um between what you would really prefer if you had to choose one of the two. Option one being endless discussions until you have until you have consensus which we have been known to reach so this is not a garden path dead end it's just going to take a long time and option two realizing at some point in time that this is going to take a long time so deferring it to a committee who then makes a decision that not everybody likes but brings us closure all right there's only two options for the discussion you you you ratified the proposal further discussion is part of the proposal a so can i see a show of hands uh for those people who would prefer option a which is long discussions until you have consensus what i'm doing is voting for both options this is a bad question because the reason that you have the technical committee is that you hope that these people are sensible enough to strike a balance between those two options so there is no question they're there to decide what is the right balance between those two extremes actually if you modify the the proposal one for martin are we yeah we're taking amendments instead of a going for an absolute consensus if we decide to go for a rough consensus instead where you don't need to have absolutely the last project member agreeing uh that might be more reasonable than discussion until everybody is convinced as the newest member the technical committee um i was a little unaware of the long history of the process the technical committee and i was uh the in its system debate well i think contentious within the committee what's the one for so we only have one minute left okay faster faster okay um while it was very contentious i think what it raised within the technical committee was the notion that the technical committee itself does not have to come to consensus to resolve an issue and that our existing voting process was sufficient in order to come to closure um it didn't make everybody happy but i think if the technical committee would take a more uh principled view on using uh constructing a vote and taking a vote and calling the issue at an end when issues are clearly not going to be resolved quickly that we could make process we could make progress more quickly oftentimes we do spend a lot of time in the technical committee trying to generate total consensus among the technical committee and for some issues that makes a lot of sense but i think we need to be more aggressive in taking votes instead and getting to majority or rough consensus as minors says instead of trying to get to a total consensus of the committee and using our existing process to resolve issues more quickly with the with by coming to rough consensus or even just majority seems like a process that we should be using more often rather than less often okay well i think with that we really are just about out of time i have one thing that i wanted to say to in response to sam which is um sam mentioned the network manager we mentioned system d and i think that a thing that has really disappointed me over the last couple of years in the attitudes of some of my colleagues is um their position towards the defense of minorities in debbie and by which i don't mean you know blacks and gays i mean people who choose a decision that is unpopular and recently we've seen a lot of those communities losing out and i'm hoping that this won't carry on okay well with that i think we really are out of time thank you very much for being here i know that most of us are going to be around for at least part of the week we certainly would encourage you to come find us have more conversation ask questions this discussion the technical committee processes etc don't stop at the end of this meeting they keep going so feel free to stay engaged and help us in any way that you would like to thank you very much for your time and attention