Add Sep & Oct meetings, as tentative

[debian-ctte.git] / meetings / 20120531 / ctte_meeting_may_31_2012.txt

09:59:25  * rra is here.
10:00:02  * zack waves, I've proposed to the -ctte the idea of IRC meetings to periodically review pending issues, and in particular suggested to have this 1st meeting
10:00:13 <zack> beside that, I'm here mostly as a lurker, or in case my input is desired
10:01:05 <Ganneff> are "outsiders" supposed to speak or shutup?
10:01:49 -!- vorlon [~vorlon@becquer.dodds.net] has joined #debian-ctte
10:01:51  * vorlon waves
10:01:55 <Diziet> Hi all.
10:02:00 <dondelelcaro> I guess if they have something useful to say, it should be a problem... but if it becomes one, we make things more authoritarian
10:02:06  * rra waves.
10:02:07 <zack> Ganneff: I guess that if we outsiders shut up, unless asked otherwise, it will make it things simpler
10:02:16 <dondelelcaro> s/should/shouldn't/
10:02:28 <vorlon> so do we have an agenda? :)
10:02:32 <dondelelcaro> bdale: did you manage to make things work?
10:02:37 -!- Topic for #debian-ctte: Next meeting May 31st 1700 UTC (date -d @1338483600) | Open issues: #614907: node <-> nodejs conflict, #573745: python maintainer; #636783: super-majority conflict; #552688: hardening build flags  
10:02:37 -!- Topic set by dondelelcaro [~don@hemlock.ucr.edu] [Thu May 31 09:40:25 2012]
10:02:40 <rra> The channel topic is probably not a bad agenda.
10:03:04 <rra> I'd like to start by taking five minutes to dispose of #552688.
10:03:15 <dondelelcaro> sounds good to me
10:03:23 <Diziet> rra: Go ahead.
10:03:48 -!- mhy [~mark@gw.mhy.org.uk] has joined #debian-ctte
10:04:10 <rra> The hardening build flags have basically been resolved; I think the only question is whether we should just close the bug or whether we should hold a vote on it for the record.  I'm happy to call for the vote, and I sent mail explaining why it made sense to me to vote on it, but the more I thought about it, the more I wasn't sure that logic was right.
10:04:23 <rra> So I wanted to poll people here: should we vote on it for the record, or should we just close it?
10:05:00 <dondelelcaro> it doesn't matter to me; since the outcome is acceptable, I think we can just close it unless someone disagrees
10:05:07 <Diziet> In general I would be happy just to close it.  It has often been the case that TC members' intervention has got things sorted without making a formal resolution and we generally haven't recorded those either.
10:05:41 <Diziet> If we want it for `PR purposes' if you like, then perhaps we should start a new list of `issues resolved after they were brought to the TC but without the need for a formal vote'.
10:05:53 <Diziet> But I don't feel strongly.
10:06:29 <rra> I think that might not be a bad idea, but it's way down in my priority list and I should probably use those resources to catch up on Policy or whatnot.  So if someone wanted to track that, I have no objections, but I'm not volunteering.  :)
10:06:44 <vorlon> I found the argument to vote on it for the record persuasive, but maybe I haven't thought about it as much as you yet
10:07:27 <vorlon> but as it seems there's no strong feeling either way, I guess it's better to close the issue out rather than spending the energy on a formal vote
10:08:08 <rra> If anyone involved wanted whatever authoritative blessing a formal vote would convey, I think my argument would be stronger, but in this case I don't think that's the case.
10:08:22 <Diziet> Indeed.  If anyone involved wanted it then we should do it.
10:08:34 <vorlon> rra: you'll close the bug as resolved, then?
10:08:39 <rra> Okay.  Well, closing is reversible in case anyone who isn't here wants to do something different, so I'll just close it after this meeting.
10:08:47 <dondelelcaro> cool
10:08:50 <rra> We can always re-open if someone objects.
10:08:50 <vorlon> [ACTION] rra to close bug #552688 as resolved
10:09:01 <Diziet> OK
10:09:08 -!- dondelelcaro changed the topic of #debian-ctte to: Next meeting May 31st 1700 UTC (date -d @1338483600) | Open issues: #614907: node <-> nodejs conflict, #573745: python maintainer; #636783: super-majority conflict; #552688: hardening build flags [rra will close as resolved] 
10:09:09  * vorlon wants a meetingbot ;)
10:09:17 <Ganneff> (hint: for the future meetings you should invite meetbot)
10:09:24 <Ganneff> talk to "darst"
10:09:43 <Diziet> Shall we do `node' next ?
10:09:51 <dondelelcaro> sure
10:09:52 <vorlon> sure
10:09:54 <rra> Works for me.
10:10:16 <Diziet> OK.  So we had a plan that would involve allowing the ax25 version to leave a symlink behind to avoid breaking existing systems.
10:10:39 <Diziet> If we do that then new installs of ax25 wouldn't have `node' and of course nodejs wouldn't have it either.
10:11:13 <vorlon> FYI, my mail to the nodejs author requesting an upstream rename has gone unanswered
10:11:17 <Diziet> That seems to have been the last concrete thing proposed; there's been a lot of moral theorising too if I can put it like that.
10:11:26 <Diziet> vorlon: I can't say I'm surprised.
10:11:34 <rra> It sounded like Patrick Ouellette was basically okay with that, although there was a lot of conflict in that mail thread, so I'm not certain.
10:11:36 <vorlon> so we don't have a solution that both satisfies policy and avoids breaking upstream expectations / documentation
10:11:44 <rra> Basically okay with the ax25 renaming, that is.
10:12:06 <Diziet> So the question is: do we need to discuss any further ?
10:12:10 <Diziet> Do we need any more information ?
10:12:22 <bdale> hi
10:12:25  * bdale is at a car dealership with his wife, multitasking
10:12:26 <Diziet> There is a concrete option, as I describe above, which I could write up as a proposal.
10:12:30 <Diziet> Hi.
10:12:30 <bdale> as a long time ham radio guy and former user of the ax25 code, it seems to me that changing the ham flavor makes sense, though I agree with Diziet's concern about letting folks just show up and grab name space
10:12:36 <rra> Realistically, I think that Node.js should at least have an option to be /usr/bin/node via some mechanism other than manual intervention by the local sysadmin, not because I want to reward upstream behavior here, but because I think that's best for our users.
10:13:00 <rra> I'm happy for that option to not be the default.
10:13:01 <Diziet> rra: A low-priority debconf question ?
10:13:07 <rra> But I think it's going to be surprising if it's not available.
10:13:12 <dondelelcaro> yeah
10:13:23 <Diziet> We should set the maximum priority.
10:13:55 <rra> Yeah, debconf would be okay.  From a user perspective, I'm not sure low makes sense.  The goal is to keep people from being confused, and having the question be suppressed in most installations isn't really helpful there.
10:13:58 <Diziet> `best for our users'> I hate this phrase.  It's tendentious.  Because the moral hazard is bad for all our users in the future.
10:14:10 <rra> Good point.
10:14:33 <Diziet> Also we should be using our weight to help stop upstreams doing crap like this.
10:14:38 <dondelelcaro> wasn't the option proposed that nodejs would get /usr/bin/node IFF node wasn't installed, that both should use a different name for the binary, and that node should use /usr/bin/node IFF nodejs wasn't installed, and if both were installed, they should have a coordinating debconf question or something?
10:14:40 <rra> What I'm trying to say is that people who just want to use Debian to get something done are going to be surprised by Node.js being available but not called what it's called elsewhere, and I'm not sure that we gain anything by not providing that.
10:14:51 <Diziet> See also how the KDE licence fiasco was `bad for our users' but big projects don't make that kind of mistake nowadays.
10:14:52 <bdale> Diziet: right, but I suspect we're already to the point where node.js users outnumber users of the ax25 code, and probably trending hard in that direction
10:14:54 <vorlon> so regardless of other mitigation, if we decide nodejs will be /usr/bin/nodejs and not /usr/bin/node by default, I think someone on the TC should communicate this to the upstream mailing list
10:15:17 <rra> Debian refusing to call Node.js node is more likely to just cause upstream to call us bad names or ignore our other concerns than it is to actually change anyone's behavior, IMO.
10:15:34 <Diziet> rra: If they call us bad names in public so much the better.
10:15:37 <vorlon> upstream has already staunchly ignored our concerns
10:15:47 <vorlon> so I'm not sure there's much to be lost there
10:15:58 <vorlon> (and not just our concerns, but other distributions' as well)
10:16:02 <Diziet> It's the _next upstream_ who is thinking of doing the same thing.
10:16:04 <bdale> rra: sadly, you're probably right.  it's one of the reasons that I really hate it when we fail to address name space conflicts quickly when they first show up.
10:16:09 <Diziet> And it's not `everywhere else' since AIUI Fedora have decided to rename too.
10:16:23 <rra> Diziet: I think those are unofficial Fedora packages, not actually Fedora proper.
10:16:34 <rra> They ironically even seemed to be from Node.js upstream.
10:16:40 <vorlon> bdale: my understanding is that efforts were made to address this upstream, to no avail
10:16:47 <Diziet> rra: Lots of stuff in the rpmish universe is unofficial packages; that's just how they do things there.
10:16:59 <bdale> I think requiring that both have something other than 'node' as a primary name makes sense .. having it be easy for the node.js variant to also be /usr/bin/node seems to meet both concerns?
10:17:02 <rra> Right, I'm just saying that I don't think we can accurately say that "Fedora" decided to do something.
10:17:12 <rra> bdale: That's where I'm at, yes.
10:17:40 <Diziet> That is, I accept that there will this pain for node.js users.  But I hope that if this turns into a big deal and lots of complaints from upstream, that it might help next time an upstream is being <censored>
10:18:12 <bdale> Diziet: I wish that were true, I have little faith that it will work out usefully that way
10:18:25 <vorlon> if we're going to make it easy to be /usr/bin/node, what is the argument for not making it the default?
10:18:38 <Diziet> `Act as if the guiding principle etc. etc. universal law etc. etc.'
10:18:42 <bdale> the ax25 version is in /usr/sbin, right?
10:18:47 <vorlon> yes
10:18:57 <rra> Carsten had a pretty extensive analysis of the possible options here.  Let me go dig that up again.
10:19:00 <bdale> so there's no actual conflict, just potential confusion?
10:19:05 <Diziet> vorlon: We want to encourage the world to make software which works with #!/usr/bin/nodejs
10:19:09 <rra> bdale: There's a conflict with unqualified binaries.
10:19:19 <rra> If you run "node" and have /usr/sbin first in your path, you're probably unhappy.
10:19:29 <rra> And what you get changes randomly based on your PATH.
10:19:36 <vorlon> Diziet: and we'll do that even if upstream doesn't provide that path?
10:19:44 <vorlon> do we expect this to be successful? :)
10:19:49 <Diziet> vorlon: Yes.  It might well be.
10:19:53 <bdale> sorry, as I said I'm in a weird physical space atm and multitasking
10:19:54 <bdale> rra: sure .. I get that .. I always have sbin dirs in my path
10:20:01 <dondelelcaro> vorlon: https://github.com/remy/nodemon/issues/68 (issues with the "fedora supplied node")
10:20:23 <dondelelcaro> so it looks at least like people are writing stuff use nodejs instead of node on fedora
10:20:35 <Diziet> vorlon: Because upstream don't control distros and distros will see the same issues as we do.
10:21:04 -!- jcristau [~jcristau@irc.cristau.org] has joined #debian-ctte
10:21:08  * vorlon nods
10:21:18 <dondelelcaro> from my perspective, it seems clear that nodejs needs to provide /usr/bin/nodejs; the only question then is what to do with /usr/bin/node
10:21:21 <Diziet> It wouldn't be the first time distros had decided to do something which an upstream didn't like.
10:21:29 <rra> I think Carsten's message was only in debian-devel.
10:21:37 <rra> dondelelcaro: Agreed.
10:21:43 <Diziet> dondelelcaro: Yes.
10:21:58 <Diziet> I would like it not to be provided by default.
10:22:03 <vorlon> anyone have a pointer to the message that describes what we think we want to endorse?
10:22:43 <Diziet> <mXe7vGcXEYO.A.hdB.dKZpPB@bendel>
10:22:52 <Diziet> Sent to debian-ctte.
10:22:58 <Diziet> Is relevant but not the definitive proposal.
10:23:02 <Diziet> We don't need to dig that out though.
10:23:07 <vorlon> <20120506172918.GC32011@virgil.dodds.net> was my position, fwiw
10:23:10 <Diziet> Not in this meeting anyway.
10:23:12 <rra> Carsten had a concrete proposal but it only went to debian-devel.  I'm trying to find it.
10:23:34 <bdale> Diziet: when you say not be default, what's your feeling on a debconf question to add the link?
10:24:24 <Diziet> I want it not to be the default to add the link, and the question should be of low enough priority that most installs don't see it (since node.js might well turn out to be a dependency for things and those things' users don't want to be asked lots of questions).
10:24:29 <vorlon> is a debconf question better than a compat package?  (I think it's worse)
10:24:34 <rra> I think there are two options for the link: a debconf package, and a separate package.  Fedora did a compat package.
10:24:40 <rra> I think a compat package may make somewhat more sense.
10:24:41 <Diziet> I don't mind whether it's a package or a question.
10:25:02 <rra> I'm not sure where Carsten's message went now, since I can't find it in debian-devel either.
10:25:03 <vorlon> we could stipulate that no packages in Debian are allowed to depend on the compat package or reference /usr/bin/node
10:25:11 <Diziet> If it's a package then nodejs shouldn't even Suggest it.
10:25:15 <bdale> ok, I agree that /usr/bin/nodejs should be the name provided by the package.  I'm personally ok if there's no automatic provision of /usr/bin/node at all.
10:25:15 <rra> Yeah, and that's an easy thing for Lintian to check for.
10:25:23 <Diziet> vorlon: Yes.
10:25:47 <bdale> yes, a lintian rule that flags /usr/bin/node as probably wrong sounds like a great idea
10:25:57 <rra> I concur on the concern about asking Debconf questions when the package is pulled in via a dependency.
10:25:59 <Diziet> bdale: I would also be happy with no automatic provision but I get the impression that that's a minority view.
10:26:04 <vorlon> rra: yeah, I didn't remember/find a complete proposal from Carsten; I only saw http://lists.debian.org/debian-ctte/2012/05/msg00033.html
10:26:17 <rra> vorlon: I think he may have only sent it to me.
10:26:21 <vorlon> ok
10:26:22 <Diziet> lintian> /usr/dict/words ? :-)
10:27:08 <bdale> Diziet: I'm not sure we need to be prescriptive about how /usr/bin/node might be linked.  if we declare that the canonical name in the package should be /usr/bin/nodejs, isn't the rest simply a matter of choosing whatever approach users/admins/package maintainers want that's within policy?
10:27:21 <Diziet> I don't really see why the ax25 compat symlink needs a whole package.  It could just be left as cruft during upgrade.
10:27:21 <vorlon> it might be useful to write up the current proposal on a whiteboard of some kind - shall I throw together a wiki page?
10:27:35 <rra> Part of the complexity here is to figure out how to handle the compatibility symlink for ax25's node during upgrades with a compat package in cases where you might install and remove the compat package.  Other edge cases like that.  It's probably not worth talking about here as opposed to just asking someone to write something up in mail.
10:27:49 <Diziet> rra: Right.
10:28:11 <Diziet> rra: I think the rules re ax25 are:  Old installations should get the symlink.  New installations should not.
10:28:16 <dondelelcaro> http://whiteboard.debian.net/nodejs_proposal.wb
10:28:20 <dondelelcaro> vorlon: ^^
10:28:44 <rra> Diziet: I think one of the concerns was that installing and then removing the nodejs compat package would blow away the symlink for the ax25 node package, and a question is whether we're okay with that.
10:29:01 <Diziet> rra: I think I'm unhappy with it.
10:29:12 <bdale> why would it do that, if the path to the two links would be different?
10:29:13 <Diziet> That's an argument for compat packages for both or neither.
10:29:21 <rra> bdale: Oh, right, good point.
10:29:32 <Diziet> But it might break your system while you had nodejs-node installed ?
10:29:45 <Diziet> (and stop you fixing it for aforementioned connectivity reasons)
10:29:46 <bdale> I'm back to the 'there's no real conflict, just potential confusion' thing
10:30:53 <vorlon> So it sounds like we're moving in the direction of <87aa1nnl0b.fsf@poker.hands.com>
10:31:03 <bdale> to break a system, it requires an unqualified use of 'node' and a path that puts the wrong one first, right?
10:31:05 <bdale> that feels low probability to me, but I agree that if we can get it right so that it doesn't happen that's a good plan
10:31:48 <Diziet> So if we want either both or neither to have compat packages our options are (a) compat packages for both (b) manual symlink for both.
10:31:54 <bdale> is there an easy way to dereference a message-id online?  I don't have that msg on my notebook.
10:32:02 <rra> bdale: Yeah, that's correct.  And one concern from the ham community was that apparently the existing node isn't only run from inetd or the equivalent, but may also be run from complex local scripts.
10:32:02 <jcristau> lists.debian.org/$m-id
10:32:08 <dondelelcaro> bdale: http://lists.debian.org/debian-devel/2012/05/msg00210.html
10:32:16 <bdale> dondelelcaro: thanks
10:32:27 <bdale> jcristau: thanks, I didn't know that
10:32:34 <Diziet> Since both sides have to do the same thing and they're arguing I think we need to choose between compat packages or manual symlinks.
10:32:34 <jcristau> (or mid.gmane.org/$m-id)
10:32:43 <rra> vorlon: Yes, that's the basic proposal that I remember, and that seems reasonable to me on first glance.  I think Carsten had some improvements for edge cases.
10:32:56 <vorlon> ok, http://whiteboard.debian.net/nodejs_proposal.wb has a concrete layout for the compat packages
10:32:57 <Diziet> I would prefer manual symlinks (with perhaps a debconf question on the nodejs side).
10:33:06 <vorlon> do those look sensible?
10:33:18 <bdale> looking
10:33:19 <rra> I don't want to force the ax25 folks to create a manual symlink; we should transparently handle their upgrade.
10:33:41 <Diziet> rra: OK.  And doing that transparency with a diversion in the preinst is hideous.  OK.
10:33:47 <Diziet> So we're into compat packages.
10:34:12 <rra> I think supporting upgrades from the existing node package is very important.  That's a committment that we try to make as a project: we don't break people's stuff on upgrades unless we have no other options.
10:34:20 <Diziet> rra: I agree.
10:35:03 <rra> Yup, the proposal on the whiteboard looks good to me.
10:35:16 <Diziet> We also need to specify that the priority of nodejs-legacy is extra.
10:35:50 <Diziet> And it's not in tasks etc.
10:35:50 <rra> Yup.
10:35:54 <vorlon> ok
10:35:55 <bdale> and having node conflict on nodejs-legacy is to prevent the unqualified name confusion?
10:35:59 <vorlon> bdale: yes
10:36:04 <bdale> ok
10:36:18 <bdale> I'm good with what's on the wb
10:36:18 <vorlon> since it's still a namespace collision on the path, even if not on the filesystem
10:36:27 <bdale> vorlon: agreed
10:36:29 <vorlon> any objections / further refinements to what's there now?
10:36:44 <bdale> just making sure I'm actually awake
10:36:51 <vorlon> if not, I'm happy to take the action to write it up for a vote
10:36:58 <rra> Works for me.
10:37:00 <Diziet> Looks good to me.
10:37:01 <Diziet> Thanks.
10:37:05 <dondelelcaro> sounds good to me too; thanks
10:37:07 <rra> We can hammer out further edge cases over email.
10:37:14 <rra> If any come up.
10:37:18 <vorlon> [ACTION] vorlon to write up a resolution for bug #614907 based on http://whiteboard.debian.net/nodejs_proposal.wb
10:37:38 <rra> Okay, we have a little more than 20 minutes left; if we're going to talk about Python, we should probably do that now.
10:37:39 -!- dondelelcaro changed the topic of #debian-ctte to: Next meeting May 31st 1700 UTC (date -d @1338483600) | Open issues: #614907: node <-> nodejs conflict [vorlon to write up resolution], #573745: python maintainer; #636783: super-majority conflict; #552688: hardening build flags [rra will close as resolved]  
10:37:40 <bdale> vorlon: please make it a simple vote between this resolution and further discussion
10:37:44 <vorlon> bdale: ack
10:38:27 <bdale> rra: ok .. where do we stand?
10:38:32 <Diziet> Can I briefly mention parallel now ?
10:38:39 <Diziet> I think it's shorter than the other two.
10:38:50 <bdale> Diziet: ok
10:38:55 <Diziet> Based on the emails I'm seeing I think there's still some conflict going on.
10:39:04 -!- Mithrandir [~tfheen@vuizook.err.no] has joined #debian-ctte
10:39:08 <Diziet> At least some people are unhappy with what each other are doing.
10:39:09 <rra> Diziet: Sure, go for it; we took it off the agenda since you'd closed it, but it sounds like it's not entirely at rest?
10:39:10 <Diziet> Hi.
10:39:23 <Diziet> rra: Unfortunately not.
10:39:25 <rra> The --tollef flag thing annoys me.
10:39:30 <Diziet> Mmm.
10:39:40 <rra> Admittedly, I'm not Tollef, so it's really up to him whether to be annoyed, but.
10:39:46 <Diziet> It's not entirely clear to me what to do about all this but I think a starting point would be for us to offer to mediate.
10:39:59 <rra> Naming things after people is almost always a horrible idea.
10:40:06 <Diziet> sgt-puzzles
10:40:07 <Mithrandir> I'm not sure if I'm amused or annoyed, and it should really be --Tollef if it's referring to me.
10:40:13 <Mithrandir> but yeah, not a good name
10:40:32 <Diziet> But we can't do mediation without a private list since mediation means the sides talk to us and we translate/interpret/negotiate/etc.
10:41:02 <rra> Well, is the mediation necessarily a tech-ctte thing, or is there just a need for mediation in general?
10:41:15 <Diziet> So I guess what I'm saying is 1. can we please make a private list (or perhaps make our existing private list work) and 2. actually invite everyone to use it for mediation.
10:41:21 <rra> It's not really clear to me whether we currently have "jurisdiction" here.
10:41:25 <vorlon> is there still an existing private list?
10:41:32 <vorlon> cf. my recent private mails to everyone by name
10:41:40 <Diziet> rra: The advantage of having the TC do the mediation is that then if it comes down to `people can't agree', the TC have all the information to make a decision.
10:41:42 <rra> But regardless, I'm personally convinced of the need for a private list given the number of interpersonal conflicts we're asked to handle.
10:41:46 <Diziet> Otherwise you have to go through the argument _again_
10:41:54 <rra> Point.
10:42:11 <vorlon> private list - +1
10:42:14 <Diziet> OK.
10:42:20 <Diziet> I will try to get that sorted out.
10:42:27 <vorlon> do we think we have the authority to set up that list on our own say-so?
10:42:36 <Diziet> Yes.
10:42:40 <vorlon> there was a question raised at last UDS about whether the constitution required us to have discussions in public
10:42:41 <dondelelcaro> vorlon: I don't believe any other listmasters will disagree
10:42:43 <rra> We arguably have a constitutional issue.
10:42:56 <Diziet> rra: I think we should regularise it, yes, but afterwards.
10:43:01 <vorlon> ack
10:43:13 <bdale> I'm not up to speed on this, and it's not clear that trying to get up to speed right this instant is the best use of our collective time.  is there a proposal here, or just a sense that maybe we should interject ourselves?
10:43:18 <Diziet> I admit that's playing a bit fast and loose but _in practice_ we've been having lots of people emailing us as individuals anyway.
10:43:38 <Diziet> bdale: It's not clear what we may need to do but people are quite cross in my email and trying to persuade me of their point of view.
10:43:46 <Diziet> It's not clear exactly what they want me to do ...
10:43:51 <Diziet> And why they're sending to just me.
10:43:57 <vorlon> bdale: the bug was closed, the moreutils maintainer raised an additional objection following Diziet's bug closure
10:44:16 <vorlon> ah, and apparently there's further private follow-up that I'm not privvy to ;)
10:44:18 <zack> if I may, the constitution explicitly mentions that the tech-ctte is allowed to use private list for discussing membership appointment; so at least a reasonable doubt that it is not allowed to to so for other matters exists
10:44:48 <Diziet> How about after we set up a private list that works someone (not me since I probably look like I've taken sides) emails everyone involved with this to please contact us with their concerns (in public or private as they choose) and we will try to help.
10:45:01 <bdale> I'm ok with a private list in principle, in practice it hasn't worked well in the past
10:45:05 <rra> Yeah, but 6.3.3 is pretty explicit.  We have a set of amendments to the constitution that we want to talk about anyway; we should probably do something about 6.3.3 as part of that.
10:45:06 <Diziet> vorlon: There have been emails to what looks like a random CC list.
10:45:10 <vorlon> heh
10:45:14 <Diziet> rra: Indeed.
10:45:41 <Diziet> vorlon: I don't really feel very comfortable about that obv. - it's definitely worse than the TC officially talking about things with people in private.
10:45:50 <Diziet> If we need to make any decisions they will be made in public.
10:46:07 <rra> I think mediating privately is fine.
10:46:10 <bdale> ugh .. lag
10:46:21 <rra> Mediating isn't really discussing decisions.  I think we have enough wiggle room there.
10:46:29 <Diziet> Would anyone care to volunteer to send the invitation to mediation then ?
10:46:30 <rra> If the mediation breaks down, we need to take the discussion public.
10:46:45 <Diziet> rra: Right.
10:46:50  * rra ENOTIME at present, unfortunately.  :/
10:47:00 <zack> sorry (again), but have you actually been asked to mediate in the --tollef issue? it looks like the main issue there is technical: --tollef is not compatible with moreutils behavior, so the implemented "solution" is broken
10:47:19 <Diziet> zack: We haven't been asked to mediate.
10:47:27 <Diziet> What we have is some angry emails.
10:47:31 <vorlon> [ACTION] Diziet to sort out a private mailing list for the TC via lists.debian.org
10:47:40 <Diziet> In response to us maybe making a decison or maybe in response to something the parallel maintainer or upstream did.
10:47:54 <vorlon> Diziet: who are the parties to the dispute?  moreutils and parallel maintainers?
10:48:00 <vorlon> or are you getting angry mails from others?
10:48:03 <Diziet> vorlon: I'm not sure exactly who everyone is.
10:48:15 <bdale> ok, so this turns out to seem anything but simple/quick .. if the action we can take today is delegate getting a private list set up, so be it.
10:48:29 <Diziet> Eg who is Ian Zimmerman.
10:48:40 <Diziet> Ole Tange is upstream ?
10:48:43  * rra hates to cut this short, but I really do want to get to Python.
10:48:46 <Diziet> For GNU parallel.
10:48:50 <bdale> rra: me too
10:49:11 <vorlon> so I didn't see anyone volunteering to invite mediation for parallel
10:49:14 <dondelelcaro> yeah... can we agree to come back to this via e-mail in a future meeting?
10:49:21 <Diziet> OK.
10:49:26 <dondelelcaro> s/in a/& or/
10:49:39 <Diziet> Let's do Python then.
10:49:55 <rra> Okay, where I think we currently are:
10:49:58 <Diziet> I confess I haven't been following the latest ins and outs.
10:50:05 <vorlon> did everyone receive and have a chance to read the last private mail I sent on the subject?
10:50:29 <dondelelcaro> yes
10:50:37 <rra> The packaging helpers seem to have largely been resolved to everyone's satisfaction.  Apart from some worries that there might be future conflicts, no one seems to feel like the packaging helper side of things currently has problems, and there's a maintenance team for those packages.
10:50:38 <Diziet> Date: Sat, 28 Apr 2012 18:51:53 -0700
10:50:39 <Diziet> ?
10:50:42 <rra> So they seem to be off the table.
10:50:52 <vorlon> Diziet: no, May - let me grab the message-id
10:50:58 <rra> What's left here is the Python interpretor itself.
10:51:08 <vorlon> Diziet: <20120518052629.GA25212@virgil.dodds.net>
10:51:15 <vorlon> Date: Thu, 17 May 2012 22:26:29 -0700
10:51:26 <Diziet> I don't have that at all.
10:51:29 <rra> zack polled debian-python to see who was actually interested in volunteering to help maintain Python.  I found the results highly surprising.
10:51:34 <vorlon> Diziet: email address I should try re-sending to?
10:51:43 <vorlon> (previously sent to ian@davenant.greenend.org.uk)
10:51:47 <Diziet> ijackson@chiark.greenend.org.uk
10:51:50 <Diziet> Oh.
10:52:06 <Diziet> That's an out of date address for me.  I really need to fix the last few packages with that in their Maintainer...
10:52:24 <Diziet> got it ta
10:52:29 <vorlon> ah, heh.  I copy-pasted that one, apparently several of these private mails have been misaddressed
10:52:45 <bdale> vorlon: yes, I've read your private msg .. no real surprises
10:53:06 <rra> The results from the polling of debian-python appear to be: morph is still very much interested in putting together a maintenance team, but it's not clear that the other people volunteering to help wanted to be part of that team (although Barry seems generally open to help anyone).  Jakub Wilk is willing to maintain the packages by himself but doesn't seem very interested in forming a team.
10:53:16 <rra> Not a lot of people responded to volunteer.
10:54:00 <bdale> so the question at this point is what?  whether we force a change in maint of the interpreter package, and if so who the team is?
10:54:04 <rra> Yes.
10:54:44 <rra> There were also multiple responses in debian-python saying that people were opposed to forcibly replacing Matthias, expressed with varying degrees of strength.
10:54:51 <Diziet> It doesn't sound like we have a team we would be happy replacing Matthias with, even if we take a very downbeat view of Matthias.
10:54:53 <vorlon> rra: right; and there's the point from ScottK that having a maintenance team for the metapackages that's at odds with the team for the interpreter packages is not a healthy outcome
10:55:05 <bdale> I find this difficult while doko remains both usefully active and unwilling to participate in public discussion of the bug filed with the TC
10:55:07 <rra> Diziet: That's my opinion as well.
10:55:14 <rra> bdale: Yes.
10:55:33 <rra> I think it's unarguable that there's a real communication problem here.  Not enough is said publicly about what's going on with Python maintenance.
10:56:04 <vorlon> I certainly find it difficult, but I also think there's only one right decision for the technical maintenance of python
10:56:12 <rra> This is something that in general doko struggles with (the gcc 4.7 timing also wasn't very smooth).  Also, doko is wearing a lot of hats at the moment without a lot of team backup.  Both of those things concern me a lot.
10:56:14 <Diziet> The only thing we could do would orphan it but we'd have to declare that the people who have been making Matthias's life miserable shouldn't get it either.
10:56:15 <vorlon> i.e. from the set of options we have available to us
10:56:28 <rra> However.  The alternative options we have here are not clearly better.
10:56:58 <bdale> I talked to him at UDS .. vorlon's private message has content substantially similar to my discussion with him
10:57:04 <bdale> I agree
10:57:12 <rra> And when Barry, Jakub, and Scott all explicitly say that replacing Matthias is a bad idea, that really gives me pause.
10:57:30 <vorlon> Diziet: orphan> right - and given that we've already surveyed debian-python for likely adopters, I don't see the value in that
10:57:31 <Diziet> How about this: we'll make a formal decision that doko keeps it BUT say that this is despite the lack of public communication and is primarily due to the lack of an alternative team with which we'd be happy.
10:58:03 <vorlon> Diziet: that's not quite the rationale I would give
10:58:12 <vorlon> I'm happy to wordsmith something that reflects all of our views
10:58:37 <vorlon> (I think your wording implies we would prefer to have an alternative team that doko is not part of... which is not my position)
10:58:39 <rra> I would really like Matthias to add a comaintainer, particularly someone who's willing to do a bunch of communicating and coordination, since that's Matthias's weak point IMO.
10:58:44 <Diziet> vorlon: Please do.  I think it's important to make it clear that if things change we may change our mind.
10:58:55 <Diziet> rra: That would be a good thing to put in our resolution.
10:59:12 <vorlon> rra: do you think this is still an issue, given that there are comaintainers to the python-defaults and python3-defaults packages?
10:59:25 <rra> Yes, because of the communication issues.
10:59:26 <vorlon> doko makes it clear he thinks this is a non-issue now in practice
10:59:27 <jcristau> rra: how would that person communicate with doko?
10:59:31 <Diziet> vorlon: I think he either needs to start communicating publicly, or have a co-maintainer who does.
10:59:32 <zack> a summary of the outcome of my poll is at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573745#465 in case you want to review the options, fwiw one of them did include a co-maintainer (not saying it should be preferred or anything of course, just a data point)
10:59:59 <vorlon> Diziet, rra: why and how do the comaintainers of the python-defaults packages not already fulfill that function?
10:59:59 <rra> I don't think there's a need for a *technical* comaintainer to do the packaging, particularly, but the communication issues are ongoing.  Someone needs to coordinate when new versions are added and dropped and make sure everyone is on the same page and that is currently not happening as well as it should.
11:00:30 <rra> If the python-defaults comaintainers feel like they have enough influence and say over what happens with versions of the interpretors to fill that function, that's sufficient, I think.
11:00:50 <vorlon> the defaults packages decide which are the supported and default versions of python in the archive
11:00:58 <bdale> rra: yes
11:00:58 <bdale> a co-maintainer who communicates would be a great addition
11:00:58 <bdale> sorry, I'm clearly facing variable lag
11:00:59 <rra> jcristau: That's the key.  *Someone* has to both know what's going on and be able to communicate it and to be able to coordinate (including changing the timing if needed).
11:01:07 <rra> I don't really care how that's done.
11:01:12 <vorlon> the only part doko can actually block as a solo interpreter maintainer is the initial upload of a new version to unstable
11:01:16 <rra> Whether it's done by convincing Matthias or taking independent action.
11:01:37 <rra> vorlon: Or stop supporting older versions, but I guess anyone could do that anyway, and that isn't really the issue.
11:01:41 <vorlon> and while this *was* the point of contention in the not-so-distant past, it was also before the python-defaults packages had comaintainers
11:02:14 <vorlon> rra: right, well, the maintainer could request the ftpmasters to remove the package without coordinating with python-defaults first, but I don't think that's actually a realistic scenario
11:03:07 <rra> zack: The comaintainer option is Matthias and Barry.  Given that Matthias could already just name Barry as a comaintainer, I'm a bit dubious about that as an option.  It feels like either it is already possible without the TC doing anything or it wouldn't work.  But maybe it's more nuanced than that.
11:03:16 <bdale> vorlon: good points, all
11:03:21 <bdale> vorlon: I think it would make sense for our resolution to encourage but not require that doko take on a co-maintainer for the interpreter package(s), otherwise I think you writing up a proposed resolution draft that we can review and/or vote on in email is fine
11:03:52 <rra> You're right; the python-defaults change does take a lot of the pressure off the primary concern, which was the communication around transitions.  And the other primary concern as I recall was the Python packaging standards and helpers, and that seems to have been more or less resolved.
11:04:14 <dondelelcaro> sounds good
11:04:17 <vorlon> given that this issue remains contentious in the wider community, I think we do want a full array of ballot options here... I'm certainly happy to help wordsmith the "primary" ballot option
11:04:48 <vorlon> rra: I feel I should note here that the one major hold-out from consensus regarding the deprecation of python-support is morph
11:04:57 <bdale> vorlon: ok .. I'd like a shorter rather than longer list of options, but if you're willing to write up a longer list so that we explicitly vote the other options down, that's ok with me
11:05:05 -!- OdyX [~OdyX@cl-229.gva-01.ch.sixxs.net] has joined #debian-ctte
11:05:09 <Diziet> Is there anyone on the TC who would support any other ballot option other than the kind of thing we're discussing (which is basically `doko keeps the package; we have some requests/advice/opinions') ?
11:05:10 <rra> Yes, I think we should explicitly list the option that we had presented to us originally.
11:05:28 <bdale> rra: good point
11:05:31 <rra> Even if no one on the committee is supporting it, it just feels weird to me to not even list it.
11:05:33 <Diziet> rra: OK.  Yes.  That would be fine on the ballot even if no-one supports it.
11:05:40 <vorlon> ok
11:05:44 <morph_laptop> vorlon: (since you named me) also jwilk, to be fair
11:06:05 <vorlon> morph_laptop: ah, indeed?  sorry, I was unaware
11:06:09 <morph_laptop> np
11:06:16 <vorlon> let's just say I've seen you being more vocal about it ;)
11:06:22 <rra> morph: A question there, then: *is* the packaging helpers situation resolved to your satisfaction?  I had the impression that everyone was more or less happy, but if that's not the case, then that's new information.
11:06:27 -!- Topic for #debian-ctte: Next meeting May 31st 1700 UTC (date -d @1338483600) | Open issues: #614907: node <-> nodejs conflict [vorlon to write up resolution], #573745: python maintainer; #636783: super-majority conflict; #552688: hardening build flags [rra will close as resolved]  
11:06:27 -!- Topic set by dondelelcaro [~don@hemlock.ucr.edu] [Thu May 31 10:37:39 2012]
11:06:37 <rra> I unfortunately haven't been following debian-python, which would have been helpful.
11:06:49 <rra> I read some selected threads and then trusted what people said in those threads, which isn't a great research method.
11:07:23 <vorlon> are the other TC members pressed for time?
11:07:29 <dondelelcaro> I'm ok
11:07:30 <vorlon> I can hang around to continue discussing
11:07:33 <bdale> I'm not pressed for time
11:07:35 <rra> My 11am was cancelled, so I can stay.
11:07:37 <dondelelcaro> ok
11:07:39 <Diziet> I'm OK for time.
11:07:41 <morph_laptop> rra: well, the dh_python3 is good, but dh_python2 still has several bugs that needs to be fixed to be an-pair with my idea; one of the bigges nuiance is the need to rebuild to support a new python verison, but it will eb resolved removing 2.6 (since py3k support more versions in the same dir)
11:08:01 <vorlon> right
11:08:07 <Diziet> We have a bit of a backlog so this meeting being long won't set too much of a precedent I hope.
11:08:14 <dondelelcaro> yeah
11:08:19 <vorlon> python2 helpers each have different trade-offs to work around a different set of upstream bugs/misfeatures
11:08:25  * rra will generally want to keep it to an hour, but the first one is always special.
11:08:28 <zack> rra: on that front, now both the old helpers are deprecated; that is at least an indication that the helper issue is more or less solved, I can dig it up the relevant threads if you want
11:08:33 <dondelelcaro> I'd also like to schedule the next meeting before we get too far along [I probably should have done that first...]
11:08:46 <vorlon> the long-term solution is that python3 is supposed to make things better for distributions
11:09:02 <Diziet> vorlon: python2 is going to be around for years.
11:09:05 <vorlon> (and I believe it does - thanks in no small part to barry's upstream work)
11:09:07 <rra> morph_laptop: Okay.  So what I'm hearing from that is that it's not completely resolved, but Python 3 fixes things, and the Python 2 issues are, if not great, livable.  Is that accurate?
11:09:09 <bdale> fwiw, I put an item in penta for a tech ctte mtg at debconf for those who will be there
11:09:26 <morph_laptop> rra: sounds fine for me
11:09:30 <vorlon> Diziet: certainly... and so we're saddled with having to make tradeoffs for python2
11:09:33 <bdale> as a bof
11:09:46 <vorlon> now, the python-defaults team have made their decision about what they think the right tradeoff is
11:09:55 <vorlon> and some python module maintainers have rejected that in favor of another
11:10:24 <rra> vorlon: Is that a place where we need to do something, or is it going to sort itself out over time?
11:10:39 <vorlon> and unfortunately, the lack of making a consistent set of tradeoffs introduces yet another set of bugs that we wouldn't have if we'd all agreed on one or the other
11:11:00 <vorlon> rra: if it's going to sort itself out over time, it seems to be geological time
11:11:14 <rra> Okay.  So it's causing some amount of bugginess ongoing.
11:11:16 <vorlon> i.e.: it solves itself when python2 goes away, which as Diziet says is long in the future
11:11:30 <Diziet> vorlon: I'm not sure where this conversation is going TBH.  Are you trying to discover if there is still an underlying dispute about the helpers ?
11:11:34 <vorlon> (though as a data point, Ubuntu is pushing to support only python3 applications for 14.04)
11:11:49 <rra> Diziet: That's what I'm trying to determine.  I'm trying to figure out what the remaining dispute is.
11:11:54 <vorlon> Diziet: I'm saying that there is an underlying dispute about the helpers, in response to rra's question
11:12:17 <rra> I know Python transitions were a huge problem.  python-defaults maintainership seems to be a way to resolve that, although I'm not yet clear on whether everyone agrees it's resolved.
11:12:48 <jcristau> rra: that's kind of resolved by python upstream not releasing new versions
11:12:54 <rra> I know that the way Python add-ons were packaged was another large dispute, with two competing helper suites and a lot of upsetness on both sides about the decisions made by the others.  I was hoping that was resolved; it sounds like it isn't entirely.
11:13:17 <rra> jcristau: Python 2.7 came out during this release cycle, didn't it?
11:13:23 <jcristau> yeah, i mean after 2.7
11:13:28 <vorlon> it's /formally/ resolved by the deprecation of both python-central and python-support by the respective authors, in favor of dh_python2
11:13:36 <bdale> ok, well, it sounds like we have enough info to write up a ballot and vote it?
11:13:38 <rra> Was the python2.7 transition handled okay, or was it another problem?
11:13:54 <rra> Actually, that's not really the question I have.
11:14:11 <rra> The real question I have is that I'm not sure of the timing of this: was the python-defaults comaintainership before or after python2.7?
11:14:37 <jcristau> before
11:14:44 <rra> The contention is that having python-defaults be comaintained addresses that part of the problem.  I guess what I'm asking is have we actually tested that with a new release of Python?  If so, how did it work?
11:15:25 <zack> if I may, it looks to me that the ctte has been asked to solve the _maintenance_ issue; while I agree that in the past the helper issue was intertwined with that, arguably nowadays that issue is "solved enough" to be separate
11:15:34 <vorlon> rra: from a quick google search: https://lists.debian.org/debian-python/2011/02/msg00008.html
11:15:44 <zack> so, hopefully, the ctte doesn't _need_ to rule anymore on the helper issue
11:15:49 <rra> bdale: So far, if I had to vote on something right now, I'd be confused about why the TC was even being asked to change things.  Given that clearly the TC is still being asked, I want to understand why people are still upset.
11:16:05 <vorlon> zack: yes, I definitely agree that it's out of scope for us to decide on helpers
11:16:21 <rra> Okay.  Then I'll stop worrying about the helpers.  :)
11:16:27 <zack> \o/ :)
11:16:45 <jcristau> the 2.7 transition at least wasn't stalled for a year for unclear reasons.
11:16:50 <bdale> rra: my take all along has been that the core issue is doko's communication style, or lack thereof
11:17:12 <Diziet> Right.  Does that mean we're ready now to draft a resolution on python ?  vorlon, do you need anything else ?
11:17:36 <rra> bdale: Agreed.  But if that communication style doesn't really affect the broader Python community in Debian any more due to doko not being involved as much in helpers, Python 3 removing some of the pressure, and python-defaults being maintained by other people, then it's not clear that we have to have an opinion on his communication style.
11:17:38 <bdale> right, 2.7 seemed from a distance to go more or less well
11:18:06 -!- Topic for #debian-ctte: Next meeting May 31st 1700 UTC (date -d @1338483600) | Open issues: #614907: node <-> nodejs conflict [vorlon to write up resolution], #573745: python maintainer; #636783: super-majority conflict; #552688: hardening build flags [rra will close as resolved]  
11:18:06 -!- Topic set by dondelelcaro [~don@hemlock.ucr.edu] [Thu May 31 10:37:39 2012]
11:19:04 <bdale> zack: by the way, so I don't forget later, thank you very much for all your effort on this in recent times
11:19:05 <Diziet> rra: More to the point we don't have any useful /options/ to do anything about his communication style.
11:19:10 <OdyX> 3.2.3 is still not in it's final version though.
11:19:18 <vorlon> Diziet: I gather that none of the above discussion has changed the consensus about what I should be writing, so I don't need anything else
11:19:25 <Diziet> vorlon: Good :-).
11:19:29 <Diziet> Are we done on this topic then ?
11:19:39 <zack> bdale: cheers, the potential bugfix ratio of this meeting is more than a reward for that :)
11:19:40 <dondelelcaro> ok; so as I understand it, vorlon will be writing up the primary option, with other options to be present
11:19:47 <bdale> rra: I agree.  which is why I think we're to the point where we can write a ballot and vote on it at this point, as many of the points of contention even within the TC itself have been resolved in the time this has been on our plate
11:19:50 <rra> I mean, I know there are other things that annoy people, such as new versions of Python being uploaded to Ubuntu before Debian and whatnot, but it's just not clear to me that this rises to the level of requiring the TC to do something.
11:20:02 <vorlon> [ACTION] vorlon to write up a proposed ballot option for bug #636783
11:20:32 <Diziet> rra: It's not something we could do anything about other than by firing doko and if we don't have a team we would prefer to replace doko with then that's that.
11:20:44 <rra> Yeah.
11:20:56 <dondelelcaro> vorlon: it's #573745, but you'd figure that out. ;-)
11:21:01 -!- Topic for #debian-ctte: Next meeting May 31st 1700 UTC (date -d @1338483600) | Open issues: #614907: node <-> nodejs conflict [vorlon to write up resolution], #573745: python maintainer; #636783: super-majority conflict; #552688: hardening build flags [rra will close as resolved]  
11:21:01 -!- Topic set by dondelelcaro [~don@hemlock.ucr.edu] [Thu May 31 10:37:39 2012]
11:21:04 <vorlon> ah, heh
11:21:04 <rra> Certainly, I personally am not interested in replacing doko with any other single maintainer.
11:21:19 <Diziet> If we're done with Python, shall we do date of next meeting ?
11:21:34 -!- dondelelcaro changed the topic of #debian-ctte to: Next meeting May 31st 1700 UTC (date -d @1338483600) | Open issues: #614907: node <-> nodejs conflict [vorlon to write up resolution]; #573745: python maintainer [vorlon to write up resolution]; #636783: super-majority conflict; #552688: hardening build flags [rra will close as resolved]   
11:21:47 <rra> Diziet: Sounds good to me.
11:21:53 <dondelelcaro> yeah; lets get that set in case people have to leave
11:21:56 <Diziet> I guess this time of the week works for most people ?
11:22:06 <Diziet> (We're not going to hear `no' from people who aren't here perhaps...)
11:22:13 <bdale> yes
11:22:14 <bdale> wow .. ping times exceeding 40 seconds from here now
11:22:16 <Diziet> But they can object in email.
11:22:20 <dondelelcaro> right
11:22:23 <vorlon> yeah, this slot is clear for me weekly
11:22:30 <Diziet> 1 month from now would be 28th of June.
11:22:34 <rra> I normally have a meeting that starts 22 minutes ago, but if we use this time and keep it to an hour, it works for me.
11:22:36 <Diziet> Is that too soon ?
11:22:44 <rra> No.
11:22:45 <vorlon> did aba ack/nack this time slot?
11:22:53 <dondelelcaro> vorlon: I think he ack'ed it
11:22:56 <vorlon> ok
11:22:56 <rra> I'd rather have a meeting and say we don't have much to discuss than not have enough meetings.
11:22:57 <dondelelcaro> I /msg'ed him
11:23:14 <rra> Once a month seems reasonable to me.
11:23:18 <vorlon> fine with me
11:23:28  * zack hugs you all for the enthusiasm in this meeting and in already scheduling next one
11:23:29 <dondelelcaro> ok; this slot on the 28th?
11:23:31 <bdale> monthly is good, an hour is good, this time works for me
11:23:32 <Diziet> OK, I will send an email saying: that's when it will be unless anyone objects.
11:23:44 <Diziet> [ACTION] Diziet to send notice of next meeting
11:23:46 <vorlon> fwiw there are a couple of things from recent Debian list discussions that I would like it if the TC could take up and drive to conclusion
11:23:57 <vorlon> but I'm going to avoid getting into those right now :)
11:24:08 <rra> There are a couple of things from recent Debian list discussions that I'd personally like to drive off a cliff.  ;)
11:24:14 <vorlon> bdale: you mean you're not going to be on a car lot a month from now? :P
11:24:15 <Diziet> *snerk*
11:24:25 <Diziet> vorlon: Bring them up by email ?
11:24:42 <vorlon> potentially
11:24:53 <vorlon> but I might not get to it until next month regardless, as I seem to have taken a few action items :)
11:24:58 -!- dondelelcaro changed the topic of #debian-ctte to: Next meeting June 28th 1700 UTC (date -d @1340902800) | Open issues: #614907: node <-> nodejs conflict [vorlon to write up resolution]; #573745: python maintainer [vorlon to write up resolution]; #636783: super-majority conflict; #552688: hardening build flags [rra will close as resolved]    
11:25:00 <Diziet> Heh.
11:25:21 <Diziet> The thing left is the constitution.  Should we do that now or have we gone on long enough ?
11:25:29 <rra> So, the one item we have left is that we have a bunch of constitutional fiddling that we would like to do.
11:25:32  * rra is good to talk about it.
11:25:44 <dondelelcaro> I'm ok too; though aba was the one who proposed it
11:25:45 <bdale> vorlon: anything we need to talk about now, or is email good?
11:25:48 <rra> I think the supermajority fix is uncontroversial.
11:25:51 <vorlon> bdale: nah, nothing urgent
11:26:24 <Diziet> I still think we should try to do all of our proposed changes in parallel.  So we need to decide roughly what they are.
11:26:32 <rra> I think we should allow private discussions with some pretty strict limits around that allowance.  At the very least, all votes and rationales need to be public.
11:26:32 <Diziet> We have a clear proposal for supermajority.
11:27:01 <Diziet> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636783#50
11:27:05 <rra> I kind of want to say that we should try to say something about allowing private discussion of personality conflict issues but not of technical issues, but I'm not sure how to phrase it.
11:27:05 <Diziet> rra: ^ how about that wording ?
11:27:16 <Diziet> rra: They merge into each other anyway,.
11:27:22 <rra> Yeah, I know.
11:27:36 <Diziet> I think it would be useful to be able to have a private conversation if two people are shouting at each other over whether something is a bug.
11:27:59 <rra> I'm not horribly happy with just removing discussion from the list of things we do in public without saying anything more.
11:28:05 <rra> I do think all discussion should be public by default.
11:28:34 <vorlon> I think that's probably a useful way to word it, and then spell out the cases when it's acceptable to go private?
11:28:44 <rra> I want to give us the freedom to take things private when discussing it in public isn't productive, but I don't want it to be the default.
11:29:59 <rra> vorlon: Yeah, that feels better to me.
11:30:34 <Diziet> vorlon: I don't want a list of specific permissions to go private which we'll have to argue about each time.
11:30:49 <Diziet> Whether to be public or private is a matter of judgement and I would like to have the freedom to exercise it.
11:30:59 <vorlon> certainly
11:31:23 <rra> Something like "Technical committee discussions are normally public.  However, members may discuss issues privately provided that all draft resolutions, amendments, and votes are made public."
11:31:24 <vorlon> I think it should be possible to balance both concerns in the wording?
11:31:33 <dondelelcaro> though I suppose, even if we exercise judgement, we'll still argue about it...
11:31:37 <vorlon> heh
11:31:57 <Diziet> `normally' would be false if we decided to take on a routine mediation role (which is something we should imo try)
11:32:15 <rra> I dunno, I'm not very enthused about the tech-ctte becoming mediators.
11:32:24 <rra> That's for a couple of reasons.
11:32:40 <Diziet> How about   `Discussions are held in public unless that would make it difficult to talk freely and productively'
11:32:43 <rra> One is that mediation takes a ton of time, and it's not like most of us have a surfeit of time already.  I'm not sure we should commit to doing something even more.
11:32:53 <vorlon> 2) because too much mediation makes rra angry, and we wouldn't like him when he's angry
11:32:54 <Diziet> rra: OK fine we don't need to have that argument.
11:33:05 <Diziet> I want however the TC to have the _permission_ in the TC to become mediators if we want to.
11:33:10 <zack> I'm about to leave, but I've one last meta-topic: could you please post the irc logs somewhere (e.g. on the tech-ctte list) when you're done? The meeting was public anyhow and I would be useful to have it both for future ref and in the interim between now and the implementation of [ACTION]s
11:33:22 <zack> (yes, if the next time you use meetbot, that could be automated)
11:33:33 <Diziet> Does anyone have a log easily to hand ?  If not I can c&p.
11:33:41 <rra> The other is that I think there's a bit of a conflict between being a mediator and being on the TC in that having a mediator who has considerable power to decide the results of whatever is being mediated sometimes doesn't go well.  It can add an element of pressure and authority that isn't helpful.
11:33:42 <vorlon> who wants to take the action to follow up on meetbot with Darst? :)
11:33:52 <zack> I have the log and could post them, if you want me to
11:34:05 <zack> (I'll leave, but leave an irc proxy running)
11:34:05 <dondelelcaro> Diziet: yeah, I have the log too
11:34:09 <rra> Diziet: I'm not sure why we would need permission?
11:34:28 <bdale> vorlon: if my wife needs another new car a month from now, I have bigger problems than meeting timing...
11:34:30 <Diziet> rra: We need the rule about private discussion not to say that it's `abnormal' since for mediation it's not.
11:34:32  * zack waves and thanks all participants
11:34:39 <rra> I don't see anything in the constitution that says we can't mediate other than the public discussion part.  If you just mean letting us have private discussions so that we can mediate... ah, okay, I see.  Yeah, that's fine.
11:34:43 <rra> I get your point now.
11:35:03 <Diziet> What did you think about my phrasing re `freely and productively' ?
11:35:23 <rra> I'm worried it's going to provoke arguments over whether that criteria applies.  :)
11:35:50 <Diziet> rra: Well if you want to avoid _all_ such arguments then we should say nothing in the constitution like my draft in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636783#50 says
11:35:53 <rra> Basically, I want to be clearer that the public/private decision is at the discretion of the TC, but the TC is formally encouraged to be public by default.
11:36:24 <rra> (And yeah, that's different than what I said about five minutes ago, but I realized that what I was saying earlier doesn't work.)
11:36:34 <Diziet> Right.
11:36:59 <Diziet> OK.  We could have a non-normative statement `The TC is encouraged to hold discussions in public'.
11:37:05 <rra> So... hm.  I guess I agree with your change but would add one more sentence like that.  Yes.
11:37:11 <Diziet> Right.
11:37:19 <bdale> ok, I need to move .. thanks all for today, will be back online in a couple hours
11:37:25 <vorlon> thanks, bdale!
11:37:30 <Diziet> Thanks.
11:37:32 <rra> Thanks!
11:37:48 <dondelelcaro> thanks
11:37:51 <Diziet> Shall we close it there ?  We aren't done with the constitution but we're leaking people (I think zack's input on that would be useful)
11:38:17 <Diziet> Just quickly one thing re that though: is it just me that thinks we should increase the max size ?  If so I'll drop it.
11:38:23 <rra> Real quickly: for maximum size, meh... I think 8 people is already a lot, particularly when we try to schedule meetings.  I wonder if we would gain the benefits there by being a little more aggressive (read: doing this at all) about asking people who haven't had much time whether they're really still active.
11:38:34 <dondelelcaro> yeah
11:39:06 <Diziet> I'm not getting a great deal of support here :-).  OK we can drop that.
11:39:29 <Diziet> We need to have the discussion re an advisory GR about overruling too but I think that needs more time and people.
11:39:39 <rra> yeah, agreed.  I was just about to say that too.
11:39:52 <Diziet> Then I guess we're into AOB ?
11:39:57 -!- dondelelcaro changed the topic of #debian-ctte to: Next meeting June 28th 1700 UTC (date -d @1340902800) | Open issues: #614907: node <-> nodejs conflict [vorlon to write up resolution]; #573745: python maintainer [vorlon to write up resolution]; #636783: super-majority conflict; #552688: hardening build flags [rra will close as resolved]     
11:40:26 <Diziet> Noone has any AOB then.  I guess we're done.
11:40:32 <vorlon> sounds good to me
11:40:38 <Diziet> I will c&p the log since no-one has said they have it in a disk file.
11:40:47 <rra> Agreed.  And yeah, I wasn't smart and didn't log.
11:40:47 <dondelelcaro> Diziet: I've got it on a disk file if you want it
11:41:06 <Diziet> dondelelcaro: Oh good.  Please email the whole thing to the TC list then.
11:41:27 <dondelelcaro> will do; it's actually the equivalent of C&P, but I'll start really logging
11:42:11 <rra> dondelelcaro: Thank you for coordinating!
11:43:02 <dondelelcaro> rra: np
11:43:14 <Diziet> dondelelcaro: Thanks, indeed.
11:43:18 <dondelelcaro> glad everyone was able to meet
11:43:24 <dondelelcaro> and that it was useful
11:43:49 <vorlon> yes, thanks dondelelcaro for organizing, and to everyone for making the time