15:00:23 #startmeeting FESCO (2019-11-11) 15:00:23 Meeting started Mon Nov 11 15:00:23 2019 UTC. 15:00:23 This meeting is logged and archived in a public location. 15:00:23 The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:23 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:23 The meeting name has been set to 'fesco_(2019-11-11)' 15:00:23 #meetingname fesco 15:00:23 #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor 15:00:23 #topic init process 15:00:24 The meeting name has been set to 'fesco' 15:00:24 Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek 15:00:44 .hello kevin 15:00:45 nirik: kevin 'Kevin Fenzi' 15:00:47 .hello2 15:00:48 otaylor: otaylor 'Owen Taylor' 15:00:50 .hello2 15:00:51 .hello2 15:00:54 bookwar: bookwar 'Aleksandra Fedorova' 15:00:57 sgallagh: sgallagh 'Stephen Gallagher' 15:01:01 .hello churchyard 15:01:01 mhroncok: churchyard 'Miro Hrončok' 15:01:04 .hello2 15:01:05 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 15:02:17 .hello2 15:02:18 zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' 15:02:31 Ugh, had to switch machines, my desktop just locked... 15:02:39 .hello2 15:02:40 danilocesar: danilocesar 'None' 15:02:48 That is rebooting. Looks like we have quorum though 15:03:48 was it fedora 31? :) 15:04:08 bookwar: indeed it was 15:04:11 jforbes: should report it to the kernel maintainers. ;) 15:04:13 #topic F32 System-Wide Change: Modules in non-Modular Buildroot 15:04:13 .fesco 2257 15:04:13 https://pagure.io/fesco/issue/2257 15:04:14 jforbes: Issue #2257: Change default stream for maven module - fesco - Pagure.io - https://pagure.io/fesco/issue/2257 15:04:39 nirik: it is actually gnome-shell pegging CPU, the system is interactive though ssh :) 15:04:54 ah, alright. 15:05:33 so, on this one it might depend on what we want to do about defaults in geneal... 15:05:38 general. Sheesh. 15:05:49 proposal: defer the decision until we sort out the default modular streams strategy 15:06:02 Yeah. I’m putting in a placeholder -1 until that’s sorted. 15:06:08 mhroncok: +1 15:06:17 Which equals a +1 to mhroncok 15:06:25 mhroncok: +1 15:06:37 jforbes: do you have a memory leak in gnome-shell? https://gitlab.gnome.org/GNOME/gnome-shell/issues/1631 15:06:40 mhroncok: +1 15:06:53 mhroncok: +1 15:07:40 +1 15:07:56 zbyszek: It has 64G, so it would take a long time for that to cause an issue. This was a notification pop up and it went dead 15:08:02 +1, it is questionable if we should have a maven module as default stream at all 15:09:43 Hmm, just a sec, the topic doesn't match the ticket... 15:10:10 I seem to have screwed up the agenda... But we are discussing the correct topic 15:11:11 #agreed Change default streem for maven module: defer the decision until we sort out the default modular streams strategy (+8,0,-0) 15:11:41 .fesco 2255 15:11:42 jforbes: Issue #2255: F32 System-Wide Change: Modules in non-Modular Buildroot - fesco - Pagure.io - https://pagure.io/fesco/issue/2255 15:11:45 Oh! Fesco meeting is one hour earlier than I expected, damn daylight savings time. 15:12:16 I have a question on the topic of default streams, shall I wait for AOB? 15:12:23 jforbes: s/stream/streem/ 15:12:32 err, the other way around 15:13:02 yeah, sorry. Back on the desktop now. 15:13:14 AOB? 15:13:33 ignatenkobrain: (any other business, sorry) 15:13:46 FESCo calls it "Open Floor" :) 15:14:04 Tomato tomato :-) 15:14:07 * satellit_ https://pagure.io/fesco/issue/2267 ? 15:14:13 Yes, Open Floor is probably bedt there 15:14:19 tomato on the open floor? 15:14:31 mbooth: we have just started, so let's see first if we cover it via agenda, and if not, bring it to open floor 15:14:33 satellit_: You can raise that on Open Floor if you want. 15:14:46 k 15:14:56 Wow, why can't I type this morning 15:14:57 But it wasn't on the agenda because our policy only requires it in the meeting if a FESCo member feels it needs live discussion 15:15:15 Anyway. on 2255... 15:15:40 Did everyone get a chance to view the doc I sent out on Friday? 15:16:18 sgallagh: quick q: is the least of default streams complete? 15:16:29 * nirik did... 15:16:31 zbyszek: Yes 15:16:42 It seems that maven and eclipse are the only non-trivial ones. 15:16:42 I took that list from the fedora-module-defaults repo 15:16:50 Yes, and it was appropriately titled :) 15:17:05 nirik: "Is there any idea from dnf maintainers (who I assume would have to work to make any of those things happen on upgrades) how long they might take? ie, longer than until f32beta?" 15:17:06 Yes, sorry, just making sure. 15:17:29 mhroncok: I've reached out to them this morning. Haven't gotten an answer yet. 15:17:46 I believe that resetting the stream on upgrade will take less time implementing than any other solution to this problem, such as tracking the reason why a stream was selected 15:17:50 yeah, if we can have better dnf handling of these cases before f32 then I'd say we can leave things alone... if not... then we probibly need to disable/do something 15:18:42 mhroncok: do you mean "possible solution 3" ? 15:18:55 there is a proposed blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1767351 15:19:11 zbyszek: let me see 15:19:11 nirik: Oh, I misunderstood your question then. 15:19:25 oh? 15:19:32 I thought you were asking how long it would take them to make the changes described in the doc for detecting which streams to reset, etc. 15:19:43 zbyszek: no, I mean what dmach says in https://pagure.io/fesco/issue/2255#comment-610520 15:20:14 well, I was hoping for something like 'this solution will take a long time, this solution will be much easier, this solution we could have by f32 beta, this one we likely wouldn't, etc' 15:21:39 I guess we could try and decide which fix we want most? 15:21:39 nirik: that would make it easier 15:23:08 sgallagh: as a side note (not to derail things), I thought one of the ideas with modularity was that lifecycles could be independent of releases. Should we also look at what happens at non release boundries? ie, say a default stream eol's... 15:23:12 regarding the change proposal... we are trying to solve a situation here and I don't think this particular change is a best place to do this 15:23:32 nirik: That *will* derail things and I'd prefer to table that right now. 15:23:43 ok, fair, just thought I would mention it. 15:23:54 Understood. 15:25:07 mhroncok: yeah... 15:25:32 proposal: defer the decision until we sort out the default modular streams strategy 15:25:48 To clarify: if we accept a plan disable default modules, then the proposal in $topic becomes moot and is automatically rejected? 15:25:54 I'd like to disagree 15:26:00 sure, go on 15:26:24 I think this can still be enabled in parallel, because there *are* some things we can test even if we don't have default module streams. 15:26:48 such as? 15:27:00 note that I still lack any technical specification of whta this change actually does 15:27:04 The Ursa Prime implementation allows us to have overrides for the buildroot generation, so if we wanted to, we can make the "buildroot only" modules available. 15:27:36 I am going to agree with sgallagh on this one. Enabling it does not decide a strategy, but does enable functionality that is potentially useful 15:27:44 sgallagh: I am so sorry, but I have no idea what that menas 15:27:54 *means 15:28:02 mhroncok: It's pretty simple; it generates a fedoraNN-buildroot repository constructed of a set of modules (the defaults plus overrides). This repo is then merged with the non-modular buildroot repo 15:28:43 do i understand correctly that: we now blocking Ursa Prime change on the fact that we have "bad" default modules. So we want to clean up default modules first, enable Ursa Prime as a tool, but without a content yet, and then review the concept of default modules and buildroot modules 15:29:35 iff we decide that default modular streams are a no go, I don't see why we would do this 15:29:46 (Sorry, phone rang. Back now) 15:29:53 mhroncok: +1 15:30:02 mhroncok: in that case we would just have the overrides? 15:30:03 and if we enable this before we make the decision, it will make 1) java blow up, 2) more pckages relying on default streams 15:30:20 sgallagh: do we have example of a "good" module to add via Ursa Prime? 15:30:24 can we have buildroot overrides without ursa prime? 15:30:31 mhroncok: Not from modular content. 15:30:35 mhroncok: not modular 15:30:40 that's the point 15:31:45 Consider the following case: some software will likely end up being module-only. 15:32:11 Even if we disallow default streams for runtime, it may still be beneficial to have those things available in the buildroot. 15:32:25 I don't think non-default modules should be the basis for building any other package in Fedora. 15:32:53 I.e. I disagree with "it may still be beneficial", I believe the opposite. 15:32:53 zbyszek: Consider someone making a module stream for sphinx or asciidoc or similar. 15:33:03 zbyszek: Why is that? Particularly if it is only a build time dep and not a runtime dep 15:33:18 It may be that they literally *can't* build it in the regular buildroot, because it needs an older/newer runtime 15:33:22 I could see allowing this as a useful mechanism for transitioning some package to modular - avoiding having to force all dependent packages to modularize immediately 15:33:31 But it would only matter for other packages at build-time 15:33:55 So it could be delivered as a non-default stream that was allowed to appear in the buildroot (under strict permission from FESCo) 15:34:01 As long as we are allowing a package maintainer to decide to go "module only" for some software - we need to be able to manage such situations 15:34:06 if this is indeed the reson to have this, the rationale for this change should mention it 15:34:15 I don't agree that this is the way to go 15:34:53 IMHO only leaf software should go module only 15:34:56 mhroncok: I didn't consider that case when making the proposal because I thought we were still going to have default streams 15:35:11 Now that this may be happening, I need to address those other cases. 15:35:12 and given the nature of a distribution, no software can be safely considered leaf forever 15:35:32 Exactly. 15:35:39 Furthermore, not being allowed to deliver it is tantamount to saying "default streams may never be reintroduced" 15:35:45 yes 15:35:47 The distinction between "buildroot" and "runtime" packages does not exist in Fedora. 15:35:52 the word temporary was added by you 15:36:02 Maybe this debate is simply not worth having until we decide about default streams? 15:36:28 mhroncok Yes, because I was trying to find a compromise that would allow us to still get things into shape without disrupting the distro. 15:36:32 (Further) 15:36:49 * otaylor , for the record, things that removing default streams with the idea of maybe adding them back later is yanking everybody about in a not-useful way 15:37:00 all defaults should remain in non-modular fedora until such time where there is no noticeable difference between modular nad non-modular packages on installations. when this happen, we can reconsider the situation on buildtime 15:37:03 But if you're going to tell us "no, you can't have default streams *ever*", then you're pre-deciding the outcome. 15:37:18 mhroncok: And we *cannot get there* if we don't have a way to test it. 15:37:23 I'm against removing them unless we don't have a solution to the issues before f32 (since it's at upgrade boundries that we have problems) 15:37:24 sure, test it 15:37:25 The way to test it *is* Ursa Prime. 15:37:54 If you're telling us "We can't have Ursa Prime", then you've already decided the outcome. 15:38:07 this change has consequences. it needs to be tested before it is enabled 15:38:21 I am afraid of those consequences 15:38:26 This change literally cannot be tested without enabling it. 15:38:29 No decision is "forever", we can always reconsider every idea in the future whenever the technical situation chagnes. 15:38:35 but you can have whatever you want in staging, no? 15:38:37 Because it needs access to real-world packages and content. 15:38:47 mhroncok: I don't see how you test in some artificial environment - you need to test *with actual packagers* *with actual fedora content* 15:39:19 I agree that it is not easy to test this in artificial environment 15:39:31 the infra staging environment is useful to test basic spin-up of software, but not useful to see "is this working for people" 15:39:55 nirik: Where are we on the staging bring-up, BTW? 15:40:03 I'd argue that default modular streams are not working for people 15:40:06 we've tested this 15:40:06 Last I checked it was just waiting for a test compose of the pungi config? 15:40:18 I'm not sure. mboddu was working on that I think? 15:41:00 mhroncok: We've determined that there were two main issues with them. 1) Upgrades are unclean. That's still being worked out. 2) Some content went module-only and now non-modular content can't build against it. 15:41:11 Ursa Prime is the solution for 2) 15:41:28 the list of things you've posted on devel is much longer than that 15:41:47 mhroncok: The list I posted on devel was modularity in general. 15:41:56 Those are the items directly pertaining to default streams 15:42:02 ursa prime does solve 2 (most probably, still no reply about what happens to conflicting packages) 15:42:16 but ursa prime also makes 1 potentially much worse 15:42:17 What do you mean "conflicting packages"? 15:42:27 How so? 15:42:31 I mena the questions I've posted on the devel thread weeks ago 15:42:44 mhroncok: The thread got long and I probably lost track of it. 15:42:49 Can you refresh my memory? 15:42:56 working on it 15:43:13 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JNTMUOBZHHCEOV7KS7MRNOBO6VGGT7RX/ 15:43:36 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JX7CNMIYVWBY4PWV3QQIDQGOTSNQJB5D/ 15:43:48 > If this is the goal of default modular streams, wouldn't it be in fact much 15:43:51 > easier to keep the default versions as urisne packages? 15:44:08 Yeah, that is the biggest question I have too. 15:44:17 that is the thing that started the big angry thread 15:44:36 and the concern is still valid for me and no argument was presented that would answer this 15:44:51 but even if we forget about this for a while, there were more questions 15:44:53 Apologies. I could have sworn I replied to that long ago. 15:44:54 with non modular packages you have to deal with parallel installability and also discoverability is bad? 15:45:25 nirik: for defaults? no 15:45:25 yes, you have to deal with that, which is a plus, and no, discoverability is actually much better. 15:45:51 want an alternate version of postgres? sure, keep it in a module 15:45:55 a plus? wow... 15:46:00 'dnf search foo', see 'foobar', 'foobar-11-compat', 'foobar-12-compat', make your choice. 15:46:09 oh you are saying the default should always be non modular... 15:46:13 yes 15:46:15 for months 15:46:17 yes 15:47:11 when you deal with parallel installability, it is a plus 15:47:25 If anyone thinks that discoverability of compat packages is not as good as it should be, then we can trivially enhance dnf to show them in blue (or something), just by tweaking some print statements. This is *vastly* easier. 15:47:33 having to deal with the parallel installability might not be plus 15:47:34 For things which offer parallel. Though I could argue that more things should 15:47:46 zbyszek: but they are not always named compat? 15:48:03 mhroncok: i think if you remove the default stream functionality, encourage packagers to leave things ursine and use modules only for alternatives, you might as well not have modularity 15:48:07 Can we please stop pretending like "start over from scratch" is a real option? 15:48:12 gimp gimp0.9 gimp2.0 15:48:21 otaylor: why not? it gives all the benfits 15:48:23 nirik: yeah, I don't remember the exact rules. 15:48:26 Nothing is stopping anyone from making compat packages if that makes sense for their package. 15:48:54 Modularity offers them an alternative mechanism that doesn't require renaming everything and modifying dependent code to locate it. 15:49:01 They *can* coexist. 15:49:04 yes 15:49:10 mhroncok: I think one of the *big* goals of modularity was to allow simplifying things by saying "what if we can have alternatives in the distro that aren't parallel installable" 15:49:15 and it's an excellent opt-in fetaure 15:49:17 So it's a false argument to claim that people should do this thing instead. 15:49:30 this thing? 15:49:34 otaylor: Exactly 15:49:43 mhroncok: adding metadata to an rpm package doesn't make it different from an rpm package, thus i don't get the case against default streams if we restrict them by policies 15:49:44 otaylor: and what I say keeps all that 15:50:10 mhroncok: Insert any of the alternate approaches people keep throwing out there as if they were somehow in conflict with Modularity. 15:50:26 I also proposed that we could build those defaults as modules and simply ad them to the repository - e.g. do ursa prime on installs 15:50:36 *add 15:50:44 it was rejected very fast 15:51:10 Yes, because it was already a case we had considered and found could not meet other requirements we had 15:51:14 bookwar: the metadata causes the package to have completely different update rules, so it's not just "adding metadata", it's changing the delivery and upgrade and how this package interacts with other packages. 15:51:19 having defaults in non-modular repos, alternatives in modular is somehow conflicting with modularity? 15:51:50 mhroncok: The pitch that was just made was "don't do modules, do compat packages instead". 15:52:04 We've also heard "Switch to Gentoo slots" 15:52:12 we hard a lot of things 15:52:15 *heard 15:52:21 Or "use these largely-untested RPM features" 15:52:26 mhroncok: I'd say the only reason to do that is if we basically cannot get dnf to work as we'd like it - it's throwing away flexibility and metadata 15:52:39 what kind of flexibility? 15:53:29 I personally think that libraries should be compat packages over modules, otherwise we have dependency hell - but that is not relevant to what I have porposed: keep all defaults non-modular 15:53:46 mhroncok: My problem is this: I've attempted to meet you halfway. I wrote up a document on how to drop default streams for the time being as a compromise solution while we fix the upgrade problems. So you then immediately moved the goalposts and started asserting that we can never have default streams. 15:53:50 the alternate versions in modules will exclude the non-modular defaults when selected 15:54:04 You are not arguing in good faith and it's very frustrating. 15:54:09 zbyszek: this is the part i don't understand i guess, why we change the upgrade procedure for default modules 15:54:12 mhroncok: well, e.g., removing a package in a different version of a module and having it not be visible 15:54:37 sgallagh: this was my opinion all the time and it hasn't changed, sorry if that was your understanding 15:55:06 mhroncok: but basically, I don't think it's different from working-module-default-streams from a user point of view, just with less metadata, and new and different things that we have to make to work right 15:55:09 sgallagh: "You are not arguing in good faith and it's very frustrating." please explain 15:55:25 mhroncok, sgallagh let's not dive there :) 15:55:38 * mboddu got out of meeting, and reading back... 15:56:05 I have never said that we can never have default streams. 15:56:14 I say we shouldn't 15:56:15 * nirik suspects we aren't going to solve this today here... but I guess talking about it is good. :) 15:56:53 10:35 AM Furthermore, not being allowed to deliver it is tantamount to saying "default streams may never be reintroduced" 15:56:53 10:35 AM yes 15:57:05 I should point out, it is good to hear all sides of the argument, but also, FESCo only requires majority vote. 15:57:17 * otaylor thinks the role of fesco here is to identify concerns if we have them and bring them to the modularity team, then let the modularity come up and implement things *as they see fit* - and not to spend forever trying to negotiate technology 15:57:36 sgallagh: right. what I meant was that I agree we should not have them, sorry about that 15:57:53 if that contradicts what I say now, it was not done on purpose 15:58:41 and it is indeed very frustrating that when I have an opinion on something, it is considered ill will 15:58:53 how about proposal: mark bug 1767351 a f32 fesco blocker, gather info from dnf team about timelines for possible default modules upgrade issues, test ursa-prime more in stg, more list discussion or something on longer term plans, revisit next week. 15:59:12 So, there is a lot to work out with modularity, and default streams. Those are not all going to be worked out here today. In the meantime, the issue at hand here is Ursa Prime specifically 15:59:12 .bug 1767351 15:59:13 zbyszek: 1767351 – Cannot upgrade to Fedora 32: Modules blocking the upgrade path - https://bugzilla.redhat.com/1767351 15:59:18 mhroncok: Your opinion isn't the part I see as ill will. 15:59:57 is it the way I communicate? 16:00:08 It was the part where once I tried to compromise with you, you then said "once we disable it, we won't re-enable it ever". Which now I see may have been a miscommunication 16:00:17 my understanding: 1) maven module is a hard block on Ursa prime as proposed now, 2) there could be good modules for which it makes sense to enable Ursa Prime for rawhide, if it won't be using "default" as a criteria or if we remove default modules first 3) we still need to make a decision on whether or not we are going to remove default status from current default modules 4) there is a still unresolved issue with upgrade 16:00:23 But can you see where that would have led me to believe you were not acting in good faith? 16:00:38 (Demanding concessions and then using my willingness to compromise to demand more) 16:00:41 sorry a post man, brb 16:01:04 i guess the remaining thing I don't understand how 4) is relevant to Ursa Prime 16:01:10 is it? 16:01:10 So if that wasn't the message you intended to send, I apologize. But that's how it sounded as written. 16:01:37 bookwar: I don't see it as such 16:01:47 bookwar: I think the concern is that if we enable ursa-prime and it uses default modules, people will start using that and if we later disable default modules it will leave them in... a bad place. 16:02:06 bookwar: The Ursa Prime implementation also allows us to say "these default modules *are not* added to the buildroot", FWIW 16:02:17 So we could say "maven is problematic, leave it out for now" 16:02:52 bookwar: The upgrade issue is entirely separate. 16:02:59 sgallagh: from the current list of default modules which ones you think make sense to have in a buildroot? 16:03:16 or are there other modules which it makes sense to get there? 16:03:39 bookwar: Avocado would be one 16:04:19 * mhroncok is back 16:04:28 dwm less so, but could still valuable for testing purposes. 16:04:37 But why? It's just two sources packages. And we would want python-aexpect as non-modular certainly. 16:04:52 zbyszek: why certainly? 16:04:52 Then having a module with a single package seems pointless. 16:05:16 bookwar: because it's a python package that could be useful to other people. 16:05:55 zbyszek: Number of packages is irrelevant. 16:06:00 sgallagh: my understanding was that you are considering my proposal to keep the defaults in non-modular Fedora. not necessary that you agree with it, but that we are simply evaluating the things that would need to be done. 16:06:41 mhroncok: I was evaluating what it would take to do that while we work other things out. 16:06:49 sgallagh: my proposal was meant as permanent (not that it cannot be reevaluated in the future, but that it is by no means a temporary workaround) 16:07:36 I see now that wthis migth have not been communicated properly, but there was no ill will. I'm not trying to trick anybody. I am trying to be as transparent about my opinions as possible 16:07:49 zbyszek: i can see it as if i am having several streams, then i have a unified experience as a developer to maintain default and non-default ones, having two separate workflows seems to be redundant, and it is a tooling job to make default stream available to end-user 16:08:10 sgallagh: the number of packages is relevant, because I don't see any reason for having a module with a single package that is not supposed to be an alternative version. 16:08:17 bookwar: OK, I see 16:08:30 mhroncok: I understand that now. I was trying to explain how I could have drawn that conclusion from the information I had. 16:08:41 Hopefully to avoid a similar situation in the future 16:08:56 zbyszek: Avocado has several different supported versions at the same time 16:09:10 bookwar: I think this reason is way too weak. It makes that one maintainer's life a bit easier, but brings a lot of problems for users of that package. 16:09:27 zbyszek: Such as? 16:09:47 sgallagh: I propose that we meet later this week and talk about this 16:09:48 Sorry, but you need to qualify "brings a lot of problems" 16:10:41 my primary concern with ursa prime is that if we later decide that defaults remains non-modular, the list of things that build against a default stream of something will be bigger and harder to handle 16:11:06 So I think we are definitely at a point where this is not going to be decided in this meeting. Do we want to vote on nirik's proposal? 16:11:22 What was nirik's proposal? 16:11:25 mark bug 1767351 a f32 fesco blocker, gather info from dnf team about timelines for possible default modules upgrade issues, test ursa-prime more in stg, more list discussion or something on longer term plans, revisit next week. 16:11:31 * otaylor wonders if we have need to have a straw vote to see where people align on the top-level issues - while I *want* mhroncok to be happy with the solution that is arrived with, the requirement is, as jforbes said, only that the majority of fesco is OK with the solution that is arrived at 16:12:07 otaylor: yeah, it's not clear where everyone stands on all these big issues (aside from the vocal folks on each side) 16:12:09 otaylor: Propose a non-binding vote? 16:12:19 otaylor: and I am completely fine with that. we don't need to vote unanimously 16:12:32 i personally would vote for Ursa Prime in rawhide with the remark that it doesn't expose everything, not even "default everything" but rather exposes only vetted list of modules. And then move on to the topic of upgradeability of default modules as a separate issue 16:12:37 It's always preferable when we do. It leads to decent compromises. 16:12:43 ideally we would reach consensus... but that doesn't always happen 16:12:46 But I agree that we may never get there in this case. 16:12:51 Sure: 16:13:12 bookwar: +1 16:13:24 bookwar: +1 16:13:26 sgallagh: Having the default version as a module forces users and dependent packages to deal with the package being modular. This includes creating problems for projects which reuse Fedora packages to build other things. And people who do not want to use modular packages. 16:13:27 bookwar: I'd be good with that 16:13:41 bookwar: -1 16:13:46 bookwar: -1 16:14:10 bookwar: do you see enabling "default everything" once we have a plan for default modules agreed with the dnf team, or would it stay "vetted list"? 16:14:32 otaylor: i would keep a separate criteria 16:14:32 FWIW, does usrs-prime consider about the non-default modules that are essential buildroot requirements? You can't build RPMs with the maven module, for example, you need the javapackages-tools module, which is a buildroot-only module. 16:14:40 otaylor: I suggest we don't decide that alongside this. 16:14:41 zbyszek: but 'deal with the package being modular' is the stuff around upgrades we are trying to fix, no? and people don't want to use modular packages because... there's problems around upgrades? 16:14:50 i think "default" and "buildroot" are two different purposes 16:15:05 We can just say "FESCo must provide criteria for when to enable a module in the buildroot" and decide the details later 16:15:15 bookwar: I'm fine making that an initial step to get ursa prime moving 16:15:19 bookwar: +1 16:15:31 bookwar: +1 (since I didn't say it explicitly above) 16:15:54 So I am seeing that as +5,0,-2 16:15:58 sorry, what exactly are we voting on? 16:16:06 also i think mbooth's comments is valid, we can consider a buildroot-only modules even 16:16:07 So we could move ahead with avocado and dwm in the buildroot for now as canaries to test things out? 16:16:25 zbyszek: Ursa Prime in rawhide with the remark that it doesn't expose everything, not even "default everything" but rather exposes only vetted list of modules. And then move on to the topic of upgradeability of default modules as a separate issue 16:16:34 Oh, OK, -1 then. 16:16:41 we don't even have a definition for build-only module 16:16:55 any module builds ends up in a repo unless mboddu is pinged and module is untagged manually 16:17:07 And I proposed avocado and dwm as the representative packages, since they're reasonably unlikely to break other stuff. 16:17:13 So that settles it at +5,0,-3 16:17:13 ignatenkobrain: And yet there are at least two buildroot only modules that I know of :) 16:17:45 Why would we want to have dwm, which is a leaf app, in the buildroot? What we we be testing with that? 16:17:56 mbooth: I can tell you about rpm:4.15, rust:stable. Those were supposed to be buildroot-only... However, each build ended up in a compose 16:18:08 zbyszek: That was mostly a "control". 16:18:18 "javapackages-tools" and "tycho" are two modules used to build other modules that do not get shipped to users (because we don't build them for rawhide) 16:19:04 ignatenkobrain: sound like a bug, have you filed it? 16:21:28 #agreed Ursa Prime in rawhide with the remark that it doesn't expose everything, not even "default everything" but rather exposes only vetted list of modules (+5,0,-3) 16:21:30 so, that passed? (someone didn't vote tho?) 16:21:38 So, I think we're using two different definitions of "buildroot-only modules" 16:21:40 bookwar: I think someone else did, but mboddu should know for sure 16:21:44 I thought we only had 8 here 16:21:53 ah, could be 16:21:55 contyk is not here 16:21:55 Those examples were meant to exist solely for other modules to depend on. 16:22:19 I'm absolutely confident that contyk would have voted in favor, FWIW 16:22:32 me too 16:22:37 It also wouldn't change the result. 16:22:44 Right 16:22:44 either way 16:23:09 to clarify, currently, the vetted list is empty 16:23:09 So the next part of the proposal was to move on to the discussion of upgradeability of default modules 16:23:23 Hold up 16:23:40 mhroncok is correct, the vetted list is empty because we didn't include it in the first proposal. 16:24:10 Proposal: For the purposes of testing, we will allow the avocado and dwm modules in the Ursa Prime buildroot 16:24:25 +1 16:24:31 i don't understand what that tests 16:24:48 As I said above, 'dwm' is a control. Avocado is potentially useful for packages to consume during the %check phase of their builds 16:24:52 but to be fair, I don't understand why those packages are in modules 16:25:05 I really don't get why avocado is a module. It has two packages, both defined as 'ref: latest'. What mhroncok said. 16:25:45 It has two streams: 52lts and 69lts 16:26:31 Correction, it has 69lts and latest in current Rawhide 16:26:48 Where, yes, they happen to both be at the same upstream version, but will diverge. 16:27:06 +1 for testing 16:27:23 sgallagh: +1 16:27:29 sgallagh: +1 16:27:51 mhroncok: i think it tests the infra itself as well as process and lifecycle issues 16:28:01 mhroncok: ^^ that 16:28:04 Right, fairly low risk and useful data 16:28:40 before we add a build dependency like java stuff, we can work with test dependencies, which fairly easy to clean if all goes wrong 16:28:58 Exactly 16:29:14 mhroncok zbyszek ignatenkobrain votes? 16:29:34 -1 I stand by my opinion that no non-modular package should depend on modular 16:29:47 -1 16:29:49 feel free to test this, but only if we disallow this to happen 16:30:03 mhroncok: At runtime or buildtime? 16:30:05 -1 16:30:06 any 16:30:19 I think we're going to have to agree to disagree there. 16:30:27 I assumed we already did 16:30:38 #agreed For the purposes of testing, we will allow the avocado and dwm modules in the Ursa Prime buildroot (+5,0,-3) 16:31:18 proposal: ask the maintainers of those modules if they want this before we do it 16:31:23 "I stand by my opinion that no non-modular package should depend on modular" i don't think it will work if you just will block any modularity-related topics based on this statement 16:31:39 we sort of need to vote on it once, but then accept the outcome and work with what comes next 16:31:43 bookwar: what other optins do i have? 16:31:48 So do we follow to discuss upgradeability of default streams here, or is that something that should continue on list and come back here later? 16:31:59 mhroncok: dwm is maintained by contyk and avocado by merlinm, both of whom are on the Modularity Team. 16:32:13 So I think we're fine. 16:32:35 sgallagh: thanks, that settles it for me 16:32:43 np 16:32:46 jforbes: I'd like more data from the dnf team before we decide anything there... 16:32:46 jforbes: we can vote on fesco blocker status 16:32:57 or have a break ) 16:32:59 yeah, I guess we could do that. 16:33:04 yes, let's do that 16:33:18 Which one are we declaring a blocker? 16:33:21 that == "vote" 16:33:35 zbyszek: sorry for confusing everyone ) 16:33:40 Okay proposal: mark bug 1767351 a f32 fesco blocker 16:33:46 +1 16:33:59 +1 16:33:59 .bug 1767351 16:34:00 mhroncok: 1767351 – Cannot upgrade to Fedora 32: Modules blocking the upgrade path - https://bugzilla.redhat.com/1767351 16:34:05 +1 16:34:15 +1 (as I was in the BZ) 16:34:20 jforbes: +1 16:34:26 +1 16:34:37 +1 here 16:34:46 so... should it perhaps be a beta one? 16:35:02 nirik: That was where it was proposed 16:35:02 "I'm proposing this as a beta blocker, ..." 16:35:03 final is probibly too late to do too much 16:35:07 ok, great 16:35:08 yes, beta blocker 16:35:45 jforbes: When doing the INFO, add that we declared it a beta blocker, please 16:36:55 ignatenkobrain: vote? 16:38:01 #agreed mark bug 1767351 a f32 fesco beta blocker (+7,0,-0) 16:38:17 #topic Next week's chair 16:38:18 I'll relay this to the BZ 16:38:24 Thanks sgallagh 16:38:28 I will be out next week for a training class 16:38:44 Any takers? 16:39:19 I can do it. 16:39:46 #action zbyszek will chair next week's meeting 16:39:55 #topic Open Floor 16:40:02 (thanks zbyszek) 16:40:06 ó/ 16:40:17 I have something, but mbooth please go first. 16:40:30 So after that you may chuckle to yourselfs because I want default stream for eclipse 16:40:32 * mbooth ducks 16:40:33 https://pagure.io/fesco/issue/2267 soas spin ? 16:41:13 mbooth: could you please do the change proposal that includes all the details, such as what happens to the nonmodular packages? 16:42:20 mhroncok: Well, my situation is this: Due to lack of response from releng for weeks, we missed the GA for getting a change in F31 (even though you gave us freeze exception) 16:42:25 is the conflicts with that other module sorted out? ie, it all works modular except isn't default? 16:42:44 That means Eclipse is totally uninstallable because the conflicts is now baked into F31 16:43:00 this is my concern: https://pagure.io/fesco/issue/2236#comment-600605 16:44:25 mhroncok: This is my concern: https://bugzilla.redhat.com/show_bug.cgi?id=1759176 16:45:04 I uderstand your concern 16:45:34 I'm worried that the way we are "fixing" the problem will create the same problem somewhere else 16:45:49 mbooth: it is not visible from the bz how making module default supposed to help 16:45:54 I think we should delay the answer to this until we finish the discussion of default modules. 16:46:05 proposal: we simply add a default stream for eclipse now, so eclipse is installable 16:46:08 * nirik is confused what happened here. 16:46:29 bookwar: Because default module packages always take precendence over non-modular packages. 16:46:55 -1 to add default stream of anything unless it contains a contingency plan, and a plan of what happens to the non-modular packages 16:47:09 and no, i'm not just -1 anything modular here 16:47:15 I just want this coordinated properly 16:47:23 mbooth: why installing a module explicitly doesn't work? 16:47:26 mhroncok: As we discussed when this was initially brought up, the non modular packages are dead 16:47:35 define dead 16:47:58 mhroncok: Non maintained, out-of-date, unbuildable, pick one 16:48:08 and theplan is to keep tham as such? 16:48:11 mhroncok: I think you are asking mbooth to jump through a lot of hoops that are very specific to your concerns about the future of default streams, and I don't think that's reasonable to ask of a packager 16:48:12 bookwar: From the description, it does 16:48:16 or to explicitly retire them? 16:48:55 otaylor: my concerns have nothing to do with the future of default streams. my concern is about cooridnating things 16:49:06 mbooth: afaiu, if the conflict between packages is resolved, then eclipse should be installable from module, if it is not resolved, then default stream won't help. So does it work from module or not? 16:49:16 mhroncok: Retiring them doesn't help with them being baked into the frozen release repo 16:49:19 * nirik just tried 'dnf module enable eclipse' in rawhide. got: "Error: Problems in request:" 16:49:36 AGREED: Drop the unmaintained eclipse from the non-modular repositories and ship module streams of eclipse. Whenever the conflicts are resolved later, we can make a default stream available (+6, 0, 0) 16:49:37 * jforbes zbyszek to add eclipse to fedora-obsolet-packages 16:49:37 * jforbes mbooth to drive the retirement of non-modular eclipse 16:49:37 AGREED: The bug about eclipse not being installable is approved as FESCo FE (+6, 0, 0) 16:49:43 That was from the orinigal 16:50:02 sgallagh: no, it doesn't. I'm talking about f32 16:50:24 Yeah eclipse packages will be retired in f32, I am talking about f31 16:50:24 mhroncok: maybe I just don't understand your ask 16:50:26 Yeah, we should probably do that in Rawhide, sure. 16:50:46 But the request is for how to un-^&#* the F31 situation. 16:50:47 We missed the opportunity to fix the conflicts in f31 because of lack of response from releng team 16:51:05 mbooth: do you feel you understand what mhroncok is asking for wrt. to adding a default stream for eclipse? 16:51:24 mbooth: The releng "team" is basically one overworked guy and a little help from nirik. It's not surprising, but it is unfortunate. 16:51:30 mbooth: can you point to where that was? I know it's water under the bridge, but I can't see it. 16:51:59 * sgallagh has a hard stop in 9 minutes 16:52:03 nirik: We had three tickets, but this took longest to resolve: https://pagure.io/releng/issue/8909 16:52:24 the two I looked at in the other ticket were finished in about 15min of you filing them 16:52:41 On the order of a fortnight or so 16:52:42 ok, thats the one then... 16:53:01 But yeah, can't change the past :-) 16:53:24 might be nice to note in those sorts of tickets that they are important for release... because around release, releng is most busy 16:53:34 mbooth: but it is fixed now? what is the current status of conflicts? 16:53:35 so, we are dealing with broken f31 here, the proposal is to enable default modular stream for eclipse on f31 only, to make it installable 16:53:59 are we possitive that doing that will actually make it so? 16:54:23 bookwar: No, because F31 is released and the conflict is baked into the f31 repositories -- no amount of submissions to the update repos will remove the conflicting package from the base release repo 16:54:39 mbooth: ok, i guess I got it now 16:54:47 Trying myself now 16:55:35 Problem: conflicting requests 16:55:35 - nothing provides osgi(com.ifedorenko.m2e.sourcelookup) needed by eclipse-m2e-mavendev-0.3.0.201506181201-8.fc30.noarch 16:55:36 mhroncok: Yeah mizdebsk was able to confirm that it would fix it (as it always did) 16:56:06 making it default will not fix it. 16:56:36 sgallagh: What makes you say that? 16:56:44 mbooth: we couldn't make eclipse default, because it was conflicting with maven module, which was also default 16:57:00 mbooth: Because I just tried `dnf module enable eclipse:latest` and `dnf install eclipse` and it failed 16:57:47 bookwar: Right! And an update to maven module removed the conflict, but I can't change the past 16:58:08 mbooth: An update in stable? 16:58:10 sgallagh: That's because eclipse module is not default. 16:58:10 Or u-t? 16:58:21 I agree with mhroncok that a proper description of what is proposed (including if if it is for F31 or rawhide), and what happens with non-modular packages. 16:58:28 ... is needed. 16:58:28 mbooth: once it's marked "enabled" that is stronger than default 16:59:09 sgallagh: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-d13aabe040 16:59:11 I want to be able to test the proposed solution on a few different systems, and right now I'm not even exactly sure what is being proposed. 16:59:14 Oh, hang on 16:59:26 It doesn't work for eclipse:latest, but it *does* work for eclipse:2019-06 16:59:32 Which one were you asking to be default? 16:59:36 latest 16:59:53 zbyszek: we already agreed it would be a default once the conflicts were resolved. This is an F31 only request 17:00:16 jforbes: I disagree 17:00:28 "Drop the unmaintained eclipse from the non-modular repositories" hasn't happen 17:00:38 jforbes: dnf module enable eclipse:latest and dnf install eclipse does not work here, so I'm not sure about the "conflicts were resolved" part. 17:00:38 mhroncok: I just posted the FESCO decisions 17:00:44 "and ship module streams of eclipse" happened 17:00:55 "Whenever the conflicts are resolved later" is currently unclear 17:01:11 https://paste.centos.org/view/bcb39f8f 17:01:58 We were unable to resolve the conflict before GA, so the conflict is only removed in an update -- the conflict will live forever in the F31 release repositories, we can't change that now. 17:02:10 Hence "missing the window" 17:02:45 zbyszek: Right, just saying that the eventual default has been decided, the request is for an exception for F31 because the conflict couldn't land in time for F31. What happens to the non-modular packages and rawhide was already agreed upon. 17:02:48 mbooth: sure, but I have a system with updates installed. I'm not trying to install from the DVD here. 17:03:06 The fact that it doesn't work right now is very relevant to this discussion however 17:03:29 zbyszek: Right but the DVD still provides the package that went away in the update! 17:03:34 mbooth: I just confirmed that the maven u-t update does in fact resolve the situation and gave it karma 17:04:16 --disablerepo=fedora-modular ? 17:04:23 zbyszek: Add `--enablerepo=updates-testing-modular` and it works 17:04:26 I just confirmed this 17:04:36 We just need to get the maven update in u-t-m pushed to stable 17:04:56 so the GA set does not break it always? 17:04:59 and with the maven update 17:05:05 does the ursine eclips enot install? 17:05:09 nirik: If you install without updates, yes it will break 17:05:13 eclipse not install? 17:06:04 sgallagh: so we know for sure that with updated maven we get a fixed modular eclipse, and it can be installed from a module? 17:06:04 sgallagh: sudo dnf install --enablerepo=updates-testing-modular eclipse ? That still doens't work. 17:06:30 mhroncok: even if you could get it to install, it isn't buildable, isn't updatable. this was why we originally granted the FE 17:06:50 zbyszek: you are installing non-modular one 17:07:25 zbyszek: `sudo dnf enable eclipse:latest && sudo dnf install --enablerepo=updates-testing-modular eclipse` 17:07:31 is a meeting aproper place to figure this out? 17:07:52 sgallagh: this is exactly what I did. 17:08:25 zbyszek: Oh, zanata-client was not in my conflicts list. 17:08:29 Maybe that's contributing? 17:08:42 mbooth: can you update the bugzilla with the relevant info? 17:08:54 I need the default stream for "dnf install eclipse --enablerepo=updates-testing-modular" does not work, you get the conflict, hence my request for the default stream 17:08:55 or a fesco ticket... 17:09:01 jforbes: "The bug about eclipse not being installable is approved as FESCo FE" 17:09:13 it is like every time we are trying to discuss this issue we are diving in into full-scale debugging session 17:09:19 yes 17:09:23 bookwar: https://bugzilla.redhat.com/show_bug.cgi?id=1759176 17:09:25 * sgallagh is now late for his hard stop. 17:09:34 Bye 17:09:42 thanks sgallagh 17:09:53 mbooth: there is info there 17:09:56 proposal: open a fesco ticket that contains the exact request and exact rationale for it 17:09:57 bookwar: Because no-one trusts my assessment of the situation I guess :-/ 17:10:09 mbooth: it's not about trust 17:10:12 I just don't understand 17:10:14 mhroncok: +1 17:10:48 please make a proposal that we can understand 17:10:54 mbooth: it is not about you, but we really need the info. There should be at least the output of successful modular install of the eclipse with updated maven in that issue, so that we know that modular part works 17:10:57 mbooth: it is not about trust. It is about putting a clear description in writing, so we are all on the same page and can consider the details calmly. 17:11:03 as with the original proposal, we are trying to figure all the detail ina meeting 17:11:37 as a data point: I was able to install eclipse from eclipse:latest on f31 with --enablerepo=updates-testing-modular 17:12:03 I would like to see this worked out sooner rather than later, so perhaps file the ticket, get it ready and we can vote before the next meeting? 17:12:03 The BZ above is the ticket I filed after fesco asked me to file one last time... But have had no requests for clarification from fesco 17:12:12 mbooth: when doing things like this in a meeting, we very often get details wrong, e.g. because people assume that they are talking about the same version, when in fact they are not. 17:12:41 mbooth: there was no request for fesco until now 17:12:50 (I mean, after the first one) 17:13:11 mbooth: File a FESCo ticket specifically for the F31 change? 17:13:19 mbooth: ^ this would be quite helpful also for users to have the workaround with updates-testing-modular repo in the BZ , so they can start using it and verify that it works 17:13:52 mbooth: it also seems that some additional Obsoletes need to be pushed for this solution to work on upgraded systems (like mine). 17:14:00 So I can more detail to one of the existing tickets or file a new ticket, which do you prefer? 17:14:29 mbooth: new ticket please 17:15:00 zbyszek: Okay I will do that 17:15:03 Right, the previous ticket is resolved, and now you are asking for an exception to that resolution, so that would be a new ticket 17:15:09 mbooth: thank you 17:15:25 Okay, moving on, I know zbyszek and satellit_ both had something. 17:15:30 zbyszek first? 17:15:41 I'll go quickly 17:15:51 .fesco 2261 17:15:52 zbyszek: Issue #2261: Election Interview Questions — FESCo (Fedora 31) - fesco - Pagure.io - https://pagure.io/fesco/issue/2261 17:16:18 +1 to reusing the old questions 17:16:18 I withdraw my proposal to update, so by default FPM will continue with the old questinos. 17:16:25 I hope everyone's OK with that. 17:16:25 * nirik was hoping for new questions, but ok 17:16:56 nirik: we need them by the 13th ;( 17:17:22 nirik: perhaps focus on new questions now for the next cycle? I think we have missed this one 17:17:23 yeah, I was hoping people would have ones they wanted answered. Oh well. 17:18:06 So, I suppose a vote doesn't matter, there are no new questions to vote on, so the existing will be there. 17:18:14 satellit_ 17:18:17 Yep. 17:18:21 Python 2 exception: sugar desktop environment https://pagure.io/fesco/issue/2267 17:18:21 i was thinking of adding something more direct, like "what's you opinion on modularity", but it would transform fesco voting into vote on topics 17:19:09 satellit_: it seems to me that the request is incomplete 17:19:16 satellit_: i think we are waiting for inputs from maintainers of involved packages 17:19:42 pbrobinson made it....I am just a volunteer 17:20:15 satellit_: what do you like to know? 17:20:30 Right, and when the input from the dependent maintainers is made, I expect we will vote based on that, but I don't think anything can be done before then 17:20:55 can the Python packages not get retired till resolved (delay) 17:21:06 for a resoanble deadline, yes 17:21:09 forever? no 17:21:14 k 17:21:21 (my personal opinion) 17:21:42 but if the maintainers re not aware fo this, they might remove their python2 packages 17:21:52 the key is to talk to them 17:23:01 Anything else for Open Floor? 17:23:19 If not, closing at 25 after 17:25:00 #endmeeting