16:59:15 #startmeeting 16:59:15 Meeting started Thu Sep 27 16:59:15 2012 UTC. The chair is dondelelcaro. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:38 #chair bdale vorlon cjwatson rra Diziet aba 16:59:38 Current chairs: Diziet aba bdale cjwatson dondelelcaro rra vorlon 16:59:46 #topic Who is here? 16:59:51 Bdale Garbee 16:59:54 Don Armstrong 16:59:55 Colin Watson 17:00:51 Diziet, aba, rra, vorlon: ping 17:01:03 (vorlon may be out; not sure) 17:01:22 * rra waves, on phone but here. 17:01:26 cool 17:01:53 Diziet said to me elsewhere that he'd be here 17:02:10 ah, cool. Maybe just running late. 17:02:19 Hi, Ian Jackson here. 17:02:22 awesome 17:02:45 so with the exception of aba and vorlon, we're all here. 17:02:49 #topic Next Meeting? 17:03:29 Thu 25th October ? 17:03:40 works for me 17:03:41 the calendar tells me that thursday october 25th is the last thursday in october. Is that at 17OO GMT ok with everyone? 17:03:45 Works for me 17:03:52 err, UTC. 17:03:52 That's still summer time in the UK. 17:03:55 cool 17:04:00 it's still summer time in the US too 17:04:06 date -d '@1351184400' 17:04:29 * rra will be out for most of October, so will miss the next meeting regardless. 17:04:37 So works for me in that sense. :) 17:04:44 rra: doing something fun, I hope! ;-) 17:04:48 * rra gets off the phone, gomen. 17:04:56 Yup, going to the Oregon coast with my family for two and a half weeks. 17:05:03 #agreed Next meeting is at date -d 'Thursday October 25 2012 17:00 UTC' 17:05:09 rra: nice 17:05:36 rra: Have fun :-) 17:05:44 Thanks! 17:05:49 #topic #573745 python maintainer 17:06:11 there's a preliminary draft here: http://anonscm.debian.org/gitweb/?p=collab-maint/debian-ctte.git;a=blob;f=573745_python_maintainer/dla_draft.txt 17:06:47 which I believe encompases what we last discussed; since I haven't given everyone enough time to review it, I think we can just quickly continue 17:06:50 I like it. I have very little to comment. At the very end of item 1 I would s/ outcomes\./\./ 17:07:22 sounds fine to me 17:07:23 For the avoidance of doubt, point 6 is outside your A/B/C split, right ? 17:07:28 right 17:07:33 err, it's inside 17:07:46 Oh so it is. 17:07:53 6 and 7 belong to C? 17:07:56 yeah 17:07:58 Can I request that we include point 7 in A and B too ? 17:08:03 that sounds reasonable 17:08:06 I was just going to say the same. 17:08:13 I was going to suggest that after I thought about it more too... 17:08:18 Call 6 5a perhaps. 17:08:20 so, resequence to put 7 before the choice 17:08:27 right 17:08:28 That would work too. 17:08:29 Whatever. 17:08:53 I actually kind of like the "outcomes" there since it softens it a bit. Hm. It's minor, but I'm a little twitchy about telling other people their behavior isn't acceptable in a formal resolution. 17:08:57 As for formatting of options, how about a vertical line of A B C to the LHS or RHS of the text ? Makes it a bit easier to see. 17:09:06 rra: Fair enough. 17:09:13 That's a good argument. 17:09:14 Saying that it's not an acceptable outcome makes it about the result rather than the people. 17:09:20 ok, here-ish 17:09:27 rra: well said 17:09:59 I don't know how much it will help, but it would be good to make that effort, yes. 17:10:02 yeah 17:10:24 Diziet: yeah, I'm ok with that formatting change; I just didn't do it to start with because it's easier to change word wrap without the A/B/C 17:10:46 C-x . runs the command set-fill-prefix 17:10:50 Diziet: yerp 17:10:56 just means an extra set of keys. ;-) 17:10:59 Heh. 17:11:00 OK 17:11:07 Other than that, this looks good to me too. 17:11:17 agreed, I'd be prepared to vote on this 17:11:23 Although agreed with the formatting clarity. 17:11:49 ok 17:12:01 I'll make that change and then send it out to the list for more complete discussion before calling for votes 17:12:14 OK 17:12:17 #action dondelelcaro to change formatting and then send it out to the list for more complete discussion before calling for votes 17:12:23 Just a day or two for niggles will do I think. 17:12:34 yerp 17:12:35 #topic #636783 super-majority conflict; 17:12:43 I haven't done very much about this. 17:12:46 ok 17:12:55 I got a bit derailed by thinking about how to deal with pseudo-accepted amendments. 17:13:12 And concluded that the right thing would be for the TC to accept them en masse towards the end of the discussion period. 17:13:21 There would be a 1 week wait for the constitutional cooldown. 17:13:46 That sounds workable to me. 17:14:11 ok; so I guess we're just waiting on an eventual draft for this? 17:14:18 OK. If that sounds workable I will try to write it up. I want to have all the procedural bits ready to go so when we get into a wider discussion everyone knows what the process will be. 17:14:23 dondelelcaro: Yes. 17:14:37 sounds good 17:14:38 sounds workable 17:14:44 That is, I don't want to get into a situation of deciding the process (ie the rules) during the discussion. 17:14:47 Broader guidance from the project on maintainer overrides would actually have been really useful for the whole metapackage discussion, for me at least. 17:15:05 #action diziet to actually press on as discussed 17:15:10 Diziet: agreed, a solid proposal best before too much broad attention/discussion or we'll all go nuts 17:15:12 rra: Right. 17:15:33 cool; moving on, if that's ok 17:15:38 #topic #681419 Depends: foo | foo-nonfree 17:15:40 I think I may do a kind of a pre-discussion on -project to let everyone complain about (ie ignore) the process bits. 17:15:51 Diziet: sounds good 17:15:51 Diziet: sure 17:16:00 I think we decided last time on this that we should discuss it further in email, and then didn't. 17:16:16 Yes. 17:16:29 We need to action someone to start the conversation. 17:16:32 I missed the last meeting, I think, so feel a bit disconnected .. this one seems fairly obvious to me? 17:16:51 The tail end of the bug log looks close to write-voting-text to me. What's left? 17:16:52 bdale: There's some debate over whether we should allow non-free dependencies as an alternative or require that people use metapackages. 17:17:08 That's the bit I particularly remember, but I think there was some other stuff too. 17:17:14 By metapackages do you mean virtual packages? 17:17:16 non-free as non-primary dependency is clearly acceptable 17:17:19 cjwatson: Yes. 17:17:19 Er, yes, sorry. 17:17:22 I keep using the wrong word. 17:17:23 I didn't recall it requiring further discussion, I thought there were clearly two ballot options that needed to be written up 17:17:52 ok; who wants to take it? 17:17:55 I'm with bdale on this but I can imagine other points of view. I don't know how much further discussion is likely to clarify that. 17:17:56 I don't think we've quite aired enough the virtual package vs. real package thing. 17:18:07 hrm... ok 17:18:08 I have some ctte-related guilt I'd like to assuage so I wouldn't mind taking on some drafting here. 17:18:13 because we had a definite consensus that Depends/Recommends: foo-nonfree is unacceptable, and then there were two camps about whether Depends: foo | foo-nonfree was permissible 17:18:15 But I think this needs someone to write up a concrete proposal for me to pick at. 17:18:26 forcing the creation of a virtual package to hide the fact that we're willing to admit there's a non-free alternative makes no sense at all 17:18:47 bdale: What a bizarre way of putting it. 17:19:07 what's the point of a virtual package if not to allow the package in main to pretend it doesn't know? 17:19:12 I suppose it depends whether you think mentioning it as an alternative is somehow explicitly endorsing it. 17:19:19 cjwatson: Precisely. 17:19:26 cjwatson: I've never bought into that 17:19:33 Nor I, but I understand the POV. 17:19:37 I think it's unarguable that it does. 17:19:45 (I've seen enough packages with giant lists of alternatives ...) 17:19:46 I mean, unarguably it does endorse. 17:19:49 I mention Microsoft fairly routinely, I certainly don't endorse them. And don't even get me started about Apple. 17:19:54 heh 17:20:05 And in the case of foo | foo-nonfree, it's generally sufficient to have foo-nonfree provide foo. 17:20:20 really? 17:20:23 apt-cache show xul-ext- used to be a good source of giant disjunctions where it wasn't plausible that the maintainer actually endorsed them all. 17:20:29 "generally sufficient" is not the bar I set for things I want to forbid maintainers to do 17:20:36 So the only other ones are foo | bar where bar is non-free and I think there having Depends: foo | what-foo-does is better. 17:20:56 vorlon: What I mean is that the extra overhead is generally not necessary, so overall it's minor. 17:21:08 Diziet: fwiw I don't consider myself a "persuadable voter" on this issue. I understand your argument but I don't agree with it. I think we should vote and be done with it. 17:21:21 so we clearly have two camps here, and definitely need a draft which has at least alternatives on non-free are ok, and virtual packages are required (or strongly recommended) 17:21:23 I would like the opportunity to disucss it by email. 17:21:38 Diziet: would after a draft be sufficient? 17:21:42 Sure. Would you be happy to discuss in the context of ... what he said 17:21:43 IRC is a terrible medium for extended discussion of something where there's significant disagreement. 17:21:46 dondelelcaro: Yes. 17:21:51 and/or Diziet can volunteer to deliver a draft? 17:21:57 cjwatson: are you ok with taking the draft to start? 17:22:00 Yes 17:22:07 If that's OK with everyone 17:22:12 fine with me 17:22:15 I don't think anyone should hold back writing drafts until we've got consensus. 17:22:21 Good here. 17:22:26 cjwatson: are you drafting both options? 17:22:31 (Even though my recent efforts in that direction haven't necessarily had stellarly wonderful results.) 17:22:34 vorlon: Yes 17:22:37 #action cjwatson to draft up a resolution to ##681419 alternatives on non-free are ok, and virtual packages are required 17:22:40 I think I can accurately represent both 17:22:42 cjwatson: I would be happy to draft the other option. 17:22:51 either/or is cool with me 17:23:13 We can let the best draft win (where best may include whoever-gets-round-to-it-first) 17:23:17 Why don't you draft the "allow" version and I'll put forward my arguments in email. 17:23:22 OK 17:23:26 sounds good 17:23:29 If I don't persuade anyone I'll write it up as an option and you can vote it down. 17:24:21 I'm going to skip around slightly on the agenda here 17:24:22 #action Diziet to respond to cjwatson's draft 17:24:27 dondelelcaro: OK 17:24:28 #topic #685795 New ctte member 17:24:40 Did we have any applicants ? If we did I'm not getting the emails. 17:24:50 there were a number of them, yes 17:24:51 Oh, you're not getting the mail, then. 17:24:53 Oh bum. 17:24:54 we have quite a few applications .. you haven't seen them? 17:24:58 sent to the mailing list you set up! :) 17:24:59 Diziet: yes; sorry, I think the alias for you is wrong then... I'll forward them to you 17:25:00 We've actually gotten an embarassment of riches. 17:25:05 dondelelcaro: Thanks. 17:25:10 rra: jinx 17:25:14 you type faster than I do... 17:25:22 dondelelcaro: Can you forward me the whole thread with everyone's comments if any ? 17:25:25 Yes, we seem to have more than a sufficiency of excellent candidates, although we don't know whether all of them would accept it. 17:25:30 no one has commented so far 17:25:30 I haven't seen any commentary yet. 17:25:36 Diziet: if you could file an RT ticket to get your alias changed, that'd be awesome, too 17:25:37 We shouldn't discuss the candidates specifically here in public. 17:25:43 right, I agree 17:25:44 dondelelcaro: I will sort that out today. 17:25:49 It's possible it's at my end. 17:25:55 Yeah, I've been waiting on saying anything until we had a fairly complete set, because each time I thought I had an opinion, another excellent candidate shows up. :) 17:25:59 I do think we could talk here about how we want to proceed 17:26:15 bdale: Yes. 17:26:18 with such a rich list of candidates, we're going to have to make decisions that aren't easy 17:26:22 Given the people who have been mentioned so far, I do have a preference that I'd be happy to state. Did we say when we were closing for nominations? 17:26:32 rra: October 1st ish 17:26:41 Ah, okay. 17:26:57 I'd rather wait until we close nominations and then look at a list of everyone and then write up something for -private. 17:26:59 Well how about this. When the deadline passes we should send out a mail thanking people for applying and saying we're pleased and impressed with the quality of the applications. 17:27:14 Don has been sending out individual thanks as we go along. 17:27:15 And asking for forbearance as it's going to be a tough decision. 17:27:15 Diziet: I've actually been thanking people for sending in nominations 17:27:23 dondelelcaro: thanks for that 17:27:28 dondelelcaro: Good-oh, but I think a feel-good holding mail to d-d-a would be useful. 17:27:46 Diziet: right, sounds reasonable. Or just to d-d or whatever. 17:28:45 if we have feedback about particular applicants, how would we like to see that happen? 17:29:07 should I follow up to each nomination mail, or collate my thoughts in a single mail to the list? 17:29:19 I was going to collate mine. I think it'll be easier to write that way anyway. 17:29:20 vorlon: If we have loads of applicants we should try to be systematic. 17:29:35 we have loads 17:29:40 I've personally got an org outline; so a collection in a single mail would probably be ideal. 17:29:42 Should we confirm with the nominees before starting in on discussions? 17:29:44 or so it seems to me 17:29:55 cjwatson: yes 17:30:00 We have some self-nominations, but not all. 17:30:01 cjwatson: Certainly. 17:30:06 some were self-nominations, those are of course obvious 17:30:13 Should we invite public comments ? 17:30:22 We could make a shortlist and publish it. 17:30:23 should I talke on the validation, or does someone else want to? 17:30:30 s/talke/take/ 17:31:34 Diziet: I think not until we've prepared a shortlist, just so anyone who isn't selected isn't publicly passed over 17:31:41 right 17:31:49 In some ways I'd almost rather not publish a shortlist because the quality is generally so good, IYSWIM 17:32:02 ok, so we need to confirm who that was nominated by others would agree to serve 17:32:06 cjwatson: yeah, that is sort of my thought too 17:32:07 then we have the 'long list' 17:32:10 bdale: right 17:32:11 But if people feel it'd be good for transparency I don't actually mind as such 17:32:12 some of the nominees are ones that I have rather negative reactions to, honestly, so I'd prefer to get my private comments in first 17:32:56 it could be appropriate to thank everyone on the long list for being willing in some public way, even before we start to debate them? 17:33:22 dondelelcaro: shortlist, passed over> Right. 17:33:45 bdale: I think we should do that in the acknowledgement of the nominations without naming them publicly 17:33:53 bdale: We should not name any nominees publicly at least until we've shortlisted them. 17:33:54 Is the shortlist for voting among the ctte, or for presentation to zack? 17:34:01 Diziet: why not? 17:34:20 bdale: Because we will invite negative comments about candidates some people feel obviously unsuitable. 17:34:33 I think we should at least not name any nominees publicly who aren't willing to serve. Folks who don't want to be involved may not want to be mentioned as possibly involved at all. 17:34:39 And I would like to publish a list which is purely postive. 17:34:46 rra: right, ergo my mention of 'the long list' 17:34:56 Ah, yes, right. I'm with you now. 17:35:04 That is, if we publish all the willing nominees and later publish a shortlist we've said something negative about people. 17:35:07 clearly in my mind anyone willing to serve deserves public recognition of that fact 17:35:11 I have Diziet's concern too, but would also like to thank people, so I'm torn. 17:35:14 if that "draws attack", then so be it 17:35:31 why would we ever publish a "short list"? 17:35:34 bdale: maybe we should ask in the follow-up mail about whether people would be willing to be publicly recognized as being nominated? 17:36:05 to my mind, we publish the long list, then we announce who has been invited to join and accepted. end of story. 17:36:06 bdale: well, I think we need to have some sort of public discussion of the candidates so non-CTTE members can weigh in 17:36:15 do that on the long list 17:36:16 do we? 17:36:17 bdale: It's a standard approach in decisionmaking with too many options. You eliminate options that can be seen with a small amount of effort to be unsuitable so you can concentrate on the rest. 17:36:18 much les contentious 17:36:35 this is a TC+DPL decision 17:36:37 true 17:36:58 I don't know that public discussion is useful, and it certainly carries risk of being contentious 17:37:04 And I would like to invite public comment. That's asking for effort from the project. We should make that request responsibly and not ask for comments on people we aren't going to appoint. 17:37:11 I'm happy to see inputs on everyone on the long list, and have the process of winnowing that down to one accepted offer be invisibly part of the TC+DPL workings, personally 17:37:12 public discussion> God, no. 17:37:19 I mean, publicly request comments to be emailed to us privately. 17:37:53 * rra is with bdale on this one, I think. It's not very transparent, but I'm just seeing so many ways in which public discussion could go horribly divisively wrong. 17:38:11 We definitely must not have public discussion. 17:38:19 ok; I'm happy to not have public discussion so long as there's public commentary to the private list 17:38:40 And we must make it clear if we make a call for comments that any negative comments will be shared (with sender's name filed off) with the candidate to allow the candidate to respond. 17:38:41 Yeah, that makes sense. Inviting private feedback is a good idea and hopefully will help push us towards more diversity, which was one of the original goals. 17:38:47 right, so my idea is that we publicly acknowledge everyone who puts their name in the hat (the "long list"), and invite project inputs privately to the TC. then we make a decision, suggest to the DPL, invite, accept, then announce who the new member is 17:38:59 well, I'm not sure even public commentary is particularly useful, but I don't feel strongly enough about this to argue it 17:39:17 (i.e., I'm not sure even private commentary from the public is useful) 17:39:27 We have a pretty limited experience of the whole project. I think getting data is important. 17:39:32 it may not be, but making it clear that we're willing to listen seems valuable 17:39:54 btw, do I have the right count here? 6 nominees? 17:39:59 We should write the call for comments carefully. 17:40:08 put differently, I'd rather slog through a pile of email that ends up not changing my mind much than find out after the fact that there's something material I just didn't know 17:40:11 vorlon: I suspect that it isn't going to be significantly different from the commentary we're going to get internally, but (to take a completely made-up example) if the result is feedback from six or nine people in the project saying that it would be GREAT if the tech-ctte would add someone with functional programming language experience due to , that would be really useful. 17:40:19 Diziet: of course 17:40:35 vorlon: That's my count so far. 17:40:46 If we have only 6 (that's not loads, 20 is loads) then that can be a shortlist. 17:41:21 * bdale subscribes to the "1, 2, many" philosophy in things like this 17:41:26 but whatever, short == long, it's all good 17:41:37 ok 17:41:45 My point was that if we have 20 nominees we shouldn't invite feedback on them all. 17:41:46 so the process starts with verifying everyone nominated wants to be included 17:41:49 bdale: Yes. 17:41:52 right 17:42:20 Those who say "no" we thank privately and don't mention publicly. 17:42:25 I'll draft the announcement mail, and bounce it to -private once bdale confirms 17:42:36 then we publicly thank the list of nominees for stepping forward, say we're starting private deliberations, and welcome commentary to a private TC address 17:42:45 Diziet: yes 17:42:46 right 17:42:52 I'm happy with that if we don't get a sudden last-minute rush. 17:43:01 I suspect we won't 17:43:03 If we have 10 candidates we might want to think about shortlists. 17:43:11 we have a nicely diverse set so far, to my mind 17:43:16 But we can cross that bridge when we come to it. 17:43:19 #action bdale to confirm that non-self nominees wish to serve 17:43:20 yes 17:43:38 wilco 17:43:45 #action dondelelcaro to draft announcement mail thank the list of nominees for stepping forward, say we're starting private deliberations, and welcome commentary to a private TC address 17:43:56 As for our selection process: I would like us to try to structure our deliberations. 17:44:15 Diziet: that's fine. suggest you review the list of candidates soon 17:44:18 That is, we should have a set of criteria and we should explicitly have an opinion (probably an opinion each) about each of the criteria. 17:44:25 bdale: Will do. 17:44:42 That's a good idea, I think. If we do that, we should publicly discuss the criteria, I think. 17:44:46 Yes. 17:44:50 Er, too many thinks. :) 17:44:57 hrm 17:45:00 Thinking is good :-). 17:45:08 We have one stated public criteria so far, namely increased diversity. 17:45:21 will require some care to discuss criteria without telegraphing opinions about individuals beyond a general increase diversity mantra 17:45:27 rra: Yes, but of course our other criteria are implicit. 17:45:32 bdale: As you say. 17:45:38 There are a few other ones that are obvious (general experience with Debian, proven track record of technical expertise). 17:45:56 Other criteria> Eg, being right in technical conversations, being a quick learner, being able to handle conflict well, whatever. 17:46:17 I'm all for a deliberate process, as long as we don't bog down 17:46:26 Exactly. My point is that we should try to capture all the important criteria and thus exclude irrelevancies. 17:46:40 We should probably cap the criteria at something around five if we're all going to express an opinion on every criteria, or we're going to end up with a ton of text. 17:46:47 This is a proven way of helping escape cognitive biases. 17:46:53 rra: Yes. 17:47:11 The opinions can be quite short. "Excellent" "unsure" or whatever. 17:47:16 True. 17:47:41 It's kind of an interesting question as to whether "collaborates well with existing members of the tech-ctte" is a good criteria or not. 17:47:46 ok; would it be ok for Diziet to propose a set of critera to -private, and then we can discuss them? [Or even on -ctte.] 17:47:50 ok, feels like we have a plan .. time to move on? 17:47:55 dondelelcaro: I will do it on -ctte 17:47:59 sounds good 17:48:02 Works here. 17:48:03 #action Diziet to propose selection criteria on -ctte 17:48:08 #topic #688772 gnome Depends on network-manager-gnome 17:48:36 (saved this one for second to last, since I figured it would take the most time) 17:48:40 Firstly I want to apologise to all of you lot and to the innocent bystanders. I should have avoided writing those emails while incensed, and the result is that they haven't helped. 17:48:52 (I can't stay too much longer. Maybe 20 minutes.) 17:49:01 * rra has about 12 minutes myself. 17:49:05 ok 17:49:26 Diziet: Thank you, and apology accepted here, and I appreciate your willingness to apologize there. Been there, done that myself. 17:49:55 col: Next time I seem to be doing the same thing feel free to remind me of this time... 17:50:02 Heh 17:50:11 Diziet: :) 17:50:20 I'm concerned that the opposing viewpoint now feels that things are stacked against them from the outset. 17:50:30 * rra has been thinking about this all morning, and there's an angle of the social aspect of this that I think is kind of important. This also ties into Diziet's desire to get further guidance from the project on maintainer overrides. 17:50:34 Diziet: fwiw I do think that starting the discussion with a draft resolution sets a very confrontational tone 17:50:37 Which may or may not be true but it doesn't make for good impartial wossname. 17:50:42 as a general rule 17:51:09 As we've started doing more, we're getting increased pushback that we're being too aggressive and we're making too many decisions. That had already started with some earlier decisions, and is now getting stronger. I think that's an interesting signal that we want to pay close attention to, although I'm not entirely sure on how best to absorb it. 17:51:35 To some extent I think this is an inevitable consequence of having been very quiet for some time. 17:51:36 it's also fascinating after years of being chided for not taking actions 17:51:38 social aspect> Yes, but I think that should be reflected in our tone. I don't think that when we take a technical decision we should consider the projects' internal social situation (unless it were a technical question about how the bts should behave or something) 17:52:14 One of the things that struck me this morning was that a core characteristic of Debian for a lot of people, I think, is that it's someplace where they can do what they think is Right as opposed to what other people tell them to do. A lot of us work in jobs where we don't get to make what we think is the right decision, or have to take the practical over the aesthetic, and Debian is a valuable escape from that, and that's what makes the project so mu 17:52:25 so mu$% 17:52:34 rra: yes 17:52:39 But yes I agree. 17:52:40 I'm not saying that we're making the wrong decisions, but I'm feeling like we're starting to get pushback that people are worried we're tromping on that. 17:53:03 right 17:53:07 so the thing about this issue is that to me it's all about whether the maintainer or the end user is supposed to have the ultimate power 17:53:21 There is also the fact that Debian does the right thing for its users. Ie, our users trust us to do what is Right as you say - without fear or favour. 17:53:24 Just speaking personally, there is, at some point, a line where I'd rather not fix something I think is broken if it means that people have more fun working on Debian. 17:53:25 a behavior that "forces" a choice on an end user is not empowering that user 17:53:29 I'm not sure where that line is, but I know it exists. 17:53:32 Surely that includes without fear or favour towards an internal power structure. 17:53:43 bdale: I'm sure there's some name for the fallacy of ascribing to the whole the views expressed by two separate vocal minorities in response to differing circumstances :) 17:53:45 bdale: Exactly. 17:53:55 bdale: That's kind of how I feel as well, although the maintainers' position as stated in most recent mails is that they feel they're doing the right thing for users. 17:54:02 I've certainly as a package maintainer been frustrated in the past when users wanted to override my brilliance, but in *every* case I realized in the end that they were right and I was wrong 17:54:18 cjwatson: right thing for users> Well yes they would say that. We had that argument in the gnome-core part of the discussion and rejected it. 17:54:29 In the name of assuming good faith, although I can't say I agree at this point, I'd like to take it at face value that that's their intention. 17:54:43 (I mean I can't say I agree that it's actually the best thing.) 17:54:46 cjwatson: Yes, that's fine, for these purposes we should indeed assume good faith. 17:54:47 in this specific instance, the issue at the core to me is the one about what and end user's expectations on upgrade should be 17:54:52 cjwatson: But that doesn't mean we have to agree with it. 17:55:01 Thus I think framing it in terms of maintainers vs. end users is actually kind of presupposing the answer. 17:55:09 bdale: I tentatively agree with that, but I think it also has the substantial caveat that the tech-ctte aren't actually the users, and we aren't really blessed with special insight into what the users want. We have our opinions, and I personally think they're well-informed ones (but then, I would think that). 17:55:31 right 17:55:46 I'm inclined to agree with rra's observation in email and the thoughts of others since that there's room in the world for a "this meta package means you subscribe to the entirety of my world view, so get over it" kind of packaging behavior, but I'm not comfortable accepting that a hard dependency from the gnome package to network-manager does the right thing in the current case for upgrades 17:55:48 cjwatson: I find it difficult to see how using Recommends in this case can be criticised as not good for users. 17:56:14 rra: I completely agree, so what we need to focus on are the *mechanisms* in question 17:56:21 And I would like to point out that the maintainers have not even made any kind of coherent argument in favour of Depends vs Recommends ! 17:56:32 in this case, a hard depends empowers a maintainer over an end user 17:56:46 supposing for the moment that we accept that the maintainers have a solid reason for wanting to upgrade the Recommends to a Depends for the gnome metapackage 17:56:54 what are some other ways to get the desired behavior on upgrade? 17:57:01 Diziet: Yeah, this is the technical side of it that I'm really struggling with. I truly do not understand why the GNOME folks are so strongly opposed to using Recommends. The reasons presented so far just don't make sense to me. It may be that I'll never understand, and I'm not sure that's, in and of itself, a reason to overrule them. (In fact, I'm fairly sure it's not enough by itself.) But it bothers me that smart people don't like Recommends 17:57:02 it's not clear to me that there are any 17:57:29 what's the desired behavior? 17:57:31 what about if, on upgrade, something detects that nm was not previously installed, and calls 'service network-manager disable' automatically for the user? 17:57:41 would that be an appropriate compromise? 17:57:47 vorlon: I find it hard to see why we would consider "accepting" that the maintainers have a "solid reason" which they haven't, in all of this time, communicated to anyone. 17:58:00 rra: in my own case, I believe I understand why a recommends makes more sense than a depends in a case like this, and until/unless I'm convinced otherwise, I *do* think it's ok to overrule a maintainer on this when we're lacking a coherent argument to the contrary 17:58:07 Diziet: for the sake of argument - or rather, for the sake of possibly side-stepping the argument ;) 17:58:22 Although hm. 17:58:39 I'll never understand, and I'm not sure that's, in and of itself, a reason to overrule them> People who want to get their way in a technical discussion have the responsibility to explain so we can understand. We can't fail to act simply because someone is incomprehensible to us. 17:58:41 Josselin's position in http://lists.debian.org/debian-ctte/2012/09/msg00089.html appears to be that they explicitly want to override previous decisions [from context, I presume partially because NM has improved sufficiently] 17:58:57 yes 17:59:02 jcristau: the desired behavior, if we believe in empowering end users, is that choices they've made aren't over-ridden? 17:59:03 So it's not clear to me that "automatically run service" would be a compromise he would accept 17:59:04 cjwatson: Yes, I still wonder how much of this is because network-manager has changed a lot and is more tightly integrated and the switch away from other things back to NM is explicitly desired behavior. 17:59:08 vorlon: compromise> Well, it's suboptimal. I don't see why we should accept this suboptimal technical approach for no reason. No reason at all! 17:59:13 I'm not sure if that means they want to override the previous decision to not install it, or the previous decision to not use it 17:59:14 And thus I don't see how it would be a useful compromise in that sense 17:59:21 The only reasons being advanced are essentially that it would keep the maintainers happy. 17:59:22 jcristau: Yeah, that's an excellent question and I'm not sure I have a good answer. 17:59:39 So, there are a few things we could try to accomplish. 17:59:41 bdale: that's not really a behavior.. 17:59:57 1. Maintain user's existing stated preferences around whether n-m is being used to manage their network. 17:59:58 well, then I'm not sure there's much point in us continuing to discuss in this echo chamber, we should press the GNOME maintainers for the details ;) 18:00:01 I think that's absolutely a behaviour of the whole system 18:00:07 mbiebl said he wanted to make nm not touch /e/n/i anymore. which i guess would help with some of the objections 18:00:11 2. Deliver to the user the integrated experience that GNOME is attempting to achieve. 18:00:12 even if nm does get installed 18:00:12 It's not a static behaviour of a given Debian installation when it's not being upgraded 18:00:19 vorlon: IMO we should vote to uphold our previous decision. 18:00:21 But it's certainly a behaviour of Debian as a whole 18:00:22 jcristau: what do you mean? the behavior I want is that a choice I made is honored/preserved on an upgrade unless I'm given the opportunity to explicitly make a new decision 18:00:27 but i'm not quite sure what the other objections are 18:00:29 that's being discussed on the d-i side, in case anyone cares 18:00:49 3. Deliver to the user an integrated GNOME 3 experience even if they opted out of some parts of that integration on GNOME 2, on the grounds that GNOME 3 integration is fundamentally different. 18:00:50 (moving the installation logic to d-i, scraping out the /e/n/i munging from NM.) 18:00:58 Can anyone present a technical reason to prefer Depends to Recommends ? 18:01:00 'nm is not installed' isn't really a 'choice', in itself 18:01:14 Diziet: I don't think the reasons for disallowing this in a gnome metapackage are as strong as those for disallowing it in gnome-core, and I don't think simply voting to overrule the GNOME maintainers a second time gets to the root of the problem 18:01:33 rra: "fundamentally different" kind of argues for a new meta-package, though, doesn't it? 18:01:37 jcristau: Having nm not be installed but the gnome metapackage installed is a choice. You have to have done that explicitly, or at least by disabling Recommends. It didn't happen by accident. 18:01:41 I think that in the case where the gnome metapackage was installed in squeeze, and network-manager was not installed, that is a pretty good heuristic indication of a desire to disabe it. 18:01:46 *disable 18:01:48 vorlon: Surely it does. The root of the problem is that users are getting n-m when they don't want it. Once we re-empower the user, the problem will go away. 18:01:56 no 18:02:11 rra: lots of people disable recommends though 18:02:25 jcristau: why is that a problem? 18:02:32 Diziet: Well, the obvious technical reason to prefer Depends to Recommends is if you want to force installation of network-manager when it wasn't previously installed. 18:02:33 the root of the problem is that the maintainers of a very important piece of our desktop stack have a completely different understanding of what the user experience should be than the TC does 18:02:44 rra: That's not a goal. _Why_ would you want to force it ? 18:02:56 jcristau: I am in complete agreement with http://lists.debian.org/debian-ctte/2012/07/msg00146.html on that subject 18:02:59 Against the wishes of the user ? 18:03:01 jcristau: I would love to have numbers on that, actually. I wonder if we could get popcon to gather that. 18:03:09 repeatedly overriding those maintainers lets us get our way, but it's short-sighted and demotivating 18:03:17 Diziet: Well, I think there's disagreement over what the wishes of the user are. 18:03:39 vorlon: So if a maintainer doesn't like our decisions they can just do what they like anyway and we will back down eventually to avoid demotivating them ? 18:04:02 Diziet: that assumes that the maintainer is acting in bad faith 18:04:09 My one quibble with "re-empower the user" is that I think it's quite close to "but you can just remove the metapackage and have full control over your package selection", in that the flip side of having full control/power/whatever is having to make all the decisions. 18:04:15 Diziet: Many, many moons ago, n-m was really buggy and really obnoxious. It was widely disliked among the people I talked to at conferences and the like who were using Linux desktops. Since then, it has changed *substantially*, and is also much more tightly integrated with GNOME 3's shell environment. 18:04:27 cjwatson: yes, true 18:04:32 dondelelcaro: No, it's just a fact. They don't have to be acting in bad faith; they can just be wiggling somehow. 18:04:35 I struggle with this a lot, conceptually 18:04:40 Diziet: So the possible argument here is that the user didn't opt out of n-m in GNOME 3; they opted out of an earlier, much buggier n-m in GNOME 2. 18:04:45 Diziet: I'm not backing down from anything 18:04:56 (See my point about removing one thing from a metapackage implying that you have to then make decisions about everything else in that subsystem, which you may well not be remotely familiar with.) 18:04:57 I've never been able to use the 'gnome' meta-package, for example, because it was always too inclusive, even when I was actually using gnome 18:04:58 more tightly integrated> This is not a real reason IMO. 18:05:03 rra: did the maintainer provide this argument or is this yours? 18:05:13 waldi: I don't know. That's part of why I'm frustrated. 18:05:20 Diziet: I'm saying that if we have to override the maintainer twice in a row, assuming the maintainer isn't acting in bad faith, *we've* done something wrong and need to go deeper 18:05:23 waldi: It's possible that's what Josselin meant. But I'm not at all sure. 18:05:24 waldi: It's rra's. 18:05:30 I always wanted a way to have a 'give me all of gnome except the parts I really don't want' option, which only exists if everything is a recommends and nothing is a depends, which has never been the case 18:05:52 rra: I think you are doing the maintainer's work for them, and it's not helping. You shouldn't be working so hard to try to supply arguments for the maintainers which might make sense if they were true, when you don't actually know if they're true. 18:06:00 ok, so I think we need to get a better argument for why network-manager should be Depends: instead of Recommends: in gnome from the maintainers to see if it's convincing, or if we should directly addressing 18:06:15 bdale: Yes, me too. That's part of the reason, actually, why I'm not as worried about the gnome metapackage as gnome-core. My personal experience was that the gnome metapackage was already unusable for anyone who wanted to customize the GNOME application set much at all. 18:06:17 Diziet: it's always ok to make arguments for both sides 18:06:43 rra: right. which brings me back to focusing on the upgrade experience. 18:06:45 we certainly want to know the maintainer's logic, but we don't need to be limited to it 18:06:51 dondelelcaro: Well yes, but I think you should make arguments that you believe in. Rather than supposing ifs and buts. 18:07:03 rra: should be possible to get numbers from popcon.d.o on how many submissions have gnome installed without nm 18:07:07 * jcristau digs around on popv 18:07:09 popov, even 18:07:11 jcristau: We have that. 18:07:12 jcristau: that's actually already been done 18:07:13 Diziet: I want to try to extend empathy, particularly when people are really upset. I just (personally, as a matter of my own personality) can't see people this upset and not want to try to build a mental model of what they're thinking to understand why they're upset. 18:07:15 jcristau: Jakub posted that. 18:07:17 oh 18:07:18 jcristau: it's 5% 18:07:19 According to the popcon data, 1812 out of 31630 the "gnome" metapackage 18:07:19 users don't have the "network-manager" package installed. 18:07:20 jcristau: this have been answered already 18:07:24 jcristau: ^ from Jakub 18:07:25 ok 18:07:46 rra: I empathize with your need to empathize, I share it 18:07:47 we seem to have overrun the time limit rra and cjwatson imposed :) 18:07:53 rra: My mental model is that this is to do with religion. 18:07:58 I think this needs further discussion with the GNOME maintainers 18:08:00 right 18:08:10 Can we please set a deadline for reply ? 18:08:12 lets follow this up with the gnome maintainers and see if we can figure it all out 18:08:17 what I would like to see is a clear argument from the GNOME maintainers about why this *must* be a depends and not a recommends 18:08:32 why don't I follow up about it 18:08:39 dondelelcaro: thank you 18:08:39 Would a week be enough ? 18:08:46 #action follow this up with the gnome maintainers to get a clear argument from the GNOME maintainers about why this *must* be a depends and not a recommends 18:08:51 #action dondelelcaro to follow this up with the gnome maintainers to get a clear argument from the GNOME maintainers about why this *must* be a depends and not a recommends 18:09:09 Diziet: I think they'll respond fairly quickly; if not, we can cross that bridge then 18:09:17 dondelelcaro: then> Do you mean in a month's time ? 18:09:31 Diziet: This is just a personal philosophical thing, on which I know that other people can and do disagree, but I try to make "this is an irrational opinion" something I say only about my own opinions and not about other people's. I'd personally rather leave it at "I don't understand the reasons," instead of making the additional jump to "I don't think you have any valid reasons." 18:09:42 Or in a week's time we'll say "did you want to reply you have a week" which is giving them two weeks. 18:09:54 Diziet: uh... no. If they haven't responded within a resonable period of time, then we can re-prod them 18:09:55 I'd like to explore why tighter integration is the responsibility of the metapackage and not of the packages which are so integrated. 18:10:11 rra: I think I do understand the reasons. They have been extensively stated and amount to doctrine from GNOME upstream. 18:10:11 Because that to me is the core of my confusion with the tighter-integration argument. 18:10:20 Diziet: but imposing a deadline on them is presuming that they are not going to respond, and antagonistic 18:10:27 Diziet: Well, I think that's a different thing than it being religious. 18:10:37 dondelelcaro: it's also moderately pragmatic if we want this fixed in wheezy 18:10:39 dondelelcaro: So in a week's time you'll agree with me that they've had enough time and we should assume there are no good reasons ? 18:10:56 "It's going to cause us a big support burden" (which is usually what divergence from upstream actually translates into) is a practical argument, not a religious one. :) 18:10:58 rra: Err, I must not have made myself clear then. They seem equivalent to me. 18:10:59 right, we should work to resolve this within the month 18:11:06 if you can just find them and have a conversation and come away with clarity, that's ideal 18:11:39 resolve this within the month> so a week to ask the question, a week to draft a resolution, a week to vote on it, and a week in DELAYED-7 ? 18:11:45 #topic Additional Business 18:12:08 I have a pathetic wishlist request 18:12:25 sure 18:12:33 is there any chance somebody here would be willing to provide the meeting schedule as an iCal feed? :) 18:12:40 vorlon: yeah, I can do that 18:12:41 seconded 18:12:44 ok cool 18:12:55 would it being in the git repository be good enough? 18:13:04 I'll put the future tentative meetings in there too 18:13:23 dondelelcaro: only if that results in a well-formed, stable ical url I can point my calendaring software at 18:13:57 emails, or things I have to poll, manage to not get where they need to be 18:13:58 "i don't want nm installed no matter what" sounds religious to me... oh well. 18:13:59 vorlon: ok; I'll at least keep it there, and if necessary, I'll set up some hack to make it workable for calendaring software) 18:14:32 jcristau: what if it's really "I'm a developer of and I'd like to use it instead of n-m" .. still religious? 18:14:41 I don't think characterising either side as religious is particularly helpful, really. 18:14:51 I don't either 18:14:55 #action dondelelcaro to shove calendar into git and serve using ical-able linkage 18:14:56 so while in theory this time slot is free for me every day, it would be very helpful to have it on my calendar so I actually factor it into my day planning and manage to eat breakfast before 10am ;) 18:14:57 It's not going to persuade anyone and it doesn't help us explore technical reasons. 18:14:57 them's fightin' words! 18:15:02 s/every day/every week/ 18:15:17 jcristau: Well, speaking as one of the people who replaced n-m with wicd, for me it really was about a specific set of bugs, and if those bugs are now fixed (and I were still using GNOME -- part of the problem with expressing opinions I'm having personally is that I don't use GNOME any more and truly don't know what GNOME 3 is like since gnome-shell won't run on the system that I was using GNOME on), I would have been happy to switch back if those bu 18:15:23 vorlon: me too. I didn't have this on my calendar until this morning, thanks to dondelelcaro for the poke 18:15:26 But if not, I'd still want to use wicd. 18:15:29 bdale: yes, if you can have both nm and your alternative installed and choose which of them manages your network interfaces 18:15:33 those bu$, but I think I know what you mean 18:15:46 ok... any objection to stopping here? 18:15:52 [discussion can continue, of course] 18:16:01 maybe that's not possible now, i wouldn't know. but that's not quite the same thing. 18:16:04 #endmeeting