18:59:32 #startmeeting 18:59:32 Meeting started Wed Aug 21 18:59:32 2019 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:38 #topic Roll Call 18:59:51 Who's here? 18:59:51 Tollef Fog Heen 18:59:52 Margarita Manterola 18:59:54 Gunnar Wolf is here 18:59:59 Philip Hands 19:00:52 OdyX? You said you'd be here? 19:00:53 Didier Raboud 19:00:57 Ah, there :) 19:01:13 Present and mostly focused. 19:01:20 #topic #932795 How to handle FTBFS bugs in release architectures 19:01:40 So, Gunnar reached out to the Release Team about this 10 days ago. 19:01:50 gwolf, did you hear anything about it? 19:01:51 I expected to see more movement on this bug... but it seems it does not inspire much communication by anybody :-( 19:02:10 I got a private mail from a RT member stating his opinion 19:02:37 could we get it on our alias (from that person) ? 19:03:05 It seems like a classical "TC cannot override a delegate" case, right? 19:03:19 I will obscure the person and send it to ctte-private - In short, it says it "makes sense", but he fears the team is a bit overworked with arch qualification 19:03:36 But he mentions RT has a meeting on 2019-08-28, and they can discuss the issue 19:03:41 (will ask him to do so) 19:03:47 So unless RT asks the TC to rule, we can't say much more than "hmm yeah, it seems it makes {,no}sense" 19:04:04 right. Just give our opinion on the thing 19:04:58 Agreed 19:05:07 we can also decide to set technical policy here by (*handwave*) requiring packages that do not build on $standard_machine to declare so in a suitable format in the control file. 19:05:33 In which suitable format? 19:05:36 (oh - I'm sending it unobscured - he *did* mean to send it to our public list, sorry) 19:05:49 that'd need to be further defined, but not by the TC, since we don't do that. 19:05:58 I think this would actually be going down the road of designing... 19:06:36 I think there is a broader social issue about bug severities and RC bugs in particular. 19:06:49 not sure if we're the right body to address that issue. 19:07:00 I'm not sure we want to go down that route, on one hand, having it explicit if packages have unusual requirements would be good, on the other hand, lots of work, and it'll be useless unless it's actually used. 19:07:15 (that route = the one I'm handwaving about) 19:07:27 bremner: I think we are *not* the right body. But a general answer, we can give. 19:07:50 Right, I think this might actually be an interesting thing to specify. But I don't think it's up to us to do so... 19:07:52 I haven't followed closely, but, provided we don't have a mechanism for packages to specify their minimal requirements (minCPU: 2), building in otherwise fine environments (chroot, etc) that just have 1 CPU available seems reasonabl. 19:08:31 It could be right for packages to specify any "oddities" of its build - but it opens a can of worms. What can be specified? What not? 19:08:37 bremner: but then who is? Not the Policy editors, not the DPL; the RT ? 19:09:07 is this something the community team should be involved in? 19:09:18 You know my opinion - I think it should be up to the RT to define the minimum expectations. But, yes, that's something they should first accept 19:09:35 Uhm, I don't think their responsibilities are well defined, but I don't think that's in their scope 19:09:52 So GR ? 19:09:59 marga: it's a refinement of definining release architectures 19:10:13 marga: their = who? CT? 19:10:18 I mean, if what vector instructions are allowed is valid, I think #cores also is 19:10:21 I meant the community team in my comment, sorry 19:10:28 and they drop architectures when "they can't keep up" over time 19:10:37 I do think this falls onto the release team to define what's supported 19:10:56 more broadly, it's up to the release time what is "release critical" 19:11:01 OdyX: Why GR? 19:11:04 But I don't know who's responsibility it is to define how to specify oddities 19:11:21 and this bug was essentially about the submitter wanting a bug to be RC 19:11:24 marga: nobody's really. Somebody who's interested. 19:11:32 gwolf: it would allow to avoid picking a team to have to decide on that, an provide a clear path forward. 19:11:58 Well - mips is getting dropped because the architecture is no longer technically able to build many packages (FSVO many) with <2GB per process - That's arch qualification. 19:12:10 I think we're discussing multiple things here: the social bits, how to work around the underlying bug with technical measures and who decides what when it comes to RC-ness 19:12:17 gwolf: "We collectively decide that it's a bug worth fixing when packages don't build with $blabla" 19:12:21 and having all those discussions interleaved is confusing. 19:12:26 agreed 19:12:31 Defining minimum thresholds per architecture does not seem too taxing for me - but I'd like to hear explicitly from the team before we pass the ball to them 19:12:32 ack 19:12:33 social issues first? 19:12:38 bremner: sgtm. 19:13:05 FOAD, QA work is important, and underappreciated 19:13:18 OdyX: hmm... GR seems not-nice in my book. Maybe as the TC we can make a call to RT to state after their meeting whether they can take this? 19:13:37 And if not, well, it becomes An Issue™ 19:13:44 gwolf: GRs don't solve social issues, let's keep to that first. 19:13:48 right. 19:14:09 so, what are the social issues? 19:14:14 and past efforts that started as mere QA (amd64, reproducible, …), have proven their usefulness later 19:14:26 right. 19:14:27 The social issue I think is QA work not being appreciated? 19:15:28 * ntyni waves, sorry I'm late 19:15:57 marga: Yes. The hostility in the original bug report was quite unwarranted, FWIW. I didn't feel any kind of understanding was attempted. 19:16:18 Right, I agree with that. But I'm not sure how we could solve it 19:17:01 We maybe can't solve it, but it might help to publically affirm the value of QA work as something the project should care about. 19:17:19 I think that is technical policy if you squint right 19:17:26 There's a point about "which QA", isn't it? 19:17:32 of course. 19:17:34 I'm not sure the maintainer saw this as QA work. At some point you go from QA to pushing the envelope on what a reasonable build env looks like in order to file more RC bugs, so it depends a bit on point of view. 19:17:59 Mithrandir: OK. Is that an independent social problem? 19:18:35 I think we can certainly agree that "QA merits our consideration, as do QA-related bugs" 19:18:39 Mithrandir: also, I think assuming good faith comes in here 19:18:54 Mithrandir, while that could be the case, I think that's not the case here, so probably not worth discussing hypothetical cases. 19:18:57 But it could be argued that "QA work should not be done on impossible situations" 19:19:10 Because for one of the parties, single-core building is an impossible situation 19:19:58 And we _do_ have lower limits for other things: disk, RAM. 19:19:59 So, this could be rephrased on whether it is really a QA effort or a relic from the past or whatever... Not all QA efforts are valued equal :-\ 19:20:14 bremner: I don't know if it's the case here. I genuinely believe that one side did not see this as useful QA work, at least initially. 19:20:40 Yes, agreed. 19:20:43 Mithrandir: I know, but I think that was the wrong way to approach it. 19:20:54 Ok, so, what do we want to do about this? 19:21:03 I personally find value in the essence of the single-CPU setup: it's a simple model. 19:22:25 I also sympathize with the position arguing for single-CPU being workable. 19:22:30 However, that's not for us to judge 19:22:36 We cannot qualify it as enough or not 19:22:37 on the other hand, testing software "Algorithms for Parallel Adaptive Mesh Refinement" on multi-CPU, makes sense. 19:22:55 OK, but can we finish the social question first? 19:23:30 bremner: What would solve it? Us agreeing to issue a call for recognizing QA work, in the abstract? 19:23:43 Sure, although it's related: these models and how they're communicated also have social effects. 19:24:01 or recognizing work that crosses the boundaries of individual packages or teams. 19:24:05 should the submitter have a way of tagging a bug "this is part of a QA effort", in order to hopefully let the maintainer know that while a setup might seem slightly contrived, the submitter has created that setup to increase quality? 19:24:26 Mithrandir: a usertag? 19:24:31 (and so hopefully build more empathy for qa efforts over time) 19:25:05 maybe a usertag would be useful, yes, or a real tag? 19:25:12 yeah, either way I guess 19:25:15 Ummm, while Lucas had his daily rebuild project going, all mails included something similar to what Mithrandir suggests - and it helped quickly understand what was going on 19:25:21 If it's a serious bug, it will trigger the whole autoremoval process. 19:25:25 So, yes, it could be a recommendation for this case as well 19:25:54 1) QA good. 2) explain you're doing QA 19:25:55 Yeah, I guess we could recommend an introduction to bugs explaining that this is part of an ongoing QA effort and then invite everybody to recognize that QA efforts make our codebase better 19:26:10 with or without usertags. That's also the social discussion: are all FTBFS serious? 19:26:11 recommend that QA efforts set up a wiki page explaining what they do and include that link in bug reports would also work. 19:26:15 I don't know how much we would solve, but I guess we can do that. 19:26:44 OdyX, I don't think that's a social issue 19:26:54 or at least it's a different one 19:26:57 I think that's the part that's left to the RT 19:27:03 indeed. 19:27:23 but the severity of the bug being serious is what makes the odds higher. 19:27:24 yes 19:27:41 I agree with the interpretation that RT defines which bugs are RC 19:27:46 And doing QA that results in packages removed from a release is harsh. 19:27:55 So perhaps "do QA as important bugs" ? 19:28:38 Generally I think being conservative with bug severities is sensible. OTOH, some things are clearly RC. 19:28:42 "think about whether you think your QA effort, even if it leads to FTBFS bugs, should lead to the package failing the QA test to be removed from the next stable release" 19:29:01 ^ thanks for the phrasing. 19:29:12 Mithrandir: 19:29:49 quite -- one seems very likely to get a significantly more negative reaction if firing off a lot of bugs that are going to remove packages 19:30:19 Ok, it seems we have consensus on this? 19:30:28 I'd like to "both-sides", and add something like "as a maintainer, consider whether such a bug makes your package unfit for the stable release" 19:30:50 bremner: yup! 19:30:55 +1 19:31:00 Right. In this case, that addresses the social issue. 19:31:13 Ok, we need to action someone to send that email, I guess 19:31:21 Anybody feels like volunteering? 19:31:38 Well, I took action on this bug earlier on 19:31:43 I can take it again 19:31:47 Ok :) 19:31:54 are we doing this as a recommendation with a resolution or just issuing some informal guidelines? 19:31:55 I will draft it and send it to the private alias 19:32:10 fwiw I think the submitter has stated clearly that he thinks all FTBFS bugs should be RC, presumably with all the consequences including removal 19:32:13 I think it would be a way of non-ruling but issuing a general recommendation 19:32:36 so I'm not sure how much that recommendation helps 19:32:39 Mithrandir: I think resolution needs RT input? 19:32:47 #action gwolf to write an email with the agreed consensus regarding explaining QA efforts, recognizing QA efforts, considering whether this should be RC from the QA point of view and the maintainer point of view. 19:32:49 6.1.5 Offer advice; if phrased well enough. 19:32:56 (but I certainly agree with the proposed recommendation) 19:33:09 I still hope RT will discuss the issue... 19:33:25 Right, do they need any kind of input from our side? 19:33:26 should we mention that we think the specific decision is up to the RT? do we agree on that? 19:34:04 In our "advice" decision? I'd avoid pressuring them through it. 19:34:07 yes, they decide whether packages are fit for the release or not, by way of RC-bugginess, which in theory is decoupled from bug severities. 19:34:24 Yeah, agreed 19:34:33 yes, I agree 19:34:33 lets say it's loosely coupled :-] 19:34:38 agreed 19:34:41 sorry, only just got here 19:34:49 and by extension, I think they should also decide if bugs filed by a QA effort are RC or not. 19:34:58 Ok, are we done with this bug or is there anything else that warrants discussion here? 19:35:10 Mithrandir: yes, I think that's implicit 19:35:29 I think part of the issue with this particular QA bug-filing is that the bug submitter wants his bugs to be RC to force people to fix them 19:35:33 Mithrandir: but I'm happy to be explicit if you think it helps 19:35:38 * gwolf quickly jumps to search for coffee 19:35:54 and I don't think that's OK - RC status is a tool for producing working releases, not a stick to hit maintainers with 19:35:57 bremner: probably more implicit than by extension, I agree. I think being explicit here could be useful, since we are being asked about this particular angle. 19:36:06 smcv: yes. 19:36:12 smcv: quite 19:36:17 smcv: yes, I also think there's a "stick" part that I'm uncomfortable with 19:36:21 I would prefer not to judge the motivations 19:36:39 And rather stick with our recommendations, which I think that are sensible. 19:36:39 smcv: I agree also. That was my original comment about "general problem with bug severities and RC bugs" 19:37:14 smcv: I think the bug submitter is far from alone in feeling that way about RC bugs. 19:37:32 I think QA is important, and it's good for people to do it, but they should not expect that every bug they find gets prioritized highly 19:37:45 we don't seem to have any other levers to convince people that our priorities should be other people's priorities. 19:37:54 * gwolf agrees with general sentiment on RC-stickiness 19:37:55 remember release goals? 19:38:07 smcv: agreed, and it can change over time. reproducible builds started out as a pet project and is now rather important. 19:38:16 Mithrandir: but still not RC 19:38:35 I think this is not going anywhere productive, can we move on to the next topic? 19:38:40 ok 19:38:56 #topic #934948 Unnecessary dependencies vs multiple binary packages 19:39:30 Alright, so I really liked Simon's elaborate response to this one, but it only happened today 19:39:39 smcv: Thanks for your summary on this one. Really helped me understand the issue better than a casual read while tired. 19:39:58 thanks indeed. 19:39:59 smcv: yeah, that was great, thanks 19:40:36 so we're waiting on the reply to that now? 19:40:39 having spent an hour earlier today trying to describe the problem, I still don't have a solution 19:40:55 there's a reply already 19:40:58 marga: Yes, it only happened today - But it feels we will (again) end up deciding "hey, that's not for us to decide" 19:41:05 Date: Wed, 21 Aug 2019 22:59:50 +0530 19:41:08 We cannot overrule a delegated body (ftp-masters) 19:41:11 gwolf: that was part of the setup 19:41:16 yes 19:41:25 Well, they explicitly asked for advice 19:41:55 oh, was it them that asked Praveen to open the bug? Right... 19:42:04 I don't see the reply 19:42:07 I don't think so? 19:42:21 No, Praveen opened the bug asking for advice 19:42:32 ftp-master just told them not to do what they were doing. 19:42:33 The original bug report mentions, "I was also told to contact CTTE and DPL before going for a GR by js team members." 19:42:52 Ah, yes, although I didn't see that in the chat log 19:43:29 smcv: so if there was no executables involved, just dropping the depends on nodejs would be fine, right? 19:43:36 I can't help thinking that was less "hmm, we don't know, ask the CTTE" and more "stop talking to us, please talk to someone who is not us, and if you *really* think we are wrong, the bureaucratic way to overrule us is a GR" 19:44:03 possibly with an implied subtext of "don't open a GR" that Praveen missed 19:44:42 bremner: as far as I can work out, nothing would fail without the dependency? so yes? 19:44:59 libraries for interpreters that don't depend on their interpreter feel a bit weird 19:45:07 would alternative dependencies be a viable compromise? Depends: nodejs | ruby 19:45:17 sounds like a textbook use case for Recommends, tbh 19:45:20 but maybe only because I'm used to Python which is needed at install-time to byte-compile 19:45:29 smcv: fwiw, emacs addons work that way (no dependency on emacs, if done correctly) 19:45:43 smcv: it's not _needed_, but better, is it not? 19:45:54 I'm not sure where the rule of having to depend on the interpreter comes from 19:45:57 on the perl side I think libraries having Depends: perl is more for the standard library than for /usr/bin/perl 19:46:06 if you think "this is like libfoo-perl" then Depends makes sense 19:46:11 (looking at the packages in question)... I don't think a general case can be made out of this - as this is quite clearly tied to the two ecosystems in question (ruby and node) 19:46:19 if you think "this is like openarena-data" then Recommends or no relationship at all makes sense 19:46:33 either mental model can work here, I think 19:46:42 and JS can be useful without an interpreter (served to browsers). 19:46:45 right 19:46:46 there's also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=119517 19:47:17 so "any JS that is useful when served accross network should not Depend on a local interpreter" ? 19:47:17 Part of the argument was that the js bits were usable from a browser (which completely escapes our packaging ecosystem 19:47:19 ) 19:47:43 gwolf: to me, that suggests that the relationship to nodejs should at most be recommends. 19:47:46 I think "not useful without the interpreter" is not a problem the package system needs to solve 19:47:55 I mean, nodejs uses will have nodejs installed. 19:48:04 gwolf: not completely; we (or "some") want to be able to ship full web applications from Debian packages" 19:48:07 Yeah, I actually agree that if the file is usable without the interpreter, the interpreter doesn't need to be in the Depends field, it could be Recommends or even Suggests. 19:48:20 But of course, this is a case by case thing, not something that will match all packages 19:48:42 I don't even think it needs to be usable in an obvious way. Maybe the user has a private copy of nodejs 19:49:03 bremner: You could also say that installing a Ruby library without Ruby installed is agreeable because you want to be able to open it locally with Emacs to study it 19:49:08 I'm quite biased also because I've come to be used to having perl and python2 on virtually all systems. 19:49:15 Uhm... I'm not sure that's a valid argument. You could make it for python interpreters as well. 19:49:21 it is not the use case Debian works with... 19:49:34 python is different because the postinst runs pycompile 19:49:47 so it literally won't install correctly without a python interpreter 19:49:59 … which makes things faster, but is not _mandatory_. 19:50:00 (won't configure, in dpkg-speak, iirc) 19:50:06 well, in the case of executables, the harm of a missing interpreter is clear, since the user doesn't need to know what interpreter it uses 19:50:14 I just want my frobnicator. 19:50:27 You are right. But the point is that in general we want our packages to be usable inside Debian, not with outside packages 19:50:40 bremner: yup, but even that is allowed to be non-Depends for non-core bits of the package. 19:50:46 right, if you install the package that provides /usr/bin/frobnicator, and it happens to be written in nodejs, and it doesn't have Depends: nodejs, then you will be sad 19:50:57 at least if it's the frobnicator package in Section: utils 19:51:18 if it's the node-frobnicator package in Section: javascript that arugument is weaker 19:51:44 marga: the harm of the extra depends is larger than the (hypothetical?) harm of the missing depends, unless the install breaks or something similar 19:51:55 smcv: my technical view on sections is that they can die in a fire 19:51:58 ;) 19:52:03 what's the harm of the extra depends? 19:52:06 bremner: sure, but they're a convenient way to make my point 19:52:08 ... This still feels at very least that a Recommends would be in place 19:52:14 marga: getting nodejs when you don't want it 19:52:20 marga: bloating your install by ~50MB for node 19:52:27 50MB 19:52:28 Ok. 19:52:29 bremner: "this is the package for a utility" vs. "this is the package for a Javascript library" 19:52:31 marga: pulling in an interpreter one has no intention of ever using 19:52:36 (didn't check for Ruby) 19:53:26 Ruby seems smaller, but we're looking at 15+MB at least. 19:53:38 so it's not huge, but also not tiny. 19:53:47 plus security surface in both cases 19:53:48 (assuming that's a real subset of our users) 19:54:29 The question asked to FTP is #921628 "Allow creating separate binaries for node and browser environments when the node component provides and executable" 19:54:34 the fact that one of praveen's example packages is a mixture of ruby and javascript seems particularly odd, but I suppose that's a combination that makes sense to Ruby-on-Rails programmers 19:54:34 (ufff, most of nodejs' dependencies size is taken by libicu64 - 32MB... International Components for Unicode :-P 19:55:03 OdyX: yes, it would have helped for Praveen to summarize that bug. 19:55:31 and that goes back to my original question about executables being the problem. 19:55:41 OdyX: so for the "provides an executable" case, which is actually not the one where Praveen is asking us to not-really-overrule-but-sort-of-overrule the ftp team, I would automatically have said 19:55:48 smcv: a lot of CSS/JS related stuff seem to be nodejs, so there's some crossover there. I've seen a bit of the same in the Rust world. 19:55:55 move the dotted line into a different place 19:56:13 instead of: nodejs stuff | browser stuff 19:56:19 have: library | executable 19:56:40 and then it becomes obvious that the executable needs a dependency on its interpreter, and the library doesn't 19:56:41 smcv, can you clarify? I'm not sure I see what you mean 19:56:50 From the py and pl examples, it seems harsh to special-case js on the interpreter question. Put I have yet to see a web dev using nodejs from Debian, nor expecting to have nodejs without installing it explicitely. 19:57:13 so for example src:tap.py (which I maintain) has these binary packages 19:57:17 python3-tap - a library 19:57:26 python-tap - a library 19:57:51 and tappy - /usr/bin/tappy (which, behind the scenes, is a CLI wrapper around python3-tap) 19:58:34 following the general principle of packaging the executable as though it's an executable, and the library as though it's a library, and those are different things 19:58:46 currently the interpreter is a depends of python{,3}-tap, and not of tappy 19:58:47 And how would that look like for the node package? 19:59:12 move the nodejs depends to tappy, away from libjs-tap ? 19:59:16 node-frobnicator (also Provides: libjs-frobnicator) - a library 19:59:46 and frobnicator (exists to supply /usr/bin/frobnicator) - an executable, which happens to depend on nodejs and node-frobnicator 20:00:04 But would the ftp team allow this? 20:00:11 that's the question 20:00:12 ah, that's where things become scary; thanks for the highlight. 20:00:17 they did for tappy 20:00:45 smcv: yes, but you didn't submit 7000 packages of that form 20:00:49 right, but the JS team happens to have a ton of tiny packages 20:00:52 I had thought that it was best-practice to package executables to look like executables, and libraries, separately, to look like libraries, if you see what I mean 20:00:53 right 20:01:12 smcv: agreed with the best practice part. 20:01:27 as opposed to for example libaudio-mpd-perl, which I happen to have installed solely because it contains /usr/bin/mpd-dynamic 20:01:34 actually, both tappy and python3-tap Depends: python3:any 20:01:49 (and I keep accidentally removing it when I mark all of Section: perl as "automatically installed") 20:01:52 (be 20:01:57 Yeah, but we already mentioned that python libraries need the intepreter to run postinst 20:01:58 (It's been 1hr... And I have to leave, sorry ☹ ) 20:02:01 (because pycompile) 20:02:04 yeah, we're overtime 20:02:11 Is there an action to take here? 20:02:15 I will look at backlog in a couple of hours, and probably comment off-meeting-time 20:02:31 (yeah. Sorry, I'm very tired and need some repeating to understand stuff tonight) 20:03:09 can I continue to brain-dump a bit and give people something to think about offline? 20:03:16 so, this is all to avoid a dependency that pulls in ~50MB when it might be on a web server that wants to serve it to clients, is that right? ... and there are web servers that might not have 50MB spare presumably. Hmm 20:03:32 yes please. I don't think we're ready to rule on this. 20:03:39 FWIW, I think this issue makes perfect sense for ftp-masters to decide 20:03:40 It seems to me that Pirate's cause could benefit from having a Coach/mentor to help phrasing things clearly too. 20:03:47 fil: I'm vaguely worried about container use case, not really machines. 20:03:47 for the 7000-packages-like this situation, I wonder whether the answer is to aggregate some of the JS libraries into fewer larger packages that "look like a library" 20:03:54 And I'm leaning towards "the ctte supports ftp-masters' decision" 20:04:07 #action smcv will continue brain-dumping and share with us. 20:04:08 but yes, it's a bit too quick to decide - my brain is more hungry than clear 20:04:09 smcv: they already have something like that going on, but I think you know? 20:04:09 Thanks Simon! 20:04:14 and aggregate some of the executables that happen to have been written in JS into fewer larger packages that "look like executables" (in the style of libglib2.0-bin) 20:04:15 Mithrandir: ah, fair enough 20:04:18 * gwolf leaves now. o/ ! 20:04:29 And we'll close it here, we didn't get to discuss re-thinking the TC. We'll do that next time 20:04:33 #endmeeting