19:02:37 <marga> #startmeeting
19:02:37 <MeetBot> Meeting started Wed Sep 18 19:02:37 2019 UTC.  The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:37 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:38 <marga> #topic Roll Call
19:02:39 <marga> Who's here today/tonight?
19:02:40 <marga> Margarita Manterola
19:02:47 <fil> Philip Hands
19:02:54 <ntyni> Niko Tyni
19:02:59 <Mithrandir> Tollef Fog Heen
19:03:27 <gwolf> Gunnar Wolf
19:03:49 <marga> Sorry, my connection had been working fine for over two hours but I guess I jinxed it.  Seems to be working again, but I'll co-chair people just in case.
19:03:51 <OdyX> Didier Raboud
19:04:59 <marga> #addchair OdyX
19:05:09 <marga> Is that it? I couldn't find the reference
19:05:10 <gwolf> marga: My IRC client hiccuped for the first time since before DebConf, so maybe something jinxed us all
19:05:26 <OdyX> Ed… Stop that.
19:05:28 <marga> Anyway, let's move to our first topic
19:05:51 <marga> #topic #932795 How to handle FTBFS bugs in release architectures
19:06:21 <marga> So, last time Gunnar had an AI of writing something up. Something was indeed written and commented on. What's the current status and how do we want to move forward?
19:06:29 <gwolf> Well, there is little to report on this front
19:06:50 <gwolf> I am waiting for some more comments to somehow merge them and propose a better document
19:07:07 <marga> Ok, do we want to set any kind of deadlines for that?
19:07:08 <gwolf> But I'm not sure whether some points are at all mergeable /-:
19:07:36 <marga> I had some minor editing comments, but I didn't know how to send those, particularly given the other requested changes.
19:07:42 <gwolf> i'd say, by Friday I'll send to the internal list a new draft, as well as comments... Is that OK?
19:07:50 <marga> Sound good.
19:07:53 <gwolf> right... Should I set up a non-public pad instead?
19:08:10 <OdyX> Why private?
19:08:36 <gwolf> Well, because it's not yet public. But whatever
19:09:04 <marga> pads are hard enough already without making them private on top of that :)
19:09:27 <marga> #action gwolf to incorporate comments to the draft response and send that out for review by Friday.
19:09:47 <gwolf> OK!
19:10:08 <marga> Anything else on this topic? I personally think Gunnar's email pretty much captures what we discussed here, so I'm happy that we're close to a resolution.
19:10:50 <fil> likewise
19:11:00 <OdyX> It's not a very bold move from the TC, but we're laying down good principles yes.
19:11:17 <ntyni> agreed
19:12:23 <gwolf> right... Bold we are not.
19:12:26 <marga> Okay, moving on...
19:12:28 <marga> #topic #934948 Dropping dependencies to avoid extra binary package when same source package targets more than one environment
19:12:56 <marga> This one had an AI for smcv: ACTION: smcv will continue brain-dumping and share with us.
19:13:41 <gwolf> But it seems we don't have a smcv handy :-(
19:13:49 <marga> Right.
19:14:02 <marga> I don't think that happened, unless I somehow missed the email.
19:14:26 <marga> I'm a bit confused by the emails that we got between last month and this, they seem to be only the answers to some mails that we're not getting...
19:15:32 <marga> But anyway, it seems that this is a case of a single maintainer not being able to have a conversation with ftp-master
19:16:23 <OdyX> and ftp-master being fed up / not patient/pedagogic enough to make themselves understood clearly to said maintainer too?
19:16:59 <OdyX> (not fingerpointing, just saying they look busy and terse answers can leave a too wide margin of interpretation sometimes.
19:17:00 <fil> well, it's hardly his first such case :-/
19:17:05 <marga> Right. It seems that what would be needed here would be some kind of mediated conversation between maintainer and ftp-master
19:17:17 <gwolf> There is some value in the maintainer's request, of being able to keep installs lean by splitting packages... But OTOH ftp-master's point makes sense systemically, as we don't want to drown in metadata with tiny little useless packages
19:17:40 <OdyX> The line is hard to draw, and isn't drawn consistently
19:17:58 <gwolf> I think the resolution for #934948 will be quite close to #932795 - "be kind to each other, consider things from their position..."
19:18:20 <Mithrandir> ftp-master has offered to be consistent by removing the other package too, so I kinda think they've made their position somewhat clear?
19:19:15 <OdyX> I also feel there's a language barrier at play here, and wonder if someone could two-way-translate the needs of the maintainers as well as the constraints from ftp-maste
19:19:18 <marga> gwolf, I agree. I don't think this is something we can rule on, though
19:19:40 <OdyX> Mithrandir: arguably, it might have been understood as provocation/irony.
19:19:55 <marga> Is this maybe a job for the community team? I don't really know what the scope of the team is since the rename.
19:20:39 <Mithrandir> I can reach out to them and ask if they would consider getting involved?
19:21:09 <marga> Mithrandir, that would be nice
19:21:10 <gwolf> marga: I think it's a good idea
19:21:49 <gwolf> We need to agree IMO that tech-ctte is not a stick for not-nice people to become nice to "me" (for a plural use of "me").
19:22:15 <Mithrandir> ok, I'll reach out to the community team and see if they consider it within their realm, and if they do, let them run with it. If not, I'll let the TC know.
19:22:28 <Mithrandir> (I'll let the TC know in either case)
19:22:44 <marga> #action Mithrandir to find out if this case is in the scope of the Community Team.
19:23:03 <marga> gwolf, in general, TC shouldn't be a stick
19:23:10 <gwolf> exactly
19:24:01 <fil> I'm somehow imagining that they won't relish the request ... but I guess that the lot of the Community Team to some extent :-/
19:24:12 <fil> that's, even
19:24:40 <marga> Ok, anything else on this topic? Is there something we would want to do here?  We know (and the requester knows) that we can't override ftp-master.
19:24:40 <Mithrandir> I don't think they have an easy job, no.
19:25:52 <gwolf> move on, I say, next topic..
19:26:00 <marga> Ok!
19:26:16 <marga> #topic The nature of the TC and whether we want to change something
19:26:36 <marga> So, this is a topic I added last month, based on our DebConf discussion and the previous discussion that had been going on in the mailing lists
19:27:01 <gwolf> And, I'd add, related to the mails we have got (and seldom answered) from Sam
19:27:10 <marga> Yes.
19:27:23 <marga> With all of these discussions going on, it seems pretty clear that the TC is not living up to the ideals of why it was established.
19:27:30 <marga> We almost never decide on technical policy
19:27:52 <marga> We decline to rule a lot, because a lot of the matters that are raised to us are social in nature
19:27:53 <gwolf> Although it is also related that we don't get that many reports/issues on technical policy
19:27:58 <OdyX> and when we do, it's a hard-sell (menu, systemd)
19:28:02 <marga> Right, exactly.
19:28:20 <Mithrandir> OdyX: yup, because a lot of those are 80/20 social/technical.
19:28:39 <marga> On one of the latest emails on this matter, OdyX mentioned that we could basically split the role in two: arbitration and steering
19:29:05 <marga> I think Ian had proposed a similar split, although not exactly the same (? I fail to remember exactly what Ian's proposal was)
19:29:43 <fil> he wants to scrap the TC doesn't he?
19:30:00 <marga> Yeah, well, but he was saying that there could be 2 bodies to take on the TC tasks
19:30:01 <OdyX> I also detailed the "arbitration" part: sometimes, a "that's the current community practice, it's not documented clearly, but mostly everyone knows it, so please abide"
19:30:08 <OdyX> … is needed.
19:30:11 * fil has a certain sympathy for that, but suspects we'd need to imediately set up the same thing again
19:31:19 <OdyX> A steering committee is, to some extent, an idea that is really alien to how Debian works.
19:31:24 <gwolf> Well, the social arbitration falls towards Community Team
19:31:32 <gwolf> And... yes, I was about to write just what OdyX
19:31:41 <gwolf> We don't steer no stinking steering
19:31:52 <OdyX> But it has been needed in the past: systemd, menu, etc.
19:31:57 <bremner> err. sorry I;m late.
19:32:39 <Mithrandir> Debian's answer to A or B is often "why not both, and C too?", which is both a strength and a weakness.
19:33:08 <OdyX> the question is what would have happened without the TC in the systemd case e.g. My bet? An endless flamewar with a horrible no-winner GR.
19:33:41 <marga> Yeah, I don't think the solution is to scrap the TC completely
19:33:54 <Mithrandir> that's the 20 year flood, while we should think about those, let's not design all our processes as if every case is a 20 year flood case.
19:34:07 <gwolf> It has not (yet?) been proposed. And I don't think it would get us anywhere better
19:34:09 <marga> But how can we change it so that we bring more value? So that people don't feel like we are a stick to hit others with?
19:34:31 <gwolf> It's OK that the TC does not get that much _real_ work (and that it discards some bugs as notforus)
19:34:38 <joostvb> (bits from ctte @ debconf gives good insight)
19:34:43 <OdyX> lower the GR barrier to "normal GR" ?
19:35:16 <Mithrandir> isn't this a "how do we make Debian scale better"? type of question, more than just the TC?
19:35:17 <OdyX> Remove authority to overrule developers?
19:35:28 <OdyX> Mithrandir: sure.
19:35:33 * fil thinks the A, B & C thing is mostly strength -- most attempts to do things like guess which science is worthy of funding, by committee, are hopeless
19:35:42 <marga> gwolf, yeah, I'm not worried about not having too much work. But it's bad when maintainers opt to orphan a package rather than engage with us.  That's a big red flag of things not working
19:36:04 <gwolf> marga: Yes. Although it's not a _usual_ case.
19:36:19 <gwolf> There are some people who don't like the mere existence of TC
19:36:33 <Mithrandir> marga: agreed about the orphan-vs-engage.
19:36:49 <bremner> I think the orphan-vs-engage is not all on the TC
19:37:01 <gwolf> FWIW I was quite shocked to see that kind of answer :-/
19:37:08 <marga> OdyX, if the TC doesn't have the authority to overrule, then the recourse in that case would be a GR. Is that what you're proposing? Or something else?
19:37:08 <bremner> in particular TC process is not exausting just because of the TC
19:37:13 <Mithrandir> I think it's because everything we do is on a stage and it becomes a bit of a trial-by-combat.
19:37:34 <marga> Yeah, one of the things that was floated at DebConf was to remove the "we do everything in the open" clause
19:37:53 <Mithrandir> so while the TC might not be at fault, some/many/lots of people will disengage if the other party just keeps upping the ante.
19:38:03 <marga> And I actually think that COULD be a change for the better. The problem is that it goes against the typical Debian transparency
19:38:08 <bremner> Mithrandir: but that could happen with any RC bug IMHO
19:38:15 <OdyX> marga: I was just wondering what could make the TC less of a giant nuclear hammer.
19:38:17 <gwolf> And FWIW we *don't* do everything in the open - We do have the closed list (which has non-negligible value IMO)
19:38:18 <fil> it's a rational response -- if someone sues you regarding something that you don't care that much about, simply walking away may well be the right thing to do, and the TC is a bit like being taken to court
19:38:23 <Mithrandir> bremner: most RC bugs aren't reported on in LWN.
19:38:33 <OdyX> (but by removing overruling, it's mostly not a hammer at all)
19:39:03 <bremner> Mithrandir: I can imagining orphaning packages because of bugs
19:39:07 <gwolf> TC needs to be able to overrule. But it needs to use this power VERY seldomly
19:39:20 <OdyX> (which it did in the recent years)
19:39:25 <marga> Yeah, and we do use it very seldomly
19:39:40 <Mithrandir> OdyX: if we don't want to be heavy artillery, I think we need to have fewer heavy artillery-shaped tools in our toolbox.  I think it's more about perception about what we have available than what we use.
19:40:30 <marga> Mithrandir, so are you advocating for removing the power to overrule?
19:41:08 <bremner> I'm not convinced the TC would be useful as a purely advisory body
19:41:09 <OdyX> fil: following up on the court's analogy, it seems Debian could make use of other, lower courts. With only the TC as Supreme Court, all cases are of the same paramount importance.
19:41:13 <Mithrandir> marga: no.
19:41:27 <Mithrandir> as for openness, I think that's a super important to keep in mind, but at the same time, the world is a bit different now than 20 years ago, and stuff that used to be ok on the wider internet no longer is, and I think we need to change accordingly.
19:41:50 <marga> Someone suggested that if we overrule someone, we send them a nice gift (like a box of chocolates). To make the overruling sting less.
19:42:03 <OdyX> a functioning judiciary system (but the more I follow the analogy, the scarier I get) is layered, and cases normally start small; with mediation as a non-court option.
19:42:16 <bremner> marga: angry people will react to (anything) angrily
19:42:22 <marga> OdyX, and what would be the lower courts?
19:42:53 <gwolf> OdyX: We are a society of 1000 members. We don't need multi-layered systems for this
19:42:58 <Mithrandir> I think we should be given the ability to perform work in a non-public arena and be trusted to judge when that is appropriate (but we should default to public-when-possible/reasonable9
19:43:10 <gwolf> We have 2-4 concurrently open bugs... No reason to scale up bureaucracy
19:43:15 <fil> are the likes of ftp-master often acting as lower courts?  (at which point this breaks down, since we cannot overrule them)
19:43:20 <marga> Another proposal that was floated around was to have a process for involving the TC early, without "invoking" the TC. Like "Could you please come and look at this bug?" and then have someone from the TC look at the bug and weigh in with their opinion.
19:43:21 <OdyX> non-public mediation by 3-4 non-involved DDs; then a small non-TC (but with powers) body, perhaps acting privately too. Don't really know.
19:43:30 <gwolf> And we now have the Community Team with whom to split up some tasks (the social bits)
19:44:49 <OdyX> marga: yeah. If you think of the TC as "the judiciary", having an external "district judge" as first adviser/opinion on a matter could help
19:45:49 <marga> So, the constitution says: Public discussion and decision-making. Discussion, draft resolutions and amendments, and votes by members of the committee, are made public on the Technical Committee public discussion list. There is no separate secretary for the Committee.
19:45:50 <fil> the problem I see with that is that our biggest fails of late have IMO been ones of acting too late, and extra layers seem likely to introduce more delay
19:46:01 <OdyX> gwolf: they don't have powers at all (which is maybe a feature)
19:46:11 <bremner> fil: unless less things reach us
19:46:14 <marga> Would inviting people to raise awareness of a bug that *might* need attention on the private mailing list contradict that or not?
19:46:16 <gwolf> OdyX: right
19:46:48 <gwolf> But the TC *does* need the powers. IMO it's important to be able to overrule. And it's important that we keep in mind it is a last resort.
19:47:13 <OdyX> gwolf: and if they start having powers to arbitrate, a delegation would be a minimal, and an election/designation process would be "nice"™
19:47:52 <ntyni> #934948 started out pretty much as "Could you please come and look at this bug", though with a GR threat in the mix
19:47:53 <OdyX> marga: not if bugs come to our attention but we all turn our heads away in hope that someone else from the TC feels empowered/motivated enough to look
19:47:58 <marga> A possible procedure would be: "If you think that a bug is escalating and might eventually end up in the TC, drop us a note at <private address>. Someone from the TC will take a look at the bug and weigh in with their personal opinion (not a TC ruling)"
19:47:59 <bremner> I guess the self selecting part is another potential area of change
19:48:13 <marga> I'd say we establish a rotation or something
19:48:30 <OdyX> It's basically a private BTS
19:49:11 <marga> Well, we could use RT, maybe?
19:49:12 <fil> bremner: true, if something can be sorted out without ever getting to us, that might be quick -- also, if one's done a mini-TC thing first, at least all the facts ought to get collected and be available immediately
19:49:34 <marga> If we want to spend time on procedure... (and digging through spam, or has that been fixed by now?)
19:49:55 <gwolf> A rotation for quick-opinion might be right, I think - But we must keep sure of *trying* to be representative of the group
19:49:58 <gwolf> (which is not trivial)
19:50:15 <marga> Uhm, no, that would mean delays
19:50:28 <marga> the point is that the person is giving their personal opinion, not the TC opinion
19:50:48 <marga> We could make it be the TC's opinion, but then it would be a slow process, not quick.
19:50:57 <marga> And the goal of that was to make it less nuclear
19:51:02 <OdyX> marga: I think my point is that most TC-level cases need a heavy context switch, and that won't be much different with private cases. At least with public cases, I get the urge to look at all the cases we get.
19:51:57 <gwolf> marga: Yes, but people might want to contact *one or some* of us - But wearing our TC hats
19:52:26 <marga> bremner, were you trying to propose that the TC should be elected by all DDs? I'm not against it, but the tricky part their is that this needs a lot of constitutional changes to make it work. But yes, that's definitely something that could be done.
19:53:34 <bremner> marga: It came up in the discussion. I'm not sure if it's a good idea or not, but I think it's fair to say the TC selection process is something that bugs (some) people.
19:54:34 <gwolf> Right, some people are bugged by it. Now, having an elected TC would probably mean campaining... And the TC would have to become a board of sorts - Getting back to the "steering" part.
19:54:39 <gwolf> Which could be good or bad (-:
19:54:41 <OdyX> It's not perfect, and I think it became slightly better; but I fail to see a "much better" alternative.
19:54:47 <gwolf> (it would be different, for sure)
19:55:08 <bremner> it's fine with me if we think the people that it bugs should run the GR
19:55:18 <Mithrandir> taking a step back, why should we steer? Who is asking for it, what value does it bring?
19:56:52 <OdyX> The "menu" is maybe a better example that the systemd case; for me it was good that the TC could say "knowing the drawbacks, we decide that the burden of maintaining menu is now on the shoulders of the menu maintainers, and not on everyone".
19:57:30 <OdyX> Without an actual TC decision, menu "MUST" would still be in policy, but ignored by large parts of the project.
19:58:41 <OdyX> So perhaps the TC did not the steering _itself_, but it ruled by reading a consensus from the project and saying to some people in disagreement with said consensus that they were… well… not in agreement with the consensus.
19:59:00 <OdyX> Steering (in Debian) could be "when consensus doesn't work anymore"
19:59:19 <gwolf> [ I have to leave... 1hr is over! ]
19:59:35 <gwolf> (but the meeting can of course continue without me)
19:59:41 <OdyX> and as long as we define consensus as "noone disagrees strongly enough"; we will allow loud disagreers to block adopotion of largely consensual changes.
19:59:48 <Mithrandir> this discussion won't be done for a while. :-)
20:00:16 <OdyX> menu was typically this: some few loud supporters fighting to keep menu in Policy.
20:01:01 <OdyX> (not dismissing their very good reasons; just saying the project consensus [or at least the TC decision] was not to agree with their reasons)
20:01:32 <bremner> People seem (publically) fine with Sam making "concensus calls" as DPL. Is that what we mean by steering?
20:02:18 <OdyX> Sure. And it's technical steering.
20:02:53 <marga> Sorry! I got dropped off again. I guess the future isn't that great after all.
20:03:03 <fil> I'm not a fan of the idea in general (of it being a TC role), because the TC isn't really representative enough -- the menu example was more like identifying that there was a consensus, rather than defining a new direction, so that seemed OK to me
20:03:13 <Mithrandir> personally, not with a TC hat on, I think those are problematic, but I don't have the bandwidth to get properly involved with those ways of working.
20:03:50 <Mithrandir> I think it values speed over making good decisions and assumes too much of -devel's representativeness of the project.
20:03:55 <bremner> ack
20:04:25 <OdyX> fil: indeed. And on the "services must signal when failing to restart", we declined to actively set a direction; we just said what we thought was a good one.
20:05:42 <marga> Alright, we're overtime, and I agree that this discussion will continue, but I think it was useful to hear what each of you thought
20:05:54 <marga> I'll action myself to send email to the mailing list about this.
20:05:59 <bremner> sounds good
20:06:04 <bremner> the public list, I guess?
20:06:09 <OdyX> Yes. Good discussion.
20:06:13 <marga> I'll try to summarize the different points that have been raised and the different approaches we could take
20:06:24 <marga> Yes, the public list. Nothing private about this discussion :)
20:06:30 <OdyX> I wonder if a higher-bandwidth (video, phone) meeting could help.
20:06:31 <fil> Sam's consensus stuff at least provides a way of providing people that don't mind much either way a direction of travel to contemplate, which might well result in there being a real consensus that would not otherwise have developed
20:06:56 <marga> #action marga to try to create a summary of the many different opinions floating around.
20:06:59 <OdyX> (or DebConf, but well, can't make it all years)
20:07:06 <fil> OdyX: not from a plane ;-)
20:07:11 <marga> Indeed!
20:07:13 <marga> :)
20:07:16 <marga> #endmeeting