 Hello, everybody. This is the boss to meet the technical committee and The technical committee is formed currently of eight people four of us are present here I guess most of you know All of us but this who is mr. David Brevner It's a left for him. Hello Philip hands Some people that we do really care about but they're not here to say hello, which are Marga, Manterola Simone Simon McVity the year about Nicotine they cannot be here today the conference. I am Boonard Wolf and The technical committee has had many many other members in the past and We thank them all and There have been we will talk a bit about the interesting things that have happened So well some may be wondering in fact my main motivation for calling for this session and for well inviting my colleagues here is Is that we want people to get involved to know what the technical committee is and we will maybe to join us at some point in the future a So the technical committee is outlined by by the Constitution Section six of the constitution Defines what the technical committee is and can and cannot do basically The technical committee can decide on any matter of technical policy Decide on any technical matter where developers jurisdictions overlap Make a decision when asked to do so Tie-breaking overrule a developer So that means a if a developer is doing something we can tell them that's not a right thing to do That's a last resort measure and just to offer advice If you want to please say say anything I'm skipping just Now the technical committee is also bounded by the Constitution a The discussion has to be public. So of course like like many other deviant teams, we do have a Private channels, but everything that we do must be supported in in public discussions and decision-making with the technical committee doesn't go into details when outlining a solution no detail design work and The technical committee is seen as a last resort so if something doesn't work out between people between developers a Technical committee can get involved. We are asked to break the ties among the available options and After after alternative options have been tried and failed So we can offer advice to you to any developer who asks That and that's precisely what what what we're currently doing that our Will get to the two bugs. We are currently working on so the technical committee is a self-nominated a board Well a group that is the technical committee asks the DPL to have members to it It's DPL appointed its last resort and it's a body for conflict resolution and advice providing So what do we do? What have we done in this last year? Well, most of our productivity has been Adding adding members and deciding who is the chair We do that via box in the web tracker in the in the past year. We have had two technical decisions So both decisions are repealing all their decisions by the technical committee because well the reality In different parts of the project has shifted. So for example This this first one there was a very long thread Some of you will remember about whether nodes could be no name node or had to be no JS Because there was another thing called node. Well, the technical committee had decided a long time ago that the JavaScript Node had to be called node JS, but now that the other package called node is gone the we we repealed that past decision most of the things well the committee is providing Points of view say qualified points of view. So in this last year we we closed four bugs without a formal resolution It was not needed Consensus was found and accepted by the developers. So we have these four bugs again. I'm not getting into the tails Currently we have two open box. We will be discussing both were opened within the last two weeks and Well, they are regarding the policies print that well is being spearheaded by Sean Whitton Regrettably has other activity at this same time But well, we're discussing whether vendor specific patch series should be permitted in the archive and What should happen when a maintainer script fail to restart a service during package installation or removal? Okay. Well, I'm missing there because I'm at the very bottom, but The technical committee has a limit a time limit of three and a half years for the permanence in it so well Simon and me were the last ones to join our term will expire at the end of 2021 and Well from the rest of us and well tolef is currently the eldest one here. He's About to leave the committee at the end of this year as well as the year was our past chair The the rules for it aren't strange, but well anyway So every year we want to get around one or two new members It's not that we need it Constitution states that the committee can operate with between four and eight people. We are currently eight so But we want to get new people to enlist to work with us to volunteer Work is not that contentious or that hard We did have a well before I joined the they did have a really really hard time deciding the system You wouldn't want to go over it again. It's a really really nice way to to stress test the backtracking system It's probably the largest bug in the entire BTS It's a rather large park. Yeah So Well, even though the name is technical committee the work is mostly social and It's about solving disagreements as much of the things we're currently discussing at this We are talking broadly about technical things But more deeply about how to solve social issues listening to people sometimes taking some decisions it's mostly a political thing and Well, we're looking for people with these qualities, right people with empathy technical agility mentorship responsiveness social sensitivity sensitivity and we're cool headed even in a word whether like we're Having no we need more diversity. That's that's true. That's a fact We I am very happy. I guess you will join the feeling of this that were a our current chair is Marga Which well brings brings some diversity in into a well mostly male mostly everything the project But we need more diversity. We want different people Say we don't have anybody from this part of the world or things like that We're looking for people to nominate themselves. So Either yourself or somebody else if you think about somebody who could make a good committee member Please nominate them. We're friendly We are available. We want to hear you. We're just people developers. Just like you and of course we want to improve processes And well, that's that's it for the presentation. I'm joining the rest of the group for for your questions Have you Have you ever gone anywhere with the road map? initiative I thought we decided that we shouldn't be in the road map initiative didn't we Yeah, that's my yeah, I think our opinion was that if we wanted to be involved in the road map initiative We do it as individuals not as a commit not as a committee Has anybody else gone anywhere with the road map? I don't know. Okay. That's great personally That's going to me is a bit too top-down, but you know, everybody can have their own opinion. That's why I'm not involved with the road map maybe Why I'm why are you here? Why are you in this session? What interests you to learn from the technical committee? Please people I think the monkeys care So since you don't ask any questions, I'm going to ask questions of the audience What are the barriers for you to bring things to the technical committee everything is great for you? You have no conflicts no differences of opinion That's great. If it's so and please say so so that the world knows everything is great in Debian otherwise I'd like to know because There's not too many things coming to us, which you know is okay. I'm lazy, so and Also, I just made a terrible bug in my C code, which I could work on instead But so please tell me Even if it's only hypothetical for you, so what might prevent you from? bringing things to the technical committee Am I supposed to answer for everyone or I guess? In my personal opinion I think the there's a history of having the projects go to the technical committee and either not finding a resolution in a reasonable amount of time or The universe exploding and so I think a lot of people have scared of Putting things forward to the technical committee. I Think this has changed We've like the for instance the term limits and everything so that's like a lot of new blood coming in regularly but Yeah, I don't know if like we have a lot of inertia in the way we see things in the project, so Maybe it will change with time I hope I think we're all pretty committed to dealing with issues Quickly if we can if there's any way of doing that So if it's if you if you imagine that it's going to be nine months of aggravation or silence That probably won't happen We might say I have a tendency to say To people that I don't think the boat justifies going to the technical committee because I think that can quite often be said very quickly indeed and Still leaving an opening for them to come back and say no really Because there are some bugs, which will clearly either Lay dormant forever or get closed and you might as well close them straight away That's the only reason I do it if if people Think I'm wrong then please just Try again So you shouldn't I've done that a few times recently Don't take that as we're just trying to throw them away Some bugs Haven't been ready for the technical committee when they were submitted I think one of the things that people don't use enough is the advice capacity of the technical committee We always use the technical committee as like the Supreme Court of the DeVion project And yeah, I I think the like constitutional Requirements that people go forward to ask the committee for advice Instead of the committee just coming from the top and saying hey, we think that maybe you should do things like it like that Could be relaxed a bit, I don't know if it's a sensible thing to do maybe Maybe maybe not. I don't know I think Since I joined we have had a quite low activity in fact At least three monthly meetings have been cancelled because we didn't have any box open which is good Which is good a bit boring, but it's good But say We have had and I think it's a good resolution after all One bug asking us to review the whether we it was right to do the change of the Init system of course and that's asking the technical committee for a resolution our resolution is no that's not our job So but but I think it's okay to just come to do to this body and ask Whatever irks you with the project probably we will I mean look into it if it's within what we have to do probably we will not but and We're currently answering two questions regarding policy Well in the same way the policy maintainers say hey, what's your opinion on this so they can have a backing to do a policy change They actually haven't asked for advice. They've don't get to the decision to us, which is slightly different You're both correct There's two bugs and one of you is correct about each of them So I think one thing That I hope can change is that people feel like having a bug forwarded to the technical committee if you're the maintainer and Somebody disagrees with you and forwards a bug to the technical committee people see that as a very negative thing and I Think we should think about Why There certainly are aspects that are negative and we should try and change those and We should also make sure that the perception isn't worse than the reality so Because it's a bit unfortunate if it's a way to get people to orphan their packages by Filing bugs with the technical committee, right? That's the systems not working. Well at that point collectively part of it You know is the way that things have happened as what I mentioned in the past, but And part of it is you know interpersonal things in the project are always a bit tricky, right, but I Don't know if there's things that we can do as a committee. I think we talked about being timely and Maybe talking to people early in the process I mean, we've had various sort of informal consultations about conflict issues Which is sort of on the edge of our formal role, but I think it's helpful And if we are really, you know, have to get into lawyering about it We can say we're doing it as individual developers, right? I mean, but I mean conflicts don't get easier to solve as they Develop, right? People's positions become hardened and they become angrier and Less rational. I know I do So a question Anything to shut me up No, in fact not David you mentioned that people might often packages as a result of of decision of the of the TC so Has the seventh and in general are you as a TC following up after your decision? What happens after a decision has been taken by you and published how this how this continues and what the Consequences of the decision that that you have published. So so what I said actually so we'll come to your question a sec but to clarify people often Their packages Sometimes Because not because of a decision the technical committee makes but because someone asked the technical committee to make a decision They just find the process sufficiently daunting so It's hard to make a decision that will make them happy and in that situation But I guess maybe somebody else wants to answer the your real question, which was do we follow up or maybe not? So I mean we do right? I mean and but it is also In a sense up to the project as a whole to say okay, or I mean usually if you bring something to the technical committee and There's two parties and one of them gets their way typically, right? I mean over simplistically, but and That one is going to Be interested in whether this decision is implemented or not and can bring the lack of implementation To that to the attention of the committee if it doesn't happen. So I think there's sort of a built-in I don't know maybe other people I mean there's subtleties that I'm missing here But of all the things that we might be screwing up. I think that that's probably not one of them I haven't really seen a big Need for it like in a formal formal way because partially because of that and partially because if the TC decides something then maintainers Don't actually go around undermining that by failing to implement stuff I think if they did then we would have other problems So I Normally get interested in the the actual problem while we're looking into it And so I quite often carry on looking at it afterwards So, you know very informal way. I sort of follow up but I haven't made a point of it so if decisions are Where about things that I'm really not interested in then I probably wouldn't notice if They became toxic afterwards. I don't know Well, I am happy and that's one of the points I pointed out in the presentation Which I must say it's basically a copy from what did they're presented late last year. I am happy that most of the things that have been decided were not a formal decision, but Was helping rich consensus So if both parties in an argument say, okay, this is no longer a problem because we have spoken to her Well, we don't have to follow through because it's done. I Have something from IRC Helmut has made a comment about why people are reluctant to Actually put things forwards to the committee He's saying that he's experienced twice that he has put an issue forward to the committee and by the time It was resolved. The issue was obsolete Not how long ago was that I Don't know I know I know that was a problem or at least a perception problem I don't know with the committee long time ago. I think it was less than a year ago, but I Don't recall exactly. I think we will get back to you with the answer I think it's a fair comment. It will always be something we need to watch to make sure that the committee is or to Try to make the committee as responsive as possible. I mean as you know everything in Debian happens According to people fitting it around all their various responsibilities but Generally people who join the committee Join it knowing that for some periods of time, they will have to Try to really make an effort to be responsive to Committee stuff so it was more than one year ago. So maybe it got better Maybe I mean I think it's a look we're part of Debian, right? So we run on Debian time just like the rest of the project and But it it's also true that it's a time-sensitive Thing so I think if you report an issue That's caused by someone doing something just as we go into one of the harder Freezes freezes just before a release then the technical committee in the past has certainly not been responsive enough to do something useful before the release happened so I Guess we just need to Notice that that's exactly what's going if that happens again. We'll have to make some sort of precipitates We've only got two days to decide this type decision It's better to make a decision than now than to make it the right decision later and Just deal with it straight away because there's certainly been more than one issue in the past where That situation has occurred and just by you know someone's effectively won their case by default Because there wasn't time to deal with it so yeah, it's it's not crazy for submitters to Explain the time aspects of their request when they make it also help us understand what the issues are Yeah, that's quite often people Assume that we're going to instantly see their side of the argument and there's no need to explain it really and If you do that, then we all go. What is this thing that they're talking about and it takes ages so if you have a good argument set it out and Possibly point out the other side of the argument a bit as well and make sure that there's Clarity about what the issue really is and then that is an introduction to the other side to make a decent argument back If it's just this person's rubbish and You need to tell them to stop doing that It's much more difficult to do anything useful in a short time Helmut has been saying that he agrees with Gunnar What you said makes a lot of sense I have another question from IOC Which is about one of the cases that just arrived in your inbox What do you think about allowing Fendo specific batch series in a source package? I Think I've made my position pretty clear that I think it's a really bad idea to allow that interview. I Haven't completely formed an opinion yet, but I'm leaning towards That I don't see a good argument in favor Of these patch series. I mean I or rather I haven't found the arguments presented so far to be convincing my my initial reaction to it was that seems like a great place to hide malware and It would need a pretty strong argument to keep them given that Because I haven't really noticed them previous to this so Someone needs to come up with that argument, I suppose I'm in line with the positions they presented and well I should say nobody has spoken for for the The vendor specific patch series so far besides the person that that brought up the the topic So I mean I cannot say state I cannot foresee what we will end up deciding but I don't see this will be a very contentious argument We're basically waiting for other people to talk and I guess that within within within this say one month period. We have between a IRC meetings, I hope it will be closed What's the question also about the other case or was he starting a question about? No, only duckies as far as I can tell at least I'm really interested in feedback from developers in general on the init scripts thing Because that seems quite subtle to me so if you know a lot about an it scripts, please read this bug and It educate me for for those who haven't read the bug It's basically should what what should maintain the scripts to when restarting a demon fails Should I fail or should I continue? I mean, yeah, there's no clear position But but we do have the problem of a as there is no clear answer We have a unpredictable outcomes Sorry, I'm I'm not asking about the question. I I just want to ask about how do you make consensus because I think the most violent argument I remember now is the upstart in the system the argument and it ends up that We have a My love to vote which one is the best? maybe not the best of which one has the most involved and So so in in general How do you discuss that and make it says normal cast all of you in the community or agree on someone? something or For this is simply easy. It's our kind of really corner cast that That we have to fall to make the decision That there's no room for discussion Yielding the microphone because I wasn't part of it. I Wasn't there either. I did watch quite a lot of the discussion. I think mostly people submitted Quite detailed descriptions of why they thought what they thought and tried to persuade one another and in that particular instance People were not persuaded so it came down to a vote but the way we more often do things is that We don't normally have to go into so much detail because it's easier to come You know, if everybody agrees at the start, you don't even We don't even vote normally or we we do a Because we have to Yeah, I think there have been instances where we don't haven't voted Yeah, because it was completely obvious that everybody agreed with doing a particular thing, but so if there's some sort of split then people start justifying their positions and The more that happens sometimes people change their opinions and then the the disagreement evaporates Yeah, in in general you try to to make the disagreement disappear by understanding why the other person holds their position and and in some cases, it's generally because you have like the world looks different from different places, but quite often it's just because you know it's it's fairly easy to align on on a world view which is This is the set of trade-offs and this makes more sense to do it that way than that way. I was thinking well Of course people will will bring this this topic of the system the decision and will probably keep bringing it up in future Years, but the thing is I'm thinking of it as something more broad I mean no, I don't remember so kind of such a Discussion or backlash when red had to do the same decision or when well many other distributions did May maybe what happens is that? We do have an open decision process people Everybody wants to be part of such a relevant decision that changes the world the Linux landscape for good but the thing is I mean the same decision was taking in so many places that Say we were recently asked Whether we should review that of course we unanimously said no, we don't want to review that but I think hundreds of other distributions are Okay with the with the path taken I think the the premise for the Asking us to review it was completely broken is the reason why when when there was a disagreement in the technical committee It was between whether that we should switch to an upstart or to system D It wasn't whether we should stay with sister being it or I mean open Rd was a long third So at this point, I think it's you know with the benefit of hindsight I think it's pretty clear that upstart wasn't going to be a great choice because where's upstart It it got event. I mean it got killed off by by upstream basically when we decided to switch. Yeah, but also, you know Upstarts had severe problems for quite a time and The original developer we don't have to talk about yes, I mean we don't have to But but that's the reason why the question was wrong when it was presented to us again because the question was asking it was if As if going back to Cis via knit was an option and it was wasn't an option even then that wasn't on the table So it was between two choices one of which isn't there anymore Open RC was was way behind though. Wasn't it really are there any more questions? I Shouldn't have started that. It's okay. It's system D I think the real problem actually is that people think that they are You know that Debian is theirs everybody in Debian thinks that Debian is theirs So that's why people didn't complain in red hat because red hats just you know like milk or something It's something they buy and that's not that's great No, that's really good, but that's why people get upset, you know, you don't get upset about The person that manufactures your tires changing the ingredients or something You still want opinions in the peanut gallery on what should happen when main scripts fell to be sort of service? Yes, I do. Okay. I guess like so broadly like obviously like the reason Isn't fun committee and reason that you know Nobody can really decide what which way to go is because like it is sort of implementation specific like rather It is going to be deployment specific maybe some cases where you absolutely do care and you want to fail And that's going to be something you're going to notice and then be able to take action on in other cases You know give two shits, but I think that said the default I suspect the answer should be it should cause a failure just thinking from the context of I am setting something up and see I'm sending something up via like chef or whatever and I say install those package and expect to be configured one chef one successfully Maybe you say I should add up like a check that after we install this package We know then do some health check to make sure it was both installed incorrectly configured, but I think it'd be less surprising If Like that install failed because the ended result of the service running didn't occur And then this sort of goes back to Debbie and this ethos of like, you know on by default if you install something it should be running and We of course we that's not Appropriate for every deployment. So we already provide mechanisms for you to say in when installing packages don't serve the service But I think that in the same way it would be reasonable to offer a tunable But I think that default should be to fail So it's sense It was a coach in Sofina. Yeah, it made sense I'm not yeah, so without saying yes, we agree. Let's decide it looks way But no, thanks for the the cogently expressed position Anybody else have similar different opinions? We still have ten minutes It's not that we have to squeeze every last minute of the session if there's no more questions. Well, there's Perfectly was time to have some more coffee. So thanks to everyone for coming and Also to people who are watching the stream and on IRC and hi helmet And we're looking forward to your nominations for the tech committee, of course. Yes, please think about it Yep, we are short on candidates. We want you or would want you to nominate your friends or a No, really nominating your friends is great because if you've got if you're in some little Nook of Debian where most people have never heard of what you do even and you know That there's one person that is really good at solving arguments between the rest of you guys then nominate them because that's the sort of person we want and they will broaden the the diversity of the The committee probably because they're not from the usual suspects of people that keep on turning up to debcom and and all that so if you're doing some strange little bit of Something which nobody's ever heard of and there's some very wise person that you can point out then nominate them in in terms of actually how much time it takes it's not very much we say that We ask people to reserve like an hour a week in practice. I find it it's less So it's in terms of actual workload. It's not that much Okay, I suggest everybody leaves now Bye