18:59:53 #startmeeting 18:59:53 Meeting started Wed Dec 20 18:59:53 2017 UTC. The chair is OdyX. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:07 #topic Introductions 19:00:10 OdyX, ok, will def be reading :) 19:00:12 Didier Raboud 19:00:19 Tollef Fog Heen 19:00:20 Niko Tyni 19:00:25 David Bremner 19:01:18 fil is excused 19:01:50 marga: you around ? 19:02:25 #topic Review of previous meetings' TODOs 19:02:39 http://meetbot.debian.net/debian-ctte/2017/debian-ctte.2017-10-18-19.01.html was our last recorded meeting. 19:03:06 hartmans did the poking for modemmanager, and I did the two process, discussion and d-d-a for TC candidacies. 19:03:16 I've failed to do what I was supposed to do, sorry. 19:03:41 No worries. Do you want to get the action item again or hand it over ? 19:03:58 either is fine, I should have some time over yuletide. 19:04:07 #action Mithrandir to start an initial "bug handling" checklist. 19:04:15 #topic #877024 modemmanager should ask before messing with serial ports 19:04:19 This has stalled 19:04:48 I thought we decided to go into a holding pattern? Is there something we should do to intervene at this point? 19:05:40 my position is last on the bug log: I don't see the urge, and enough damage was done. Upstream agrees, so it feels to me it's good to leave it to maintainers 19:05:51 ooc, is the package orphaned now? 19:06:08 (problem is, the escalation to TC had a withdrawal of one maintainer as result) 19:06:15 Technically, it's not. 19:07:15 would it be counterproductive to close the TC bug? 19:07:33 Not if we have (and mention) good reasoning IMHO. 19:07:41 I would be counterproductive to rule, IMHO. 19:07:46 has the remaining maintainer participated in the discussion at all? 19:07:56 Not as far as I can tell. 19:08:21 An option would be for one of us to reach out to hir and discuss. 19:08:38 Any taker ? 19:09:24 what would we want to discuss? whether they generally think the upstream proposed fix is OK? 19:09:57 well, and how they would take a TC ruling. 19:10:19 my understanding from what mbiebl wrote was that the new/old maintainer isn't really active. 19:11:16 well, if we can get hir to either orphan or become active again, either is a win (clarity, or maintainership), righ t? 19:11:34 yes, if that doesn't feel too much outside our remit 19:12:11 I mean, we can always do such a thing as individual DDs, but it is a bit of a cheat. 19:12:13 Well. Even if it's a hard to remove hat, it's no formal TC-as-a-whole action. 19:12:55 Talking to Mathieu seems just like a not-too-hard thing to do; which we haven't done yet AFAIK. 19:13:14 (I'd take that action if it were not for the other items on our agenda) 19:13:18 I can ask about his plans for maintainership. 19:13:23 tnx 19:13:57 #action bremner to reach out to modemmanager's maintainer to clarify position and expectations regarding #877024 19:14:00 #ave 19:14:09 #ceasar 19:14:11 #save 19:14:19 #topic #880014 2018 - New TC member 19:14:33 So. Let's try to stick to "whatever we can say in public" :) 19:14:52 I asked a specific question in private, to which I'd appreciate more feedback though. 19:15:05 ack I failed to respond. 19:15:17 There's the question of making our numbers' public. 19:15:29 the one I responded to, right? 19:15:34 yep; thanks ntyni :) 19:15:40 yes. can someome summarize the numbers thing for lazy me? 19:16:38 the TC currently doesn't disclose any numbers (candidacies, accepted candidacies, vette nominations, nominees, chosen nominees) 19:16:39 I mean, why and why not make the numbers public in general? 19:17:19 pros should be obvious as in more visibility to the project 19:17:36 There's the fear of singling out individuals, depending on which numbers are disclosed, and who made their nominations public. 19:18:20 right, both "winning" and "losing" candidates might be sensitive. 19:19:06 Yep. So for the most recent nominations (hi bremner, ntyni), the TC acted in blackbox and the only process output was a post-DPL-veto public vote. 19:19:43 right. 19:20:00 I think we could make the number of nominees public; just saying "the TC has received $n valid nominations" (valid as in "is currently DD", not necessarily accepted). 19:20:49 as a nominee, I could handle it I think. 19:21:27 We should rather not make any "filtered output" nominees' counts public though. 19:21:50 #action OdyX to suggest making the number of nominees public to the list. 19:21:59 assuming the rest of process stays the same. 19:22:06 hi! 19:22:18 There's the GR / constitution change discussion, but I don't think that's urgent at all. 19:22:22 * fil reads backlog (having got the kids in bed) 19:22:42 if someone (TM) feels it is, they know what to do 19:23:11 and meanwhile we keep on having private pre-votes ? 19:23:18 I will move on to the next topic, as we need to either discuss that on the public list, or the gory personal details on our private alias; there's not much more we can do here. 19:23:32 ntyni: Yes AFAIC 19:23:40 in principle could someone make a GR to force us to have a more public vote? 19:24:03 I'm not recommending this, I just want to know the redress is there. 19:24:12 bremner: by modifying the consitution, sure 19:24:32 bremner: In my reading of the constition, we can use any non-voting flamewar/discussion/private meeting/dice to find out our preferred candidate, now. 19:24:42 dondelelcaro: there seems to be disagreement as to whether the current process is constitutional. 19:25:11 bremner: but by making it explicitly clear that it's not (by modifying the constitution), one can force the entire process to be public. 19:25:23 the discussion is whether our "sorting vote" counts as "vote on appointment". 19:25:37 (I think that would be terrible, but that's a separate discussion to whether it's possible) 19:26:03 OdyX: the alternative would be to have 'discussion' but no actual secret ballot; I'm not sure where that line is drawn 19:26:26 right, I guess it's clear some private discussion is OK 19:27:51 keithp: we use the secret ballot to avoid public downvoting; the private "sorting" enables a public "A vs FD" vote for one seat instead of a "A vs B vs C vs FD" vote to which all TC members would downvote B & C. 19:27:54 bremner: I think if someone felt that the constitution said differently, they could ask the secretary for a ruling 19:28:11 I'll move on :-) 19:28:12 #topic #881339 allow node-babel-preset-env to build depend on itself 19:28:52 Oh. I missed that that was a ctte bug 19:28:59 having looked into this one, I'm still not sure why node-babel-preset-env actually build depends on itself 19:29:07 I haven't followed closely, but dondelelcaro did (thank you) 19:29:12 thanks indeed 19:29:21 OdyX: right, if we couldn't have a secret ballot of that sort, we'd end up having "discussion" about who to place on the ballot, which could result in a single A vs FD public ballot anyways 19:29:35 keithp: yep 19:29:48 I can see that it depends on a bunch of node things, but not all of them seem to be required to do the bootstraping 19:29:54 it's not forbidden for a package to B-D on itself, but hurts bootstrapping and sorts. 19:30:13 my usual question: why is this our problem? 19:30:30 but I suspect here that if they just document why it needs the B-D, and explain how to manually bootstrap/point to documentation, ftpmaster will be OK 19:30:51 As it seems from quickly skimming through the bugreport, either it's an FTP-Master problem (and we found out we cannot [and don't want] to intervene), or just a misunderstanding. 19:31:01 bremner: yeah, my opinion is that this issue isn't ripe for the TC to do anything 19:31:43 bremner: AFAICT, there wasn't any communication with ftpmaster before it was refered to the TC 19:31:54 We could just close it with "TC cannot overrule DPL delegates' decisions other than by setting policy, and there's no policy to be set here" ? 19:32:07 there's some more ftpmaster communication logged in the bug fwiw 19:32:09 but not that much 19:32:14 has ftpmaster actually rejected the package? 19:32:28 bremner: yeah, but it was just an initial reject with "why does this B-D on itself?" 19:32:34 ok. 19:32:49 and notes that it could build without that B-D 19:32:58 ftpmaster backed this by quoting policy 2.2.1 19:33:06 "the packages in main must not require or recommend a package outside of main" 19:33:27 any compiler written in its input language would be rejected on that line 19:33:31 sure 19:33:47 do we have explicit self-build-dependencies in the archive atm? 19:33:49 ntyni: right, I think that's because to easily do the initial bootstrap, you need lenna and some other things 19:33:53 ntyni: gcc 19:33:54 ntyni: surely gcc 19:34:08 presumably java as well 19:34:12 even though gcc is build-essential? 19:34:13 Besides our curiosity, is there TC material here? Could someone #action hirself to get that to closure ? 19:34:15 (though GCC's bootstrap procedure is well known and pretty easy to do) 19:34:15 Is this just a case of a tired and emotional maintainer being trigger happy with TC referrals? 19:34:39 OdyX: it raises an interesting question on 2.2.1 in re compilers 19:34:51 keithp: no, _we_ raised that 19:35:03 which we can do, but not necessarily for this bug 19:35:04 keithp: I'm not saying it's uninteresting, nor that I agree nor disagree with FTP Masters. 19:35:07 ntyni: yeah, because it needs the right versioned dependencies 19:35:19 bremner: Thorsten raised 2.2.1 19:35:32 ntyni: rustc and golang too. 19:35:36 I'm saying I don't see how this needs TC-as-a-body involvment. 19:36:17 We figured in the browserified-javascript case that the TC cannot overrule a DPL delegate, this needs to be done via GR. 19:36:23 so, if it's a policy bug, reassign to policy? 19:36:25 OdyX: agreed, it doesn't seem like we should be making a ruling here 19:36:48 or perhaps better, open a new policy bug 19:36:50 We can only emit our opinion, and I don't think it's valuable at this point, especially not for a package that can circumvent self-B-D easily. 19:37:10 bremner already has an #action, any other taker ? 19:37:38 * marga is here. 19:37:41 I can take the action 19:37:52 Maybe I can redeem myself from my months of disappearance 19:38:11 (also, sorry for being late, I got the hour wrong) 19:38:33 I note Thorsten asking: Ok, so why don't you just use these solutions? 19:38:42 There's no redeeming necessary. But if you're interested, please do! 19:38:52 to which the reply was: I've forwarded it to the ctte 19:39:05 that's just typical *sigh* 19:39:30 #action Marga to close the bug stating that it's not in our power to overrule delegates 19:40:08 There's probably hand-holding to be done there; and also the generic circular-build-dependencies discussion. 19:40:37 #topic #883573 Reevaluate libpam-systemd systemd-sysv dependency ordering (746578) 19:41:23 It seems like we ought to also note that punting things at the ctte is not a great alternative to answering the technical questions asked by delegates, since we'll just want to know the same things 19:41:37 Indeed 19:42:10 For 883573, I haven't had time to grasp the full context yet. It seemed like the APT maintainer had reasonable input, and didn't see why we should diverge. 19:43:38 I'm a bit confused by this bug, as it sounds to me like apt resolver is doing something wrong. I'm not against changing the order now, but it still seems weird that instead of fixing the resolver we get to rule on whether the dependencies can be re-ordered 19:44:22 well, aiui there's a ruling in effect explicitly stating the order 19:44:55 as hypothesis: we could nullify the decision without saying what should be done instead. 19:44:57 so perhaps the thing to do is to declare that the maintainers are now free to choose the order (assuming the old ruling is not necessary anymore as claimed in the bug) 19:45:03 Yes, I understand, but at the same time this seems like a situation that could happen with other packages and that the resolver should be able to resolve? 19:45:34 yeah, makes sense to say that the decision is not necessary after stretch 19:45:49 in other words "time has flown away, software has changed, please keep in mind that we don't want to force systemd onto users who explicitely refuse it, but implement the sanest technical solution" 19:45:59 it makes sense for the archive to have one or the other order so what you end up with doesn't depend on installation order. 19:46:14 I think that's what I thought when I read this stuff (but I'm a bit sleep deprived, so ...) 19:46:47 Mithrandir: I don't follow what you mean by "the archive" here. Isn't that just whatever is uploaded? 19:46:48 fil: it's not clear to me to whom you agree (but we seem to be mostly in agreement) 19:47:22 bremner: yes, and we want that to be consistent across packages. 19:47:33 Mithrandir: ok, but this bug is about one package? 19:47:47 ah, ok, I thought it was more general 19:47:51 was the original ruling about packages in general? 19:47:59 [that the time has passed beyond the usefulness of the decission that declared the explicit order, so it should no longer stand ... I think ;-) ] 19:48:12 I read the wrong bug, sorry. 19:48:32 I blame OdyX for putting different bug #s at each end of the topic. :-P 19:48:59 Mithrandir: I bounce the blame to jak for putting the old bug at the end of the new bug. 19:49:24 ok, so both bugs are about libpam-systemd afaict 19:49:42 anyway, I think the request is reasonable and we should just revoke the old ruling. 19:49:46 ack 19:49:49 agreed 19:50:05 yes 19:50:11 yup 19:50:39 so if there are other requirements in the future, the maintainer can do the right thing without involving us (unless there's a real need) 19:51:05 or they're just trying to annoy fil ;) 19:51:23 and, if something breaks non-systemd in the future, it will probably require a more subtle fix than the old ruling anyways 19:51:40 I can prepare a short and straight-to-the-point ballot unless someone beats me to it. 19:52:01 OdyX: please do. 19:52:05 #info #883573 there's agreement that the old ruling can be revoked; it needs balotting & vote. 19:52:24 #action OdyX to prepare a short ballot to revoke the previous decision for #883573 19:52:36 #topic Additional Business 19:52:43 err. previous decision for the 7XXXXX bug 19:53:00 bremner: right. But it'll be a bug closing #883573 19:53:03 ok. 19:53:18 I had a possibly wacky suggestion about nominations for the TC 19:53:22 I'm glad we could all be present for the last meeting of 2017 btw. 19:53:34 And I'm sad to see keithp go in 11 days :/ 19:53:35 what if we explicitly see nominations of "new" DDs? 19:53:43 it seems like such a short tenure 19:53:53 * OdyX hugs keithp 19:54:01 where "new" = less than five years since becoming a DD, or ? 19:54:07 bremner: talk to fil. He tried fancy ideas before 19:54:07 OdyX: hope to in taiwan :-) 19:54:13 (unlikely…) 19:54:23 bremner, see = seek? 19:54:25 is this like spam, where there's a checklist of bad ideas? 19:54:28 marga: yes 19:54:36 bremner, how? 19:54:46 bremner: do it! (whatever it is :-) ) 19:54:57 marga: by asking for that explicitely in a call for nominations 19:55:12 many "new" dd's probably feel they should not self-nominate. 19:55:14 bremner: I don't think we have a blacklist. From experience, the problem is getting nominations of people for which the TC can acquire enough confidence on the hoped skillset. 19:55:31 bremner, and you feel they should? 19:56:25 marga: I feel like people's technical knowledge in some ways goes downhill after becoming a DD 19:56:52 Interesting, I don't think they are necessarily correlated in that way :) 19:57:04 I feel remiss in not doing running nomination roulette machine -- is it too late, or should I pester people over Xmas? 19:57:13 well. I did say it was a "potentially wacky" idea 19:57:14 please pester 19:57:26 s/doing running/running my/ 19:57:27 We need TC members with energy and a good understanding of both the technical and social landscapes of the project. 19:57:33 Anyway, I think it would be definitely fine to include a note that no specific tenure is required and that we would like to particularly invite people to self-nominate even if they feel like they haven't been a DD for "long enough" 19:57:41 sure. 19:57:53 yes 19:58:00 Stating that we want people with less than 5 years as DDs sounds like you are actually asking people who have been there longer to not nominate 19:58:30 marga: well, we can send out multiple calls for nominations. It's a kindof marketing trick 19:58:40 heh 19:59:01 It might not be healthy to trick people into the TC :) 19:59:11 works for debconf 19:59:20 I'll close the meeting, as we have drifted to unformal discussion, but _please_ continue the discussion. 19:59:21 "works" 19:59:28 #endmeeting