 So good evening everyone we have four members of the technical committee with us tonight for a technical committee buff, so Let's get started Thank you very much For those of you who weren't here earlier don't know who I am. I'm BDL I currently serve as chairman of the deviant technical committee. We have three other members with this Present in fact, let me go ahead and change the next slide. It's the current membership of the committee I thought Steve like check was going to be here by now and there are rumors that emails from him are flying around So a plane may have landed somewhere or something. I don't know But I'm here Russ Albury and Donna Armstrong are not here this year Andy's here Ian and Colin and as I said, I think Steve is on the way, but I haven't actually seen him yet So this is the current membership of the technical committee. I guess the change from Last year is that Manoj for Vastava chose to step down from the committee I think we all thank him for his service to the committee over the years We are of course considering Possible new members for the future. We'll talk about that in a little bit To just sort of set context for those of you who don't think about these details all the time The existence of the Debian technical committee is defined by section 6 of the Debian constitution these various sub-pieces Sort of provide the context and the authority by which the committee exists and in some ways bound what the sort of desirable and appropriate areas of activity by the committee are a couple of things that I think are worth Pointing to out specifically are the fact that 635 sort of suggests that it's not really Within the technical committee's purview to be designing new proposals That doesn't mean that members of the technical committee can't be themselves coming up with new ideas or Contributing to group activities that lead to new proposals But the real purpose of the committee when it boils down to you know sort of the simplest form Is that we're here to help? arbitrate and help make decisions when developers Working on software or other things within the project cannot decide among themselves what the right answer is and that's really Sort of the focus of what the technical committee is about So unlike in some projects where there's a lot of decision-making that happens on a routine basis By some overarching technical body in Debbie and our constitution sort of inverts that Responsibility if you will and the vast majority of decisions are assumed to be owned by and made by individual developers working on The things that they do for the project and it's only when those developers come into conflict and need help resolving Questions that the technical committee generally becomes involved Having said that we have over the last year or so been trying to have Semi-regular IRC meetings. I think approximately once a month though. They don't always go off as planned These are not Necessarily where big decisions get made But they're an opportunity for us to remind each other on the committee of what the open action items are To discuss informally what progress we've made working on the various issues and in effect To sort of poke each other to see who volunteers to take the lead on taking the next steps on some things And one of the consequences of that that I'm very pleased about to report on is that this year The list of open issues before the committee right now does not include anything that was on that list this time a year ago And that's actually the first time in several years that I've been able to say that we had a couple of long-standing thorny ugly problems that nobody really knew how to or wanted to deal with and Those have all been resolved. So the issues that are the five issues that are actually open in the bug tracking system before the committee this year are You know all essentially sort of current things and I feel pretty good about that with that that's really the the sum of the Sort of presentation part of what I wanted to do today to provide a little bit of context with four of the now Seven of us here and the possibility that Steve might show up at some point This is an excellent opportunity for any of you have questions about any of the open issues opinions on things want to understand how the Committee thinks about things what we're what our thoughts are on some of these matters or whatever to ask questions And first to have an open discussion. This is meant to be a boff not a presentation So at this point, I'm going to step down from stage join my colleagues and the chairs over here We've got a mic that will pass around and there's at least one here that Will be used to take questions from the audience. So who would like to kick things off? Come on. Don't be shy You didn't all come up here just because it's a prettier place place to sit Yeah, Keith I'm supposed to have a question now. I just came up for the view No, it wasn't exciting was disturbing. He said Are there are there a pending issue? Do you have a queue of issues that you're looking at that you think are going to become things that the tech committee needs to Resolve what kinds of things are looking like they are becoming issues within the community? No, we don't have a list of things that we're kind of holding off on putting on that list That's the list of the things that we know are on our plate I'm sure people have their own ideas about what things might be turning up at the technical committee Formally or informally we had a bit of discussion recently about the whole system D thing, but I was about to ask That It doesn't seem to congeal yet into the kind of question that Anybody could decide on and I think that's one of the reasons why we keep having these conversations Well, and by the way the technical committee doesn't just act because we think we need to act So we only act if if be there shows a list of things before so if developers couldn't agree on it People could ask us to make a decision say could do or similar But we're not just doing a decision because we think it might be an issue that needs to be decided So unless I asked later on in that process. I don't think we're currently Very active which has the wind us from looking at the things Right, and I think specifically with regard to system D and upstart the the parties involved are still actively throwing coded each other and Until it gets to the point where either somebody wins or they feel that They've reached utter impasse and there's no further way that anything can develop I think that's that would be the point when When it would be brought to us and I divided hope that it doesn't Yes, so generally Things are brought to the committee because there's an existing bug in the BTS that someone You know that people are getting in an argument over how it ought to be resolved or something like that And those bugs get reassigned to us Occasionally somebody writes a new bug submission as a way of crafting a question for the committee But generally when that happens It's an indication that it's going to either be something that's only marginally within the tech committee's responsibility or That it's going to be particularly difficult to resolve the things the questions where we're the able to sort of act I think the most expeditiously is where it's a question of you know Yes, or no on this particular patch set or this particular You know intended change The last one on the list here is actually sort of an interesting example that somewhere between Some of those things and the sort of system D kind of question in that We were sort of asked to help make a decision about which of the JPEG library Implementation should be the default one that lives in the distribution and this is a case where you know the initial set of questions that we fired back At the parties involved. We're all around You know are we really to the point where we can sort of pick a or B or are there in fact things that would have to be Implemented or something first to have a complete solution in place part of the reasons not completely resolved yet is at least in my mind I don't think we have a complete set of answers to those questions yet though Maybe it's just because I have been a little distracted lately, but In looking at it This has led to a very healthy discussion where people are pointing out What other distributions are doing there's discussion about what the technical basis of the distinctions between the different implementations are Appointing to conflicts in external standards bodies that lead to you know matters of interpretation about what the right way to proceed is and so forth And that's all exactly the kind of you know sort of helping to muddle through the What in the end is sort of a combination of a technical choice bound up in you know Which of two forks of a of a project we ought to be paying the most attention to kind of thing that I think it's Useful for us as a committee to try and help with but As Colin says you know when you're in a situation where people with competing Ideas or competing proposals are still sort of you know rapidly throwing code at each other It's not time for us to be involved If we had our choice most such decisions would be resolved by the developers in question and never come to the committee Yeah, I just wanted to expand on that a bit So the JPEG one at least in principle is something where there's a specific Technical change that the TC could decide to do one way or the other it amounts to the ownership of Lib JPEG dev The package name and you know what JPEG library you get if you install that and there are a whole bunch of consequences that flow from that but there's actually a clear Underlying technical decision to be made and the the system D1. I think one of the reasons why the The argument keeps turning up again on Debian developers because there's a lot of fear about what might or might not be done And I know people you know worried about this and people pushing their various agendas But there's not actually a particular technical change that somebody who is in charge of something as a maintainer or that the technical committee as a arbitration body could Could decide on there's nobody is proposing Oh, well, we will make the following specific changes the following packages To achieve this objective at the moment people are still talking in woolly terms about Throwing this in or throwing that out or making everything the default or making everything mandatory and It's it's not really at an actionable decision and I'm personally I'm hoping that Before we have to have another conversation about the merits of one thing or another We might get to the point where there is actually two different Technical things that might be done and then we could have a question about which of those was better Right, and if now if you look at the last issues that you have with lip JPEG What we're actually doing is there we can't decide but what we're doing is to get to Place where we know okay. What are the benefits of which solution so that we actually could do a decision and We have this lip JPEG. We are near to that place with with a let's say this system D or whatever discussion we are far more away from it and Driving something to that place can actually be done by the developers in question. It doesn't need to take a committee, but Yeah, we could try to help there if necessary, but it's not something with a special on us But just special on getting things done in a way said Everybody would understand what it implies and means So I would say then next question so currently the release team sorry the Technique committee gets into action only if explicitly addressed So would the committee see it's all a bit more proactive if Well, some kind of development is stalled within Debian Two examples for that The one is architecture re-qualification. We had that addressed last tip conf nothing that happened We did have it addressed shortly after the we see release until now Nothing much did happen. There are a lot of teams involved with that and I think Something should happen, but nobody tries to do something the other thing is I'm a bit stuck with my proposal about verbose build blocks which Teams everybody seems to be in violent agreement about that But nothing does happen. It's stalled and It would be nice to base some further QA work on that so General development would help so the question again Could the technical committee a bit more proactive for kind of these things? Okay, I will just start with the first question As some of you know I was member of I'm still a member of the release team I was a release major a few years ago So who does do this decision which architectures are in Debian and with this architectures Debian releases The first question which I textures are in Debian in the archive is done by fdp masters in second question Which architectures are part of a release are done by the release team? So I think those are the two bodies of Debian who have the first say on that if someone disagrees with their decisions Of course, it could be escalated to the technical committee Obviously like with other technical decisions people don't agree with being a certain patch was ejected by maintain or whatever else But I think one should give them the chance For the state aside first and what I have seen is that the release team is at least currently Still in the let's say Post release mode where they're trying to get the thing starting again for the new release. However, I Personally wouldn't expect decisions on which architectures are fit for the next release or not within the next few months Just because they are currently again Getting things summed up My personal expectation however is said I think we are going to lose one or two architectures said we're already Sharp on the edge last time for example currently sparked doesn't run well on our build these Kernels that we have in stable and just was a current old stable So I'm not sure this will go will have another release cycle just as an example Yeah The I think on the on more general point of whether the on proactivity of the tech committee The question I would normally ask is is it going to improve the situation for for us to do that so In the case of verbose build logs, I will I'll join in your violent agreement as a developer as a member of the tech committee I would question whether Coming down from the mountain on on the on the matter would Actually get things done or just make people feel like they're being steamroller steamroller and instinctively push back so I would I think my my recommendation for ways forward and that is I Think I've I've seen a Lot of general recommendations that we should be doing x y and z but not generally patches to that effect and I'd probably suggest patches wait a month or two followed by NMU campaign Pursuant to the usual rules and that sort of thing is probably likely to get things done more effectively and Annoying fewer people in the process than by the technical committee coming down laying down tablets of stone matter that that's specifically the case with a with a thing like the verbose build logs where Really very few people if any I've seen no Discussion from any be suggesting that this is a bad idea Everybody seems to agree that it's at best neutral and a lot of people are in favor So it's not really the case that there's a disagreement for the technical committee to resolve there's just some undone work and Like anything in the project if there is some undone work that is bothering you that it's not being done There's a very simple solution to that Yeah, I mean, I think there is I think there are one or two glitches, but there is nothing major at this point So the constitution reads that the technical committee can be asked for advice and the past I haven't seen this being invoked very often. So can you give an example of when to ask the committee for advice and How to do that because I don't think it's been done by creating a bug Right. So The way that has mostly happened up until now that I'm aware of has been through Informal processes usually not asking the committee as a whole for an opinion as much as seeking out Individual members of the committee and asking their opinions on things We have had a few cases in the past where someone sent an email to the committee's email list Saying, you know, this is not something that I feel compelled to file a bug about at this point But I could use some advice and we've had a couple like that Ian has actually I think one of the drafts that you've got up right now is related to making a more formal You could describe this better than I am making a sort of more formal assertion of what the mechanisms are by which we can have Sort of non-binding open conversations about things like this or I Think you're referring to the proposal to regularize Private communications with the committee So it doesn't happen very often, but particularly sometimes people have, you know Technical things get mixed up with interpersonal things and at the moment It's very difficult for the committee to deal with that in a in a kind of properly aboveboard way because According to the Constitution, we're supposed to do everything in public But it's very difficult to have a conversation about whether we should replace somebody as a package maintainer or indeed to mediate At an early stage when things are going badly wrong if everything, you know If everything has to be out in public in particular if you want to go to the committee and say I'm having a bit of trouble talking to this particular maintainer, you know Can you help like help us out here? That would be a very valuable thing for us to be able to do Because then we'd have a history, you know, if it does come to the crunch and we have to decide On a package maintainership. We've already got some kind of experience dealing with the maintainer ourselves and It doesn't immediately escalate the whole thing to a big public slaying match It can be just you know, I think we're having a bit of a misunderstanding. Can you help us out? Which is a very Useful thing to do so One of the things that I've suggested is that the Constitution should be changed specifically to allow us to have those private Conversations not private decision-making, but at least private communications In a sense, you can't really stop people doing that and we as committee members We've occasionally had emails sent to somewhere or the committee at our private email addresses And this doesn't seem like a particularly good way of carrying on and in the best will in the world You have to respond to these emails in a constructive manner So it's just a bit Yeah, thanks for clarifying that Ian So in the case where what you would like is advice on a technical issue as opposed to you know Problem dealing with some individual in the project Then I think sending an email to our committee mailing list is probably as good as anything In terms of getting the entire committee's attention Certainly while we're here at deb con for those of you who are here This is an opportune time to you know come find us casually in the hallways or whatever and get advice or guidance or input or whatever I know that you know part of the reason we all agreed to participate on the committee is that we all have an Intense passion for this project and a strong desire to see things continue to improve and get better And if a little bit of conversation about something will help you get past a technical hurdle or you know Help figure out the best way to do something where you're not in conflict with somebody else You just yourself could use some advice and guidance on how to do it Then we're more than happy to help with as much of that as you'd like to take advantage of us for I think I speak for everybody on that So there's one other thing I want to say about that It's not really in direct response to your question But your question was I think prompted by the the thing in the list of you know powers that the committee is empowered to give advice We often do that of our own bat if we are somebody comes to us with a decision Sometimes Either as part or the entire disposal of that is we'll you know the actual formal resolution from the committee will say and furthermore Our opinion on this you know our non-binding opinion is is this and that could be Useful as guidance to other people in the project and it can also be useful to people who need to guess what the committee might do in the future But in terms of You wouldn't really want to ask for that because the formal decision-making process for the committee of having votes on resolutions is quite cumbersome and not really suited to Easily giving advice, but if you just want if you just got some question and you want Either about a technical disagreement or just about a technical question. They're not sure of We can certainly help and just mailing us is a good plan Yeah, I have a gunna wolf in the IRC He says I guess when those semi-personal issues arrive to take the technical committee They should be redirected to DPR mediation Being the DPR a single person and be his boss most directly linked to social personal mediation I think I'd say that it would depend on the calls if it's If it's one of those things that happens all the time where you get a people people get really passionate about a about a technical dispute and it escalates into Either basically just calling each other names or or there is some kind of more deeply rooted Dispute about each other's working styles come up that comes up that sort of thing happens a lot and in that case Some sometimes sometimes we're best off just addressing the technical issue and not Actually trying to get every single person in the project to get along Sometimes it really is Something that needs personal mediation and I don't know that we've talked much about the interplay with DPR mediation But maybe we could ask them for help rather than necessarily just handing it all over to them And it also depends on what the outcome is or it needs to be if we notice that that conflict is already Broke in a ways if we need to decide for example about the ownership of a package We can't just forward it to someone else because we need to take a decision at the end Of course depends sometimes it's just best to tell those people and say please try to get Mediation instead of calling a 10 comedy in other cases It might not be that useful so I'm not sure I speak for my colleagues here, but I have a personal view on this so the the technical committee is empowered by the Constitution to make decisions about package maintainership and Many of these kind of disputes that might be helpfully resolved through mediation Ultimately if mediation fails need to be resolved by a decision about package maintainership and It's not really helpful to have Those kind of things come to the committee very very late When everybody's already You know had all particularly after a mediation attempt has already Been attempted and has failed because the committee then doesn't have any information to work on and what we have is a series of historical disputes about who said what whom when but the committee doesn't have hasn't had the experience of of Dealing with those people ourselves And so I think it would be most useful if the technical committee could take on more of that mediation role And this is something that we've not historically Done very much of for a number of reasons. One is there's this problem in the Constitution that we're not supposed to have private conversations which obviously is very difficult You can't mediate unless you can talk to people privately to both sides Secondly, there's as you say there's a feeling that the Maybe this is something that an elected person like the DPL would be would be better to do and Thirdly people just don't really ask it of us. Most of them maybe for the first two reasons So one of the things I'm trying to do with my proposed constitutional changes to make it easier for the technical committee to engage in mediation And that's not to say that the DPL mediation is a bad idea. I you know, I'm looking forward to seeing that hopefully produce good results Historically our in the project Procedures for dealing and processes for dealing with interpersonal problems and various other kinds of problems haven't always been very good and it's good to see us Trying out various different things I think about another question here Oh So next question, please. I think someone raised his hand before good It's not that true question It's just we have an idea when you will be able to make a decision on who you will appoint as a new member in the team Yeah, I have to take some personal responsibility for the fact that this is taking so long the Sometime actually last year we began a process of sort of looking for you know possible new member for the committee and they're actually multiple people in the room whose names were floated as possibilities for that and We started off by saying okay that all the people whose names have been raised We should begin by asking them if they would actually be interested before we go and have some long discussion and debate about who would be the right person to ask and the The responsibility to do that fell on my shoulders. I did that we got answers from everybody and then Things kind of came to a screeching halt for a couple of reasons that aren't important Then we got into a situation where As I said Manoj chose to leave the committee and that sort of distracted us for a little while And we started thinking again about this and then we had a DPL election and then quite frankly I've been a little distracted by the events in my personal life for the last couple months. So Without going into a lot of details or anything I will take sort of personal responsibility for the fact that this has been delayed for a while I think I think it is time for us in fact probably while we're here those of us that are here I'll talk about this some more, but in terms of actually coming to a decision. I don't want to try and Make some hard assertion about it, but it's back on my mind And we're all starting to think and talk about it again So I would hope we'll get through that process and actually invite, you know Additional member or two to the committee sometime reason boys in I think one should also be aware that this is nothing Nothing, but we need to have fulfilled a certain day and say we need it definitely because otherwise We're not going to continue working and what we definitely want to do is you want to find someone who really fits in who? makes our decisions better and it's a bit hard to It's not that we all say well. Yes, it's obvious this person's a list we're going to to take but Different candidates have different advantages. So We are still at discussing which I think is also quite important on that You say fits in or possibly doesn't fit in because one of the things that we could do with is more diversity in the committee So yeah, I agree with what Colin just said but also I mean I take a slightly different view about this I think it's quite unfortunate that This has taken so long and as a member of the committee. I bear some responsibility Along with the rest of us for having let this sit undone for so long And I know that you know if you've had your name put forward you naturally wonder What has become of this? Do we not like you? You know anything like that? No I'm afraid that really there's there's there's no good answer to this than that We're just being a bit crap about this and So our apologies Yeah, so I wasn't implying said I'm happy about the current state So if someone understood it that way it I'm I really think we should have been first and we are however it's let's say it's not it's not like said Said with other long-standing bugs that we had that people were fighting about how to go on with certain things But yes, we should finish this and I think soon as a better and fit in also might mean for me Is that we say okay? We have some of us in a different approach to things which helps us to make other sessions better So fits in is not like it looks the same like everyone Already on the committee. So I hope to have clarified that now a bit So next question Hello, my name is Michael Staperberg and I'm actually one of the system D maintainers So naturally my question centers around this Earlier you've said that there are still things that need to be done before we can actually make a technical decision about system D Whereas my current point of view is that we could just flip the switch So let me just ask what are these things that need to be done before? So Yeah, are you proposing you see the thing is that I'm missing is that you don't seem to be as far as I know We're missing a kind of concrete proposal in terms of are you proposing a patch to policy? For example Those materials I I haven't seen a proposed patch to the policy for example floating about is that If that's the stage that you think you're at Then I think you should write that up and suggest it Because that would give us something concrete to accept or reject But I really might suggest even if it's not not about your package Is that you look in the bug log of lip JPEG and see which kind of questions? We ask to get what we really need to be able to decide on and I think it's not only for us Relevant to decide but all is also for the project so just as a suggestion take a short look there and look at the kind of questions We asked there Okay, thanks. I think that clarifies it Good so next question. I mean this is for you to ask questions so Okay, what would be a good level of Frequency or number of issues to be brought to the technical committee I mean, do you think it's just happens to magically be perfect as it is or it should be used more Well, actually if you ask me, I will be happy if just ever the conflict with the soil before it takes to us Yeah, it's that's one of those questions. It's like asking what's the good rate of test failures? Right to a one sense the good rate of test failures is zero But if actually your test failure rate is zero it means your tests aren't working so You know if previously the rate of Referral of issues the technical committee was very very low indeed and that was mostly because everybody knew that nothing would happen We've been a lot better recently. We're making decisions More quickly sometimes very quickly I Think that's a good thing. I would encourage people who have had you know, if you have a problem that you think is is worthwhile and And that's not being addressed properly. Please do bring it to the committee and I'm expecting that We will have to go through a continued increase in Straightforward technical decisions a bit like the Lib J Peg one or the ones we've had recently And I think it would be healthy for us to deal with quite a few more of those So that because that exerts a kind of back pressure, right? If you're a maintainer and somebody disagrees with you having the possibility that The person was seeing we would will actually take it to the technical committee and you might be overruled will be a useful Thing that people might start to think about the moment That's not really something that as a maintainer I myself as a maintainer don't really need to worry about the idea that somebody would disagree with me enough to Take it to the committee and I wouldn't even get to vote on it myself. So Yeah, I think it would be healthy if we have a Higher rate than we have at the moment at least for a bit and if we start getting things that I think people should have been Obvious well when we have had a one or two things that were brought to us recently Where were the the answer was quite obvious and to be honest? It doesn't take a great deal of our time to dispose of something obvious I was gonna say that I think I Have sort of a split personality about this because on one hand My personal mental model is that you take things to the technical committee when there's a failure of the ability to make a decision That everyone can live with without Going and getting some higher authority to do it for you And so as a developer I'm much more inclined personally to want to you know Take a deep breath go off in a corner think about it and make a decision then I am to go sort of seek an Overrule from from somebody else So that leads me to believe that Having a substantially larger number of questions come to the committee would somehow mean that something somewhere else in our overall Project processes maybe was broken or not working as well as it could on the other hand as we've already talked about today I'd love to see a higher level of interaction between Developers in the project and the technical committee as a body and if that came in the form of Asking more questions or more advice on our mailing list or you know possibly taking advantage of us for You know some mentoring and mediation in a private context if if Ian's Current proposal that's being floated actually sort of wins its way all the way through the process or those sorts Of things I'd be more than happy to see you know us as a group taking a more active role even if it's not in the form of having more bugs filed against us and and answering more You know making more decisions that because other people are somehow failing to make more of the decisions on a regular basis Yeah, I would I would follow up I guess to that by saying I would like the I would like the number of issues that are brought To us to reflect the actual rate of failure in the project so if It it doesn't it doesn't seem to me that the number of things that are brought to us reflect the true extent of descent and While I would like there to be less descent I would also like It to actually be making progress The other thing is the the notion of back pressure is an excellent one. I would if if the result of that were that developers put more effort into explaining things coherently and Justifying their actions. I don't want developers to have to justify every single thing they do But when when things get contentious people ought to be putting in some effort and In if if the if the result of a more active technical committee was Developers having to put in a bit more effort to explain what they're doing then I think that would be good for everybody We we would like to avoid too much failure And so obviously we prefer when people don't have to go to the technical committee but I would like to suggest you maybe to get more to see it in the other direction maybe get more involved in the project on mailing list and discussions to avoid the Problem before they come to the point where you have to join. I mean if you look at what the rest does I mean is helping a lot in driving forward some important discussion or calming down when it comes down to problems and if one or two other members of the technical committee could do the same I Think it could really improve the atmosphere of discussion the important at least on even devil that's probably a reasonable criticism of of several of us myself included the I would like to avoid The perception that we're participating out some members of the technical committee and thereby sort of squashing descent or something But but yeah in general, I think that's right But I think we have just about two minutes left now, so if there are no similes left, so if there are no further The questions I think we could stop it. I think we could stop at this point if there are no further questions Be there. Okay Okay, well, thank you. Thanks And I will just reiterate that we're all here for the duration of the conference Feel free if you have thoughts later on to come by and grab us and ask questions or have more conversation. Thanks again so thanks the Dinner would be served in 15 minutes right on the other side