18:59:20 <marga> #startmeeting
18:59:20 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:26 <marga> #topic Roll Call
18:59:34 <marga> Hello, is there anybody out there?
19:00:51 <Mithrandir> Tollef Fog Heen
19:01:16 <marga> Margarita Manterola
19:01:32 <smcv> Simon McVittie
19:02:52 <Mithrandir> Seems like we’re the only ones?
19:03:00 <marga> I guess... :(
19:03:12 <marga> #topic Review of previous meeting AIs
19:04:06 <smcv> smcv to draft a reply to #934948: yes I finally got round to this
19:04:10 <gwolf> o/
19:04:12 <gwolf> Gunnar Wolf
19:04:17 <marga> 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 <gwolf> Somewhat-here :)
19:05:46 <marga> Alright, let's move into the open bug that Simon has drafted a reply for
19:06:04 <marga> #topic #934948 Dropping dependencies to avoid extra binary package when same source package targets more than one environment
19:06:50 <smcv> do we have a preferred platform for editing this sort of thing?
19:07:04 <Mithrandir> for cooperative editing?  Titanpad?
19:07:29 <Mithrandir> https://etherpad.wikimedia.org/ is the one I tend to use
19:09:02 <marga> 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 <marga> The open question is what we suggest
19:09:18 <smcv> anyone know how to paste into a titanpad without mashing all the lines together? :-(
19:09:22 <smcv> *etherpad
19:09:33 <marga> And I don't know what the answer is. Re-attempt to have a dialogue about this?
19:10:59 <smcv> https://etherpad.wikimedia.org/p/RVW5h33RhT28pIY6W_ds
19:11:46 <smcv> 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 <gwolf> I like very much Simon's draft. I will just correct a bit I found (using "I" instead of "we")
19:13:14 <gwolf> (of course, we still need the finalising touch :-] )
19:15:06 <Mithrandir> there's no need for it to depend on any interpreter, since neither of those languages do postinst compiling
19:15:21 <Mithrandir> so I think we should suggest that any interpreter dependencies are dropped.
19:15:24 <Mithrandir> is that reasonable?
19:15:55 <marga> Yeah, I think that's reasonable
19:15:56 <smcv> I think the dependency on other ruby libraries was the issue?
19:16:02 <smcv> which we can't wish away like that
19:16:05 <marga> The problem was that the ruby libraries bring the interpreter anyway
19:16:18 <Mithrandir> then those are buggy, given the prior principles in that mail.
19:16:38 <Mithrandir> probably minor-to-normal buggy, not important (and surely not RC)
19:17:01 <gwolf> right. I guess this will mark as buggy many many many many libraries :-P
19:17:06 <marga> The guidelines say that it's ok not to depend, not that it's a bug to depend?
19:17:35 <Mithrandir> unneccessary dependencies are bugs, are they not?
19:17:36 <gwolf> marga: Yes, but that means a package can be forced to transitively depend when it's not really needed
19:17:59 <smcv> sorry, this is a design principle that should have been in my list but was not
19:18:14 <Mithrandir> smcv: dependency minimisation?
19:18:43 <smcv> "a package that depends on a library libfoo, where libfoo depends on libbar, should not be required to know about libbar"
19:18:47 <smcv> or something like that
19:19:12 <marga> Uhm, yeah, that's just normal dependency handling
19:19:32 <gwolf> I have to leave, sorry
19:19:42 <gwolf> I didn't have this meeting on my head :-(
19:19:48 <gwolf> o/ !
19:20:10 <smcv> I was about to ask gwolf what he meant about transitive dependencies, if not that, but ...
19:20:23 <marga> 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 <Mithrandir> I think that makes sense.
19:21:03 <smcv> 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 <smcv> (where ruby-task-list depends on those + the ruby interpreter)
19:21:56 <marga> Yes
19:22:01 <Mithrandir> 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 <smcv> 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 <Mithrandir> right now, it looks a bit like "you don't have to, but if you want to, feel free"
19:23:08 <smcv> Mithrandir: I have no objection to you making that stronger
19:23:23 <smcv> relevant thread at https://lists.debian.org/debian-devel/2019/11/msg00212.html
19:23:54 <Mithrandir> 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 <smcv> I think the consensus on that thread is compatible with what Mithrandir said just now
19:25:34 <marga> agreed
19:25:35 <smcv> don't depend, unless there's a reason why you need to[1]
19:25:47 <smcv> [1] for many languages, you need to, because of reasons
19:26:00 <fil> Hi -- sorry for being late (kids took some extra getting to bed today :-/ )
19:27:11 <Mithrandir> smcv: something like that?  Feel free to wordsmith, of course.
19:27:51 <smcv> 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 <smcv> which kinda sidesteps the issue by making each language's part big enough to be worth splitting
19:28:35 <Mithrandir> that's very unjavascripty.
19:28:36 <smcv> and oh look! the only rdep of ruby-task-list in Debian is ... gitlab
19:29:43 <marga> not sure what the point is there :)
19:30:23 <smcv> 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 <marga> I meant on the gitlab side
19:30:43 <smcv> but if we had ruby-assorted-gitlab-dependencies and libjs-assorted-gitlab-dependencies, not so much
19:31:09 <marga> 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 <smcv> reattempt dialogue isn't really a solution, it's a path to a solution
19:31:39 <marga> ah, ok, but "assorted-gitlab-dependencies" isn't really a nice package to use. Who knows what's in it...
19:32:18 <smcv> yeah, I know
19:32:21 <Mithrandir> we used to have a package like that.  It was called ia32-libs.  It made nobodoy happy.
19:32:30 <Mithrandir> except with different typos.
19:32:32 <smcv> insert usual reason to avoid omnibus packages here
19:32:49 <smcv> but I think they might sometimes be the lesser evil
19:33:48 <Mithrandir> would you prefer that over adjusting the transitive set of dependencies of the ruby toolchain to be aligned properly?
19:33:54 <OdyX> GAAH. Meeting started
19:34:01 <OdyX> sorry I'm so late.
19:35:00 <marga> 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 <smcv> 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 <smcv> 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 <fil> 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 <Mithrandir> in practice, I don't think this matters at all.  Disk is really cheap.
19:37:32 <smcv> 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 <Mithrandir> so I'm aiming for the shortest path to a reasonable solution.
19:38:11 <smcv> they have little incentive to explain/justify their reasoning because nothing short of a GR can overrule them
19:38:46 <smcv> while the maintainer has an incentive to explain/justify why the split is required, but hasn't answered my questions
19:38:50 <OdyX> And small packages in general are too easily annoying
19:38:53 <Mithrandir> it'd lead to less hot air that contributes to global warming?
19:38:55 <Mithrandir> (sorry)
19:39:04 <OdyX> :->
19:40:26 <marga> Alright, any other suggestions of what our suggestion at the end should be?
19:41:08 <smcv> 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 <OdyX> 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 <smcv> 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 <OdyX> smcv: well… Yes.
19:43:20 <OdyX> smcv: but isn't this the logical followup to the argument laid before?
19:43:38 <marga> Not really, we said we didn't want to blow up the Packages list
19:44:23 <OdyX> 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 <OdyX> Saying "it's hard, you have to resort to compromise between equally good/bad options" is not very useful.
19:45:29 <Mithrandir> apart from "it's work to adjust dependencies", what are the downsides of doing that?
19:45:47 <smcv> Mithrandir: the downsides of doing what?
19:45:53 <marga> I guess the package name would still be incorrect for the javascript part of it
19:46:13 <smcv> single binary package with weakened dependencies?
19:46:20 <Mithrandir> yes
19:46:43 <smcv> that is already sort of de facto the solution because the ftp team rejected the other one (the split packages)
19:47:07 <smcv> I think where we are at the moment might be:
19:47:10 <smcv> we are still confused
19:47:22 <smcv> the maintainer hasn't answered the questions I asked
19:47:33 <marga> what were your unanswered questions?
19:47:49 <smcv> we aren't going to make a recommendation that contradicts the ftp team decision without knowing why
19:48:16 <smcv> 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 <fil> sure -- we shouldn't reward them for not bothering to reply
19:49:01 <marga> 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 <smcv> marga: for example https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#32
19:50:19 <smcv> 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 <marga> He thought they were the same thing, then realized they weren't really the same
19:53:21 <smcv> does everyone agree with this as an addition to the list of design principles?
19:53:24 <smcv> * 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 <marga> Sounds too complicated
19:54:01 <marga> And really, I don't think it adds any extra information, that's just how dependencies work
19:54:15 <Mithrandir> yes and no, it depends on whether libfoo exposes the data types of libbar through its interfaces or not.
19:54:33 <Mithrandir> since in that case, there are lots of worms.
19:54:34 <smcv> 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 <smcv> if that was obviously unacceptable then nobody would have suggested it as a possibility
19:55:07 <fil> 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 <smcv> 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 <marga> I think the problem is that it requires all involved packages to weaken the dependency.
19:55:55 <smcv> or, yeah, that
19:56:24 <smcv> 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 <smcv> 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 <Mithrandir> 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 <fil> 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 <smcv> that breaks down with ruby libraries that are written in C and link libruby, though
19:59:16 <marga> 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 <smcv> 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 <smcv> (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 <Mithrandir> sure, and I think that's fine.
20:00:50 <Mithrandir> I think we're talking about a tiny set of people.  Possibly just containing {i}
20:01:31 <fil> quite
20:01:38 <smcv> counterexample: Ian Jackson in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#22
20:02:01 <marga> 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 <smcv> 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 <marga> I meant the interpreter dep, not the other, sorry
20:03:51 <smcv> and that instead ruby-rack should weaken or remove *its* dependency on the interpreter
20:03:54 <Mithrandir> 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 <marga> 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 <smcv> 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 <OdyX> +1
20:05:47 <fil> yup
20:06:06 <smcv> 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 <Mithrandir> seems reasonable
20:06:57 <Mithrandir> "big", isn't it?
20:07:00 <marga> Yeah
20:07:22 <smcv> sorry, I mean bigger than the current ruby-task-list
20:07:41 <smcv> not big on a scale from 0 to Libreoffice
20:07:51 <fil> :-)
20:08:33 <smcv> or texlive or whatever is everyone's favourite giant package at the moment
20:08:38 <marga> I think the current ruby-task-list already includes the js bits, no?
20:08:55 <fil> that's the impression I had
20:09:30 <smcv> there's a .coffee file, I'm honestly not sure what that is
20:09:45 <marga> heh, ok.
20:09:56 <marga> Can we close this? I think we have consensus
20:10:27 <fil> yes please :-)
20:10:47 <smcv> 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 <smcv> so, what I said above
20:11:09 <marga> Ok.
20:11:25 <smcv> ok, shall I take an action to polish the text in the etherpad?
20:11:40 <smcv> do we have a review process?
20:11:59 <smcv> mail to -private + someone else ack before sending to the bug?
20:12:04 <marga> smcv, I think we have reviewed it already. This is not a ruling, so I'm comfortable with the current state.
20:12:13 <smcv> fine by me
20:12:28 <marga> #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 <OdyX> Go ahead yes :)
20:12:42 <smcv> I'll try to get that done this evening
20:12:47 <marga> Thanks!
20:12:52 <marga> #topic Recruiting
20:12:53 * fil trusts smcv absolutely to do a marvellous job :-)
20:13:18 <marga> I sent the email to d-d-a
20:13:19 <OdyX> Oh. Only 14 days left for us.
20:13:26 <marga> fil, can you do a round of your random thingie?
20:13:30 <OdyX> Thanks for the recruiting mail marga.
20:13:33 <fil> sure...
20:13:46 <marga> Thanks
20:13:58 <OdyX> (I smirked at the typos in my lastname, handle and IRC nick; no offense taken though :-) )
20:14:04 <marga> And I guess we'll actually do all the recruiting process in January, once we have nominations?
20:14:11 <marga> ugh, I'm sorry
20:14:17 * marga shame cubes
20:14:24 <Mithrandir> OdyX: and then we're freeeeeee!
20:14:25 <marga> I should have proof-read that better
20:14:59 <marga> #topic Farewell to Mithrandir and OdyX
20:14:59 <OdyX> 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 <OdyX> Oh, Is the farewell song happening? Do we get flowers, or chocolate ?
20:15:30 <marga> :)
20:15:45 <marga> Just a thanks for all the years and the time you've spent on the ctte
20:15:56 <marga> Do you want to make a good bye speech?
20:16:05 <Mithrandir> it's been a pleasure, everyone.  Quite a journey, and I think the TC is in good hands going forward.
20:16:12 <OdyX> This yes.
20:16:25 <Mithrandir> Good luck on the recruiting, it's hard work.
20:16:40 <OdyX> It's been quite a bumpy ride; being on the TC is hard, but important
20:17:12 <OdyX> I really enjoyed all the discussions we have had, with each and every of you.
20:17:29 <fil> 10 sent -- is that enough for now, or should we annoy more people?
20:18:13 <marga> fil, I think we probably want a few more :)
20:18:28 <marga> OdyX and Mithrandir: thanks again for being great mentors to all of us
20:18:38 <marga> And now we can consider this meeting done.
20:18:42 <marga> #endmeeting