17:08:51 #startmeeting 17:08:51 Meeting started Thu Jun 26 17:08:51 2014 UTC. The chair is Diziet. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:08:51 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:08:54 #topic Who is here? 17:08:56 Ian Jackson 17:09:05 Keith Packard 17:09:12 Steve Langasek 17:09:59 Colin Watson 17:10:17 OK that's everyone who has been speaking recently. 17:10:17 #topic Next Meeting? 17:10:26 Normal schedule would seem to be 24th of July. 17:10:37 Or perhaps 31st. 17:10:56 * bdale is here, but on the phone .. will have full attention here shortly 17:10:58 Oh I see my diary already has 31st pencilled in. 17:11:28 Do we want to schedule a meeting during Debconf and do we want to do that after seeing the DC schedule ? 17:11:29 yes, the 31st seems to already be on the calendar 17:11:31 * bdale is trying to arrange internet service for the new house .. /o\ 17:11:42 bdale: Congrats on the new house. Good luck... 17:11:47 scheduling one during DebConf> well, it's the right time of the month 17:12:02 I think we should deal with that at the next meeting on 31st. 17:12:09 Diziet: I haven't done so yet, but was planning to request a TC BOF at Debconf as usual 17:12:18 So next meeting is 31st same time at which we'll discuss timing of a TC mtg. 17:12:30 #action bdale to request TC bof at Debconf 17:12:44 Diziet: sounds fine to me 17:13:05 #agreed Next meeting same time 31st of July 17:13:13 #agreed Discuss time of meeting during Debconf on the 31st 17:13:16 as was already in meeting.ics 17:13:21 #topic #717076 Decide between libjpeg-turbo and libjpeg8 et al. 17:13:33 Is there any more to be said about this ? 17:13:39 If not I will just call for a vote after the meeting. 17:14:39 Sounds good to me 17:14:43 OK, good. 17:14:48 I think it's fine. As I said thanks for picking up the ball I dropped. 17:14:52 NP 17:14:53 #topic #636783 constitution: super-majority bug 17:14:59 Oh I forgot 17:15:05 #agreed Diziet to CFV on #717076 17:15:17 * bdale is ready to vote on the jpeg issue 17:15:41 I doubt anyone has had much of a chance to read my text in detail. 17:15:49 And we should leave some time for -vote to comment. 17:16:06 My main question here is the grouping one. Which of these changes can be combined. 17:16:45 I saw that there was an email with you on this, glanced quickly, but haven't had time to read it yet or consider, so no opinion from me yet on groupability 17:16:57 OK 17:18:01 03Ian Jackson 05master 9ca30e7 06debian-ctte 10meetings/agenda.txt meetings/agenda.txt: add two missing constitution items 17:18:01 03Ian Jackson 05master 77aabaa 06debian-ctte Merge branch 'master' of git+ssh://git.debian.org/git/collab-maint/debian-ctte 17:18:08 Let's go onto the other issues quickly then. 17:18:13 #topic #636783 constitution: casting vote 17:18:40 It seems that there is quite some opposition to involving the DPL. We should probably just go with expanding the TC to 9 then. 17:18:49 Unless that is also controversial. 17:19:07 Russ wasn't too keen on it in comment #200, apparently 17:19:37 I disagree with him on this; while mathematically it's true, my feeling is that most of these kinds of issues (god forbid we have more ...) are likely to devolve to two competing standpoints 17:20:04 Also he is just wrong. Our rules don't permit the casting voter to deal with condorcet cycles; the Schwarz sequential dropping is done first. 17:20:14 So you still only use the casting vote when there's ties. 17:20:38 "No (unequal) defeats within the Schwartz set" 17:20:56 I like the idea of expanding the ctte to 9 in any case, fwiw 17:20:57 I should say this in email really. 17:21:01 OK. 17:21:24 #agreed Move forward with proposal to expand to 9. (agreed amongst those present) 17:21:35 #topic #636783 constitution: minimum discussion period 17:21:35 9-member ctte resolves the simple problems in a simple way, without radically changing the dynamics 17:21:53 keithp: right, my feelings too 17:22:02 I know we don't have consensus on this. And I have just sent a proposal, so people probably want to read it. 17:22:10 yes, I'd like to read first 17:22:15 OK. 17:22:21 #topic #636783 constitution: TC member retirement/rollover 17:22:50 We seem to be agreed that this is a good principle and are arguing about details on -project. AJ and I have proposals. 17:23:21 I'm not current on -project 17:23:40 Just a handful of TC-related messages in the past few days. 17:23:49 I've been trying to remember to CC #636783 17:23:50 ok, will try to catch up later today 17:24:12 No-one seems to be objecting to the direction, anyway. 17:24:16 #topic #636783 constitution: TC chair retirement/rollover 17:24:18 I'm in favor of limiting terms, but ultimately this has to be decided by the project rather than by the CTTE so I haven't felt the need to stick my nose in 17:24:24 vorlon: Right. 17:24:37 #topic #636783 constitution: TC member retirement/rollover 17:24:48 discussed in the same thread? 17:24:53 vorlon: Do you think it's right for the TC to sort out the details and propose the final text ? 17:24:57 bdale: Mostly, yes. 17:25:18 Diziet: if the TC doing this doesn't require my active involvement, sure ;) 17:25:24 vorlon: Heh. 17:25:36 The TC chair thing I have only just posted although iirc I mentioned it on irc last month. 17:25:54 I see the thread, haven't read it yet 17:25:56 Does anyone (notably, bdale) have any objection to the principle or any comments ? 17:26:10 since, as I said, I'm not up on -project atm 17:26:14 The principle being that the TC chair should be reappointed occasionally (eg when a new member joins the TC, or periodically). 17:26:28 The TC chair thing I posted to #636783 but only recently. 17:26:28 I agree in principle, yes 17:26:31 OK, good. 17:26:38 I think we can sort out the details by email. 17:26:45 seems likely 17:27:25 #agreed TC member retirement good in principle, details to be worked out on -project 17:27:39 #agreed TC chair retirement/reelection good in principle, details to be worked out in email 17:27:44 #topic #681419 Depends: foo | foo-nonfree 17:28:02 We've now had opinions from vorlon and myself who seem to be the opposite corners. 17:28:10 I've read both 17:28:11 I don't think I have anything to add. 17:28:13 I don't think there's anything more to discuss on this, just voting :) 17:28:21 i agree, we can vote on this 17:28:33 concur 17:29:04 Diziet: Your last mail on this didn't make a difference on foo | foo-nonfree, foo | foo-external and foo | foo-no-longer-existing, or did I miss that part? 17:29:09 vorlon: Does the text in A of cjwatson_draft.txt express everything you think it needs to ? 17:29:55 checking 17:29:57 ansgar: Uh ? I'm not sure what your point is about foo-no-longer-existing. The problem is with mentioning the names of nonfree programs. There is no problem with mentioning the names of free packages that are simply gone. 17:30:22 vorlon: The B text LGTM. 17:30:31 Diziet: Ah, I read the "external/nonfreefoo" as "anything not in main". 17:30:39 Diziet: yes, I'm happy with the A text 17:30:48 vorlon: OK then, shall action you to CFV ? 17:30:54 sure 17:30:56 OK, in that case I miraculously did a good job of representing both positions and we should just vote :) 17:31:06 #action vorlon To CFV on cjwatson_draft.txt, A vs B vs FD 17:31:12 #topic #741573 menu systems and mime-support 17:31:35 keithp: Did you intend your draft to be ready ? Because as I say in email I think there are some loose ends. 17:31:54 cjwatson: PS well done :-). 17:32:23 Diziet: I was looking for feedback on the resolution bits; the informative bit at the end is not relevant to that, of course 17:32:38 keithp: OK. So you want to keep refining that. 17:33:27 Diziet: I'll clarify what I expect a transition plan to look like, in particular 17:33:46 #agreed Continue to discuss keithp's one-menu-system text in email. 17:33:50 keithp: OK, good. 17:33:51 Thanks. 17:34:04 Is there anything else we need to say about this question here ? 17:34:08 the basic gist is that the 'menu' package should read .desktop files as well as menu files; that gives a transition that works, I think 17:34:15 keithp: thanks for getting a draft done before this meeting, btw 17:34:39 * keithp implemented macosx/windows/.desktop/.menu systems for one application to figure out how they worked :-) 17:35:18 Shall we move on ? 17:35:24 yes 17:35:26 #topic #746715 init system fallout 17:35:55 I think I replied to this one in email already? 17:35:57 Right. 17:36:09 So unless anyone has any objections I will CFV after the meeting. 17:36:14 works for me 17:36:50 #action Diziet to CFV on #746715 with text as sent last night 17:36:59 sorry everyone; watchimg the us game with almost no network 17:37:03 dondelelcaro: Ah hello. 17:37:08 #topic #750135 Maintainer of aptitude package 17:37:16 dondelelcaro: Hope you don't mind me usurping your role... 17:37:31 We have a fundamental problem with these "problem maintainer" complaints. 17:37:37 no; thanks for running the meeting 17:37:44 We have been struggling to find a good approach to dealing with them. 17:38:02 Last night I had a brainwave: how about we have a more formal process ? 17:38:07 util-linux is kind of the same. 17:38:10 Yes. 17:38:21 (For which I'm conflicted because I know the maintainers, but anyway.) 17:38:41 Eg when we get a report like that we would see if there seemed to be a case to answer, and if so we would publicly solicit references to publicly documented interactions with the maintainer. 17:39:57 After a defined period of time we would decide between (a) the existing maintainer should carry on (b) the existing maintainer needs help (c) the existing maintainer needs to be replaced. In cases (b) and (c) we would then invite further comments including volunteers. 17:40:54 (publicly solicit references> Which perhaps might be sent by private email to a TC member who would forward the reference but not the identity of the forwarder.) 17:41:00 Or some such. 17:41:41 Diziet: would that be better than the current "process" of grubbing through existing email threads for instances of such interaction? 17:42:08 keithp: At least it would avoid us having to do so much of the grubbing. 17:42:17 And it makes the process more open. 17:42:29 We also need to make sure that there's a clear avenue for the maintainer to respond; in past cases we've seen cases where people felt that the process was a bit of a lose-lose for them 17:42:39 soliciting for additional information would be good; I think I'd still end up searching on my own and adding to the list 17:42:59 (I have about 10-15 minutes.) 17:43:09 Also separating out "is there a problem" from "who is volunteering to help" will avoid the problem that no-one wants to volunteer and then find the TC leaves the existing maintainer in place (a maintainer who will now think ill of them). 17:43:19 cjwatson: Indeed 17:43:25 i think at least asking for patches and specifics is a good first step 17:43:29 cjwatson: do we want some kind of real-time tribunal to let the maintainer address the TC? 17:43:32 If this seems like a good general idea I will write up something specific, and hopefully we can try it out in these two cases. 17:43:39 we've also suffered when the maintainer felt there was nothing good that would come from commenting 17:43:46 I notice that Daniel Hartwig hasn't responded yet 17:43:48 keithp: I think it would be a good idea to invite the maintainer to do so. 17:43:54 bdale: Right, that's pretty much what I meant 17:44:24 keithp: Maybe. Some people do very badly in that kind of situation in ways that don't reflect on their qualities as maintainers 17:44:29 But maybe it should be an option 17:44:30 without naming names, at least 3 other of our toughest problems in this case involved maintainers who were technically strong but where communication style issues caused problems 17:45:02 3? 17:45:03 so, while I'd love to believe putting a more regular process in place would actually help us here, I'm not sure I believe it's really going to help 17:45:03 I would like to explicitly say that a maintainer can email is privately. 17:45:22 vorlon: I mean 3 previous complaints about maintainers of different packages 17:45:33 bdale: yes, I'm trying to think of more than 1 17:45:41 The thing I'm always cautious of in these kinds of situations is that I think one of a maintainer's most important and difficult jobs is saying no 17:45:49 (In appropriate cases!) 17:45:49 cjwatson: Indeed. 17:45:58 So I don't think "saying no" is EBW. 17:46:09 Diziet: yeah, some way of letting the maintainer contribute without leaving them exposed 17:46:10 But not saying anything is a problem. 17:46:34 keithp: well put 17:46:37 communication mediation is clearly a place where "we" can help 17:46:57 Indeed saying "yes" or "no" is basically the one thing a maintainer _can't_ delegate (passively or actively). 17:47:05 ctte counseling services 17:47:10 more or less 17:47:47 in reality, it's a lot of what we end up doing on a lot of the issues brought to us... in the past, many cases seem to me to have been as much about communication breakdowns of one kind or another as any other root cause? 17:48:04 Yes. 17:48:41 Clawing back to the aptitude case, the ... plaintiff? ... has already presented us with some specifics; I guess we need to see some examples of disputed patches which we can consider, and hear the maintainer's side of the story 17:48:41 Diziet: I recall you having explicit mediation ideas in the past, which we've talked about in Debconf TC BOFs, etc 17:48:58 bdale: Yes. 17:49:08 It's difficult because of the no-private-discussion rule. 17:49:10 cjwatson: yes, it's far easier to tackle these things when we can think/research in terms of patches that are in question than generalities 17:49:44 Diziet: hrm .. you've mentioned that "rule" before .. remind me what you think the basis of that is? 17:50:01 6.2(3) 17:50:11 contrast (4) 17:50:17 ITYM 6.3(3) 17:50:21 Err yes 17:51:08 so, sure, I personally interpret that to mean that we don't make any "decisions" in private, but I've never believed that meant we couldn't have private conversations 17:51:27 bdale: it does include 'discussion' 17:51:40 which seems pretty broad 17:51:58 Hence 636783_supermajority/propose-informal 17:52:07 but discussion has a meaning in the context of our decision making context, I don't believe that word in that para was meant to mean we can't sit down over lunch and have a chat without recording gear 17:52:21 if so, it's ludicrous 17:52:40 Some people interpret it that way. 17:52:40 Oh, you interpret "discussion" as in A.1(1)? 17:52:54 Constitution needs more capitals. 17:52:56 yes 17:53:16 Leaving that aside, I think in practice we won't get pushback if we more explicitly invite private commentary about maintainership. 17:53:24 I've always assumed "discussion" in this context mean the process leading to a ballot 17:53:40 which isn't at all the same thing as talking about a pending issue, conversing with people to find out what they think and what we can do, etc 17:53:52 I understand that others might interpret this differently 17:54:14 so I'm not *negative* about the propose-informal thing, I just don't think it is necessary, or should be necessary 17:54:41 Diziet: I agree 17:54:56 Do we think it's a good idea for me to propose some kind of structure for answering #750135 and #752400 ? 17:54:58 I expect it'll be pretty uncontroversial and we might as well do it to eliminate doubt. 17:55:03 (propose-informal) 17:55:20 Diziet: so, I think in the specifica case of aptitude, we should invite a private statement from the current maintainer, to be shared amonst the ctte but not published 17:55:24 Or to put it another way, does anyone have a better idea for how to go about answering the questions ? 17:55:31 keithp: OK. 17:55:40 well, having looked at the issue a bit deeper during the course of this meeting 17:55:49 it's not clear to me that Daniel is "current maintainer" anyway 17:55:52 Perhaps we can do these two in series rather than in parallel so that we can see how it works ... 17:56:13 vorlon: it is pretty murky 17:56:22 both Daniel and Manuel are marked as uploaders on the package; Daniel has apparently revoked Manuel's commit access to the upstream repo but not changed the uploaders field 17:56:31 ick 17:56:52 so while it's appropriate for the TC to arbitrate, it doesn't look like one is more of an incumbent than the other 17:57:00 and it's a non-native package so upstream access doesn't necessarily mean packaging access 17:57:17 right 17:57:21 vorlon: Would you mind putting that in an email ? 17:57:22 im nore 17:57:43 Diziet: ack 17:57:49 So in this case we should probably regard the two as disputants rather than putting one on a pedestal. 17:57:50 concerned about the non public work that is apparently happening 17:58:09 in series> Is either of these urgent ? util-linux might be urgent if we want a new version in jessie. 18:00:25 both are important packages that need to be well cared for, but I don't think the TC treating them as "urgent" will necessarily improve the outcome 18:00:52 I don't know that either is "urgent", but I hate to let inter-personal maintainer issues fester if it's getting in the way of functionality we'd like in our next release 18:00:56 I have to go I'm afraid. Handed the childcare baton while Kirsten goes to karate. 18:01:11 OK then. So I should propose some kind of process which we will refine and/or try out on #750135 and revise/drop/use for #752400 ? 18:01:27 cjwatson: Thanks for your contributions. 18:01:28 ttfn 18:02:04 process> Including the maintainer perhaps providing private response to us, and also perhaps an irc conversation ? 18:02:18 sure, I don't think we have anything in particular to lose by trying! 18:02:52 #agreed Diziet should propose some kind of process which we will refine and/or try out on #750135 and revise/drop/use for #752400. Including the maintainer perhaps providing private response to us, and also perhaps an irc conversation. 18:03:03 Now we have two dupes in the agenda (which we dealt with earlier). 18:03:05 and 18:03:08 #topic Additional Business 18:03:37 Anything else ? 18:03:56 not here 18:04:13 I'm good. Thanks for running the meeting, Diziet. 18:04:19 thanks guys 18:04:23 NP. Thanks everyone. 18:04:26 #endmeeting