--- /dev/null
+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
\ No newline at end of file
projects / debian-ctte.git / commitdiff