18:59:20 #startmeeting 18:59:20 Meeting started Wed Dec 18 18:59:20 2019 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:20 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:59:26 #topic Roll Call 18:59:34 Hello, is there anybody out there? 19:00:51 Tollef Fog Heen 19:01:16 Margarita Manterola 19:01:32 Simon McVittie 19:02:52 Seems like we’re the only ones? 19:03:00 I guess... :( 19:03:12 #topic Review of previous meeting AIs 19:04:06 smcv to draft a reply to #934948: yes I finally got round to this 19:04:10 o/ 19:04:12 Gunnar Wolf 19:04:17 So, from my side, I've just sent the recruiting email that I had to send to d-d-a. On top of that, I had to reply to santiago, thanking him for the numbers he provided in the bug we closed, but by now the bug is archived again and I wasn't sure it was worth unarchiving it just to thank him. 19:04:18 Somewhat-here :) 19:05:46 Alright, let's move into the open bug that Simon has drafted a reply for 19:06:04 #topic #934948 Dropping dependencies to avoid extra binary package when same source package targets more than one environment 19:06:50 do we have a preferred platform for editing this sort of thing? 19:07:04 for cooperative editing? Titanpad? 19:07:29 https://etherpad.wikimedia.org/ is the one I tend to use 19:09:02 I've just finished reading Simon's draft. I think it does a great job of collating all the topics that we discussed on this matter. 19:09:08 The open question is what we suggest 19:09:18 anyone know how to paste into a titanpad without mashing all the lines together? :-( 19:09:22 *etherpad 19:09:33 And I don't know what the answer is. Re-attempt to have a dialogue about this? 19:10:59 https://etherpad.wikimedia.org/p/RVW5h33RhT28pIY6W_ds 19:11:46 I've poked the ftp team member that I talked to before to see whether they have a team position on this 19:12:33 I like very much Simon's draft. I will just correct a bit I found (using "I" instead of "we") 19:13:14 (of course, we still need the finalising touch :-] ) 19:15:06 there's no need for it to depend on any interpreter, since neither of those languages do postinst compiling 19:15:21 so I think we should suggest that any interpreter dependencies are dropped. 19:15:24 is that reasonable? 19:15:55 Yeah, I think that's reasonable 19:15:56 I think the dependency on other ruby libraries was the issue? 19:16:02 which we can't wish away like that 19:16:05 The problem was that the ruby libraries bring the interpreter anyway 19:16:18 then those are buggy, given the prior principles in that mail. 19:16:38 probably minor-to-normal buggy, not important (and surely not RC) 19:17:01 right. I guess this will mark as buggy many many many many libraries :-P 19:17:06 The guidelines say that it's ok not to depend, not that it's a bug to depend? 19:17:35 unneccessary dependencies are bugs, are they not? 19:17:36 marga: Yes, but that means a package can be forced to transitively depend when it's not really needed 19:17:59 sorry, this is a design principle that should have been in my list but was not 19:18:14 smcv: dependency minimisation? 19:18:43 "a package that depends on a library libfoo, where libfoo depends on libbar, should not be required to know about libbar" 19:18:47 or something like that 19:19:12 Uhm, yeah, that's just normal dependency handling 19:19:32 I have to leave, sorry 19:19:42 I didn't have this meeting on my head :-( 19:19:48 o/ ! 19:20:10 I was about to ask gwolf what he meant about transitive dependencies, if not that, but ... 19:20:23 Going back to what to suggest, we could suggest dropping the unnecessary dependencies from the affected package and then asking the maintainers of the reverse dependencies to also drop the unnecessary deps? 19:20:55 I think that makes sense. 19:21:03 so what would that mean? asking the maintainers of ruby-rack, ruby-activesupport, ruby-misc, ruby-other to not depend on the ruby interpreter either? 19:21:24 (where ruby-task-list depends on those + the ruby interpreter) 19:21:56 Yes 19:22:01 smcv: I'd like to rewrite your "* In general, it is not a requirement that libraries written in a language" into something slightly stronger, saying that they should not, unless there's a reason why they need to (such as python's byte compilation) 19:22:23 tbh I can't help wondering whether we are going to produce more text in talking about this decision than the entire size of ruby-task-list 19:22:28 right now, it looks a bit like "you don't have to, but if you want to, feel free" 19:23:08 Mithrandir: I have no objection to you making that stronger 19:23:23 relevant thread at https://lists.debian.org/debian-devel/2019/11/msg00212.html 19:23:54 oh, sure, I'm not really intending to make all perl libraries buggy, I think they have a good reason in "the std library is in perl" thing 19:25:16 I think the consensus on that thread is compatible with what Mithrandir said just now 19:25:34 agreed 19:25:35 don't depend, unless there's a reason why you need to[1] 19:25:47 [1] for many languages, you need to, because of reasons 19:26:00 Hi -- sorry for being late (kids took some extra getting to bed today :-/ ) 19:27:11 smcv: something like that? Feel free to wordsmith, of course. 19:27:51 for this "two languages, one package" thing, I would honestly be tempted to lump together a bunch of ruby-and/or-JS libraries into one big source package, and make it build a ruby binary package and a JS binary package 19:28:22 which kinda sidesteps the issue by making each language's part big enough to be worth splitting 19:28:35 that's very unjavascripty. 19:28:36 and oh look! the only rdep of ruby-task-list in Debian is ... gitlab 19:29:43 not sure what the point is there :) 19:30:23 the point is that if we had ruby-task-list and libjs-task-list, both of those are likely to fail the "too small" criterion 19:30:34 I meant on the gitlab side 19:30:43 but if we had ruby-assorted-gitlab-dependencies and libjs-assorted-gitlab-dependencies, not so much 19:31:09 Anyway, I had two proposals of suggested actions: 1) reattempt dialogue 2) remove unnecessary dependencies. Should we suggest one of them? Both? 19:31:36 reattempt dialogue isn't really a solution, it's a path to a solution 19:31:39 ah, ok, but "assorted-gitlab-dependencies" isn't really a nice package to use. Who knows what's in it... 19:32:18 yeah, I know 19:32:21 we used to have a package like that. It was called ia32-libs. It made nobodoy happy. 19:32:30 except with different typos. 19:32:32 insert usual reason to avoid omnibus packages here 19:32:49 but I think they might sometimes be the lesser evil 19:33:48 would you prefer that over adjusting the transitive set of dependencies of the ruby toolchain to be aligned properly? 19:33:54 GAAH. Meeting started 19:34:01 sorry I'm so late. 19:35:00 In this case, I think it was even said that the packages were big enough to justify the split, the problem was that ftp master didn't agree with the motivation of the split 19:35:07 I don't know. depends on (a) how successful that would be (e.g. if librubyx.y gets pulled in but the actual interpreter binary doesn't, then you haven't actually won anything) 19:35:56 and (b) whether the dependencies of e.g. gitlab are already so numerous and so small to be causing practical problems even when not bilingual 19:37:22 isn't part of the problem that one really might not need the interpreter installed ... erm, or that's only on the javascript side of life? 19:37:31 in practice, I don't think this matters at all. Disk is really cheap. 19:37:32 I suspect that the ftp team rejecting the split package may have partly been influenced by "it's another small ruby package and another small JS package and I have deja vu" 19:37:47 so I'm aiming for the shortest path to a reasonable solution. 19:38:11 they have little incentive to explain/justify their reasoning because nothing short of a GR can overrule them 19:38:46 while the maintainer has an incentive to explain/justify why the split is required, but hasn't answered my questions 19:38:50 And small packages in general are too easily annoying 19:38:53 it'd lead to less hot air that contributes to global warming? 19:38:55 (sorry) 19:39:04 :-> 19:40:26 Alright, any other suggestions of what our suggestion at the end should be? 19:41:08 I'm tempted to replace 3. with: For the specific case of src:ruby-task-list, the technical committee does not feel that we have a sufficiently clear picture of the context and trade-offs to make a recommendation. 19:42:06 Or go to the full-length of "split it in three parts: one for each language, with reasonable dependencies, and the third depending on both first" ? 19:42:48 OdyX: are you trying to go full "judgement of solomon" by making a recommendation neither the maintainer nor the ftp team will like? :-) 19:43:07 smcv: well… Yes. 19:43:20 smcv: but isn't this the logical followup to the argument laid before? 19:43:38 Not really, we said we didn't want to blow up the Packages list 19:44:23 So we're saying there are compromises to be made. Now, $group; please do the compromises now that we laid the problem properly ? 19:45:02 Saying "it's hard, you have to resort to compromise between equally good/bad options" is not very useful. 19:45:29 apart from "it's work to adjust dependencies", what are the downsides of doing that? 19:45:47 Mithrandir: the downsides of doing what? 19:45:53 I guess the package name would still be incorrect for the javascript part of it 19:46:13 single binary package with weakened dependencies? 19:46:20 yes 19:46:43 that is already sort of de facto the solution because the ftp team rejected the other one (the split packages) 19:47:07 I think where we are at the moment might be: 19:47:10 we are still confused 19:47:22 the maintainer hasn't answered the questions I asked 19:47:33 what were your unanswered questions? 19:47:49 we aren't going to make a recommendation that contradicts the ftp team decision without knowing why 19:48:16 and so if the maintainer doesn't like that de facto answer (single binary package, weakened dependencies), the next step is to justify the alternative better? 19:48:51 sure -- we shouldn't reward them for not bothering to reply 19:49:01 I think that makes sense. I'd actually be in favor of your "we don't know" message, but it should still have some call to action at the end. 19:49:09 marga: for example https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#32 19:50:19 although that's node-autoprefixer, which praveen raised in the first mail of the bug, then later asked us to stop thinking about, leaving me confused as to why he'd mentioned it in the first place 19:51:25 He thought they were the same thing, then realized they weren't really the same 19:53:21 does everyone agree with this as an addition to the list of design principles? 19:53:24 * If a package depends on a library libfoo, and libfoo requires a second library libbar, then the depending package should not be required to take action based on out-of-band knowledge of the transitive dependency (for example, it should not be required to depend on libbar to make libfoo work). 19:53:40 Sounds too complicated 19:54:01 And really, I don't think it adds any extra information, that's just how dependencies work 19:54:15 yes and no, it depends on whether libfoo exposes the data types of libbar through its interfaces or not. 19:54:33 since in that case, there are lots of worms. 19:54:34 since reducing ruby-task-list's Depends on ruby-misc and ruby-other to Recommends seems to be one of the things under discussion, I don't think it's as obvious as you're making out 19:55:06 if that was obviously unacceptable then nobody would have suggested it as a possibility 19:55:07 I still haven't really spotted the thing that's supposed to be wrong with the weakened dependencies option -- is it that one might install gitlab without an interpreter, and then be befuddled? 19:55:44 it's that one might install gitlab (which depends on ruby-task-list which depends on ruby-misc), and have it not work, because ruby-misc is missing 19:55:47 I think the problem is that it requires all involved packages to weaken the dependency. 19:55:55 or, yeah, that 19:56:24 if the entire Ruby ecosystem (or at least the parts of it in this dependency tree) drop their Depends on the ruby interpreter, then there is no problem 19:57:04 because, as I think fil is implying, gitlab's maintainers surely know that parts of it are written in ruby and know how to give it an appropriate Depends on the interpreter, without relying on a transitive dependency via libraries 19:57:47 I sure hope. getting rid of ruby-foo's dependencies on ruby sounds like something we can do over time with lintian. 19:58:10 oh, and if they don't drop them, then some people might end up with ruby installed that don't strictly need it? 19:58:13 that breaks down with ruby libraries that are written in C and link libruby, though 19:59:16 Alright, we're at the hour and still sort of stuck... Can we move forward? 19:59:31 * fil still suspects that the set of people that care about either issue may well be empty, but I might be missing something 19:59:42 e.g. if we have a dependency chain ruby-misc -> ruby-other -> ruby-debian -> libruby2.5, then anyone installing ruby-misc (even for its side-effect of containing libjs-misc) gets libruby2.5 which is most of the size and functionality of the ruby interpreter 20:00:02 (ruby-debian is the first example I found of a ruby lib written in C, I'm sure there are better examples) 20:00:29 sure, and I think that's fine. 20:00:50 I think we're talking about a tiny set of people. Possibly just containing {i} 20:01:31 quite 20:01:38 counterexample: Ian Jackson in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#22 20:02:01 So, "For the specifics of this case, the technical committee suggests weakening the dependencies of the package, and asking the depended-upon libraries to also weaken their dependencies"? 20:03:12 marga: I thought we had ~consensus that not depending on the ruby interpreter was A Good Thing, but that weakening for example the ruby-task-list -> ruby-rack dependency was A Bad Thing? 20:03:42 I meant the interpreter dep, not the other, sorry 20:03:51 and that instead ruby-rack should weaken or remove *its* dependency on the interpreter 20:03:54 I'd like to be precise and not use "weaken" but rather describe what we're doing: removing any dependency on ruby itself. 20:04:18 So, "For the specifics of this case, the technical committee suggests removing the dependency on the ruby interpreter, and asking the depended-upon libraries to also remove this dependency"? 20:04:49 I'm fine with that. it probably isn't a 100% solution but at least it's a step in the right direction 20:05:28 +1 20:05:47 yup 20:06:06 and if praveen wants to ship the task-list JS bits, are we suggesting that he has one big binary package, ruby-task-list, containing both Ruby and JS code, and with Provides libjs-task-list and node-task-list? 20:06:52 seems reasonable 20:06:57 "big", isn't it? 20:07:00 Yeah 20:07:22 sorry, I mean bigger than the current ruby-task-list 20:07:41 not big on a scale from 0 to Libreoffice 20:07:51 :-) 20:08:33 or texlive or whatever is everyone's favourite giant package at the moment 20:08:38 I think the current ruby-task-list already includes the js bits, no? 20:08:55 that's the impression I had 20:09:30 there's a .coffee file, I'm honestly not sure what that is 20:09:45 heh, ok. 20:09:56 Can we close this? I think we have consensus 20:10:27 yes please :-) 20:10:47 I think the current package doesn't contain the JS in the compiled-to-actual-JS form that praveen wanted it to, only a source form 20:11:06 so, what I said above 20:11:09 Ok. 20:11:25 ok, shall I take an action to polish the text in the etherpad? 20:11:40 do we have a review process? 20:11:59 mail to -private + someone else ack before sending to the bug? 20:12:04 smcv, I think we have reviewed it already. This is not a ruling, so I'm comfortable with the current state. 20:12:13 fine by me 20:12:28 #action smcv to send the email that has been drafted, with the suggestion that for this particular case, the ruby interpreter dependency should be removed. 20:12:28 Go ahead yes :) 20:12:42 I'll try to get that done this evening 20:12:47 Thanks! 20:12:52 #topic Recruiting 20:12:53 * fil trusts smcv absolutely to do a marvellous job :-) 20:13:18 I sent the email to d-d-a 20:13:19 Oh. Only 14 days left for us. 20:13:26 fil, can you do a round of your random thingie? 20:13:30 Thanks for the recruiting mail marga. 20:13:33 sure... 20:13:46 Thanks 20:13:58 (I smirked at the typos in my lastname, handle and IRC nick; no offense taken though :-) ) 20:14:04 And I guess we'll actually do all the recruiting process in January, once we have nominations? 20:14:11 ugh, I'm sorry 20:14:17 * marga shame cubes 20:14:24 OdyX: and then we're freeeeeee! 20:14:25 I should have proof-read that better 20:14:59 #topic Farewell to Mithrandir and OdyX 20:14:59 marga: no problem really. It happens. I just wanted it said somewhere ;and here+now felt better than any kind of email. 20:15:25 Oh, Is the farewell song happening? Do we get flowers, or chocolate ? 20:15:30 :) 20:15:45 Just a thanks for all the years and the time you've spent on the ctte 20:15:56 Do you want to make a good bye speech? 20:16:05 it's been a pleasure, everyone. Quite a journey, and I think the TC is in good hands going forward. 20:16:12 This yes. 20:16:25 Good luck on the recruiting, it's hard work. 20:16:40 It's been quite a bumpy ride; being on the TC is hard, but important 20:17:12 I really enjoyed all the discussions we have had, with each and every of you. 20:17:29 10 sent -- is that enough for now, or should we annoy more people? 20:18:13 fil, I think we probably want a few more :) 20:18:28 OdyX and Mithrandir: thanks again for being great mentors to all of us 20:18:38 And now we can consider this meeting done. 20:18:42 #endmeeting