18:59:36 <marga> #startmeeting
18:59:36 <MeetBot> Meeting started Wed Nov 20 18:59:36 2019 UTC.  The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:36 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:42 <marga> #topic Roll Call
18:59:49 <marga> Is anybody out there?
18:59:59 * gwolf moos
19:00:46 * ntyni waves
19:01:06 <Mithrandir> Tollef Fog Heen
19:01:14 <OdyX> Didier Raboud, barely present
19:01:22 <fil> Philip Hands
19:01:29 <marga> Margarita Manterola
19:01:30 <ntyni> Niko Tyni
19:01:31 <gwolf> Gunnar Wolf, for ~40min
19:02:19 <ntyni> bremner said he'd be late
19:02:48 <marga> Alright, let's move on...
19:03:04 <marga> #topic Review of previous meetings AIs
19:03:19 <marga> I have failed at my task, which was sending an email to d-d-a
19:03:27 <marga> I should be able to do this before the end of this week.
19:04:27 <ntyni> I actually managed to email -devel about the module/interpreter dependencies thing
19:05:02 <ntyni> thread starts at https://lists.debian.org/debian-devel/2019/11/msg00212.html
19:05:56 <gwolf> this last couple of weeks I haven't been able to read d-devel at all ☹
19:06:21 <ntyni> I didn't claim I read it either :)
19:06:46 * marga reading the thread
19:07:25 <gwolf> I shall look at it later today. This thread, at least.
19:07:40 <marga> Ok, there isn't a lot there. Mostly people giving a few extra pointers of other languages
19:07:45 <ntyni> right
19:08:08 <Mithrandir> it seems to point in the direction of modules not pulling in interpreters from my reading of it, though
19:08:15 <ntyni> only got around to it a few days ago so not concluded yet
19:08:21 <ntyni> Mithrandir: agreed
19:08:23 <gwolf> Right. Mostly this issue is regarding a corner-ish case...
19:08:38 <gwolf> so people will probably say "don't bug me, but we do XXXXXXX"
19:10:24 <marga> Alright. Thanks Niko for taking care of this!
19:10:41 <marga> Let's move on to the bug discussion to figure out what to do next
19:10:50 <marga> #topic #934948 Dropping dependencies to avoid extra binary package when same source package targets more than one environment
19:11:36 <marga> The point of the thread that Niko started was to ask for input regarding the possibility of not having to depend on ruby and nodejs for the library thing
19:12:26 <marga> Terceiro, from the Ruby side, mentions that they mostly didn't drop the interpreter dependency in ruby "due to inertia"
19:13:08 <ntyni> indeed
19:13:25 <ntyni> I don't think anybody chimed in from the nodejs part
19:14:06 <gwolf> AIUI, the issue is much more important even for nodejs, as it can be used to serve the libraries that are run $elsewhere...
19:14:25 <gwolf> so having an interpreter is far from needed in order to properly use the libraries
19:14:59 <smcv> (sorry I'm late)
19:15:22 <marga> Hey there Simon!
19:15:46 <smcv> a little while ago I spoke to a ftp team member about the specific cases mentioned in #934948 and he said he would check with other team members whether the right decisions had been made in those cases
19:17:04 <marga> So, I think each interpreted language is slightly different.  As Gunnar mentions, javascript libraries can be used to run on the browser and thus the interpreter isn't at all needed in that case. Some interpreted languages ship the standard library together with the interpreter, some separate. The meaning of the standard library also differs from language to language... So, I don't think we can make a general statement about what this
19:17:05 <marga> dependencies should be.
19:17:54 <smcv> something that did come up in my conversation with the ftp team member I am deliberately not naming is the design principle of:
19:18:16 <smcv> if it's a library for use by JS/Ruby/Python/etc., package it like a libary
19:18:50 <smcv> if it's an executable to be run by scripts, interactively etc. without needing to know or care about its implementation language, package it like an executable
19:18:58 <smcv> and this might imply a split
19:19:22 <marga> But aren't both packages involved libraries? (one nodejs and one ruby)
19:20:03 <smcv> I mentioned src:tap.py, which is one of my own packages, and he thought it's correct that tappy.deb (executable) and python3-tap.deb (library) are separate for that reason
19:20:18 <smcv> in the case of #934948 it's less clear-cut
19:20:59 <smcv> one of the packages happens to contain an executable, but it wasn't clear to us what that executable is for, and whether it's a general-purpose utility, or an equivalent of sdl2-config (which is correctly in the -dev package), or what
19:22:33 <gwolf> right, many libraries include executables that are example or testing items, and should not be forced to DEPEND on the interpreter
19:24:29 <smcv> again, I think part of the problem with #934948 is that it still isn't clear to me what Pirate wants from us
19:24:50 <marga> Advice?
19:25:55 <smcv> advice on whether to open a GR proposing overruling the ftp team?
19:26:19 <gwolf> He is asking our opinion to use it as a means for the ftp-masters to change their decision
19:26:31 <fil> the impression he gives to me is that he wants a very clear legalistic ruling in which to start hunting for loopholes, but I suspect that is at least partly due to the way I'm reading what he writes
19:26:56 <marga> Yeah, on second read I think he wants support for his case
19:26:59 <gwolf> (i.e. we can decide this without overruling a delegate - we cannot make ftp-masters obey our reasoning)
19:27:13 <gwolf> but I think we _do_ support his viewpoint... right? :-}
19:27:50 <smcv> in my case: "yes ish, but with caveats"
19:28:05 <marga> Well, my position is that there was a lot of miscommunication and that the involved people should actually talk respectfully to each other
19:28:17 <marga> I'm pretty sure that if that were to happen, the problem would be resolved
19:28:24 <marga> But we can't force that to happen from the TC
19:28:47 <gwolf> marga: Completely agree with you. But he is asking for our opinion
19:29:18 <gwolf> clearly Praveen was angry when he wrote the bug report... but forcing this through a GR would be ... the worst possible outcome :-\
19:29:35 <marga> Well, that's my opinion.  And yes, I agree that going through a GR is not the right avenue.
19:30:26 <marga> To me, it does seem to me that the package could *recommend* both ruby and nodejs instead of depending on them... Given that there doesn't seem to be official guidance for ruby modules, and the ruby team even considered dropping the deps as the default and didn't do it because of inertia. But then there's the question about the ruby libraries that the package does depend on, which should also move to recommending the interpreter.
19:30:58 <gwolf> FWIW we could read it like "he is threatening us with a GR"... I'd rather not, I'd rather see we answer to him politely, but reminding the limits of action for a TC answer
19:32:08 <ntyni> looks like there's at least one recursive dependency to a binary Ruby module which needs a Depends: libruby2.5 which probably takes away much of the point of changing the others to recommendations
19:32:33 <smcv> I think the wider context might be that if libraries are very small, it might make sense to combine multiple related libraries into a larger package, at which point splitting that package by language might be more acceptable because the split parts will be less tiny and less numerous?
19:32:59 <marga> Sure, but this is all in a package by package basis
19:33:10 <marga> I don't think there's a general ruling that we can offer here
19:33:23 <smcv> I can poke the ftp team member I spoke to and see whether they have discussed this specific case if that would help?
19:33:24 <fil> BTW just out of interest, did we ever find out if there was a use case where being forced to needlessly install a couple of interpreters actually manages to upset or inconvenience anyone?
19:33:28 <gwolf> smcv: Oh, the nodejs-inflicted pain? :-P
19:33:49 <ntyni> fil: I was wondering the same
19:34:03 <gwolf> fil: Well, if you were to prepare an embedded image where space was at a premium...
19:34:12 <gwolf> but I don't think that has been brought up...
19:34:36 <smcv> ... then some carefully-deployed rm -f is potentially your friend? </devils-advocate>
19:35:16 <fil> gwolf: and you might just add the the expulsion of the interpreters to the special-casing you're doing anyway, if you're very short of space
19:35:57 <marga> Yeah...
19:36:27 <Mithrandir> ditto; I can see it being the case in some specialised use cases, but nearly everywhere, space is cheap nowadays.
19:36:42 <ntyni> Need to get 15.5 MB of archives.
19:36:42 <ntyni> After this operation, 62.0 MB of additional disk space will be used.
19:36:46 <ntyni> that's for the ruby parts
19:37:23 <marga> yeah, it's not _nothing_ but only very specialized cases would care.
19:37:46 <marga> So... How do we move on?
19:37:55 <fil> and is there any chance of someone wanting _these_ packages on a minimal embedded system?
19:38:23 <gwolf> fil: There's always Someone Very Special™ ready to break your assumptions :-Þ
19:38:33 <marga> We can tell Pirate to: A) let it go B) Move the ruby dependencies to recommends and then let it go C) try to actually talk with the ftp-masters and see if they can come to an agreement...
19:39:10 <fil> I'm not saying that allowing minimal installs is unimportant, but if the usecase is largely fictional, then this seems like a lot of effort for little real benefit
19:39:11 <gwolf> marga: Given this is a formal question for us, I think we need to explicitly reply
19:39:35 <gwolf> sorry if I'm no understanding your point - it seems _privately_ approaching and that?
19:39:45 <marga> no, no, I meant reply to the bug
19:40:07 <marga> And we can actually include all 3 options.
19:40:10 <gwolf> I think we should issue our opinion, mostly B.
19:40:28 <gwolf> That would mean, "we agree with the submitter, but it's up to ftp-masters to actually decide"
19:40:48 <fil> seems fair
19:43:00 <marga> I think I'd still include something along the lines of "The Technical Committee still encourages you to try to talk to the ftp-master team and come to an agreement regarding this specific package"... Although I'm not too happy about that wording
19:43:09 <gwolf> Sorry, now I'm leaving you... I have to run.
19:44:09 <ntyni> marga: I agree it would be nice to include something like that
19:45:18 <marga> Ok, we are 45 minutes into this meeting, we should try to decide on something and move on...
19:45:37 <marga> smcv, as you are the one that's been following this the closest... What do you think should be the right move?
19:45:38 <smcv> would people be in favour of putting TC authority behind a preamble that says "there are a bunch of design principles, they partially contradict, it's a trade-off"?
19:46:04 <smcv> so something like
19:47:18 <smcv> 1. (approximately the design principles I gave in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#12), but these are sometimes in conflict, and when they are, it's up to the maintainer and ftp team to find the least bad trade-off
19:49:51 <smcv> 2. we encourage maintainers and the ftp team to communicate respectfully, and in particular acknowledge valid points even if they are outweighed by a higher-priority consideration
19:50:03 <smcv> (needs better wording but hopefully you get the idea)
19:50:16 <marga> Yeah, this goes along what I was saying
19:50:54 <ntyni> sure
19:50:55 <smcv> 3. in the specific case of src:ruby-task-list providing both a Ruby library and a Javascript library, we think ((A) or (B) or something else)
19:50:56 <fil> sounds good to me
19:51:03 <Mithrandir> sgtm too
19:51:31 <smcv> I can try to write a better version of (1) and (2)
19:51:39 <marga> Yeah, sgtm
19:51:50 <marga> And you could ask here for people to chime in regarding the wording
19:51:51 <smcv> I'm not sure what I think the best answer is for (3)
19:51:58 <marga> (through a pad or wahtever)
19:53:27 <smcv> ok, action me to write a draft of (1) and (2) at least
19:54:38 <marga> #action smcv to draft a reply noting that there can be a tradeoff that's up to the maintainer, that maintainers should try to respectfully communicate with ftp-master to solve conflicts, and some specific advice for this issue
19:54:44 <smcv> maybe (3) should itself be "here are some options to consider, and if the maintainer and the ftp team *really* *really* can't agree, the TC would suggest foo"
19:54:55 <marga> Sure
19:55:34 <marga> So, quickly, let's jump into the bug that got unarchived
19:55:37 <marga> #topic #932795 How to handle FTBFS bugs in release architectures
19:55:52 <marga> We had closed this bug and it was archived, but Santiago replied and it got unarchived
19:56:24 <marga> I'm not sure there's anything to be done, but I wanted to raise it in case anybody had opinions
19:56:44 <smcv> s/Santiago replied and it got unarchived/Santiago unarchived it to reply/ FWIW
19:57:45 <marga> Ah, ok, yes
19:57:49 <marga> I wasn't sure how this worked
19:58:01 <fil> I note that he mentions that there are about 50 bugs each way (fail on 1, but not 2 CPUs, or vice versa)
19:58:08 <marga> Right
19:58:37 <marga> Which I think both fall into the category of "should be fixed but not keep things out of testing"
19:59:14 <smcv> so, important?
19:59:34 <marga> Yeah, FMPOV
19:59:38 <ntyni> ye
19:59:39 <ntyni> +s
19:59:55 <Mithrandir> I don't think we should recommend any particular severity, tbh.
20:00:12 <ntyni> not sure I see much point in continuing the discussion though
20:00:34 <Mithrandir> (I agree with recommending !RC, but I think we should leave it to the maintainer/RT to decide.)
20:00:35 <fil> He's arguing that they shouldn't be simply be downgraded to non RC, and should rather require someone to actually make a case for an e.g. buster-ignore tag
20:00:45 <Mithrandir> ntyni: agreed.
20:01:01 <smcv> given the amount of disagreeing with santiago I've done on that bug, if it is felt to be important to respond, I would very much appreciate not being the one to do so again
20:01:13 <smcv> I've said everything that I think needs saying
20:01:31 <ntyni> smcv: thanks for that
20:01:54 <ntyni> (for your past participation on the bug, that is)
20:02:13 <Mithrandir> fil: the description of serious talks about "in the maintainer's or release manager's opinion", so I think it's ok for a maintainer to downgrade; the submitter can appeal to the RT if they want.
20:02:31 <Mithrandir> but yeah, I think we should re-close the bug with no action.
20:02:36 <marga> Ok, so, does anybody think we should reply?
20:02:48 <marga> The bug is still closed, and it will get auto-archived in a month... I think.
20:02:51 <ntyni> it's closed already, will be rearchived in time
20:03:09 <fil> sure -- I was just summarising -- I'm not particularly persuaded by his argument
20:03:25 <Mithrandir> ah, ok.  I guess somebody can reply with a "thank you for providing the numbers".
20:03:53 <marga> Ok, I can do that.
20:04:07 <marga> #action Marga to reply thanking Santiago for providing the numbers
20:04:32 <marga> And we're over time... So, I'll just end here, unless someone has something extremely urgent?
20:05:27 <Mithrandir> nothing from me
20:05:28 <smcv> one last link-drop:
20:05:29 <smcv> https://lists.debian.org/debian-release/2019/09/msg00475.html
20:05:37 <smcv> is relevant to the single-CPU-FTBFS thing
20:06:14 <smcv> in particular "we consider
20:06:17 <smcv> ourselves the right party for case-by-case judgment of FTBFS bugs"
20:06:21 <smcv> (we = release team there)
20:06:22 <smcv> and
20:06:29 <smcv> "we don't consider
20:06:30 <smcv> FTBFS on single CPU machines RC by default"
20:06:53 <marga> Cool, thanks!
20:07:06 <marga> #endmeeting