18:59:53 <OdyX> #startmeeting
18:59:53 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:07 <OdyX> #topic Introductions
19:00:10 <tacocat> OdyX, ok, will def be reading :)
19:00:12 <OdyX> Didier Raboud
19:00:19 <Mithrandir> Tollef Fog Heen
19:00:20 <ntyni> Niko Tyni
19:00:25 <bremner> David Bremner
19:01:18 <OdyX> fil is excused
19:01:50 <OdyX> marga: you around ?
19:02:25 <OdyX> #topic Review of previous meetings' TODOs
19:02:39 <OdyX> http://meetbot.debian.net/debian-ctte/2017/debian-ctte.2017-10-18-19.01.html was our last recorded meeting.
19:03:06 <OdyX> hartmans did the poking for modemmanager, and I did the two process, discussion and d-d-a for TC candidacies.
19:03:16 <Mithrandir> I've failed to do what I was supposed to do, sorry.
19:03:41 <OdyX> No worries. Do you want to get the action item again or hand it over ?
19:03:58 <Mithrandir> either is fine, I should have some time over yuletide.
19:04:07 <OdyX> #action Mithrandir to start an initial "bug handling" checklist.
19:04:15 <OdyX> #topic #877024 modemmanager should ask before messing with serial ports
19:04:19 <OdyX> This has stalled
19:04:48 <Mithrandir> I thought we decided to go into a holding pattern?  Is there something we should do to intervene at this point?
19:05:40 <OdyX> 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 <bremner> ooc, is the package orphaned now?
19:06:08 <OdyX> (problem is, the escalation to TC had a withdrawal of one maintainer as result)
19:06:15 <OdyX> Technically, it's not.
19:07:15 <bremner> would it be counterproductive to close the TC bug?
19:07:33 <OdyX> Not if we have (and mention) good reasoning IMHO.
19:07:41 <OdyX> I would be counterproductive to rule, IMHO.
19:07:46 <ntyni> has the remaining maintainer participated in the discussion at all?
19:07:56 <OdyX> Not as far as I can tell.
19:08:21 <OdyX> An option would be for one of us to reach out to hir and discuss.
19:08:38 <OdyX> Any taker ?
19:09:24 <bremner> what would we want to discuss? whether they generally think the upstream proposed fix is OK?
19:09:57 <OdyX> well, and how they would take a TC ruling.
19:10:19 <Mithrandir> my understanding from what mbiebl wrote was that the new/old maintainer isn't really active.
19:11:16 <OdyX> 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 <bremner> yes, if that doesn't feel too much outside our remit
19:12:11 <bremner> I mean, we can always do such a thing as individual DDs, but it is a bit of a cheat.
19:12:13 <OdyX> Well. Even if it's a hard to remove hat, it's no formal TC-as-a-whole action.
19:12:55 <OdyX> Talking to Mathieu seems just like a not-too-hard thing to do; which we haven't done yet AFAIK.
19:13:14 <OdyX> (I'd take that action if it were not for the other items on our agenda)
19:13:18 <bremner> I can ask about his plans for maintainership.
19:13:23 <keithp> tnx
19:13:57 <OdyX> #action bremner to reach out to modemmanager's maintainer to clarify position and expectations regarding #877024
19:14:00 <OdyX> #ave
19:14:09 <OdyX> #ceasar
19:14:11 <OdyX> #save
19:14:19 <OdyX> #topic #880014 2018 - New TC member
19:14:33 <OdyX> So. Let's try to stick to "whatever we can say in public" :)
19:14:52 <OdyX> I asked a specific question in private, to which I'd appreciate more feedback though.
19:15:05 <bremner> ack I failed to respond.
19:15:17 <OdyX> There's the question of making our numbers' public.
19:15:29 <ntyni> the one I responded to, right?
19:15:34 <OdyX> yep; thanks ntyni :)
19:15:40 <bremner> yes. can someome summarize the numbers thing for lazy me?
19:16:38 <OdyX> the TC currently doesn't disclose any numbers (candidacies, accepted candidacies, vette nominations, nominees, chosen nominees)
19:16:39 <bremner> I mean, why and why not make the numbers public in general?
19:17:19 <ntyni> pros should be obvious as in more visibility to the project
19:17:36 <OdyX> There's the fear of singling out individuals, depending on which numbers are disclosed, and who made their nominations public.
19:18:20 <bremner> right, both "winning" and "losing" candidates might be sensitive.
19:19:06 <OdyX> 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 <bremner> right.
19:20:00 <OdyX> 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 <bremner> as a nominee, I could handle it I think.
19:21:27 <OdyX> We should rather not make any "filtered output" nominees' counts public though.
19:21:50 <OdyX> #action OdyX to suggest making the number of nominees public to the list.
19:21:59 <bremner> assuming the rest of process stays the same.
19:22:06 <fil> hi!
19:22:18 <OdyX> 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 <bremner> if someone (TM) feels it is, they know what to do
19:23:11 <ntyni> and meanwhile we keep on having private pre-votes ?
19:23:18 <OdyX> 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 <OdyX> ntyni: Yes AFAIC
19:23:40 <bremner> in principle could someone make a GR to force us to have a more public vote?
19:24:03 <bremner> I'm not recommending this, I just want to know the redress is there.
19:24:12 <dondelelcaro> bremner: by modifying the consitution, sure
19:24:32 <OdyX> 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 <bremner> dondelelcaro: there seems to be disagreement as to whether the current process is constitutional.
19:25:11 <Mithrandir> 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 <OdyX> the discussion is whether our "sorting vote" counts as "vote on appointment".
19:25:37 <Mithrandir> (I think that would be terrible, but that's a separate discussion to whether it's possible)
19:26:03 <keithp> 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 <bremner> right, I guess it's clear some private discussion is OK
19:27:51 <OdyX> 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 <dondelelcaro> bremner: I think if someone felt that the constitution said differently, they could ask the secretary for a ruling
19:28:11 <OdyX> I'll move on :-)
19:28:12 <OdyX> #topic #881339 allow node-babel-preset-env to build depend on itself
19:28:52 <bremner> Oh. I missed that that was a ctte bug
19:28:59 <dondelelcaro> having looked into this one, I'm still not sure why node-babel-preset-env actually build depends on itself
19:29:07 <OdyX> I haven't followed closely, but dondelelcaro did (thank you)
19:29:12 <ntyni> thanks indeed
19:29:21 <keithp> 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 <OdyX> keithp: yep
19:29:48 <dondelelcaro> 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 <OdyX> it's not forbidden for a package to B-D on itself, but hurts bootstrapping and sorts.
19:30:13 <bremner> my usual question: why is this our problem?
19:30:30 <dondelelcaro> 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 <OdyX> 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 <dondelelcaro> bremner: yeah, my opinion is that this issue isn't ripe for the TC to do anything
19:31:43 <dondelelcaro> bremner: AFAICT, there wasn't any communication with ftpmaster before it was refered to the TC
19:31:54 <OdyX> 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 <ntyni> there's some more ftpmaster communication logged in the bug fwiw
19:32:09 <ntyni> but not that much
19:32:14 <bremner> has ftpmaster actually rejected the package?
19:32:28 <dondelelcaro> bremner: yeah, but it was just an initial reject with "why does this B-D on itself?"
19:32:34 <bremner> ok.
19:32:49 <keithp> and notes that it could build without that B-D
19:32:58 <ntyni> ftpmaster backed this by quoting policy 2.2.1
19:33:06 <ntyni> "the packages in main must not require or recommend a package outside of main"
19:33:27 <keithp> any compiler written in its input language would be rejected on that line
19:33:31 <ntyni> sure
19:33:47 <ntyni> do we have explicit self-build-dependencies in the archive atm?
19:33:49 <dondelelcaro> ntyni: right, I think that's because to easily do the initial bootstrap, you need lenna and some other things
19:33:53 <dondelelcaro> ntyni: gcc
19:33:54 <keithp> ntyni: surely gcc
19:34:08 <keithp> presumably java as well
19:34:12 <ntyni> even though gcc is build-essential?
19:34:13 <OdyX> Besides our curiosity, is there TC material here? Could someone #action hirself to get that to closure ?
19:34:15 <dondelelcaro> (though GCC's bootstrap procedure is well known and pretty easy to do)
19:34:15 <fil> Is this just a case of a tired and emotional maintainer being trigger happy with TC referrals?
19:34:39 <keithp> OdyX: it raises an interesting question on 2.2.1 in re compilers
19:34:51 <bremner> keithp: no, _we_ raised that
19:35:03 <bremner> which we can do, but not necessarily for this bug
19:35:04 <OdyX> keithp: I'm not saying it's uninteresting, nor that I agree nor disagree with FTP Masters.
19:35:07 <dondelelcaro> ntyni: yeah, because it needs the right versioned dependencies
19:35:19 <keithp> bremner: Thorsten raised 2.2.1
19:35:32 <Mithrandir> ntyni: rustc and golang too.
19:35:36 <OdyX> I'm saying I don't see how this needs TC-as-a-body involvment.
19:36:17 <OdyX> 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 <bremner> so, if it's a policy bug, reassign to policy?
19:36:25 <keithp> OdyX: agreed, it doesn't seem like we should be making a ruling here
19:36:48 <bremner> or perhaps better, open a new policy bug
19:36:50 <OdyX> 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 <OdyX> bremner already has an #action, any other taker ?
19:37:38 * marga is here.
19:37:41 <marga> I can take the action
19:37:52 <marga> Maybe I can redeem myself from my months of disappearance
19:38:11 <marga> (also, sorry for being late, I got the hour wrong)
19:38:33 <fil> I note Thorsten asking: Ok, so why don't you just use these solutions?
19:38:42 <OdyX> There's no redeeming necessary. But if you're interested, please do!
19:38:52 <fil> to which the reply was: I've forwarded it to the ctte
19:39:05 <fil> that's just typical *sigh*
19:39:30 <marga> #action Marga to close the bug stating that it's not in our power to overrule delegates
19:40:08 <OdyX> There's probably hand-holding to be done there; and also the generic circular-build-dependencies discussion.
19:40:37 <OdyX> #topic #883573 Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)
19:41:23 <fil> 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 <OdyX> Indeed
19:42:10 <OdyX> 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 <marga> 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 <ntyni> well, aiui there's a ruling in effect explicitly stating the order
19:44:55 <OdyX> as hypothesis: we could nullify the decision without saying what should be done instead.
19:44:57 <ntyni> 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 <marga> 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 <marga> yeah, makes sense to say that the decision is not necessary after stretch
19:45:49 <OdyX> 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 <Mithrandir> 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 <fil> I think that's what I thought when I read this stuff (but I'm a bit sleep deprived, so ...)
19:46:47 <bremner> Mithrandir: I don't follow what you mean by "the archive" here. Isn't that just whatever is uploaded?
19:46:48 <OdyX> fil: it's not clear to me to whom you agree (but we seem to be mostly in agreement)
19:47:22 <Mithrandir> bremner: yes, and we want that to be consistent across packages.
19:47:33 <bremner> Mithrandir: ok, but this bug is about one package?
19:47:47 <Mithrandir> ah, ok, I thought it was more general
19:47:51 <bremner> was the original ruling about packages in general?
19:47:59 <fil> [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 <Mithrandir> I read the wrong bug, sorry.
19:48:32 <Mithrandir> I blame OdyX for putting different bug #s at each end of the topic. :-P
19:48:59 <OdyX> Mithrandir: I bounce the blame to jak for putting the old bug at the end of the new bug.
19:49:24 <bremner> ok, so both bugs are about libpam-systemd afaict
19:49:42 <Mithrandir> anyway, I think the request is reasonable and we should just revoke the old ruling.
19:49:46 <bremner> ack
19:49:49 <marga> agreed
19:50:05 <ntyni> yes
19:50:11 <fil> yup
19:50:39 <Mithrandir> 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 <bremner> or they're just trying to annoy fil ;)
19:51:23 <keithp> 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 <OdyX> I can prepare a short and straight-to-the-point ballot unless someone beats me to it.
19:52:01 <Mithrandir> OdyX: please do.
19:52:05 <OdyX> #info #883573 there's agreement that the old ruling can be revoked; it needs balotting & vote.
19:52:24 <OdyX> #action OdyX to prepare a short ballot to revoke the previous decision for #883573
19:52:36 <OdyX> #topic Additional Business
19:52:43 <bremner> err. previous decision for the 7XXXXX bug
19:53:00 <OdyX> bremner: right. But it'll be a bug closing #883573
19:53:03 <bremner> ok.
19:53:18 <bremner> I had a possibly wacky suggestion about nominations for the TC
19:53:22 <OdyX> I'm glad we could all be present for the last meeting of 2017 btw.
19:53:34 <OdyX> And I'm sad to see keithp go in 11 days :/
19:53:35 <bremner> what if we explicitly see nominations of "new" DDs?
19:53:43 <keithp> it seems like such a short tenure
19:53:53 * OdyX hugs keithp
19:54:01 <bremner> where "new" = less than five years since becoming a DD, or ?
19:54:07 <OdyX> bremner: talk to fil. He tried fancy ideas before
19:54:07 <keithp> OdyX: hope to in taiwan :-)
19:54:13 <OdyX> (unlikely…)
19:54:23 <marga> bremner, see = seek?
19:54:25 <bremner> is this like spam, where there's a checklist of bad ideas?
19:54:28 <bremner> marga: yes
19:54:36 <marga> bremner, how?
19:54:46 <fil> bremner: do it! (whatever it is :-) )
19:54:57 <bremner> marga: by asking for that explicitely in a call for nominations
19:55:12 <bremner> many "new" dd's probably feel they should not self-nominate.
19:55:14 <OdyX> 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 <marga> bremner, and you feel they should?
19:56:25 <bremner> marga: I feel like people's technical knowledge in some ways goes downhill after becoming a DD
19:56:52 <marga> Interesting, I don't think they are necessarily correlated in that way :)
19:57:04 <fil> I feel remiss in not doing running nomination roulette machine -- is it too late, or should I pester people over Xmas?
19:57:13 <bremner> well. I did say it was a "potentially wacky" idea
19:57:14 <Mithrandir> please pester
19:57:26 <fil> s/doing running/running my/
19:57:27 <OdyX> We need TC members with energy and a good understanding of both the technical and social landscapes of the project.
19:57:33 <marga> 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 <bremner> sure.
19:57:53 <ntyni> yes
19:58:00 <marga> 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 <bremner> marga: well, we can send out multiple calls for nominations. It's a kindof marketing trick
19:58:40 <marga> heh
19:59:01 <marga> It might not be healthy to trick people into the TC :)
19:59:11 <bremner> works for debconf
19:59:20 <OdyX> I'll close the meeting, as we have drifted to unformal discussion, but _please_ continue the discussion.
19:59:21 <marga> "works"
19:59:28 <OdyX> #endmeeting