18:59:36 #startmeeting 18:59:36 Meeting started Wed Oct 16 18:59:36 2019 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:36 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:47 Ah, maybe I should ping. Sorry 18:59:53 MeetBot, pingall Meeting starting! 18:59:53 Meeting starting! 18:59:53 abrotman adsb berni bremner buxy carnil doko dondelelcaro dwfreed fil gregoa gwolf h01ger jcristau marga MeetBot Mithrandir ntyni OdyX ScottK smcv spwhitton themill weasel zigo 18:59:53 Meeting starting! 19:00:04 #topic Roll Call 19:00:12 David Bremner 19:00:12 Welcome to our October meeting, who's around? 19:00:17 Margarita Manterola 19:00:32 Philip Hands 19:01:26 Didier Raboud 19:01:40 Niko Tyni 19:02:11 gwolf said that he wouldn't be able to attend. Did anybody else give notice? 19:02:53 I guess not. 19:02:55 #topic Review of previous meetings AIs 19:03:17 Gunnar had an AI of closing 932795, which he did. Woohoo! 19:04:06 Mithrandir had an AI of discussing with the Community Team whether the communication issues identified in #934948 would be something that they would be willing to take on. 19:04:35 Given that he's not around, does anybody else happen to know if that went anywhere? 19:05:58 Nope 19:06:13 the CT (not to be confused with the TC) seems to be busy with establishing it's place / delegation / rules-of-engagement 19:06:34 I talked to them, they were going to involve themselves and see what they could do. 19:06:51 cool 19:06:56 Ah, awesome! 19:07:00 Not really here, on phone irc 19:07:02 Thanks! 19:07:13 great, thanks 19:07:44 Alright, one last AI (mine). I was supposed to create a summary of our many discussions around the role of the TC and I failed to do this, my work life keeps eating all my time/energy. :-/ 19:08:20 We don't have a lot of topics for today. So, let's do them one by one. 19:08:31 #topic #934948 Dropping dependencies to avoid extra binary package when same source package targets more than one environment 19:09:01 Given that the CT is going to see if they involve themselves, is there anything for us to do? 19:09:43 was it _only_ miscommunication, or was there some technical question (that didn't involve overriding delegates)? 19:10:09 I mean, I guess we had some discussions about best practices? 19:10:31 Yeah, but in the end there's a lot of gray areas that depend a lot on the case? 19:11:45 It's not clear from reading the information that we have the exact technical reason why the package was rejected. 19:12:28 or if such a reason exists. 19:12:29 It's likely that it was the right decision, but we would need to investigate further to make that assessment and we know already that we can't overrule, so... 19:13:34 do we get to change the decision, even if we somehow came to the conclusion it was wrong? (I thought not) 19:13:42 no 19:14:00 thought not ... next 19:14:03 but there is a general question of best practices with respect to bundling. 19:14:17 yeah, fair enough 19:14:18 Right, we can't change the decision, but we can offer advice in general 19:14:37 (which is what was asked from us) 19:15:00 and I think marga opened with being skeptical that we could give useful advice; I don't necessarily disagree. 19:15:13 (in this instance :P) 19:15:33 The delegates communicated in a way that could be improved. But they didn't really indicated they'd welcome our input there? 19:15:40 Yeah, I'm not sure we can give general advice about this, because too much depends on the exact details. 19:15:56 The delegates didn't ask for our advice, no. 19:16:28 quite -- useful advice seems likely to be used as a stick to beat someone, somehow ... unless it's so bland as to be not worth producing 19:16:53 fil: you're not wrong, but we nonetheless have Debian Policy 19:16:55 Agreed 19:17:07 which is indeed used as a stick, but still has some benefits. 19:17:08 (with fil, sorry) 19:17:57 I think FTP-master are aware they could be clearer. 19:18:14 But as it is for us; comprehensive communication is _hard_ and takes time. 19:18:28 ack 19:19:22 is the understanding about not embedding libraries somewhere in policy? 19:19:37 (aside from rules about package names for shlib packages) 19:19:52 #info https://wiki.debian.org/EmbeddedCodeCopies 19:19:57 This issue is not about embedding libraries, though 19:20:00 also, I'd imagine they may be wary of giving detailed explanations to nitpickers 19:20:04 4.13. 19:20:11 fil: oh sure. 19:21:05 marga: do you have a one sentence summary of what this is about? I remember finding the original report pretty incoherent 19:21:29 "it's not about code copies. but about adding additional binary packages just to avoid one dependency" 19:21:30 saying to someone "Rejected for reason X" where X is the most egregious of 7 reasons, is liable to get people claiming that not that X is fixed, all must be fine 19:21:51 s/not that/now that/ 19:22:05 ntyni: ah right. so this is about ftp-masters preference for not having too many small packages 19:22:12 yes I think so 19:22:25 and node/ruby crossover? 19:22:44 Ok, my understanding is that this is about a library (? not sure if one file or more) that can be both used by Ruby and by nodejs and so the maintainer decided to ship the package split into separate pieces, once with a dependency against Ruby and the other with a dependency against nodejs. 19:22:45 OdyX: sure, but I guess that's just because of extra dependencies? 19:23:16 marga: that matches my understanding 19:23:39 and the stated reason for reject is "don't have so many small binary packages" 19:23:40 The rejection is that these two packages are too small and the split is thus not justified 19:23:48 yup, in order to avoid dragging in ruby when only needing nodejs, or vice versa 19:24:11 Right. 19:24:30 I don't really agree with the emphasis on avoiding small packages, but I do think it is ftp-master's call 19:24:47 It's also the tip of the "node produces trillions of tinybitsy packages" problem. 19:24:54 ack 19:25:03 but in other places small packages seem harmless 19:25:04 Right, I guess if node wasn't involved it would be a different story 19:26:01 in this particular case, I'd quite like to see it demonstrated that there are any real users that actually care if they get nodejs and/or ruby cluttering up their system 19:27:29 I forget why these things need to be dependencies and not recommends? 19:27:48 packaging policy apparently (I'm re-reading the bug) 19:28:01 because one of the shipped binaries then doesn't work out of the box? 19:28:04 (in some cases) 19:28:11 yeah, well, devscripts 19:28:14 Like all ruby library packages should depend on the ruby interpreter. 19:28:27 ok, but that's team policy, not Debian policy 19:28:28 And the npm2deb tool creates packages that depend on nodejs 19:28:43 Sure 19:28:44 even weaker IMHO 19:29:10 they probably need parts of the standard library shipped with the interpreter 19:29:27 need for what though? 19:30:39 in the Perl world lib*-perl do things like 'use strict' that are provided by the Perl standard library 19:30:50 I imagine it's similar for Ruby; node is a different beast of course 19:31:18 Yeah, so in Ruby all ruby libraries depend on the interpreter, while for node it's less homogeneous 19:31:31 ntyni: sure, but this is only a failure mode if there is a binary shipped. Pure library packages (obviously?) don't need to depend on interpreters 19:31:42 byte-compilation would be an exception 19:32:04 So, this package could just recommend nodejs, but then the issue is that those that only want to use the node part of the library need to install "ruby | ruby-interpreter, ruby-rack, ruby-activesupport, ruby-html-pipeline" 19:32:18 there'a also the thing that one can want the library because one is throwing it a browser to be run, rather than running it locally 19:32:19 well, those could be recommends too 19:32:54 Well, not if they are really necessary for the ruby part 19:33:03 bremner: I'm saying if the library requires parts of the standard library and the standard library is shipped with the interpreter, a Depends seems appropriate 19:33:17 well, not if it creates bugs that escalate to the TC 19:33:24 I mean, I do think it would be annoying if I was trying to use the library to have to differentiate between two different recommends. 19:33:43 In practice you would already have node installed if you needed it 19:33:49 similarly for ruby 19:34:02 Well, but not necessarily ruby-activesupport, whatever that does 19:35:08 If I was the maintainer of this package, I'd opt to keep the ruby deps as Dependencies and the nodejs dep as Recommends (because it's just nodejs, AFAIU), but I do see the point of this being not-ideal. 19:35:12 yeah, maybe there is some hidden reasons, but I'm seeing a conflict between ruby team policy and ftp-master, it it's clear who wins there 19:36:15 I'm not sure I see that conflict, bremner 19:36:45 I guess the dependency is more complicated on the ruby side. 19:36:52 This whole issue is because there's a source package that ships both a ruby and a nodejs library, which is not what the policy is about 19:37:16 yeah, but the "must depend on ruby" thing is a ruby team decision 19:37:40 Yeah, but I'm inclined to think that makes sense. 19:37:51 maybe I'm in the minority then 19:38:12 I don't understand how missing depencies on interpreters are a problem in practice 19:39:09 Yeah, you might be right about the interpreter, but what about the other libs? 19:39:47 I _guess_ those are not such heavy dependencies 19:40:00 how so? 19:40:15 most libraries for interpreters are small 19:40:32 Ah, you mean in size 19:40:42 I thought you meant in how necessary they were 19:40:55 ah, no, quite the opposite. 19:41:00 Yeah, ok, they're probably less relevant in the "pull in useless stuff" part 19:41:09 I think it only becomes a problem when one zealously implements the policy about binaries working out of the box, and then rubs up against the ftp-masters too-small-package thing -- it would be perhaps important if people were using this to reimplement grep in nodejs, say, such that everything broke when removing nodejs. I don't think that's our reality. 19:41:37 well, yes, binaries are a problem. 19:42:44 Anyway, it doesn't seem like we're getting anywhere... 19:43:41 Should we be asking d-policy and ftp-master to work on a saner policy there? 19:44:06 OdyX: what could change from a policy point of view? 19:44:16 Or just defer it to ruby and node communities to get together for something meaningful? 19:44:45 OdyX: you mean put "don't depend on interpreters unless you really need them" in policy? 19:45:08 bremner: clarify which types of binaries should work directly, and which could be allowed to require recommends (sic) 19:45:15 ah, OK. 19:45:47 sounds like a potential policy bug. and maybe not that controversial? 19:46:03 What would the bug be exactly? 19:46:39 please clarify when it's OK for binaries not work without recommends? 19:46:50 I mean, that's already a kind of judgement call. 19:47:41 a non-0 exit with a meaningful stderr message would work for me. 19:47:43 Wait, but THIS bug is about a library, and the binary thing was about a package that ended up being accepted? 19:48:22 well, if it's about a library than I guess _my_ recommendation is don't depend on interpreters 19:49:03 So, the policy bug would be about not depending on an interpreter for a library? 19:49:34 could be. Or we could just issue that as advice. 19:49:53 unless it's crazy advice, of course. 19:49:54 Given that none of us is an expert on Ruby (AFAIK), I think it would be good to have input from the ruby team on this. 19:50:22 But in his first mail, smcv said that all python and perl packages also do this 19:50:33 s/packages/library packages/ 19:51:01 indeed 19:51:10 So, why is that? 19:51:28 it's generally a harmless dependency 19:51:48 in the case of perl there's the perl-base/perl split so you could have /usr/bin/perl installed without the full standard library 19:52:16 not sure if that's the main/only reason though 19:52:47 it's a very long standing tradition 19:52:59 yeah, that's not _totally_ convincing ;) 19:53:32 you're not convincing me that it's wrong either :) 19:53:47 well, it manifestly causes problems in this instance. 19:53:52 IIUC. 19:54:16 it's a weird case, and maybe it's silly to have policy machinery about it. 19:54:30 So, could we issue advice that says, "stop depending on interpreters that you don't use"? 19:55:01 I mean, it would make zero difference in this case, because of all the ruby deps, that would need to all stop depending on ruby 19:55:28 yeah that's a good point 19:55:33 Or we could, as you say, ask the ruby team why they do this. 19:56:14 Ok, do we want to take an AI? 19:56:17 and perl and python etc. before issuing such a general statement 19:56:36 ntyni: do you feel qualified to answer the perl case? 19:57:27 not sure 19:57:32 I think raising this on -devel might be good 19:57:47 this == libraries depending on interpreters 19:57:50 ok 19:58:11 Yeah, I think that makes sense 19:58:22 Is there anybody who'd like to take this? 19:58:47 I probably can't in the next two weeks. 19:59:05 at least, not and pay any attention to the answers 19:59:08 The AI would be to start a thread on -devel asking whether it still makes sense for libraries to depend on interpreters, if they don't include binaries. 19:59:28 but I can do that before next meeting if noone else wants the honour 19:59:28 I'll take that 19:59:32 yay! 19:59:49 I'm not sure that's the exact problem that is ending up in this beffudled case though -- there's also the stuff about depending on multiple interpreters when as few as zero of them might actually be needed for a particular use case 20:00:38 #action ntyni to start a thread on -devel asking whether it still makes sense for libraries to depend on interpreters, if they don't include binaries. 20:00:44 Thanks Niko :) 20:00:45 fil: I agree it's more complex than that 20:00:58 fil: sure, but if we can't answer the simple question... 20:01:03 which seems of general interest 20:01:14 Alright, we're over time and it seems that we've reached a good ending point. 20:01:27 Somehow yes. 20:01:28 #topic Any urgent other business? 20:01:39 well, as long as answering the simple question isn't taken as some sort of answer to the mess ;-) 20:02:03 Recruiting ? Mithrandir and myself are leaving in 2.5 months, this time for reaz 20:02:05 realz 20:02:10 Yeah :( 20:02:42 The tricky thing is that we've been thinking about a reform. But I guess we should start our recruiting campaign anyway 20:02:50 yes 20:03:01 Or reform now and recruit differently later. 20:03:02 is your departure not somewhat like brexit? or ist it really happening this time? ;-) 20:03:07 I mean, disbanding the TC is one way of solving the recruiting problem 20:03:27 seems a bit lazy of us though 20:03:40 fil: unless we vote a GR before Dec 31, it's a hard Mithrandexit and Odyxit yes 20:04:02 I guess I'll take the AI to send the email that I was going to send last year when I realized that the calculations had been wrong. 20:04:16 We still need to think about the other issue. 20:04:19 (no hard bord^W feelings though :P ) 20:04:44 #action marga to send mail about recruiting 20:04:59 #endmeeting