15:00:41 #startmeeting FESCO (2019-04-01) 15:00:41 Meeting started Mon Apr 1 15:00:41 2019 UTC. 15:00:41 This meeting is logged and archived in a public location. 15:00:41 The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:41 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:41 The meeting name has been set to 'fesco_(2019-04-01)' 15:00:41 #meetingname fesco 15:00:41 The meeting name has been set to 'fesco' 15:00:42 #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:00:42 #topic init process 15:00:42 Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek 15:00:46 .hello2 15:00:47 .hello2 15:00:47 sgallagh: sgallagh 'Stephen Gallagher' 15:00:50 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:00:51 .hello2 15:00:56 .hello2 15:00:56 otaylor: otaylor 'Owen Taylor' 15:00:59 jforbes: jforbes 'Justin M. Forbes' 15:01:05 .hello psabata 15:01:06 contyk: psabata 'Petr Šabata' 15:01:10 morning 15:02:02 OK, that's quorum at least. 15:02:12 We have zero open tickets on the agenda this week. 15:02:34 Based on an informal poll in #fedora-devel, we opted to open the meeting for Open Floor topics. 15:02:39 But first: 15:02:45 #topic Next week's chair 15:02:54 #action sgallagh to chair next week's FESCo meeting 15:03:02 I'll chair again next week 15:03:09 #topic Open Floor 15:03:11 Hey 15:03:13 thanks sgallagh 15:03:38 I guess I'm late, sorry about that 15:03:48 mhroncok_cell: We have no agenda, so it's hard to be late for that :) 15:04:01 mhroncok_cell: you're one week early 15:04:09 zbyszek++ 15:04:19 Also, I thought it's 1500 utc 15:04:25 it is. 15:04:26 mhroncok_cell: The meeting just started. 15:04:33 You aren't actually late. 15:04:41 Oh. It looked like it just ended, good 15:04:46 We just have no agenda, so we jumped straight to Open Floor 15:05:32 :)) 15:05:34 All of the tickets are awaiting updates except for the Blocking Media ticket which was resolved 15:06:04 #info We have no active tickets this week, so we jumped directly to Open Floor 15:06:20 Does anyone have anything they'd like to discuss? 15:06:42 contyk: Do you want to talk at all about the Ursa Major alternative or should that bake a few more days? 15:07:15 is there anything new to discuss? 15:07:38 contyk: Well, you have that draft document that's been shared to a limited audience 15:07:43 Do you want to share it out more broadly? 15:08:28 I shared it publicly in the ticket :) 15:08:39 I don't know what else to add there 15:08:52 the proposal is about having a separate small compose with the default streams 15:09:13 koji would be constructing the non-modular buildroot from the tagged package set + this external repo 15:09:33 this compose would also be made public so that third parties, including mock, could just reference it 15:09:59 That seem to be a good solution to the problem 15:10:00 there's still one unknown when it comes to handling default streams in MBS 15:10:18 the rest will need changes in createrepo/mergerepo that sgallagh is working on 15:10:23 Yet I'm still not sure we should encourage nonmodular content to depend on modules 15:10:40 so that koji can merge the buildroot repos, preserving the modular metadata which the dnf in the buildroot will use 15:10:56 what are your concerns? 15:11:28 mhroncok_cell: I don't think that is avoidable. 15:11:46 As Java, meson and several other build-tools have already converted to modules 15:12:00 (And I plan to move Node.js that direction once this is in place) 15:12:30 sgallagh: How woudl this work for something that is *runtime* like node.js ? 15:13:13 sgallagh: do we think that nonmodular content runtime-depending on modules is OK? 15:13:24 I have my concerns drafted, will try to approach fesco by the end of week 15:13:33 otaylor: That's the entire purpose of a default stream, so yes 15:13:37 I don't think it's ok 15:13:55 OK, that's overstating. 15:14:03 It's *a* primary purpose of default streams 15:14:09 Yet I don't know whether we are past a point where it is too late to reconsider 15:14:11 sgallagh: I thought the point of a default stream is to not make Fedora look smaller - to keep packages in the default available set sa they are moved to modules 15:14:51 yeah, I believe the point of defaults was to maintain the user experience, so that people don't have to care whether they install from a module or not 15:15:01 otaylor: "default available set" implies heavily that it's usable by other pacakges. 15:15:02 only having to care if they want alternative content 15:15:21 but making those packages available as runtime deps to non-modular content is related 15:15:29 sgallagh: but the idea that non-modular packages could depend on modular packages at runtime -that hurts my head a bit, and seems like we could get in a situation where we're effectively pinning a set of streams 15:15:51 Yet it was IMHO side effect, not a purpose or the purpose 15:16:02 there has to be some limits - we can't have glibc effectively through transitive dependencies depending on nodejs:10 15:16:13 Exactly 15:16:19 otaylor: I'm not sure how that would happen 15:18:19 sgallagh: that's probably an extreme example - but say I tried to make mozjs a module with mozjs:60, etc, streams, and had gnome-shell depend on mozjs:60 - that would be somewhat less useful 15:18:55 sgallagh: any usage of non-default streams of mozjs could *only* happen in a container that didn't depend on gnome-shell. 15:19:13 hmm 15:19:33 and that could be fine 15:19:45 in such a world it's impossible to make all possible combinations work 15:19:48 We're already kind of in this situation with Java though. Do we require that all packages that require Java to build or run must be in modules? 15:19:59 if you use alternative streams, you can break some things; but you should know about that 15:20:37 sgallagh: the java packages are still there 15:20:47 * nirik worries we might not notice these... perhaps just good reporting might help out. 15:20:52 you don't have to care about modules to depnd on them 15:20:55 mhroncok: In the sense that we had to create an emergency SIG to deal with it... 15:21:00 yes 15:21:11 an emergency created by this idea 15:21:33 modularizing stuff that is essential for other parts of the distro 15:21:51 contyk: maybe that one is fine ... we are trying to move apps to containers, after all, and gnome-shell will never be in a container. But I feel we have some limits or understanding on what is OK 15:22:00 I have concerns that this was never the stated plan 15:22:34 I have concerns that anybody modularizes anything based on whatever they think is better for them 15:22:48 without considering other package maintainers 15:23:01 mhroncok: I agree. That shouldn't be happening and we need stronger guidelines. 15:23:12 we are inventing technical solution to a people problem 15:23:29 sgallagh: exactly 15:23:44 and we should consider not doing this at all, not allowing this 15:23:55 only have modules as goodies, addons, extras 15:23:57 thats hard in a volenteer world 15:24:06 or modules that are an alternative to nonmodular content 15:24:10 mhroncok: That ship has effectively sailed with the RHEL 8 Beta, for the record. 15:24:17 I don't see this is an issue, to be honest 15:24:18 rhel 8 beta is not fedora 15:24:30 once we have the mechanisms for the buildroot in place 15:24:33 mhroncok: No, but any divergence we make means twice the maintenance 15:24:44 sgallagh: maybe for a red hatter 15:24:45 the modular repo is part of the distro, it's not optional 15:24:58 sgallagh: but what we do now means X-times the maintaince for everybody else 15:25:01 whether a package is in a module or not should be irrelevant, to developers and to users 15:25:06 Far better if we maintain the same code where we are effectively guaranteed that our sponsor will be funding that maintenance 15:25:28 then whether you use an alternative stream, as a user, not everything in your system might work but you should understand that 15:25:30 and that's all 15:25:46 Not even if you use an alt stream 15:26:15 Just as now (with RPM-level conflicts), it's understood that installing some packages may mean you can no longer install certain other ones. 15:26:24 * nirik wonders what the error message(s) are there. 15:26:31 nirik: Where? 15:27:04 you have foo installed that depends on module bar (default stream), you try and install baz that depends on module bar2 (alt module stream) 15:27:37 Core dumped 15:27:44 baz needs to be in a module to do that 15:27:58 I guess we are saying that shouldn't happen now because... yeah, it would have to be modular 15:28:06 mhroncok: You're probably hitting the zchunk issue. Unrelated 15:28:39 sgallagh: that was an attempted joke, sorry about that 15:28:57 contyk, nirik: That *is* still possible, actually 15:29:28 if it is thats fine, as long as the error(s) are good... ie, it tells you whats happening so you can decide what you want to do 15:29:32 baz could depend on mbar (default stream) which in turn depends on bar2 (alt module stream) 15:30:04 yeah, but that's modular content depending on modular content 15:30:06 At which point you'd get a conflict from DNF and be told no 15:30:15 anyhow, I'm ok with the buildroot plan, not sure we are going to solve all the corner cases today. 15:30:26 Sure, I just wanted to mention that it's possible to hit the scenario nirik mentioned 15:30:35 it's indeed all about error reporting; you can get in all kinds of situations, with or without modules 15:30:37 Just ursine->module->module rather than ursine->module 15:31:30 contyk: its not just about error reporting, it's about making sure there's a clear path forward ... that people can do what they need to do 15:33:40 contyk: if a developer ships a module that depends on a non-default stream, there has to be some way of running it that doesn't involve directly installing it on your system - in a container / Flatpak. 15:34:27 contyk: (and we have to make sure that core packages that that container / Flatpak would depend on don't have module dependencies on default streams that would cause problems) 15:34:51 contyk: and we have to make sure that the user can find that alternate way of running it, and it seems natural and convenient 15:36:01 with default modules, in fact, we've basically reinvented Fedora Rings :-) 15:36:30 except stuff from the inner ring depends on the outer ring 15:37:33 and the outer ring depends on stuff we don't ship 15:37:33 mhroncok: I'm saying that we actually need to keep stuff from the inner(most) ring from depending on the outer ring - we need implicit structure to the distro 15:38:45 yes, we do 15:40:19 anyway, I have a ticket drafted from friday, but I haven't got time to propose it yet 15:40:32 it touches those topics 15:42:20 OK, we've been on this topic a while and aren't really getting anywhere. Punt until mhroncok provides his counter-proposal? 15:43:07 punt 15:43:43 (I'm +1 to the proposal technically, iff this is what we actually want to do.) 15:43:55 +1 punt 15:45:10 contyk: do you you feel that moving forward with a solution is being pushed off? I think there are interesting questions to be discussed, but the basic outline is fine as a technical solution 15:45:16 * nirik is +1 to the buildroot proposal. We may need more discussion/guidelines/work after that, but it's a needed and good step 15:46:08 Yeah, I feel like we should solve the buildroot situation and then limit the situations where it is allowable 15:46:21 I think we all agree with the proposal on a technical level 15:46:29 pretty much, yes 15:46:39 except I don't want to allow this at all 15:46:45 if FESCo alter decides that modules should not be part of the distro on this level, I think it pretty much kills the technology 15:46:48 problem is, we already have such situations 15:46:54 but that would be a group decision 15:47:37 * mhroncok would rather kill a technology than a community 15:47:50 so would I 15:47:58 but I actually see this as beneficial 15:48:47 well, the java stack maintainer sure thought it was better than maintaining the streams of non modular packages. 15:49:01 for him, it was 15:50:25 I think that is the problem, for him it was, for everyone with deps on those streams, it was not 15:50:37 seems to me it's only a burden on others because we don't have this solution in place? 15:50:49 possibly, yes 15:50:50 nirik: Yeah, I think that's the case. 15:51:05 Had they come to us at the time, we'd have asked them to wait until we had this solved. 15:51:24 the technical solution for this is band aid 15:52:05 it hopefully helps with this particular problem, yet it creates room for more problems 15:52:29 mhroncok: There will always be more problems. 15:52:38 sure 15:53:19 * otaylor doesn't feel he really *understands* the java modularity plan, what the design was, how it interacts with the rest of the distro, etc. 15:53:30 otaylor: I don't either. 15:53:41 contyk: Did they consult with you on it? 15:53:46 I think I understand the plane, but I don't want to be rude :( 15:53:50 I am not sure "pan" is the right word 15:53:53 plan 15:54:16 nope 15:54:17 well, the problem was there is/was 1 person doing everything... they couldn't keep doing that, so they moved to modules with all the stuff they maintained to reduce burden. 15:54:48 it would be perfectly fine be me to say: I cannot handle this any longer, hence I orphan it 15:54:49 but I think the goal is to have the common build deps for actual applications in this javapackages module 15:54:55 I guess they might have assumed we would solve the building against modules problems before things were retired. 15:55:07 yet the message was: fesco is blocking ura major, hence I orphan this and it's not my problem any more 15:55:16 and build it just once on the oldest distro and then consume it everywhere, because bytecode 15:55:22 contyk: yes, and not publish those, since they only intend to support them for building the applications they support 15:55:30 yes 15:55:39 nirik: I understand the story, but how exactly ... is this related to openjdk versions? what's the stream strategy? do all things in the distro need the same stream? how is the default stream going to be handled? 15:56:02 nirik: I underrstand the story that somehow modularity is reducing the maintenance burden, I mean 15:56:09 some of the packages there ar eno even in any moduel 15:56:24 are not even in a module 15:56:44 otaylor: I don't know specifics to that level... would need to ask them. 15:56:45 otaylor: The default stream is set for the life of a Fedora release. So once the buildroot solution is in place, it can be relied on to be the same within a release. 15:57:00 I wonder how a provenpackager doing a mass change in rawhide would solve this "one branch for everything" concept 15:58:05 as currently they just wouldn't 15:58:14 and that is indeed less burden for the maintainer 15:58:17 basically, the Java change needed a change proposal and a document, not just doing it. And I think we really need to ask for the document retroactively, at least so that we can try to figure out how we handle similar situations going forward 15:58:19 mhroncok: Could you rephrase? I don't understand what problem you're seeing 15:58:20 well, depends on the change... 15:58:37 it just moves the burden to everybody else 15:58:45 (maybe there is such a document somewhere) 15:59:14 sgallagh: so we decide we need to ditch ldconfig scriptles from the distro - and that we do it in rawhide - but we cannot do it in the modular branch 15:59:30 we could, it would just be more work... 15:59:34 because it possibly also builds for epel 5 and debian 15:59:58 nirik: exactly - the burden is moved, it is not gone 16:00:32 so for sure, moving my packages to modules may make sense to me - the others will need to care, I won't 16:00:36 well, the burden has always been on people making changes... 16:00:43 mhroncok: That particular problem is one that mboddu and I have been discussing. 16:00:52 There are ways we can know which branches are applicable. 16:01:01 ways and hacks 16:01:08 ie, you change someones rawhide spec and they change it back because they build also on epel5 and debian. ;) 16:01:22 nirik: and I can rant against them on devel 16:01:36 and everybody else agrees we cannot change that but they are doing wrong 16:01:55 yest with modularity, the answers is: meh 16:02:21 The answer is not "meh", the answer would be "Here's a guideline on how to conditionalize your spec correctly" 16:02:46 * otaylor seems to have derailed the plan to punt this discussion to next week ... 16:02:48 you should not need to conditionalize 16:02:58 also, using the Straw Man Fallacy as your primary argument is tiresome 16:04:11 sorry about that, it is not intentional 16:04:37 mhroncok: Yes, there are many ways to solve a problem. Scrapping years of work because of an edge-case that happens to affect you more than most seems like an overreaction to me 16:04:41 as said, the technical proposal is good - I just don't agree we should do this kind of stuff at all - we should limit it to very exceptional cases at least 16:05:40 so, we would solve the retirement of java packages by... forcing stewardship-sig to maintain them forever? 16:05:51 sgallagh: this didn't affect just me - I have an impression that the people we are suppose to represent here are genuinely afraid and confused 16:06:02 mhroncok: I dont' think we have a lot of time leeway here, so if you want to make a concrete proposal as alternative to just moving forward we should definitely vote on that next week 16:06:07 mhroncok: I didn't say exclusively. I said "you more than most" 16:06:13 yes, but because we don't have this in place... not because it's a bad idea 16:07:00 nirik: probably not by forcing the stewardship sig - e.g. again we cannot force anybody to do anything 16:07:10 And the Java situation is pretty much the worst-case-scenario. 16:07:23 (No points for jokes about how that's not unusual) 16:07:23 but we can stop people doing crazy stuff like deciding to modularize glibc 16:07:27 well, worse would be just retiring it all. 16:07:58 mhroncok: Yeah, I completely agree with you that there should be lines drawn somewhere. 16:08:22 sgallagh: ok and we might have different ideas about where the line should be 16:08:26 But we *know* from past experience that no firm lines are possible 16:08:39 We tried that with Modularity 1.0 and had to abandon it because it wasn't realistic. 16:08:49 Too many things are interrelated 16:09:21 my understanding of modularity 2.0 always was that such line would move further away from "the core" not that it goes away 16:09:25 Maybe the answer is "nothing ursine can *runtime* depend on a module stream". Maybe it's somewhere else. 16:09:50 and my concern is that I think we should (at least attempt to) draw that line 16:09:50 mhroncok: The disaster that is sphinx is a good metaphor for the problem. 16:09:55 before it's too late 16:10:04 I think the issue is that java is a canary. we have various other languages which are on a 'few' maintainers who are overburdened and looking for anything to cut down maintenance. 16:10:21 mhroncok: Half the distro depends on sphinx at build-time, indirectly 16:10:27 perl could have been just as easily gone all modular 16:10:44 And did, in RHEL 8. 16:10:59 and now for EPEL-8 I need to look at making all the rest modular 16:11:06 along with python and many other things. ;) 16:11:33 smooge: I'm still uncertain on the mechanism where modularity cuts maintenance for a language - it is it just stream expansion to cut (many packages) * (many branches) work? 16:11:55 otaylor: That's one example 16:12:02 otaylor, the idea is that I will work on stream0 and it will build for F29/F30/F31 16:12:07 that and ease to moving to new streams without committing... 16:12:15 otaylor: In the case of a lot of golang stuff, you only need to build it once and tag it to run on multiple releases 16:12:32 or rust 16:12:39 Right 16:13:15 Which shows there is another intersection with the idea of distribution structure - since core stuff *should not* just update across all streams of Fedora 16:13:27 so for a maintainer who has hundreds of packages (*spot*) it would make sense to put it all in a module and deal with it once 16:14:43 while we don't have hard-and-fast rules about backports, it would be pretty bad if there suddenly started to be a pile of Python updates in F28 because F28 was pulling a default stream of Python that is being updated 16:14:46 the issue is that stuff depends on a growing mass of more stuff 16:15:10 would a 'spots-grab-bag' module be allowed? I think we now require them to be a application/lang/something related? or do we? 16:15:31 AFAIk we don't require anything at all 16:15:36 otaylor: sure, but you can leave f28 on an old stream and make a new one for newer 16:16:10 nirik: I don't think we should allow that situation, no. 16:16:22 A module should be logically linked somehow. 16:16:33 huh, I don't actually see the java ones in rawhide... 16:16:40 e.g. it makes sense to link 389ds, kerberos, SSSD and dogtag together as FreeIPA 16:17:00 so spots grab-bag would be 'everything I need to make chromium' 16:17:21 Well, anything that fit into "deps and builddeps of chromium" makes sense. 16:17:26 smooge: but something needed to make chromium could end up being a dependency of a bunch of stuff in the distro 16:17:30 But I'm pretty sure that's a subset of spot's packages 16:17:38 yes it is. 16:18:00 so we can stick python2 in that module and retire it form rawhide? 16:18:03 but some of the things he has are build-deps of build-deps of build-deps of chromium 16:18:04 for example 16:18:14 otaylor: right, and best practice would be to try to keep the module contents limited to those things that are exclusively for chromium 16:18:19 But you're right, we need better documentation about this 16:18:38 smooge: if they are chromium specific , they can be in a chromium module, but they then probably *should not* be in the buildroot for non-modular packages 16:18:57 mhroncok: Short answer: no. Longer answer: we need to describe things better. 16:19:15 otaylor, sgallagh so let me use strawman-spot a bit further 16:19:49 for strawman-spot he only wants those packages so he can build chromium.. so to him they ARE chromium specific 16:19:49 poor spot 16:19:59 this is what happened in java 16:20:37 and could happen with other packages where a person has a specific end leaf and got all these other packages because no one else took them and they needed them 16:20:48 The answer there is that if someone wants to maintain them for additional purposes, they should “adopt” them from spot and take over their maintenance. 16:21:19 smooge: I think it's pretty clear that the Java peopel were aware that there were a lot of more packages in Fedora that used java as build dependencies, and they weren't trying to say that 'ant' or whatever was just for them 16:21:36 smooge: or that they wanted to give up maintenance of 'ant' 16:21:49 they just didn't want to maintain it, *as is* 16:22:45 I didn't see it that way but I will accept I am probably mis-seeing it 16:24:18 sgallagh, the issue is that if people should adopt such packages, we need to make it clear to packagers in both tools and policies what they should do 16:24:31 I do not disagree. 16:24:42 at the moment we have the horse about 40 feet behind the cart 16:24:47 I am also not prepared to decide what those policies are in the next five minutes 16:24:53 (And I have another meeting to get to then) 16:25:08 well, not sure we can force people to maintain things beyond the scope they want to... 16:25:34 is it better to orphan something or to 'maintain' it and ignore everything about it except what you need to build your other package? 16:25:41 If someone wants to take over as chair, feel free to keep running around this track. 16:26:09 * nirik isn't sure what thing we are trying to solve now anyhow. :) 16:26:22 nirik: Putting a package into a module and not listing it as "api" of that module is meant to be how you indicate the latter. 16:26:31 sorry for another run around the track. I will get off the track now 16:26:31 So that people understand it's not in the distro for general usage 16:27:10 now it is sure... but thats not been an option until very recently 16:27:19 If it's truly build-time-only, it should also be added to the "filter" list so it doesn't end up in the compose 16:27:43 Hooray for improving on that? 16:28:36 Anyway, I need to be going. Does someone want to take over or shall I close the meeting? 16:28:48 +1 to closing 16:30:07 +1 to close 16:30:17 and sgallagh volunteered to chair the next meeting because there was nothing to discuss today 16:30:23 +1 to close 16:30:51 +1 close 16:31:05 * sgallagh snickers 16:31:08 #endmeeting