Add Sep & Oct meetings, as tentative

[debian-ctte.git] / meetings / 20120927 / debian-ctte.2012-09-27-16.59.log.txt

16:59:15 <dondelelcaro> #startmeeting
16:59:15 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:38 <dondelelcaro> #chair bdale vorlon cjwatson rra Diziet aba
16:59:38 <MeetBot> Current chairs: Diziet aba bdale cjwatson dondelelcaro rra vorlon
16:59:46 <dondelelcaro> #topic Who is here?
16:59:51 <bdale> Bdale Garbee
16:59:54 <dondelelcaro> Don Armstrong
16:59:55 <cjwatson> Colin Watson
17:00:51 <dondelelcaro> Diziet, aba, rra, vorlon: ping
17:01:03 <dondelelcaro> (vorlon may be out; not sure)
17:01:22 * rra waves, on phone but here.
17:01:26 <dondelelcaro> cool
17:01:53 <cjwatson> Diziet said to me elsewhere that he'd be here
17:02:10 <dondelelcaro> ah, cool. Maybe just running late.
17:02:19 <Diziet> Hi, Ian Jackson here.
17:02:22 <dondelelcaro> awesome
17:02:45 <dondelelcaro> so with the exception of aba and vorlon, we're all here.
17:02:49 <dondelelcaro> #topic Next Meeting?
17:03:29 <Diziet> Thu 25th October ?
17:03:40 <bdale> works for me
17:03:41 <dondelelcaro> 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 <cjwatson> Works for me
17:03:52 <dondelelcaro> err, UTC.
17:03:52 <Diziet> That's still summer time in the UK.
17:03:55 <dondelelcaro> cool
17:04:00 <dondelelcaro> it's still summer time in the US too
17:04:06 <Diziet> date -d '@1351184400'
17:04:29 * rra will be out for most of October, so will miss the next meeting regardless.
17:04:37 <rra> So works for me in that sense.  :)
17:04:44 <bdale> rra: doing something fun, I hope!  ;-)
17:04:48 * rra gets off the phone, gomen.
17:04:56 <rra> Yup, going to the Oregon coast with my family for two and a half weeks.
17:05:03 <dondelelcaro> #agreed Next meeting is at date -d 'Thursday October 25 2012 17:00 UTC'
17:05:09 <bdale> rra: nice
17:05:36 <Diziet> rra: Have fun :-)
17:05:44 <rra> Thanks!
17:05:49 <dondelelcaro> #topic #573745 python maintainer
17:06:11 <dondelelcaro> 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 <dondelelcaro> 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 <Diziet> I like it.  I have very little to comment.  At the very end of item 1 I would s/ outcomes\./\./
17:07:22 <dondelelcaro> sounds fine to me
17:07:23 <Diziet> For the avoidance of doubt, point 6 is outside your A/B/C split, right ?
17:07:28 <dondelelcaro> right
17:07:33 <dondelelcaro> err, it's inside
17:07:46 <Diziet> Oh so it is.
17:07:53 <bdale> 6 and 7 belong to C?
17:07:56 <dondelelcaro> yeah
17:07:58 <Diziet> Can I request that we include point 7 in A and B too ?
17:08:03 <dondelelcaro> that sounds reasonable
17:08:06 <cjwatson> I was just going to say the same.
17:08:13 <dondelelcaro> I was going to suggest that after I thought about it more too...
17:08:18 <Diziet> Call 6 5a perhaps.
17:08:20 <bdale> so, resequence to put 7 before the choice
17:08:27 <dondelelcaro> right
17:08:28 <Diziet> That would work too.
17:08:29 <Diziet> Whatever.
17:08:53 <rra> 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 <Diziet> 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 <Diziet> rra: Fair enough.
17:09:13 <Diziet> That's a good argument.
17:09:14 <rra> Saying that it's not an acceptable outcome makes it about the result rather than the people.
17:09:20 <vorlon> ok, here-ish
17:09:27 <bdale> rra: well said
17:09:59 <cjwatson> I don't know how much it will help, but it would be good to make that effort, yes.
17:10:02 <dondelelcaro> yeah
17:10:24 <dondelelcaro> 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 <Diziet> C-x . runs the command set-fill-prefix
17:10:50 <dondelelcaro> Diziet: yerp
17:10:56 <dondelelcaro> just means an extra set of keys. ;-)
17:10:59 <Diziet> Heh.
17:11:00 <Diziet> OK
17:11:07 <rra> Other than that, this looks good to me too.
17:11:17 <bdale> agreed, I'd be prepared to vote on this
17:11:23 <rra> Although agreed with the formatting clarity.
17:11:49 <dondelelcaro> ok
17:12:01 <dondelelcaro> I'll make that change and then send it out to the list for more complete discussion before calling for votes
17:12:14 <Diziet> OK
17:12:17 <dondelelcaro> #action dondelelcaro to change formatting and then send it out to the list for more complete discussion before calling for votes
17:12:23 <Diziet> Just a day or two for niggles will do I think.
17:12:34 <dondelelcaro> yerp
17:12:35 <dondelelcaro> #topic #636783 super-majority conflict;
17:12:43 <Diziet> I haven't done very much about this.
17:12:46 <dondelelcaro> ok
17:12:55 <Diziet> I got a bit derailed by thinking about how to deal with pseudo-accepted amendments.
17:13:12 <Diziet> 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 <Diziet> There would be a 1 week wait for the constitutional cooldown.
17:13:46 <rra> That sounds workable to me.
17:14:11 <dondelelcaro> ok; so I guess we're just waiting on an eventual draft for this?
17:14:18 <Diziet> 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 <Diziet> dondelelcaro: Yes.
17:14:37 <dondelelcaro> sounds good
17:14:38 <bdale> sounds workable
17:14:44 <Diziet> That is, I don't want to get into a situation of deciding the process (ie the rules) during the discussion.
17:14:47 <rra> 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 <Diziet> #action diziet to actually press on as discussed
17:15:10 <bdale> Diziet: agreed, a solid proposal best before too much broad attention/discussion or we'll all go nuts
17:15:12 <Diziet> rra: Right.
17:15:33 <dondelelcaro> cool; moving on, if that's ok
17:15:38 <dondelelcaro> #topic #681419 Depends: foo | foo-nonfree
17:15:40 <Diziet> 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 <dondelelcaro> Diziet: sounds good
17:15:51 <bdale> Diziet: sure
17:16:00 <rra> I think we decided last time on this that we should discuss it further in email, and then didn't.
17:16:16 <Diziet> Yes.
17:16:29 <Diziet> We need to action someone to start the conversation.
17:16:32 <bdale> I missed the last meeting, I think, so feel a bit disconnected .. this one seems fairly obvious to me?
17:16:51 <cjwatson> The tail end of the bug log looks close to write-voting-text to me.  What's left?
17:16:52 <rra> 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 <rra> That's the bit I particularly remember, but I think there was some other stuff too.
17:17:14 <cjwatson> By metapackages do you mean virtual packages?
17:17:16 <bdale> non-free as non-primary dependency is clearly acceptable
17:17:19 <Diziet> cjwatson: Yes.
17:17:19 <rra> Er, yes, sorry.
17:17:22 <rra> I keep using the wrong word.
17:17:23 <vorlon> 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 <dondelelcaro> ok; who wants to take it?
17:17:55 <cjwatson> 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 <Diziet> I don't think we've quite aired enough the virtual package vs. real package thing.
17:18:07 <dondelelcaro> hrm... ok
17:18:08 <cjwatson> I have some ctte-related guilt I'd like to assuage so I wouldn't mind taking on some drafting here.
17:18:13 <vorlon> 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 <Diziet> But I think this needs someone to write up a concrete proposal for me to pick at.
17:18:26 <bdale> 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 <Diziet> bdale: What a bizarre way of putting it.
17:19:07 <bdale> 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 <cjwatson> I suppose it depends whether you think mentioning it as an alternative is somehow explicitly endorsing it.
17:19:19 <Diziet> cjwatson: Precisely.
17:19:26 <bdale> cjwatson: I've never bought into that
17:19:33 <cjwatson> Nor I, but I understand the POV.
17:19:37 <Diziet> I think it's unarguable that it does.
17:19:45 <cjwatson> (I've seen enough packages with giant lists of alternatives ...)
17:19:46 <Diziet> I mean, unarguably it does endorse.
17:19:49 <bdale> I mention Microsoft fairly routinely, I certainly don't endorse them.  And don't even get me started about Apple.
17:19:54 <dondelelcaro> heh
17:20:05 <Diziet> And in the case of foo | foo-nonfree, it's generally sufficient to have foo-nonfree provide foo.
17:20:20 <bdale> really?
17:20:23 <cjwatson> apt-cache show xul-ext-<anything> used to be a good source of giant disjunctions where it wasn't plausible that the maintainer actually endorsed them all.
17:20:29 <vorlon> "generally sufficient" is not the bar I set for things I want to forbid maintainers to do
17:20:36 <Diziet> 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 <Diziet> vorlon: What I mean is that the extra overhead is generally not necessary, so overall it's minor.
17:21:08 <vorlon> 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 <dondelelcaro> 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 <Diziet> I would like the opportunity to disucss it by email.
17:21:38 <dondelelcaro> Diziet: would after a draft be sufficient?
17:21:42 <cjwatson> Sure.  Would you be happy to discuss in the context of ... what he said
17:21:43 <Diziet> IRC is a terrible medium for extended discussion of something where there's significant disagreement.
17:21:46 <Diziet> dondelelcaro: Yes.
17:21:51 <bdale> and/or Diziet can volunteer to deliver a draft?
17:21:57 <dondelelcaro> cjwatson: are you ok with taking the draft to start?
17:22:00 <cjwatson> Yes
17:22:07 <cjwatson> If that's OK with everyone
17:22:12 <bdale> fine with me
17:22:15 <Diziet> I don't think anyone should hold back writing drafts until we've got consensus.
17:22:21 <rra> Good here.
17:22:26 <vorlon> cjwatson: are you drafting both options?
17:22:31 <Diziet> (Even though my recent efforts in that direction haven't necessarily had stellarly wonderful results.)
17:22:34 <cjwatson> vorlon: Yes
17:22:37 <dondelelcaro> #action cjwatson to draft up a resolution to ##681419 alternatives on non-free are ok, and virtual packages are required
17:22:40 <cjwatson> I think I can accurately represent both
17:22:42 <Diziet> cjwatson: I would be happy to draft the other option.
17:22:51 <dondelelcaro> either/or is cool with me
17:23:13 <cjwatson> We can let the best draft win (where best may include whoever-gets-round-to-it-first)
17:23:17 <Diziet> Why don't you draft the "allow" version and I'll put forward my arguments in email.
17:23:22 <cjwatson> OK
17:23:26 <dondelelcaro> sounds good
17:23:29 <Diziet> If I don't persuade anyone I'll write it up as an option and you can vote it down.
17:24:21 <dondelelcaro> I'm going to skip around slightly on the agenda here
17:24:22 <Diziet> #action Diziet to respond to cjwatson's draft
17:24:27 <Diziet> dondelelcaro: OK
17:24:28 <dondelelcaro> #topic #685795 New ctte member
17:24:40 <Diziet> Did we have any applicants ?  If we did I'm not getting the emails.
17:24:50 <vorlon> there were a number of them, yes
17:24:51 <rra> Oh, you're not getting the mail, then.
17:24:53 <Diziet> Oh bum.
17:24:54 <bdale> we have quite a few applications .. you haven't seen them?
17:24:58 <vorlon> sent to the mailing list you set up! :)
17:24:59 <dondelelcaro> Diziet: yes; sorry, I think the alias for you is wrong then... I'll forward them to you
17:25:00 <rra> We've actually gotten an embarassment of riches.
17:25:05 <Diziet> dondelelcaro: Thanks.
17:25:10 <bdale> rra: jinx
17:25:14 <bdale> you type faster than I do...
17:25:22 <Diziet> dondelelcaro: Can you forward me the whole thread with everyone's comments if any ?
17:25:25 <cjwatson> 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 <vorlon> no one has commented so far
17:25:30 <cjwatson> I haven't seen any commentary yet.
17:25:36 <dondelelcaro> Diziet: if you could file an RT ticket to get your alias changed, that'd be awesome, too
17:25:37 <Diziet> We shouldn't discuss the candidates specifically here in public.
17:25:43 <dondelelcaro> right, I agree
17:25:44 <Diziet> dondelelcaro: I will sort that out today.
17:25:49 <Diziet> It's possible it's at my end.
17:25:55 <rra> 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 <bdale> I do think we could talk here about how we want to proceed
17:26:15 <Diziet> bdale: Yes.
17:26:18 <bdale> with such a rich list of candidates, we're going to have to make decisions that aren't easy
17:26:22 <rra> 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 <dondelelcaro> rra: October 1st ish
17:26:41 <rra> Ah, okay.
17:26:57 <rra> 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 <Diziet> 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 <cjwatson> Don has been sending out individual thanks as we go along.
17:27:15 <Diziet> And asking for forbearance as it's going to be a tough decision.
17:27:15 <dondelelcaro> Diziet: I've actually been thanking people for sending in nominations
17:27:23 <bdale> dondelelcaro: thanks for that
17:27:28 <Diziet> dondelelcaro: Good-oh, but I think a feel-good holding mail to d-d-a would be useful.
17:27:46 <dondelelcaro> Diziet: right, sounds reasonable. Or just to d-d or whatever.
17:28:45 <vorlon> if we have feedback about particular applicants, how would we like to see that happen?
17:29:07 <vorlon> should I follow up to each nomination mail, or collate my thoughts in a single mail to the list?
17:29:19 <cjwatson> I was going to collate mine.  I think it'll be easier to write that way anyway.
17:29:20 <Diziet> vorlon: If we have loads of applicants we should try to be systematic.
17:29:35 <bdale> we have loads
17:29:40 <dondelelcaro> I've personally got an org outline; so a collection in a single mail would probably be ideal.
17:29:42 <cjwatson> Should we confirm with the nominees before starting in on discussions?
17:29:44 <bdale> or so it seems to me
17:29:55 <bdale> cjwatson: yes
17:30:00 <cjwatson> We have some self-nominations, but not all.
17:30:01 <Diziet> cjwatson: Certainly.
17:30:06 <bdale> some were self-nominations, those are of course obvious
17:30:13 <Diziet> Should we invite public comments ?
17:30:22 <Diziet> We could make a shortlist and publish it.
17:30:23 <bdale> should I talke on the validation, or does someone else want to?
17:30:30 <bdale> s/talke/take/
17:31:34 <dondelelcaro> 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 <vorlon> right
17:31:49 <cjwatson> In some ways I'd almost rather not publish a shortlist because the quality is generally so good, IYSWIM
17:32:02 <bdale> ok, so we need to confirm who that was nominated by others would agree to serve
17:32:06 <dondelelcaro> cjwatson: yeah, that is sort of my thought too
17:32:07 <bdale> then we have the 'long list'
17:32:10 <dondelelcaro> bdale: right
17:32:11 <cjwatson> But if people feel it'd be good for transparency I don't actually mind as such
17:32:12 <vorlon> 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 <bdale> 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 <Diziet> dondelelcaro: shortlist, passed over> Right.
17:33:45 <dondelelcaro> bdale: I think we should do that in the acknowledgement of the nominations without naming them publicly
17:33:53 <Diziet> bdale: We should not name any nominees publicly at least until we've shortlisted them.
17:33:54 <cjwatson> Is the shortlist for voting among the ctte, or for presentation to zack?
17:34:01 <bdale> Diziet: why not?
17:34:20 <Diziet> bdale: Because we will invite negative comments about candidates some people feel obviously unsuitable.
17:34:33 <rra> 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 <Diziet> And I would like to publish a list which is purely postive.
17:34:46 <bdale> rra: right, ergo my mention of 'the long list'
17:34:56 <rra> Ah, yes, right.  I'm with you now.
17:35:04 <Diziet> That is, if we publish all the willing nominees and later publish a shortlist we've said something negative about people.
17:35:07 <bdale> clearly in my mind anyone willing to serve deserves public recognition of that fact
17:35:11 <rra> I have Diziet's concern too, but would also like to thank people, so I'm torn.
17:35:14 <bdale> if that "draws attack", then so be it
17:35:31 <bdale> why would we ever publish a "short list"?
17:35:34 <dondelelcaro> 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 <bdale> 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 <dondelelcaro> 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 <bdale> do that on the long list
17:36:16 <vorlon> do we?
17:36:17 <Diziet> 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 <bdale> much les contentious
17:36:35 <vorlon> this is a TC+DPL decision
17:36:37 <dondelelcaro> true
17:36:58 <vorlon> I don't know that public discussion is useful, and it certainly carries risk of being contentious
17:37:04 <Diziet> 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 <bdale> 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 <Diziet> public discussion> God, no.
17:37:19 <Diziet> 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 <Diziet> We definitely must not have public discussion.
17:38:19 <dondelelcaro> ok; I'm happy to not have public discussion so long as there's public commentary to the private list
17:38:40 <Diziet> 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 <rra> 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 <bdale> 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 <vorlon> 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 <vorlon> (i.e., I'm not sure even private commentary from the public is useful)
17:39:27 <Diziet> We have a pretty limited experience of the whole project.  I think getting data is important.
17:39:32 <bdale> it may not be, but making it clear that we're willing to listen seems valuable
17:39:54 <vorlon> btw, do I have the right count here? 6 nominees?
17:39:59 <Diziet> We should write the call for comments carefully.
17:40:08 <bdale> 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 <rra> 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 <thing I'd never heard about before>, that would be really useful.
17:40:19 <bdale> Diziet: of course
17:40:35 <cjwatson> vorlon: That's my count so far.
17:40:46 <Diziet> 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 <bdale> but whatever, short == long, it's all good
17:41:37 <bdale> ok
17:41:45 <Diziet> My point was that if we have 20 nominees we shouldn't invite feedback on them all.
17:41:46 <bdale> so the process starts with verifying everyone nominated wants to be included
17:41:49 <Diziet> bdale: Yes.
17:41:52 <dondelelcaro> right
17:42:20 <Diziet> Those who say "no" we thank privately and don't mention publicly.
17:42:25 <dondelelcaro> I'll draft the announcement mail, and bounce it to -private once bdale confirms
17:42:36 <bdale> 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 <bdale> Diziet: yes
17:42:46 <dondelelcaro> right
17:42:52 <Diziet> I'm happy with that if we don't get a sudden last-minute rush.
17:43:01 <bdale> I suspect we won't
17:43:03 <Diziet> If we have 10 candidates we might want to think about shortlists.
17:43:11 <bdale> we have a nicely diverse set so far, to my mind
17:43:16 <Diziet> But we can cross that bridge when we come to it.
17:43:19 <dondelelcaro> #action bdale to confirm that non-self nominees wish to serve
17:43:20 <bdale> yes
17:43:38 <bdale> wilco
17:43:45 <dondelelcaro> #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 <Diziet> As for our selection process: I would like us to try to structure our deliberations.
17:44:15 <bdale> Diziet: that's fine.  suggest you review the list of candidates soon
17:44:18 <Diziet> 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 <Diziet> bdale: Will do.
17:44:42 <rra> That's a good idea, I think.  If we do that, we should publicly discuss the criteria, I think.
17:44:46 <Diziet> Yes.
17:44:50 <rra> Er, too many thinks.  :)
17:44:57 <bdale> hrm
17:45:00 <Diziet> Thinking is good :-).
17:45:08 <rra> We have one stated public criteria so far, namely increased diversity.
17:45:21 <bdale> will require some care to discuss criteria without telegraphing opinions about individuals beyond a general increase diversity mantra
17:45:27 <Diziet> rra: Yes, but of course our other criteria are implicit.
17:45:32 <Diziet> bdale: As you say.
17:45:38 <rra> There are a few other ones that are obvious (general experience with Debian, proven track record of technical expertise).
17:45:56 <Diziet> Other criteria> Eg, being right in technical conversations, being a quick learner, being able to handle conflict well, whatever.
17:46:17 <bdale> I'm all for a deliberate process, as long as we don't bog down
17:46:26 <Diziet> Exactly.  My point is that we should try to capture all the important criteria and thus exclude irrelevancies.
17:46:40 <rra> 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 <Diziet> This is a proven way of helping escape cognitive biases.
17:46:53 <Diziet> rra: Yes.
17:47:11 <Diziet> The opinions can be quite short.  "Excellent" "unsure" or whatever.
17:47:16 <rra> True.
17:47:41 <rra> 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 <dondelelcaro> 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 <bdale> ok, feels like we have a plan .. time to move on?
17:47:55 <Diziet> dondelelcaro: I will do it on -ctte
17:47:59 <dondelelcaro> sounds good
17:48:02 <rra> Works here.
17:48:03 <Diziet> #action Diziet to propose selection criteria on -ctte
17:48:08 <dondelelcaro> #topic #688772 gnome Depends on network-manager-gnome
17:48:36 <dondelelcaro> (saved this one for second to last, since I figured it would take the most time)
17:48:40 <Diziet> 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 <cjwatson> (I can't stay too much longer.  Maybe 20 minutes.)
17:49:01 * rra has about 12 minutes myself.
17:49:05 <dondelelcaro> ok
17:49:26 <rra> Diziet: Thank you, and apology accepted here, and I appreciate your willingness to apologize there.  Been there, done that myself.
17:49:55 <Diziet> col: Next time I seem to be doing the same thing feel free to remind me of this time...
17:50:02 <cjwatson> Heh
17:50:11 <vorlon> Diziet: :)
17:50:20 <cjwatson> 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 <vorlon> Diziet: fwiw I do think that starting the discussion with a draft resolution sets a very confrontational tone
17:50:37 <cjwatson> Which may or may not be true but it doesn't make for good impartial wossname.
17:50:42 <vorlon> as a general rule
17:51:09 <rra> 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 <cjwatson> To some extent I think this is an inevitable consequence of having been very quiet for some time.
17:51:36 <bdale> it's also fascinating after years of being chided for not taking actions
17:51:38 <Diziet> 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 <rra> 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 <Diziet> so mu$%
17:52:34 <bdale> rra: yes
17:52:39 <Diziet> But yes I agree.
17:52:40 <rra> 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 <dondelelcaro> right
17:53:07 <bdale> 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 <Diziet> 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 <rra> 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 <bdale> a behavior that "forces" a choice on an end user is not empowering that user
17:53:29 <rra> I'm not sure where that line is, but I know it exists.
17:53:32 <Diziet> Surely that includes without fear or favour towards an internal power structure.
17:53:43 <vorlon> 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 <Diziet> bdale: Exactly.
17:53:55 <cjwatson> 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 <bdale> 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 <Diziet> 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 <cjwatson> 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 <cjwatson> (I mean I can't say I agree that it's actually the best thing.)
17:54:46 <Diziet> cjwatson: Yes, that's fine, for these purposes we should indeed assume good faith.
17:54:47 <bdale> 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 <Diziet> cjwatson: But that doesn't mean we have to agree with it.
17:55:01 <cjwatson> Thus I think framing it in terms of maintainers vs. end users is actually kind of presupposing the answer.
17:55:09 <rra> 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 <dondelelcaro> right
17:55:46 <bdale> 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 <Diziet> cjwatson: I find it difficult to see how using Recommends in this case can be criticised as not good for users.
17:56:14 <bdale> rra: I completely agree, so what we need to focus on are the *mechanisms* in question
17:56:21 <Diziet> 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 <bdale> in this case, a hard depends empowers a maintainer over an end user
17:56:46 <vorlon> 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 <vorlon> what are some other ways to get the desired behavior on upgrade?
17:57:01 <rra> 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 <bdale> it's not clear to me that there are any
17:57:29 <jcristau> what's the desired behavior?
17:57:31 <vorlon> 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 <vorlon> would that be an appropriate compromise?
17:57:47 <Diziet> 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 <bdale> 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 <vorlon> Diziet: for the sake of argument - or rather, for the sake of possibly side-stepping the argument ;)
17:58:22 <rra> Although hm.
17:58:39 <Diziet> 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 <cjwatson> 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 <vorlon> yes
17:59:02 <bdale> jcristau: the desired behavior, if we believe in empowering end users, is that choices they've made aren't over-ridden?
17:59:03 <cjwatson> So it's not clear to me that "automatically run service" would be a compromise he would accept
17:59:04 <rra> 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 <Diziet> 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 <vorlon> 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 <cjwatson> And thus I don't see how it would be a useful compromise in that sense
17:59:21 <Diziet> The only reasons being advanced are essentially that it would keep the maintainers happy.
17:59:22 <rra> jcristau: Yeah, that's an excellent question and I'm not sure I have a good answer.
17:59:39 <rra> So, there are a few things we could try to accomplish.
17:59:41 <jcristau> bdale: that's not really a behavior..
17:59:57 <rra> 1. Maintain user's existing stated preferences around whether n-m is being used to manage their network.
17:59:58 <vorlon> 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 <cjwatson> I think that's absolutely a behaviour of the whole system
18:00:07 <jcristau> 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 <rra> 2. Deliver to the user the integrated experience that GNOME is attempting to achieve.
18:00:12 <jcristau> even if nm does get installed
18:00:12 <cjwatson> It's not a static behaviour of a given Debian installation when it's not being upgraded
18:00:19 <Diziet> vorlon: IMO we should vote to uphold our previous decision.
18:00:21 <cjwatson> But it's certainly a behaviour of Debian as a whole
18:00:22 <bdale> 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 <jcristau> but i'm not quite sure what the other objections are
18:00:29 <KiBi> that's being discussed on the d-i side, in case anyone cares
18:00:49 <rra> 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 <KiBi> (moving the installation logic to d-i, scraping out the /e/n/i munging from NM.)
18:00:58 <Diziet> Can anyone present a technical reason to prefer Depends to Recommends ?
18:01:00 <jcristau> 'nm is not installed' isn't really a 'choice', in itself
18:01:14 <vorlon> 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 <bdale> rra: "fundamentally different" kind of argues for a new meta-package, though, doesn't it?
18:01:37 <rra> 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 <cjwatson> 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 <cjwatson> *disable
18:01:48 <Diziet> 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 <vorlon> no
18:02:11 <jcristau> rra: lots of people disable recommends though
18:02:25 <bdale> jcristau: why is that a problem?
18:02:32 <rra> 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 <vorlon> 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 <Diziet> rra: That's not a goal.  _Why_ would you want to force it ?
18:02:56 <cjwatson> jcristau: I am in complete agreement with http://lists.debian.org/debian-ctte/2012/07/msg00146.html on that subject
18:02:59 <Diziet> Against the wishes of the user ?
18:03:01 <rra> jcristau: I would love to have numbers on that, actually.  I wonder if we could get popcon to gather that.
18:03:09 <vorlon> repeatedly overriding those maintainers lets us get our way, but it's short-sighted and demotivating
18:03:17 <rra> Diziet: Well, I think there's disagreement over what the wishes of the user are.
18:03:39 <Diziet> 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 <dondelelcaro> Diziet: that assumes that the maintainer is acting in bad faith
18:04:09 <cjwatson> 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 <rra> 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 <bdale> cjwatson: yes, true
18:04:32 <Diziet> 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 <bdale> I struggle with this a lot, conceptually
18:04:40 <rra> 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 <vorlon> Diziet: I'm not backing down from anything
18:04:56 <cjwatson> (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 <bdale> 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 <Diziet> more tightly integrated> This is not a real reason IMO.
18:05:03 <waldi> rra: did the maintainer provide this argument or is this yours?
18:05:13 <rra> waldi: I don't know.  That's part of why I'm frustrated.
18:05:20 <vorlon> 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 <rra> waldi: It's possible that's what Josselin meant.  But I'm not at all sure.
18:05:24 <Diziet> waldi: It's rra's.
18:05:30 <bdale> 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 <Diziet> 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 <dondelelcaro> 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 <rra> 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 <dondelelcaro> Diziet: it's always ok to make arguments for both sides
18:06:43 <bdale> rra: right.  which brings me back to focusing on the upgrade experience.
18:06:45 <dondelelcaro> we certainly want to know the maintainer's logic, but we don't need to be limited to it
18:06:51 <Diziet> dondelelcaro: Well yes, but I think you should make arguments that you believe in.  Rather than supposing ifs and buts.
18:07:03 <jcristau> 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 <jcristau> popov, even
18:07:11 <Diziet> jcristau: We have that.
18:07:12 <dondelelcaro> jcristau: that's actually already been done
18:07:13 <rra> 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 <cjwatson> jcristau: Jakub posted that.
18:07:17 <jcristau> oh
18:07:18 <dondelelcaro> jcristau: it's 5%
18:07:19 <Diziet> According to the popcon data, 1812 out of 31630 the "gnome" metapackage
18:07:19 <Diziet> users don't have the "network-manager" package installed.
18:07:20 <waldi> jcristau: this have been answered already
18:07:24 <Diziet> jcristau: ^ from Jakub
18:07:25 <jcristau> ok
18:07:46 <bdale> rra: I empathize with your need to empathize, I share it
18:07:47 <vorlon> we seem to have overrun the time limit rra and cjwatson imposed :)
18:07:53 <Diziet> rra: My mental model is that this is to do with religion.
18:07:58 <vorlon> I think this needs further discussion with the GNOME maintainers
18:08:00 <dondelelcaro> right
18:08:10 <Diziet> Can we please set a deadline for reply ?
18:08:12 <dondelelcaro> lets follow this up with the gnome maintainers and see if we can figure it all out
18:08:17 <bdale> 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 <dondelelcaro> why don't I follow up about it
18:08:39 <bdale> dondelelcaro: thank you
18:08:39 <Diziet> Would a week be enough ?
18:08:46 <dondelelcaro> #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 <dondelelcaro> #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 <dondelelcaro> Diziet: I think they'll respond fairly quickly; if not, we can cross that bridge then
18:09:17 <Diziet> dondelelcaro: then> Do you mean in a month's time ?
18:09:31 <rra> 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 <Diziet> 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 <dondelelcaro> Diziet: uh... no. If they haven't responded within a resonable period of time, then we can re-prod them
18:09:55 <cjwatson> 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 <Diziet> rra: I think I do understand the reasons.  They have been extensively stated and amount to doctrine from GNOME upstream.
18:10:11 <cjwatson> Because that to me is the core of my confusion with the tighter-integration argument.
18:10:20 <dondelelcaro> Diziet: but imposing a deadline on them is presuming that they are not going to respond, and antagonistic
18:10:27 <rra> Diziet: Well, I think that's a different thing than it being religious.
18:10:37 <bdale> dondelelcaro: it's also moderately pragmatic if we want this fixed in wheezy
18:10:39 <Diziet> 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 <rra> "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 <Diziet> rra: Err, I must not have made myself clear then.  They seem equivalent to me.
18:10:59 <dondelelcaro> right, we should work to resolve this within the month
18:11:06 <bdale> if you can just find them and have a conversation and come away with clarity, that's ideal
18:11:39 <Diziet> 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 <dondelelcaro> #topic Additional Business
18:12:08 <vorlon> I have a pathetic wishlist request
18:12:25 <dondelelcaro> sure
18:12:33 <vorlon> is there any chance somebody here would be willing to provide the meeting schedule as an iCal feed? :)
18:12:40 <dondelelcaro> vorlon: yeah, I can do that
18:12:41 <bdale> seconded
18:12:44 <vorlon> ok cool
18:12:55 <dondelelcaro> would it being in the git repository be good enough?
18:13:04 <dondelelcaro> I'll put the future tentative meetings in there too
18:13:23 <vorlon> dondelelcaro: only if that results in a well-formed, stable ical url I can point my calendaring software at
18:13:57 <vorlon> emails, or things I have to poll, manage to not get where they need to be
18:13:58 <jcristau> "i don't want nm installed no matter what" sounds religious to me...  oh well.
18:13:59 <dondelelcaro> 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 <bdale> jcristau: what if it's really "I'm a developer of <choose-an-nm-alternative> and I'd like to use it instead of n-m" .. still religious?
18:14:41 <cjwatson> I don't think characterising either side as religious is particularly helpful, really.
18:14:51 <bdale> I don't either
18:14:55 <dondelelcaro> #action dondelelcaro to shove calendar into git and serve using ical-able linkage
18:14:56 <vorlon> 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 <cjwatson> It's not going to persuade anyone and it doesn't help us explore technical reasons.
18:14:57 <bdale> them's fightin' words!
18:15:02 <vorlon> s/every day/every week/
18:15:17 <rra> 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 <bdale> vorlon: me too.  I didn't have this on my calendar until this morning, thanks to dondelelcaro for the poke
18:15:26 <rra> But if not, I'd still want to use wicd.
18:15:29 <jcristau> bdale: yes, if you can have both nm and your alternative installed and choose which of them manages your network interfaces
18:15:33 <cjwatson> those bu$, but I think I know what you mean
18:15:46 <dondelelcaro> ok... any objection to stopping here?
18:15:52 <dondelelcaro> [discussion can continue, of course]
18:16:01 <jcristau> maybe that's not possible now, i wouldn't know.  but that's not quite the same thing.
18:16:04 <dondelelcaro> #endmeeting