--- /dev/null
+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
--- /dev/null
+09:43:47 -!- jwilk [~jwilk@1-dom-5.acn.waw.pl] has joined #debian-ctte
+10:01:22 -!- rra [~eagle@windlord.Stanford.EDU] has joined #debian-ctte
+10:01:29 <aba> hi
+10:01:37 <rra> Heya! Sorry I'm late.
+10:03:57 <zack> looks like you're not the only one ;)
+10:04:12 <aba> rra: at least you're here, I'd say
+10:05:03 <zack> dondelelcaro: around?
+10:05:11 <aba> bdale: are you here?
+10:05:19 <aba> vorlon: ?
+10:05:54 <bdale> here
+10:06:09 <bdale> multiplexing, as usual
+10:06:37 <bdale> need to get these meetings into a calendar I can add to my phone's sync list
+10:08:43 <dondelelcaro> here
+10:08:58 <dondelelcaro> sorry; on the road, and only now was able to set up
+10:10:28 <vorlon> hi, here-ish
+10:10:31 <vorlon> sorry
+10:11:33 <aba> bdale: do you chair the meeting?
+10:12:20 <zack> aba: given the declared availability, either you or rra are probably better choices
+10:12:22 <dondelelcaro> diziet or manoj doesn't seem to be around yet
+10:12:34 <vorlon> or cjwatson
+10:13:06 <rra> manoj and cjwatson didn't make the last meeting, IIRC; I'm not sure if they were planning on making it.
+10:13:12 <rra> I thought Diziet was planning on being here.
+10:13:25 <dondelelcaro> yeah, I thought so too
+10:13:46 <aba> he said so by mail at least
+10:14:02 <rra> Most of what we had on the agenda was the super-majority and other GR stuff, I believe, which was largely Diziet's topic.
+10:14:03 <bdale> I hadn't planned to chair, but certainly could. do we have an agenda?
+10:14:21 <vorlon> dunno
+10:14:30 <vorlon> I know I've failed to get my two action items done over the past month
+10:14:33 <rra> I think we're pending action items on the other open tickets except for the super-majority and other GR fixes.
+10:14:34 <zack> going through past action items would be nice
+10:14:42 <vorlon> and I'm not sure we have any new bugs since then
+10:14:55 <bdale> vorlon: any progress to report, or just "oops, maybe by next time"?
+10:14:56 <rra> We just had the one that you closed today (which I concur didn't seem to be a real tech-ctte bug).
+10:14:59 <aba> let us check the bugs.
+10:15:11 <aba> but doesn't look like there are new ones.
+10:15:19 -!- cjwatson [~cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #debian-ctte
+10:15:32 <cjwatson> My apologies, I'm clearly horribly behind on mail
+10:15:38 <vorlon> bdale: no progress - since I seem to be able to make time for TC work when I schedule it on my calendar, I'm planning to multitask and get at least one of the resolutions written up while I'm sitting here ;)
+10:15:43 <rra> cjwatson: Not a problem -- we'd not really started.
+10:16:08 <rra> Our only open bugs right now are node, Python, and the super-majority/GR fixes.
+10:16:11 -!- pl [~pl@83-238-131-10.ip.netia.com.pl] has joined #debian-ctte
+10:16:50 <vorlon> and I'm holding the baton for the first two of those - mea culpa
+10:16:57 <bdale> ok, so vorlon was going to write resolutions for the first to and diziet was expected to tackle the latter, right?
+10:17:09 <aba> yes
+10:17:28 <bdale> I saw some email from diziet around the non-public ctte list shortly after our last meeting, not sure where that ended up
+10:17:29 <rra> Yeah, we ran out of time to talk about the latter, and Diziet was going to drive the discussion.
+10:17:41 <rra> Me either -- his mail was the last that I saw about it.
+10:17:44 <bdale> FedEx at my door, bbiam
+10:19:55 <dondelelcaro> ok. was there something specific we needed to deal with, or do we just have the action items that vorlon was working on?
+10:20:09 <vorlon> I don't think we have anything new
+10:20:26 * bdale is back
+10:20:28 <vorlon> last time I hinted that I had another issue I wanted the TC to take up... and it wound up resolving itself via debian-devel before then ;)
+10:20:33 <vorlon> (tmpfs on /tmp)
+10:20:39 <bdale> cool
+10:20:43 <dondelelcaro> ah, good
+10:21:22 <vorlon> so, ah
+10:21:32 <vorlon> should we adjourn? :)
+10:21:37 <bdale> I think so
+10:21:45 <vorlon> oh
+10:21:45 <bdale> several of us will be at Debconf, right?
+10:21:45 <aba> yes
+10:21:48 <dondelelcaro> yes
+10:21:51 * aba not
+10:21:52 <vorlon> do we want to set another meeting date?
+10:21:55 <vorlon> I'll be at DebConf
+10:21:59 <aba> vorlon: we should
+10:22:01 * rra won't be able to make DebConf.
+10:22:05 <dondelelcaro> will we be at debcamp? or just debconf?
+10:22:13 <bdale> we should indeed set our next meeting date, but I hope/presume we can close some pending things while at Debconf, too
+10:22:13 <vorlon> I'm only there for the last day of DebCamp
+10:22:17 <dondelelcaro> maybe we can do an online meeting with streaming
+10:22:20 <dondelelcaro> ok
+10:22:30 <rra> I'd be happy to sign on for an online meeting.
+10:22:40 <zack> sorry to be a PITA, but vorlon do you want to keep both action items?
+10:22:40 <zack> if the meeting is to ajourn anyhow, maybe they could be parallelized a bit?
+10:22:41 <bdale> I'd ask that folks who won't be in Managua pay attention to email and/or IRC in case we want to push votes to conclusion during the week
+10:22:41 <dondelelcaro> or half online/half real life
+10:22:48 <dondelelcaro> right
+10:22:49 <rra> I don't think I have any local video capability, but I can participate via IRC.
+10:22:53 <rra> And watch the video.
+10:23:17 <vorlon> zack: I'm going to keep them both, yeah... I'm already halfway through the easy one, and the hard one I don't think I can pass off
+10:23:26 <bdale> I put in a BOF request, I think, but I don't know if it has been scheduled
+10:23:37 <bdale> vorlon: thanks
+10:23:54 <aba> ok, which date do we want? or should we take the date of the bof as surprise for the non-attending ones?
+10:24:13 * bdale checks penta
+10:24:16 <aba> (or do we want to schedule the next online one now, and have the bof-one inbetween?)
+10:24:19 <cjwatson> I won't be at DebConf, but (a) I'm happy to commit to paying attention to online things for the duration (b) in any case I intend to take vorlon's lead and block out some explicit time for dealing with TC work
+10:24:26 <bdale> BOF request marked as accepted
+10:24:29 <cjwatson> Since it's completely dropped off my radar for a while
+10:24:44 <cjwatson> I have sporadic local video capability
+10:24:47 <bdale> 7/9, 18:00 local time, 45 mins
+10:24:49 <dondelelcaro> why don't we schedule one irc meeting now, and we can change it if necessary
+10:25:11 <bdale> dondelelcaro: I agree
+10:25:17 <rra> does anyone know off-hand what the local GMT offset is for local time there?
+10:25:19 <aba> bdale: what does that translate to?
+10:25:22 <dondelelcaro> rra: -6, iirc
+10:25:23 <rra> I'll get that on my calendar so that I'm on IRC.
+10:25:40 <bdale> a month from now would be the 26th of July
+10:25:51 <dondelelcaro> does 17:00 UTC on the 26th work for us?
+10:25:52 <vorlon> -6, confirmed
+10:25:54 <bdale> that's enough after Debconf to seem useful
+10:26:08 <bdale> dondelelcaro: works for me
+10:26:14 <cjwatson> 18:00 local - ugh, that's 01:00 here, but doable
+10:26:24 <aba> works for me (26th)
+10:26:27 <bdale> do we have a calendar somewhere in d.o space we can use, or should I set up another google calendar for these?
+10:26:27 <rra> 17:00 UTC on the 26th works great for me.
+10:26:34 <aba> it's 02:00 here - not doable I'd say
+10:26:47 <bdale> aba: np
+10:26:48 <vorlon> 26th ok by me for the next IRC meeting
+10:26:50 <dondelelcaro> #startvote 17:00 UTC on July 26th meeting
+10:26:59 <vorlon> +1
+10:26:59 <dondelelcaro> hrm... maybe I needed to start the meeting, oh well.
+10:27:02 <cjwatson> +1
+10:27:03 <rra> +1
+10:27:05 <bdale> I don't think remote participation for the Managua BOF is all that useful, though of course you're all welcome
+10:27:25 <aba> 26th is ok for me, but I won't make the bof.
+10:27:44 <rra> I'll probably sit in on-line on the BoF just because I can.
+10:27:45 <bdale> zack: anything else you wanted to bring up?
+10:28:19 <bdale> for the future, i'll put together a simple meeting script such as what I use for the SPI board meetings and plan to play chair here on IRC, unless someone objects
+10:28:37 <rra> That sounds great here.
+10:28:46 <bdale> that will include a call for last minute agenda items when we start
+10:29:16 -!- dondelelcaro changed the topic of #debian-ctte to: Next meeting date -d 'July 26 2012 17:00 UTC' | 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]
+10:29:25 <bdale> ok, great, I think we're done then .. see those of you in Managua who can be there once I arrive late on the 5th, and we'll meet here again at 17:00 UTC on the 26th!
+10:29:32 <dondelelcaro> awesome. ok; see many of you at debconf!
+10:29:36 <zack> bdale: nope, just mentioned above the few things I consider priorities, nothing else
+10:29:40 <zack> but thanks for asking
+10:29:42 <zack> cheers!
+10:30:02 <bdale> zack: I'll also make a point of including an "items from the DPL" query in my script
+10:30:55 <rra> Yeah, that's a good idea.
+10:30:56 <zack> eh, not sure if I should be happy or worried about that :-P
+10:31:11 <vorlon> "What's zack pestering us about now"
+10:31:14 <vorlon> :)
+10:31:19 <zack> :)
+10:32:52 <vorlon> #endmeeting
+10:32:56 <vorlon> thanks all :)
+10:33:16 <rra> Thanks!
+10:33:18 <aba> thanks
+10:33:37 -!- rra [~eagle@windlord.Stanford.EDU] has quit [Quit: leaving]
+10:34:43 -!- morph_laptop [~Sandro@adsl-ull-184-62.41-151.net24.it] has left #debian-ctte [Leaving]
projects / debian-ctte.git / commitdiff