15:00:23 <jforbes> #startmeeting FESCO (2019-11-11)
15:00:23 <zodbot> Meeting started Mon Nov 11 15:00:23 2019 UTC.
15:00:23 <zodbot> This meeting is logged and archived in a public location.
15:00:23 <zodbot> The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:23 <zodbot> The meeting name has been set to 'fesco_(2019-11-11)'
15:00:23 <jforbes> #meetingname fesco
15:00:23 <jforbes> #chair nirik, ignatenkobrain, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:23 <jforbes> #topic init process
15:00:24 <zodbot> The meeting name has been set to 'fesco'
15:00:24 <zodbot> Current chairs: bookwar contyk ignatenkobrain jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:44 <nirik> .hello kevin
15:00:45 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:00:47 <otaylor> .hello2
15:00:48 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:00:50 <bookwar> .hello2
15:00:51 <sgallagh> .hello2
15:00:54 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:00:57 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:01 <mhroncok> .hello churchyard
15:01:01 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
15:01:04 <ignatenkobrain> .hello2
15:01:05 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:02:17 <zbyszek> .hello2
15:02:18 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:02:31 <jforbes> Ugh, had to switch machines, my desktop just locked...
15:02:39 <danilocesar> .hello2
15:02:40 <zodbot> danilocesar: danilocesar 'None' <danilocesar.dp@gmail.com>
15:02:48 <jforbes> That is rebooting. Looks like we have quorum though
15:03:48 <bookwar> was it fedora 31? :)
15:04:08 <jforbes> bookwar: indeed it was
15:04:11 <nirik> jforbes: should report it to the kernel maintainers. ;)
15:04:13 <jforbes> #topic F32 System-Wide Change: Modules in non-Modular Buildroot
15:04:13 <jforbes> .fesco 2257
15:04:13 <jforbes> https://pagure.io/fesco/issue/2257
15:04:14 <zodbot> jforbes: Issue #2257: Change default stream for maven module - fesco - Pagure.io - https://pagure.io/fesco/issue/2257
15:04:39 <jforbes> nirik: it is actually gnome-shell pegging CPU, the system is interactive though ssh :)
15:04:54 <nirik> ah, alright.
15:05:33 <nirik> so, on this one it might depend on what we want to do about defaults in geneal...
15:05:38 <nirik> general. Sheesh.
15:05:49 <mhroncok> proposal: defer the decision until we sort out the default modular streams strategy
15:06:02 <sgallagh> Yeah. I’m putting in a placeholder -1 until that’s sorted.
15:06:08 <jforbes> mhroncok: +1
15:06:17 <sgallagh> Which equals a +1 to mhroncok
15:06:25 <ignatenkobrain> mhroncok: +1
15:06:37 <zbyszek> jforbes: do you have a memory leak in gnome-shell? https://gitlab.gnome.org/GNOME/gnome-shell/issues/1631
15:06:40 <zbyszek> mhroncok: +1
15:06:53 <nirik> mhroncok: +1
15:07:40 <otaylor> +1
15:07:56 <jforbes> 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 <bookwar> +1, it is questionable if we should have a maven module as default stream at all
15:09:43 <jforbes> Hmm, just a sec, the topic doesn't match the ticket...
15:10:10 <jforbes> I seem to have screwed up the agenda... But we are discussing the correct topic
15:11:11 <jforbes> #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 <jforbes> .fesco 2255
15:11:42 <zodbot> jforbes: Issue #2255: F32 System-Wide Change: Modules in non-Modular Buildroot - fesco - Pagure.io - https://pagure.io/fesco/issue/2255
15:11:45 <mbooth> Oh! Fesco meeting is one hour earlier than I expected, damn daylight savings time.
15:12:16 <mbooth> I have a question on the topic of default streams, shall I wait for AOB?
15:12:23 <sgallagh> jforbes: s/stream/streem/
15:12:32 <sgallagh> err, the other way around
15:13:02 <jforbes> yeah, sorry.  Back on the desktop now.
15:13:14 <ignatenkobrain> AOB?
15:13:33 <mbooth> ignatenkobrain: (any other business, sorry)
15:13:46 <sgallagh> FESCo calls it "Open Floor" :)
15:14:04 <mbooth> Tomato tomato :-)
15:14:07 * satellit_ https://pagure.io/fesco/issue/2267 ?
15:14:13 <jforbes> Yes, Open Floor is probably bedt there
15:14:19 <ignatenkobrain> tomato on the open floor?
15:14:31 <bookwar> 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 <sgallagh> satellit_: You can raise that on Open Floor if you want.
15:14:46 <satellit_> k
15:14:56 <jforbes> Wow, why can't I type this morning
15:14:57 <sgallagh> 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 <jforbes> Anyway. on 2255...
15:15:40 <sgallagh> Did everyone get a chance to view the doc I sent out on Friday?
15:16:18 <zbyszek> sgallagh: quick q: is the least of default streams complete?
15:16:29 * nirik did...
15:16:31 <sgallagh> zbyszek: Yes
15:16:42 <zbyszek> It seems that maven and eclipse are the only non-trivial ones.
15:16:42 <sgallagh> I took that list from the fedora-module-defaults repo
15:16:50 <jforbes> Yes, and it was appropriately titled :)
15:17:05 <mhroncok> 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 <zbyszek> Yes, sorry, just making sure.
15:17:29 <sgallagh> mhroncok: I've reached out to them this morning. Haven't gotten an answer yet.
15:17:46 <mhroncok> 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 <nirik> 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 <zbyszek> mhroncok: do you mean "possible solution 3" ?
15:18:55 <mhroncok> there is a proposed blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1767351
15:19:11 <mhroncok> zbyszek: let me see
15:19:11 <sgallagh> nirik: Oh, I misunderstood your question then.
15:19:25 <nirik> oh?
15:19:32 <sgallagh> 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 <mhroncok> zbyszek: no, I mean what dmach says in https://pagure.io/fesco/issue/2255#comment-610520
15:20:14 <nirik> 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 <nirik> I guess we could try and decide which fix we want most?
15:21:39 <jforbes> nirik: that would make it easier
15:23:08 <nirik> 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 <mhroncok> 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 <sgallagh> nirik: That *will* derail things and I'd prefer to table that right now.
15:23:43 <nirik> ok, fair, just thought I would mention it.
15:23:54 <sgallagh> Understood.
15:25:07 <nirik> mhroncok: yeah...
15:25:32 <mhroncok> proposal: defer the decision until we sort out the default modular streams strategy
15:25:48 <zbyszek> To clarify: if we accept a plan disable default modules, then the proposal in $topic becomes moot and is automatically rejected?
15:25:54 <sgallagh> I'd like to disagree
15:26:00 <mhroncok> sure, go on
15:26:24 <sgallagh> 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 <mhroncok> such as?
15:27:00 <mhroncok> note that I still lack any technical specification of whta this change actually does
15:27:04 <sgallagh> 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 <jforbes> 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 <mhroncok> sgallagh: I am so sorry, but I have no idea what that menas
15:27:54 <mhroncok> *means
15:28:02 <sgallagh> 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 <bookwar> 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 <mhroncok> iff we decide that default modular streams are a no go, I don't see why we would do this
15:29:46 <sgallagh> (Sorry, phone rang. Back now)
15:29:53 <ignatenkobrain> mhroncok: +1
15:30:02 <nirik> mhroncok: in that case we would just have the overrides?
15:30:03 <mhroncok> 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 <bookwar> sgallagh: do we have example of a "good" module to add via Ursa Prime?
15:30:24 <mhroncok> can we have buildroot overrides without ursa prime?
15:30:31 <sgallagh> mhroncok: Not from modular content.
15:30:35 <jforbes> mhroncok: not modular
15:30:40 <mhroncok> that's the point
15:31:45 <sgallagh> Consider the following case: some software will likely end up being module-only.
15:32:11 <sgallagh> Even if we disallow default streams for runtime, it may still be beneficial to have those things available in the buildroot.
15:32:25 <zbyszek> I don't think non-default modules should be the basis for building any other package in Fedora.
15:32:53 <zbyszek> I.e. I disagree with "it may still be beneficial", I believe the opposite.
15:32:53 <sgallagh> zbyszek: Consider someone making a module stream for sphinx or asciidoc or similar.
15:33:03 <jforbes> zbyszek: Why is that? Particularly if it is only a build time dep and not a runtime dep
15:33:18 <sgallagh> It may be that they literally *can't* build it in the regular buildroot, because it needs an older/newer runtime
15:33:22 <otaylor> 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 <sgallagh> But it would only matter for other packages at build-time
15:33:55 <sgallagh> 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 <otaylor> 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 <mhroncok> if this is indeed the reson to have this, the rationale for this change should mention it
15:34:15 <mhroncok> I don't agree that this is the way to go
15:34:53 <mhroncok> IMHO only leaf software should go module only
15:34:56 <sgallagh> 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 <sgallagh> Now that this may be happening, I need to address those other cases.
15:35:12 <mhroncok> and given the nature of a distribution, no software can be safely considered leaf forever
15:35:32 <zbyszek> Exactly.
15:35:39 <sgallagh> Furthermore, not being allowed to deliver it is tantamount to saying "default streams may never be reintroduced"
15:35:45 <mhroncok> yes
15:35:47 <zbyszek> The distinction between "buildroot" and "runtime" packages does not exist in Fedora.
15:35:52 <mhroncok> the word temporary was added by you
15:36:02 <otaylor> Maybe this debate is simply not worth having until we decide about default streams?
15:36:28 <sgallagh> 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 <sgallagh> (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 <mhroncok> 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 <sgallagh> 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 <sgallagh> mhroncok: And we *cannot get there* if we don't have a way to test it.
15:37:23 <nirik> 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 <mhroncok> sure, test it
15:37:25 <sgallagh> The way to test it *is* Ursa Prime.
15:37:54 <sgallagh> If you're telling us "We can't have Ursa Prime", then you've already decided the outcome.
15:38:07 <mhroncok> this change has consequences. it needs to be tested before it is enabled
15:38:21 <mhroncok> I am afraid of those consequences
15:38:26 <sgallagh> This change literally cannot be tested without enabling it.
15:38:29 <zbyszek> No decision is "forever", we can always reconsider every idea in the future whenever the technical situation chagnes.
15:38:35 <ignatenkobrain> but you can have whatever you want in staging, no?
15:38:37 <sgallagh> Because it needs access to real-world packages and content.
15:38:47 <otaylor> 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 <mhroncok> I agree that it is not easy to test this in artificial environment
15:39:31 <otaylor> 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 <sgallagh> nirik: Where are we on the staging bring-up, BTW?
15:40:03 <mhroncok> I'd argue that default modular streams are not working for people
15:40:06 <mhroncok> we've tested this
15:40:06 <sgallagh> Last I checked it was just waiting for a test compose of the pungi config?
15:40:18 <nirik> I'm not sure. mboddu was working on that I think?
15:41:00 <sgallagh> 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 <sgallagh> Ursa Prime is the solution for 2)
15:41:28 <mhroncok> the list of things you've posted on devel is much longer than that
15:41:47 <sgallagh> mhroncok: The list I posted on devel was modularity in general.
15:41:56 <sgallagh> Those are the items directly pertaining to default streams
15:42:02 <mhroncok> ursa prime does solve 2 (most probably, still no reply about what happens to conflicting packages)
15:42:16 <mhroncok> but ursa prime also makes 1 potentially much worse
15:42:17 <sgallagh> What do you mean "conflicting packages"?
15:42:27 <sgallagh> How so?
15:42:31 <mhroncok> I mena the questions I've posted on the devel thread weeks ago
15:42:44 <sgallagh> mhroncok: The thread got long and I probably lost track of it.
15:42:49 <sgallagh> Can you refresh my memory?
15:42:56 <mhroncok> working on it
15:43:13 <mhroncok> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JNTMUOBZHHCEOV7KS7MRNOBO6VGGT7RX/
15:43:36 <mhroncok> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JX7CNMIYVWBY4PWV3QQIDQGOTSNQJB5D/
15:43:48 <zbyszek> > If this is the goal of default modular streams, wouldn't it be in fact much
15:43:51 <zbyszek> > easier to keep the default versions as urisne packages?
15:44:08 <zbyszek> Yeah, that is the biggest question I have too.
15:44:17 <mhroncok> that is the thing that started the big angry thread
15:44:36 <mhroncok> and the concern is still valid for me and no argument was presented that would answer this
15:44:51 <mhroncok> but even if we forget about this for a while, there were more questions
15:44:53 <sgallagh> Apologies. I could have sworn I replied to that long ago.
15:44:54 <nirik> with non modular packages you have to deal with parallel installability and also discoverability is bad?
15:45:25 <mhroncok> nirik: for defaults? no
15:45:25 <zbyszek> yes, you have to deal with that, which is a plus, and no, discoverability is actually much better.
15:45:51 <mhroncok> want an alternate version of postgres? sure, keep it in a module
15:45:55 <nirik> a plus? wow...
15:46:00 <zbyszek> 'dnf search foo', see 'foobar', 'foobar-11-compat', 'foobar-12-compat', make your choice.
15:46:09 <nirik> oh you are saying the default should always be non modular...
15:46:13 <mhroncok> yes
15:46:15 <mhroncok> for months
15:46:17 <zbyszek> yes
15:47:11 <mhroncok> when you deal with parallel installability, it is a plus
15:47:25 <zbyszek> 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 <mhroncok> having to deal with the parallel installability might not be plus
15:47:34 <jforbes> For things which offer parallel. Though I could argue that more things should
15:47:46 <nirik> zbyszek: but they are not always named compat?
15:48:03 <otaylor> 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 <sgallagh> Can we please stop pretending like "start over from scratch" is a real option?
15:48:12 <nirik> gimp gimp0.9 gimp2.0
15:48:21 <mhroncok> otaylor: why not? it gives all the benfits
15:48:23 <zbyszek> nirik: yeah, I don't remember the exact rules.
15:48:26 <sgallagh> Nothing is stopping anyone from making compat packages if that makes sense for their package.
15:48:54 <sgallagh> Modularity offers them an alternative mechanism that doesn't require renaming everything and modifying dependent code to locate it.
15:49:01 <sgallagh> They *can* coexist.
15:49:04 <mhroncok> yes
15:49:10 <otaylor> 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 <mhroncok> and it's an excellent opt-in fetaure
15:49:17 <sgallagh> So it's a false argument to claim that people should do this thing instead.
15:49:30 <mhroncok> this thing?
15:49:34 <sgallagh> otaylor: Exactly
15:49:43 <bookwar> 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 <mhroncok> otaylor: and what I say keeps all that
15:50:10 <sgallagh> mhroncok: Insert any of the alternate approaches people keep throwing out there as if they were somehow in conflict with Modularity.
15:50:26 <mhroncok> 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 <mhroncok> *add
15:50:44 <mhroncok> it was rejected very fast
15:51:10 <sgallagh> Yes, because it was already a case we had considered and found could not meet other requirements we had
15:51:14 <zbyszek> 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 <mhroncok> having defaults in non-modular repos, alternatives in modular is somehow conflicting with modularity?
15:51:50 <sgallagh> mhroncok: The pitch that was just made was "don't do modules, do compat packages instead".
15:52:04 <sgallagh> We've also heard "Switch to Gentoo slots"
15:52:12 <mhroncok> we hard a lot of things
15:52:15 <mhroncok> *heard
15:52:21 <sgallagh> Or "use these largely-untested RPM features"
15:52:26 <otaylor> 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 <mhroncok> what kind of flexibility?
15:53:29 <mhroncok> 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 <sgallagh> 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 <mhroncok> the alternate versions in modules will exclude the non-modular defaults when selected
15:54:04 <sgallagh> You are not arguing in good faith and it's very frustrating.
15:54:09 <bookwar> zbyszek: this is the part i don't understand i guess, why we change the upgrade procedure for default modules
15:54:12 <otaylor> mhroncok: well, e.g., removing a package in a different version of a module and having it not be visible
15:54:37 <mhroncok> sgallagh: this was my opinion all the time and it hasn't changed, sorry if that was your understanding
15:55:06 <otaylor> 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 <mhroncok> sgallagh: "You are not arguing in good faith and it's very frustrating." please explain
15:55:25 <bookwar> mhroncok, sgallagh let's not dive there :)
15:55:38 * mboddu got out of meeting, and reading back...
15:56:05 <mhroncok> I have never said that we can never have default streams.
15:56:14 <mhroncok> 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 <sgallagh> 10:35 AM <sgallagh> Furthermore, not being allowed to deliver it is tantamount to saying "default streams may never be reintroduced"
15:56:53 <sgallagh> 10:35 AM <mhroncok> yes
15:57:05 <jforbes> 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 <mhroncok> sgallagh: right. what I meant was that I agree we should not have them, sorry about that
15:57:53 <mhroncok> if that contradicts what I say now, it was not done on purpose
15:58:41 <mhroncok> and it is indeed very frustrating that when I have an opinion on something, it is considered ill will
15:58:53 <nirik> 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 <jforbes> 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 <zbyszek> .bug 1767351
15:59:13 <zodbot> zbyszek: 1767351 – Cannot upgrade to Fedora 32: Modules blocking the upgrade path - https://bugzilla.redhat.com/1767351
15:59:18 <sgallagh> mhroncok: Your opinion isn't the part I see as ill will.
15:59:57 <mhroncok> is it the way I communicate?
16:00:08 <sgallagh> 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 <bookwar> 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 <sgallagh> But can you see where that would have led me to believe you were not acting in good faith?
16:00:38 <sgallagh> (Demanding concessions and then using my willingness to compromise to demand more)
16:00:41 <mhroncok> sorry a post man, brb
16:01:04 <bookwar> i guess the remaining thing I don't understand  how 4) is relevant to Ursa Prime
16:01:10 <bookwar> is it?
16:01:10 <sgallagh> So if that wasn't the message you intended to send, I apologize. But that's how it sounded as written.
16:01:37 <jforbes> bookwar: I don't see it as such
16:01:47 <nirik> 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 <sgallagh> bookwar: The Ursa Prime implementation also allows us to say "these default modules *are not* added to the buildroot", FWIW
16:02:17 <sgallagh> So we could say "maven is problematic, leave it out for now"
16:02:52 <sgallagh> bookwar: The upgrade issue is entirely separate.
16:02:59 <bookwar> sgallagh: from the current list of default modules which ones you think make sense to have in a buildroot?
16:03:16 <bookwar> or are there other modules which it makes sense to get there?
16:03:39 <sgallagh> bookwar: Avocado would be one
16:04:19 * mhroncok is back
16:04:28 <sgallagh> dwm less so, but could still valuable for testing purposes.
16:04:37 <zbyszek> But why? It's just two sources packages. And we would want python-aexpect as non-modular certainly.
16:04:52 <bookwar> zbyszek: why certainly?
16:04:52 <zbyszek> Then having a module with a single package seems pointless.
16:05:16 <zbyszek> bookwar: because it's a python package that could be useful to other people.
16:05:55 <sgallagh> zbyszek: Number of packages is irrelevant.
16:06:00 <mhroncok> 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 <sgallagh> mhroncok: I was evaluating what it would take to do that while we work other things out.
16:06:49 <mhroncok> 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 <mhroncok> 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 <bookwar> 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 <zbyszek> 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 <zbyszek> bookwar: OK, I see
16:08:30 <sgallagh> 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 <sgallagh> Hopefully to avoid a similar situation in the future
16:08:56 <sgallagh> zbyszek: Avocado has several different supported versions at the same time
16:09:10 <zbyszek> 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 <sgallagh> zbyszek: Such as?
16:09:47 <mhroncok> sgallagh: I propose that we meet later this week and talk about this
16:09:48 <sgallagh> Sorry, but you need to qualify "brings a lot of problems"
16:10:41 <mhroncok> 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 <jforbes> 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 <sgallagh> What was nirik's proposal?
16:11:25 <jforbes> 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 <nirik> 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 <sgallagh> otaylor: Propose a non-binding vote?
16:12:19 <mhroncok> otaylor: and I am completely fine with that. we don't need to vote unanimously
16:12:32 <bookwar> 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 <sgallagh> It's always preferable when we do. It leads to decent compromises.
16:12:43 <nirik> ideally we would reach consensus... but that doesn't always happen
16:12:46 <sgallagh> But I agree that we may never get there in this case.
16:12:51 <otaylor> Sure:
16:13:12 <nirik> bookwar: +1
16:13:24 <jforbes> bookwar: +1
16:13:26 <zbyszek> 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 <sgallagh> bookwar: I'd be good with that
16:13:41 <ignatenkobrain> bookwar: -1
16:13:46 <mhroncok> bookwar: -1
16:14:10 <otaylor> 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 <bookwar> otaylor: i would keep a separate criteria
16:14:32 <mbooth> 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 <sgallagh> otaylor: I suggest we don't decide that alongside this.
16:14:41 <nirik> 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 <bookwar> i think "default" and "buildroot" are two different purposes
16:15:05 <sgallagh> 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 <otaylor> bookwar: I'm fine making that an initial step to get ursa prime moving
16:15:19 <otaylor> bookwar: +1
16:15:31 <sgallagh> bookwar: +1 (since I didn't say it explicitly above)
16:15:54 <jforbes> So I am seeing that as +5,0,-2
16:15:58 <zbyszek> sorry, what exactly are we voting on?
16:16:06 <bookwar> also i think mbooth's comments is valid, we can consider a buildroot-only modules even
16:16:07 <sgallagh> So we could move ahead with avocado and dwm in the buildroot for now as canaries to test things out?
16:16:25 <jforbes> 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 <zbyszek> Oh, OK, -1 then.
16:16:41 <ignatenkobrain> we don't even have a definition for build-only module
16:16:55 <ignatenkobrain> any module builds ends up in a repo unless mboddu is pinged and module is untagged manually
16:17:07 <sgallagh> And I proposed avocado and dwm as the representative packages, since they're reasonably unlikely to break other stuff.
16:17:13 <jforbes> So that settles it at +5,0,-3
16:17:13 <mbooth> ignatenkobrain: And yet there are at least two buildroot only modules that I know of :)
16:17:45 <zbyszek> 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 <ignatenkobrain> 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 <sgallagh> zbyszek: That was mostly a "control".
16:18:18 <mbooth> "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 <bookwar> ignatenkobrain: sound like a bug, have you filed it?
16:21:28 <jforbes> #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 <nirik> so, that passed? (someone didn't vote tho?)
16:21:38 <sgallagh> So, I think we're using two different definitions of "buildroot-only modules"
16:21:40 <ignatenkobrain> bookwar: I think someone else did, but mboddu should know for sure
16:21:44 <jforbes> I thought we only had 8 here
16:21:53 <nirik> ah, could be
16:21:55 <mhroncok> contyk is not here
16:21:55 <sgallagh> Those examples were meant to exist solely for other modules to depend on.
16:22:19 <sgallagh> I'm absolutely confident that contyk would have voted in favor, FWIW
16:22:32 <mhroncok> me too
16:22:37 <zbyszek> It also wouldn't change the result.
16:22:44 <sgallagh> Right
16:22:44 <mhroncok> either way
16:23:09 <mhroncok> to clarify, currently, the vetted list is empty
16:23:09 <jforbes> So the next part of the proposal was to move on to the discussion of upgradeability of default modules
16:23:23 <sgallagh> Hold up
16:23:40 <sgallagh> mhroncok is correct, the vetted list is empty because we didn't include it in the first proposal.
16:24:10 <sgallagh> Proposal: For the purposes of testing, we will allow the avocado and dwm modules in the Ursa Prime buildroot
16:24:25 <jforbes> +1
16:24:31 <mhroncok> i don't understand what that tests
16:24:48 <sgallagh> 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 <mhroncok> but to be fair, I don't understand why those packages are in modules
16:25:05 <zbyszek> 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 <sgallagh> It has two streams: 52lts and 69lts
16:26:31 <sgallagh> Correction, it has 69lts and latest in current Rawhide
16:26:48 <sgallagh> Where, yes, they happen to both be at the same upstream version, but will diverge.
16:27:06 <nirik> +1 for testing
16:27:23 <bookwar> sgallagh: +1
16:27:29 <otaylor> sgallagh: +1
16:27:51 <bookwar> mhroncok: i think it tests the infra itself as well as process and lifecycle issues
16:28:01 <sgallagh> mhroncok: ^^ that
16:28:04 <jforbes> Right, fairly low risk and useful data
16:28:40 <bookwar> 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 <sgallagh> Exactly
16:29:14 <jforbes> mhroncok zbyszek ignatenkobrain votes?
16:29:34 <mhroncok> -1 I stand by my opinion that no non-modular package should depend on modular
16:29:47 <zbyszek> -1
16:29:49 <mhroncok> feel free to test this, but only if we disallow this to happen
16:30:03 <sgallagh> mhroncok: At runtime or buildtime?
16:30:05 <ignatenkobrain> -1
16:30:06 <mhroncok> any
16:30:19 <sgallagh> I think we're going to have to agree to disagree there.
16:30:27 <mhroncok> I assumed we already did
16:30:38 <jforbes> #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 <mhroncok> proposal: ask the maintainers of those modules if they want this before we do it
16:31:23 <bookwar> "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 <bookwar> we sort of need to vote on it once, but then accept the outcome and work with what comes next
16:31:43 <mhroncok> bookwar: what other optins do i have?
16:31:48 <jforbes> 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 <sgallagh> mhroncok: dwm is maintained by contyk and avocado by merlinm, both of whom are on the Modularity Team.
16:32:13 <sgallagh> So I think we're fine.
16:32:35 <mhroncok> sgallagh: thanks, that settles it for me
16:32:43 <sgallagh> np
16:32:46 <nirik> jforbes: I'd like more data from the dnf team before we decide anything there...
16:32:46 <bookwar> jforbes: we can vote on fesco blocker status
16:32:57 <bookwar> or have a break )
16:32:59 <nirik> yeah, I guess we could do that.
16:33:04 <zbyszek> yes, let's do that
16:33:18 <sgallagh> Which one are we declaring a blocker?
16:33:21 <zbyszek> that == "vote"
16:33:35 <bookwar> zbyszek: sorry for confusing everyone )
16:33:40 <jforbes> Okay proposal:  mark bug 1767351 a f32 fesco blocker
16:33:46 <zbyszek> +1
16:33:59 <bookwar> +1
16:33:59 <mhroncok> .bug 1767351
16:34:00 <zodbot> mhroncok: 1767351 – Cannot upgrade to Fedora 32: Modules blocking the upgrade path - https://bugzilla.redhat.com/1767351
16:34:05 <mhroncok> +1
16:34:15 <sgallagh> +1 (as I was in the BZ)
16:34:20 <otaylor> jforbes: +1
16:34:26 <nirik> +1
16:34:37 <jforbes> +1 here
16:34:46 <nirik> so... should it perhaps be a beta one?
16:35:02 <sgallagh> nirik: That was where it was proposed
16:35:02 <zbyszek> "I'm proposing this as a beta blocker, ..."
16:35:03 <nirik> final is probibly too late to do too much
16:35:07 <nirik> ok, great
16:35:08 <bookwar> yes, beta blocker
16:35:45 <sgallagh> jforbes: When doing the INFO, add that we declared it a beta blocker, please
16:36:55 <jforbes> ignatenkobrain: vote?
16:38:01 <jforbes> #agreed mark bug 1767351 a f32 fesco beta blocker (+7,0,-0)
16:38:17 <jforbes> #topic Next week's chair
16:38:18 <sgallagh> I'll relay this to the BZ
16:38:24 <jforbes> Thanks sgallagh
16:38:28 <sgallagh> I will be out next week for a training class
16:38:44 <jforbes> Any takers?
16:39:19 <zbyszek> I can do it.
16:39:46 <jforbes> #action zbyszek will chair next week's meeting
16:39:55 <jforbes> #topic Open Floor
16:40:02 <jforbes> (thanks zbyszek)
16:40:06 <mbooth> ó/
16:40:17 <zbyszek> I have something, but mbooth please go first.
16:40:30 <mbooth> So after that you may chuckle to yourselfs because I want default stream for eclipse
16:40:32 * mbooth ducks
16:40:33 <satellit_> https://pagure.io/fesco/issue/2267   soas spin ?
16:41:13 <mhroncok> mbooth: could you please do the change proposal that includes all the details, such as what happens to the nonmodular packages?
16:42:20 <mbooth> 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 <nirik> is the conflicts with that other module sorted out? ie, it all works modular except isn't default?
16:42:44 <mbooth> That means Eclipse is totally uninstallable because the conflicts is now baked into F31
16:43:00 <mhroncok> this is my concern: https://pagure.io/fesco/issue/2236#comment-600605
16:44:25 <mbooth> mhroncok: This is my concern: https://bugzilla.redhat.com/show_bug.cgi?id=1759176
16:45:04 <mhroncok> I uderstand your concern
16:45:34 <mhroncok> I'm worried that the way we are "fixing" the problem will create the same problem somewhere else
16:45:49 <bookwar> mbooth: it is not visible from the bz how making module default supposed to help
16:45:54 <zbyszek> I think we should delay the answer to this until we finish the discussion of default modules.
16:46:05 <otaylor> 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 <mbooth> bookwar: Because default module packages always take precendence over non-modular packages.
16:46:55 <mhroncok> -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 <mhroncok> and no, i'm not just -1 anything modular here
16:47:15 <mhroncok> I just want this coordinated properly
16:47:23 <bookwar> mbooth: why installing a module explicitly doesn't work?
16:47:26 <jforbes> mhroncok: As we discussed when this was initially brought up, the non modular packages are dead
16:47:35 <mhroncok> define dead
16:47:58 <mbooth> mhroncok: Non maintained, out-of-date, unbuildable, pick one
16:48:08 <mhroncok> and theplan is to keep tham as such?
16:48:11 <otaylor> 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 <sgallagh> bookwar: From the description, it does
16:48:16 <mhroncok> or to explicitly retire them?
16:48:55 <mhroncok> otaylor: my concerns have nothing to do with the future of default streams. my concern is about cooridnating things
16:49:06 <bookwar> 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 <sgallagh> 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 <jforbes> 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 <jforbes> AGREED: The bug about eclipse not being installable is approved as FESCo FE (+6, 0, 0)
16:49:43 <jforbes> That was from the orinigal
16:50:02 <mhroncok> sgallagh: no, it doesn't. I'm talking about f32
16:50:24 <mbooth> Yeah eclipse packages will be retired in f32, I am talking about f31
16:50:24 <otaylor> mhroncok: maybe I just don't understand your ask
16:50:26 <sgallagh> Yeah, we should probably do that in Rawhide, sure.
16:50:46 <sgallagh> But the request is for how to un-^&#* the F31 situation.
16:50:47 <mbooth> We missed the opportunity to fix the conflicts in f31 because of lack of response from releng team
16:51:05 <otaylor> mbooth: do you feel you understand what mhroncok is asking for wrt. to adding a default stream for eclipse?
16:51:24 <sgallagh> 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 <nirik> 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 <mbooth> nirik: We had three tickets, but this took longest to resolve: https://pagure.io/releng/issue/8909
16:52:24 <nirik> the two I looked at in the other ticket were finished in about 15min of you filing them
16:52:41 <mbooth> On the order of a fortnight or so
16:52:42 <nirik> ok, thats the one then...
16:53:01 <mbooth> But yeah, can't change the past :-)
16:53:24 <nirik> 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 <bookwar> mbooth: but it is fixed now? what is the current status of conflicts?
16:53:35 <mhroncok> 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 <mhroncok> are we possitive that doing that will actually make it so?
16:54:23 <mbooth> 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 <bookwar> mbooth: ok, i guess I got it now
16:54:47 <sgallagh> Trying myself now
16:55:35 <nirik> Problem: conflicting requests
16:55:35 <nirik> - nothing provides osgi(com.ifedorenko.m2e.sourcelookup) needed by eclipse-m2e-mavendev-0.3.0.201506181201-8.fc30.noarch
16:55:36 <mbooth> mhroncok: Yeah mizdebsk was able to confirm that it would fix it (as it always did)
16:56:06 <sgallagh> making it default will not fix it.
16:56:36 <mbooth> sgallagh: What makes you say that?
16:56:44 <bookwar> mbooth: we couldn't make eclipse default, because  it was conflicting with maven module, which was also default
16:57:00 <sgallagh> mbooth: Because I just tried `dnf module enable eclipse:latest` and `dnf install eclipse` and it failed
16:57:47 <mbooth> bookwar: Right! And an update to maven module removed the conflict, but I can't change the past
16:58:08 <sgallagh> mbooth: An update in stable?
16:58:10 <mbooth> sgallagh: That's because eclipse module is not default.
16:58:10 <sgallagh> Or u-t?
16:58:21 <zbyszek> 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 <zbyszek> ... is needed.
16:58:28 <sgallagh> mbooth: once it's marked "enabled" that is stronger than default
16:59:09 <mbooth> sgallagh: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-d13aabe040
16:59:11 <zbyszek> 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 <sgallagh> Oh, hang on
16:59:26 <sgallagh> It doesn't work for eclipse:latest, but it *does* work for eclipse:2019-06
16:59:32 <sgallagh> Which one were you asking to be default?
16:59:36 <mbooth> latest
16:59:53 <jforbes> zbyszek: we already agreed it would be a default once the conflicts were resolved. This is an F31 only request
17:00:16 <mhroncok> jforbes: I disagree
17:00:28 <mhroncok> "Drop the unmaintained eclipse from the non-modular repositories" hasn't happen
17:00:38 <zbyszek> 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 <jforbes> mhroncok: I just posted the FESCO decisions
17:00:44 <mhroncok> "and ship module streams of eclipse" happened
17:00:55 <mhroncok> "Whenever the conflicts are resolved later" is currently unclear
17:01:11 <zbyszek> https://paste.centos.org/view/bcb39f8f
17:01:58 <mbooth> 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 <mbooth> Hence "missing the window"
17:02:45 <jforbes> 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 <zbyszek> mbooth: sure, but I have a system with updates installed. I'm not trying to install from the DVD here.
17:03:06 <jforbes> The fact that it doesn't work right now is very relevant to this discussion however
17:03:29 <mbooth> zbyszek: Right but the DVD still provides the package that went away in the update!
17:03:34 <sgallagh> mbooth: I just confirmed that the maven u-t update does in fact resolve the situation and gave it karma
17:04:16 <nirik> --disablerepo=fedora-modular ?
17:04:23 <sgallagh> zbyszek: Add `--enablerepo=updates-testing-modular` and it works
17:04:26 <sgallagh> I just confirmed this
17:04:36 <sgallagh> We just need to get the maven update in u-t-m pushed to stable
17:04:56 <nirik> so the GA set does not break it always?
17:04:59 <mhroncok> and with the maven update
17:05:05 <mhroncok> does the ursine eclips enot install?
17:05:09 <sgallagh> nirik: If you install without updates, yes it will break
17:05:13 <mhroncok> eclipse not install?
17:06:04 <bookwar> 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 <zbyszek> sgallagh: sudo dnf install --enablerepo=updates-testing-modular eclipse ? That still doens't work.
17:06:30 <jforbes> 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 <bookwar> zbyszek: you are installing non-modular one
17:07:25 <sgallagh> zbyszek: `sudo dnf enable eclipse:latest && sudo dnf install --enablerepo=updates-testing-modular eclipse`
17:07:31 <mhroncok> is a meeting  aproper place to figure this out?
17:07:52 <zbyszek> sgallagh: this is exactly what I did.
17:08:25 <sgallagh> zbyszek: Oh, zanata-client was not in my conflicts list.
17:08:29 <sgallagh> Maybe that's contributing?
17:08:42 <bookwar> mbooth: can you update the bugzilla with the relevant info?
17:08:54 <mbooth> 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 <nirik> or a fesco ticket...
17:09:01 <mhroncok> jforbes: "The bug about eclipse not being installable is approved as FESCo FE"
17:09:13 <bookwar> it is like every time we are trying to discuss this issue we are diving in into full-scale debugging session
17:09:19 <mhroncok> yes
17:09:23 <mbooth> bookwar: https://bugzilla.redhat.com/show_bug.cgi?id=1759176
17:09:25 * sgallagh is now late for his hard stop.
17:09:34 <sgallagh> Bye
17:09:42 <jforbes> thanks sgallagh
17:09:53 <bookwar> mbooth: there is info there
17:09:56 <mhroncok> proposal: open a fesco ticket that contains the exact request and exact rationale for it
17:09:57 <mbooth> bookwar: Because no-one trusts my assessment of the situation I guess :-/
17:10:09 <mhroncok> mbooth: it's not about trust
17:10:12 <mhroncok> I just don't understand
17:10:14 <zbyszek> mhroncok: +1
17:10:48 <mhroncok> please make a proposal that we can understand
17:10:54 <bookwar> 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 <zbyszek> 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 <mhroncok> as with the original proposal, we are trying to figure all the detail ina  meeting
17:11:37 <mhroncok> as a data point: I was able to install eclipse from eclipse:latest on f31 with --enablerepo=updates-testing-modular
17:12:03 <jforbes> 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 <mbooth> 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 <zbyszek> 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 <mhroncok> mbooth: there was no request for fesco until now
17:12:50 <mhroncok> (I mean, after the first one)
17:13:11 <jforbes> mbooth: File a FESCo ticket specifically for the F31 change?
17:13:19 <bookwar> 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 <zbyszek> 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 <mbooth> So I can more detail to one of the existing tickets or file a new ticket, which do you prefer?
17:14:29 <zbyszek> mbooth: new ticket please
17:15:00 <mbooth> zbyszek: Okay I will do that
17:15:03 <jforbes> 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 <mhroncok> mbooth: thank you
17:15:25 <jforbes> Okay, moving on, I know zbyszek and satellit_ both had something.
17:15:30 <jforbes> zbyszek first?
17:15:41 <zbyszek> I'll go quickly
17:15:51 <zbyszek> .fesco 2261
17:15:52 <zodbot> zbyszek: Issue #2261: Election Interview Questions — FESCo (Fedora 31) - fesco - Pagure.io - https://pagure.io/fesco/issue/2261
17:16:18 <jforbes> +1 to reusing the old questions
17:16:18 <zbyszek> I withdraw my proposal to update, so by default FPM will continue with the old questinos.
17:16:25 <zbyszek> I hope everyone's OK with that.
17:16:25 * nirik was hoping for new questions, but ok
17:16:56 <zbyszek> nirik: we need them by the 13th ;(
17:17:22 <jforbes> nirik: perhaps focus on new questions now for the next cycle? I think we have missed this one
17:17:23 <nirik> yeah, I was hoping people would have ones they wanted answered. Oh well.
17:18:06 <jforbes> 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 <jforbes> satellit_
17:18:17 <zbyszek> Yep.
17:18:21 <satellit_> Python 2 exception: sugar desktop environment  https://pagure.io/fesco/issue/2267
17:18:21 <bookwar> 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 <mhroncok> satellit_: it seems to me that the request is incomplete
17:19:16 <bookwar> satellit_: i think we are waiting for inputs from maintainers of involved packages
17:19:42 <satellit_> pbrobinson made it....I am just a volunteer
17:20:15 <mhroncok> satellit_: what do you like to know?
17:20:30 <jforbes> 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 <satellit_> can the Python packages not get retired till resolved (delay)
17:21:06 <mhroncok> for a resoanble deadline, yes
17:21:09 <mhroncok> forever? no
17:21:14 <satellit_> k
17:21:21 <mhroncok> (my personal opinion)
17:21:42 <mhroncok> but if the maintainers re not aware fo this, they might remove their python2 packages
17:21:52 <mhroncok> the key is to talk to them
17:23:01 <jforbes> Anything else for Open Floor?
17:23:19 <jforbes> If not, closing at 25 after
17:25:00 <jforbes> #endmeeting