15:00:14 <jforbes> #startmeeting FESCO (2019-03-18)
15:00:14 <zodbot> Meeting started Mon Mar 18 15:00:14 2019 UTC.
15:00:14 <zodbot> This meeting is logged and archived in a public location.
15:00:14 <zodbot> The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:14 <zodbot> The meeting name has been set to 'fesco_(2019-03-18)'
15:00:14 <jforbes> #meetingname fesco
15:00:14 <zodbot> The meeting name has been set to 'fesco'
15:00:14 <jforbes> #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:14 <zodbot> Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:14 <jforbes> #topic init process
15:00:20 <bowlofeggs> .hello2
15:00:21 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:00:23 <contyk> .hello psabata
15:00:24 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:27 <otaylor> .hello2
15:00:28 <zodbot> otaylor: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:00:31 <mhroncok> hey
15:00:49 <bowlofeggs> bookwar: are you declaring a war on books for lunch?
15:01:07 <bcotton> .hello2
15:01:08 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:01:15 <jforbes> bowlofeggs: too much fiber
15:01:31 <bookwar> .hello2
15:01:32 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:01:33 <nirik> morning
15:01:58 <nirik> .hello kevin
15:01:59 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
15:02:19 <bowlofeggs> jforbes: heh
15:02:54 <jforbes> Looks like we have quorum, and I know a couple of people said they would be out this week, so let's get started
15:03:02 <zbyszek> .hello2
15:03:03 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:03:07 <jforbes> #topic #2071 F30 Change: Firefox Wayland By Default On Gnome
15:03:07 <jforbes> .fesco 2071
15:03:07 <jforbes> https://pagure.io/fesco/issue/2071
15:03:09 <zodbot> jforbes: Issue #2071: F30 Change: Firefox Wayland By Default On Gnome - fesco - Pagure.io - https://pagure.io/fesco/issue/2071
15:03:30 <mhroncok> let's wait for the package build?
15:03:55 * zbyszek is installing firefox-66.0-5.test.fc30.x86_64.rpm right now
15:04:01 <nirik> was there a FE bug?
15:04:28 * nirik finds it
15:04:43 <jforbes> So, I know we discussed this last week, but QE asked us to look again. It looks like those concerns are being addressed though?  All of this happened this morning
15:04:51 <mhroncok> https://koji.fedoraproject.org/koji/taskinfo?taskID=33603834
15:05:11 <bookwar> jforbes: doesn't look like addressed for me
15:05:14 <contyk> I'd rather just postpone the change (not the update) to F31
15:05:38 <nirik> the FE was accepted...
15:05:41 <jforbes> bookwar: he addressed your question
15:05:47 <bookwar> i mean we have bugs and these bugs are user-facing, and there is no chance to fix them before the release
15:05:58 <nirik> ah, I see: "The decision to classify this bug as an "AcceptedFreezeException" was made as, while we are concerned about the gnome-shell issue and the late ff66 release date here, it makes no sense to deny an FE for those reasons, but take the Change post-Beta. So we grant it an FE, but will ask FESCo if it still thinks the change should land in F30 at all given those considerations."
15:06:39 <mhroncok> I think this should go into b eta and be reverted if it "doesn't work" there
15:06:57 <mhroncok> as for what does "doesn't work" mean, I gladly leave that to QA
15:06:59 <jforbes> bookwar: I didn't say you would like the response, only that it was addressed :)
15:07:01 <otaylor> mhroncok: the only *known* bug, is the problem with screenshots and screen sharing - but that's a fairly serious one.
15:07:32 <nirik> there is also the option to just run the X version right?
15:07:50 <bookwar> nirik: but this means postponing the Change
15:07:58 <jforbes> From the mutter bug: Jep, we're on it. Unfortunately a proper fix (not a rather hacky solution like !384 (closed) and gnome-shell!341 (closed)) requires some bigger changes. The first step to look out for is !409.
15:07:58 <jforbes> This will hopefully be ready by 3.34, but will not get backported to <=3.32. So for Fedora 30 the answer is no :(
15:08:11 <contyk> nirik: yes
15:08:32 <nirik> bookwar: no, I mean users who hit that bug can just launch a X version...
15:08:36 <nirik> (if they know to)
15:08:46 <otaylor> jforbes: I'm double checking with the main mutter maintainer on that
15:09:05 <sgallagh> Sorry I'm late
15:09:07 <jforbes> nirik: I would say at the very least, it would need to be referenced in common bugs ro something
15:09:11 <bookwar> nirik: add to "known issues"?
15:09:24 <otaylor> Persoanlly, I think misbehavior when screensharing is pretty serious - the kind of thing that gets people swearing at Fedora, and probably is not something we should just assume people can workaround :-(
15:09:33 <nirik> yeah, at least... and many people won't know about it, but it is another option...
15:09:37 <contyk> to me it seemed QA didn't want to push this change in this state
15:09:53 <contyk> but since the change was approved by us, they're asking if we really want it in
15:10:00 <jforbes> contyk: that was the impression I got, which is why it is back on the agenda
15:10:08 <mhroncok> what's the real problem if we postpone
15:10:09 <contyk> I personally don't see it as something necessary and would gladly push it to f31
15:10:10 <bowlofeggs> yeah i also got that impression
15:10:27 <bowlofeggs> if QA isn't comfortable with it, i'm happy to defer to F31
15:10:35 <nirik> apparently it only affects single window... (screenshots/sharing)
15:10:51 <mhroncok> and we should stick it to f31 now so it get's better testing before f31 is happening
15:11:00 <sgallagh> nirik: Doesn't Wayland only work with single-window sharing?
15:11:01 * otaylor would sadly push it to f31 ... getting the most used app on the system to our default rendering system instead of a compat layer is *important* but not enough to risk giving users a bad impression
15:11:07 <bookwar> nirik: it might be we just don't know other issues
15:11:32 <sgallagh> Yeah, I think we need to stick with the X renderer as the default in F30 and get this right in F31
15:11:34 <nirik> true...
15:11:44 <nirik> although beta is a good way to find those. ;)
15:11:56 <mhroncok> but if this is broken in beta
15:12:00 <bowlofeggs> F31 isn't *that* far into the future too ☺
15:12:03 <sgallagh> A commblog post on how to launch the Wayland version might be good though
15:12:10 <mhroncok> and we revert it fof final, we mind hide soem other bugz
15:12:11 <sgallagh> So adventurous people can try it on F30
15:12:15 <bowlofeggs> plus, nirik runs rawhide and will sort out all it's bugs for us!
15:12:39 <bookwar> i'd say defer to 31 but heavily promote the "improved wayland support in FF" in release notes and make it easy for people to try it
15:12:46 <nirik> ha. It's been fine for me, but I don't do screenshots/sharing much
15:13:06 <zbyszek> Hmm, so with firefox-66.0-5.test.fc30.x86_64, I lost right-click menus altogether. I'll try to open some bugs as mstransky asked.
15:13:17 <bowlofeggs> proposal: defer to F31, but also advertise some way to do a "preview" of the feature for F30 users
15:13:23 <mhroncok> bowlofeggs: +1
15:13:24 <sgallagh> bowlofeggs: +1
15:13:29 <jforbes> bowlofeggs: +1
15:13:30 <nirik> well, we already have that, but sure, +1
15:13:37 <zbyszek> bowlofeggs: +1
15:13:39 <contyk> bowlofeggs: =1
15:13:42 <contyk> +1 even
15:13:45 <bookwar> +1
15:13:50 <sgallagh> nirik: "advertise" is key, I think
15:14:05 <sgallagh> devel-announce and commblog would be good, I think
15:14:09 <bookwar> we should do a sticker or smth :)
15:14:10 <otaylor> +1
15:14:46 <jforbes> #agreed Firefox Wayland by default on gnome is deferred to F31, but also advertise some way to do a "preview" of the feature for F30 users. (+8,0,-0)
15:14:48 <contyk> badges, "I tried Firefox on Wayland and..."
15:15:11 <jforbes> "all I got was this silly badge"
15:15:16 <contyk> yep
15:15:18 <bookwar> contyk: "running FF on Wayland since it wasn't mainstream"
15:15:19 <mhroncok> sgallagh: even Fedora magazine
15:15:22 <jforbes> #topic #2096 F31 System-Wide Change: BuildRequires generators
15:15:22 <jforbes> .fesco 2096
15:15:22 <jforbes> https://pagure.io/fesco/issue/2096
15:15:24 <zodbot> jforbes: Issue #2096: F31 System-Wide Change: BuildRequires generators - fesco - Pagure.io - https://pagure.io/fesco/issue/2096
15:16:11 <mhroncok> anything changed since last week?
15:16:21 * contyk looks at the latest comments
15:16:29 <jforbes> No, discussion seems to have died off.
15:16:43 <nirik> anyone know the upstream status?
15:17:16 <contyk> I don't think it's started
15:17:24 <mhroncok> AFAIK there is none
15:17:52 <contyk> they don't want to start working on it unless we give them some blanket approval now
15:18:07 <contyk> which I just don't like; although my only concern is the SRPMs, really
15:18:12 <contyk> overall I think it'd be neat
15:18:15 <jforbes> ignatenkobrain: any insight on this?
15:18:28 <nirik> well, there's a PR
15:18:31 <nirik> https://github.com/rpm-software-management/rpm/pull/593
15:19:21 <jforbes> So conary had something like this, which I really loved. But they did it by dumping a line at the end of the build with "missing buildrequires <list>" which you then had to copy/paste into the recpie
15:20:04 <contyk> well, we kinda have that with all those tools...
15:20:16 <mhroncok> proposal: we approve this, but it can only by used in Fedora, if it is still possible to query the build dependencies via dnf repoquery at least as reliable as before
15:20:29 <bookwar> i think we shouldn't vote on ideas, we should make decisions on proposals. And figuring the requirements, the scope and so on is a part of proposal creation process
15:21:02 <mhroncok> bookwar has a point
15:21:13 <nirik> bookwar: +1
15:21:31 <mhroncok> ok, scratch my proposal
15:21:56 <mhroncok> we ask ignatenkobrain to provide more details in the proposal instead
15:22:11 <contyk> that's not really new from two weeks ago
15:22:20 <contyk> he would like us to formulate some specific questions
15:22:33 <jforbes> There was also an interesting side to this, that I am not sure how it would be handled. So package foo can use features from bar and baz. That's cool and all, but you want it built without features from baz for some specific reason
15:22:34 <nirik> there's questions about srpms on the list
15:22:57 <contyk> jforbes: you should control it with build flags
15:23:11 <contyk> not just rely on whether it's in the buildroot or not; other things can pull it in
15:23:23 <jforbes> contyk: no all packages are set up that way
15:23:37 <contyk> then they should be patched, because otherwise it's just unreliable
15:23:39 <bowlofeggs> jforbes: conary also had this concept - the use flags ☺ (don't forget, i also worked at rPath ☺)
15:23:40 <jforbes> err not all
15:23:46 <mhroncok> and not all pakcages will use buildrequires generators
15:23:53 <bowlofeggs> proposal: switch fedora to use conary
15:24:04 <mhroncok> omg
15:24:06 <jforbes> bowlofeggs: yes, we we had a way to explicitly disable that
15:24:12 <zbyszek> bowlofeggs: _1
15:24:12 <bowlofeggs> (conary seriously is the best package manager i've used before ☺)
15:24:14 <jforbes> bowlofeggs +1
15:24:49 <jforbes> That's because we started with "replace rpm with something better" there was no other business plan at the beginning :)
15:24:54 <bowlofeggs> haha yeah
15:25:07 <bowlofeggs> so i'm not sure what to do with this issue
15:25:08 <mhroncok> "we shouldn't vote on ideas" -> proposal: let's use conary
15:25:12 <bowlofeggs> lol
15:25:14 <nirik> ha
15:25:43 <bowlofeggs> i like the goal of this issue
15:25:48 <mhroncok> can we say that
15:25:58 <mhroncok> like, FESCo wants this but the proposla is not ready
15:26:00 <contyk> I'd like to reject this change at this point
15:26:09 <contyk> say that we approve of the idea
15:26:11 <mhroncok> we generally agree on the idea, but we want t a detialed technical proposal
15:26:15 <contyk> we would like to see the implementation
15:26:20 <zbyszek> proposal: FESCo likes the idea in general, but will wait for an implementation to review before accepting for use in Fedora0
15:26:20 <contyk> and then they can submit a new change
15:26:28 <zbyszek> *Fedora
15:26:42 <mhroncok> zbyszek: I'm even OK to say "specification"
15:26:44 <bowlofeggs> zbyszek: +1 (and i would also invite them to ask us questions along the way if they like)
15:27:02 <jforbes> Yes, I think we can change implementation to specification there
15:27:12 <contyk> zbyszek: does it mean you'd like to leave it open?
15:27:21 <contyk> zbyszek: or would you prefer a new proposal in the future?
15:27:21 <mhroncok> (+1 either way, inclined to specification)
15:27:32 <zbyszek> OK, specification.
15:27:44 <zbyszek> Yeah, I'd leave it open.
15:27:49 <bowlofeggs> spec is fine with me too
15:27:54 <bowlofeggs> either one
15:28:19 <contyk> how often will we be revisiting the ticket? asking for a friend
15:28:36 <mhroncok> I think if this happens
15:28:45 <mhroncok> a new proposal, incl. discussion on devel must happen
15:29:03 <jforbes> So proposal: FESCo likes the idea in general, but will wait for a specification to review before accepting for use in Fedora. We will be happy to answer questions in ticket along the way
15:29:19 <zbyszek> jforbes: ack.
15:29:23 <mhroncok> jforbes: does this make the change rejected?
15:29:37 <contyk> :))
15:29:48 <mhroncok> contyk: I hear you, I on your side :D
15:29:49 <bowlofeggs> i think it does reject the change, but in a different way than typical?
15:29:54 <jforbes> mhroncok: I would say ticket is revisited (in ticket) as they ask questions. I would hate to close it because there is good discussion there already
15:29:56 <bowlofeggs> jforbes: +1
15:30:03 <zbyszek> jforbes: +1
15:30:14 <bookwar> jforbes: +1 review on updates
15:30:26 <sgallagh> +1
15:30:28 <nirik> +1
15:30:31 <zbyszek> I guess we can add "... and we encourage the submitters to reopen the ticket as soon as the specification is written."
15:30:35 <jforbes> And no, it isn't rejected, just premature and they would need to start over wit the devel thread, etc when it is ready
15:30:48 <mhroncok> +1 (I can live with that)
15:31:07 <contyk> +1; let's discuss in the meeting if there is some actual development in the ticket
15:31:24 <contyk> hopefully it won't be every week for the next six months
15:31:40 <jforbes> contyk: I would think that depends on the context of the development.  A lot of things can be addressed in ticket
15:31:48 <contyk> yes
15:32:09 <jforbes> #agreed FESCo likes the idea in general, but will wait for a specification to review before accepting for use in Fedora. We will be happy to answer questions in ticket along the way (+8,0,-0)
15:32:24 <jforbes> #topic #2104 Delay retiring of java-packages moved to module until a
15:32:24 <jforbes> solution for the (Build)Requires has been found
15:32:25 <jforbes> .fesco 2104
15:32:25 <jforbes> https://pagure.io/fesco/issue/2104
15:32:27 <zodbot> jforbes: Issue #2104: Delay retiring of java-packages moved to module until a solution for the (Build)Requires has been found - fesco - Pagure.io - https://pagure.io/fesco/issue/2104
15:32:29 <contyk> we should count the underscore votes
15:33:16 <contyk> this is kinda what I was proposing originally
15:33:30 <mhroncok> contyk: underscore votes?
15:33:36 <contyk> but our decision was to let maintainers sort it out themselves and just adopt the packages if they need them
15:33:42 <contyk> mhroncok: _1 and such :)
15:33:58 <zbyszek> So... what's the status of https://pagure.io/fesco/issue/2003?
15:34:12 <zbyszek> .fesco 2003
15:34:15 <zodbot> zbyszek: Issue #2003: Ursa Major (modules in buildroot) enablement - fesco - Pagure.io - https://pagure.io/fesco/issue/2003
15:34:30 <mhroncok> my idea was to only pospone a bit since 2003 is kinda stalled
15:34:37 <contyk> zbyszek: stalled; I'm thinking I'll try to contact the stakeholder this week and if no one responds, I'll consider it approved
15:34:40 <mhroncok> I don't want to postpone forever
15:35:01 <bowlofeggs> yeah this one is a sticky situation
15:35:03 <contyk> zbyszek: stakeholders - modularity, infra, epel, more or less
15:35:20 <mhroncok> package maintainers maybe?
15:35:31 <bowlofeggs> packages that are assigned to orphan don't have anyone to get notified when there are CVEs
15:35:32 <bookwar> i missed the beginning of this story, thus i don't understand, so when module comes into buildroot the package would be unorphaned? so package actually has maintainers they just not willing to support packages outside of module?
15:35:47 * nirik looks for the proposal there.
15:35:49 <contyk> mhroncok: I can't ask every single person, so I have specific people from those groups in mind
15:35:53 <sgallagh> General question for bowlofeggs: Can modular RPMs be passed to the Bodhi overrides?
15:36:08 <sgallagh> Can we use that as a workaround for now? Just ask someone to add your deps to the buildroot overrides?
15:36:15 <bowlofeggs> bookwar: yeah the packages got moved into modules, so the "old school" rpms are orphaned and unmaintained now
15:36:20 <jforbes> nirik: I think that is the problem, there isn't one, and it needs one
15:36:42 <bowlofeggs> sgallagh: i don't know modules to have a concept of buildroot overrides
15:36:57 <bowlofeggs> sgallagh: it definitely wouldn't work to use bodhi to get a module to be a BRO for an rpm
15:36:59 <sgallagh> bowlofeggs: We're not talking about modules right now
15:37:01 <contyk> no reason they couldn't with this proposal
15:37:04 <sgallagh> Sort of
15:37:09 <bowlofeggs> because the module koji tags dont' line up with the rpm koji tags
15:37:17 <sgallagh> bowlofeggs: We're talking about the non-modular buildroot. (Aren't we?)
15:37:48 <bowlofeggs> sgallagh: yeah, but are you asking if a module can be put as an override into a non-modular buildroot?
15:37:51 <bowlofeggs> or something else than that?
15:38:09 <contyk> which could work fine, btw
15:38:14 <sgallagh> bowlofeggs: I'm asking if we could pass e.g. nodejs-10.15.2-1.module_f29+3183+841ebc3d as a buildroot override and have it show up in the buildroot for non-modular builds?
15:38:20 <contyk> but bowlofeggs would need to assess whether it requires bodhi changes
15:38:21 <bookwar> can we ask nicely maintainers of java module to not abandon the non modular part yet? does it add too much work for them to support additional non-modular version together with a modular one? do they even aware that this is such a big deal?
15:38:28 <sgallagh> I'm not asking for the whole module right now, just individual RPMs built from a module
15:38:40 <nirik> contyk: where is the proposal again? I'm having trouble finding it in that ticket... but I thought there was one.
15:38:44 <mhroncok> sgallagh: even if that wokrs, you can break stuff
15:38:49 <bowlofeggs> sgallagh: if you are certain that koji would be ok with that, i suppose it could be done in theory
15:38:50 <smooge> bookwar, the person is aware and it is a lot of work for them.
15:39:00 <bowlofeggs> in practice, it would require a little research
15:39:05 * sgallagh nods
15:39:06 <bowlofeggs> miiiight need some changes
15:39:10 <bowlofeggs> also, might not?
15:39:12 <mhroncok> AKA how would I know if somebody else submitted an override for nodejs 13 instead of nodejs 11 and now my package builds for a different version
15:39:14 <contyk> nirik: https://pagure.io/fesco/issue/2003#comment-556140
15:39:33 <bowlofeggs> i mean, if we can just set the tags for BROs in module releases to the regular release's BRO tag, it might just work?
15:39:39 <contyk> mhroncok: we could check for that
15:39:42 <bowlofeggs> i don't know enough about modules to speak for that side ofit
15:39:46 <nirik> ah ha. it's a doc. now I recall.
15:40:01 <bookwar> smooge: ok, thanks for clarification
15:40:43 <bowlofeggs> sgallagh: do you know for sure if putting a module into the buildroot of a regular rpm works?
15:40:48 <contyk> smooge: I think you had questions what exactly I wanted you to sign off :)
15:41:01 <bowlofeggs> *regular rpm koji tag
15:41:05 <contyk> smooge: so it's basically just the idea how to move forward, what we discussed at DevConf and what the document summarizes
15:41:07 <smooge> yes. the document has nothing to say what I am agreeing to
15:41:09 <mhroncok> contyk: and the state of this proposal is: something to vote on, or wait for the mentioned stakeholders first?
15:41:10 <sgallagh> bowlofeggs: RPMs built as part of a module are not really any different than RPMs built outside them
15:41:29 <sgallagh> bowlofeggs: And yes, Ursa Major proves that this does work
15:41:50 <bowlofeggs> sgallagh: isn't a module a collection of RPMs though, and not just a single RPM? or am i misunderstanding?
15:41:55 <contyk> mhroncok: the proposal requires changes in koji and MBS; I was hoping all parties involves in the plan could agree that this is the way to do it before we start changing everything
15:42:10 <bowlofeggs> i.e., what happens if i put the override tag for f29 onto a module in koji? will that Just Work™?
15:42:16 <nirik> contyk: +1 from me on that proposal... would need koji work and releng work (to compose those modules)?
15:42:37 <sgallagh> bowlofeggs: No, what I was asking about was just sticking those tags on the produced RPMs
15:42:43 <sgallagh> Which are separate objects in Koji
15:42:49 <bowlofeggs> sgallagh: ah ok - so that would require changes then
15:42:54 <contyk> nirik: it would need koji work (create koji repos from multiple sources) and compose work (create small composes with default modules)
15:42:56 <sgallagh> bowlofeggs: Why?
15:42:57 <bowlofeggs> bodhi isn't aware of the rpms inside a module currently
15:43:09 <sgallagh> I think you're completely missing my point.
15:43:13 <bowlofeggs> so it would need to know how to find them so it could tag them
15:43:15 <bowlofeggs> oh?
15:43:28 <nirik> contyk: we could also publish the small modules thing... so mock / users could use it if desired too
15:43:29 * contyk is probably also missing sgallagh's point
15:43:34 * mhroncok grabs popcorn
15:43:35 <sgallagh> Bodhi wouldn't have to be. The maintainer would look at which RPMs got listed and ask Bodhi to tag them individually.
15:43:38 <contyk> nirik: yes
15:43:39 <bowlofeggs> i def don't feel like i understand how modules work still…
15:43:39 <smooge> sgallagh, I think you are trying to have a detailed conversation in a meeting with a lot of distractions..
15:43:41 <sgallagh> (or, ideally, in some batched way)
15:44:10 <smooge> sgallagh, and you need pictures for what you are trying to describe
15:44:13 <nirik> bowlofeggs: he's suggesting that each rpm be added manually instead of the entire module. That seems like a lot of work to me...
15:44:22 <sgallagh> Anyway, it's probably not worth continuing. We have a pretty good idea how we want to solve this long-term
15:44:28 <bowlofeggs> sgallagh: ah, bodhi doesn't let maintainers just tag any builds in koji as overrides - it needs to know which release the builds are in
15:44:32 <sgallagh> I was looking for a short-cut
15:44:39 <bowlofeggs> sgallagh: so bodhi will try to find the release fro those, and will fail to do so
15:44:45 <sgallagh> ok
15:44:48 <jforbes> Right, so the problem is the short term where things are about to explode
15:44:53 <bowlofeggs> because it doesn't know abotu the rpms inside of modules, it only knows abotu the modules
15:45:21 <ignatenkobrain> .hello2
15:45:21 <sgallagh> bowlofeggs: Right, if it depends on nodejs-10.15.2-1.module_f29+3183+841ebc3d having the f30-candidate tag, that's not going to work
15:45:21 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:45:33 <mhroncok> is there a reasonable timeframe the get out of this clusterfuck?
15:45:56 <mhroncok> if yes, we shall pospone the retirement
15:46:06 <bowlofeggs> sgallagh: yeah, i think it would need some changes in order for that idea to work, and to nirik's point it might also be a lot of work
15:46:07 <contyk> mhroncok: not for f30, no
15:46:13 <mhroncok> if not, a lot of maintainers will be sad/angly/etc. abotu Fedora nad possibly leave
15:46:20 <bowlofeggs> (work for the packager, not necessarily for me)
15:46:35 <mhroncok> contyk: f30 is of the retirement hook
15:46:57 <bowlofeggs> i feel conflicted abotu the proposals here
15:47:06 <contyk> which ones?
15:47:17 <bowlofeggs> i really don't like the idea of so many packages being unmaintained, especially since they tie to very important things like IPA
15:47:29 <bowlofeggs> the proposal to just let them stay unmaintained
15:47:45 <bowlofeggs> open source only works when people do the work
15:47:46 <contyk> regarding IPA, there is a change it will be converted to a module
15:47:51 <jforbes> I at least think someone needs to take responsibility for the CVEs
15:47:56 <contyk> which means this problem wouldn't matter to them
15:47:57 <nirik> how about we make a sig and give it all these packages, then it can retire them when the solution is ready
15:48:17 <nirik> but of course who will be in the sig?
15:48:23 <mhroncok> how does that differ?
15:48:24 <bowlofeggs> nirik: do we have volunteers for the SIG though
15:48:32 <bowlofeggs> there is that devel list proposal to make the stewardship SIG
15:48:34 <mhroncok> orphaned packages are maintained by "all"
15:48:43 <contyk> you mean the thread from February which died off like six weeks ago?
15:48:50 <nirik> mhroncok: no, I don't think so... they are maintained by none
15:48:55 <bowlofeggs> (and maintained by "all" is not so different from maintained by "none" ☺)
15:49:07 <bowlofeggs> contyk: hah, yesh
15:49:16 <nirik> how many of you read/fix/answer bugs assigned to orphan user? :)
15:49:20 <otaylor> it would need to be clear that the charter of the sig is to simply bridge the gap ... not be devuan-for-modules
15:49:22 <bowlofeggs> i never have
15:50:03 * nirik knows very little of java, so not sure I would be of much help with it.
15:50:17 <jforbes> I would be happy if we just had a way to handle CVEs there. Ignore all bugs that are not security related.
15:50:19 * bowlofeggs used to be a java programmer and doesn't ever look back
15:50:21 <bowlofeggs> hahaha
15:50:25 <bookwar> would maintaining it just be porting changes from a module?
15:50:31 <jforbes> At least then we are not exposing users
15:50:33 <mhroncok> nirik: I do when the bug blocks me from building my package
15:50:38 <contyk> bookwar: I think so
15:50:53 <contyk> unless they already differ significantly
15:50:59 <bowlofeggs> jforbes: FTBFS shoudl probably also be fixed, but i think i'm with you on that
15:51:18 <bowlofeggs> bookwar: not sure - sgallagh do you know?
15:51:30 <nirik> things that prevent large numbers of other packages from working would be in scope too I would think, or it would just be the same as dropping it
15:51:36 <sgallagh> bookwar: Theoretically, yes.
15:51:38 <jforbes> bowlofeggs: probably, but we are talking about the F30 cycle, a short timeframe, not indefinitely
15:51:59 <mhroncok> those packages won't get retired from f30
15:51:59 <bowlofeggs> jforbes: oh i thought we were just talking about rawhide here
15:52:04 <sgallagh> Part of the point of modules (rather than SCLs) is that the RPMs produced end up in the same places and such as standard RPMs
15:52:05 <bowlofeggs> isn't it past the date for F30?
15:52:05 <zbyszek> mhroncok: what about amending your proposal to "delay the retirement process until two weeks after F30 is release"
15:52:21 <mhroncok> there is a confusion
15:52:36 <mhroncok> what has anything here to do with f30?
15:52:39 <smooge> the packages are to be retired from F31
15:52:43 <smooge> not F30
15:52:44 <jforbes> bowlofeggs: yes, but the long term solution is supposed to happen in the f30 cycle timeframe
15:52:59 <mhroncok> is it?
15:53:02 <smooge> is it?
15:53:07 <mhroncok> :D
15:53:10 <contyk> hopefully!
15:53:23 <smooge> you have 4 weeks?
15:53:24 <jforbes> I thought so (F30 timeframe meaning F31 devel timeline)
15:53:24 <contyk> I'd really to move forward with that proposal
15:53:27 * nirik thought they were going to be retired from f30 too.
15:53:45 <mhroncok> I don't retire orphaned packages after beta freeze
15:53:50 <bowlofeggs> i think it's too late to retire things in F30
15:54:01 <bowlofeggs> so i think F30 will be "safe" (except that nobody will maintain the CVEs)
15:54:10 <bowlofeggs> (so maybe not so safe)
15:54:16 <jforbes> bowlofeggs: the exact opposite of "safe"
15:54:19 <bowlofeggs> haha yeah
15:54:48 <bowlofeggs> proposal: this is not an easy problem
15:55:17 <jforbes> We created this problem though, we need to find a solution
15:55:27 <contyk> it's sad people don't want to take ownership of their build deps, even for just one cycle or so
15:55:49 <nirik> some did... not sure how many are left really
15:55:52 <smooge> contyk, most of these people feel they are already overmaxed with their packages
15:56:01 <sgallagh> It's also kind of maddening that the Java folks made these changes without considering the rest of the Project
15:56:14 <jforbes> sgallagh: +1
15:56:28 <smooge> saying "oh just take it for one more release" is like saying "Hey drowning man, just take this stone"
15:56:53 <bookwar> how about we get the updated list of packages with exact link who depends on them. And publish it again on th ML
15:56:59 <bookwar> and community blog
15:57:02 <zbyszek> bookwar: this was done today
15:57:09 <mhroncok> bookwar: I put it every week on the ML
15:57:13 <mhroncok> I cc the miantinars
15:57:16 * bookwar missing everything
15:57:17 <smooge> bookwar, read devel-list for subject orphan
15:57:17 <mhroncok> they are scared
15:57:19 <contyk> he does indeed
15:57:23 <mhroncok> they cannot maintain java stuff
15:57:39 <bookwar> mhroncok: no one can maintain java stuff, it is java
15:57:41 <mhroncok> they have enough of their own packages
15:58:13 <mhroncok> orphaning this at this scale feels a lot like blackmailing Fedora to allow modules in buildroot TBH
15:58:15 <nirik> well, can we vote at least on the proposal contyk had and start moving that forward...
15:58:15 <smooge> the same thing would happen if python went module only
15:58:22 <smooge> or perl
15:58:39 <nirik> then perhaps we can get a better idea how long it might take from koji/mbs/releng and see what we can do in that timeframe?
15:58:41 <bowlofeggs> yeah java is harder than many languages
15:58:44 <smooge> a lot of things which are not java rely on maven as a build facter
15:58:56 <bowlofeggs> i used to be a java person, and did the java stack for rPath - everything depends on everything in java
15:58:59 <bowlofeggs> it's NUTS
15:58:59 <mhroncok> we deal with python2 removal slowly and try not to break things, maybe instead we should put it in the module and orphan it
15:59:03 <bowlofeggs> log4j is EPIC
15:59:28 <contyk> nirik: how about I schedule a call where a couple of us review it again and agree on the next implementation steps? before the next meeting
15:59:46 <smooge> contyk, I would like that and then I can probably sign off
15:59:53 <sgallagh> contyk: +1
15:59:54 <contyk> smooge: thanks
15:59:59 <nirik> if you like. It seems reasonable to me, I thought I sent a +1 before. ;)
16:00:18 <contyk> nirik: yeah but you were in a minority ;)
16:00:18 <bowlofeggs> contyk: i'd join a call like that
16:00:22 <jforbes> contyk: +1
16:00:26 <sgallagh> nirik: If smooge (who may have to help implement it) doesn't understand it, I'm all for having another meeting to explain it
16:00:34 <contyk> ack, I'll schedule something this week then
16:00:43 <zbyszek> contyk++
16:00:43 <zodbot> zbyszek: Karma for psabata changed to 14 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:00:47 <smooge> see that is the part I wasn't clear on.. was it me doing the work or someone else?
16:00:57 <bookwar> I am plus one for a SIG, if not fixing on our own, porting modular changes, the responsibility of the SIG would be also to ping Java module devs to help with particularly urgent thing
16:01:04 <sgallagh> smooge: There's probably a dividable set of work
16:01:17 <sgallagh> Let's figure that out on the call and not in this meeting
16:01:23 <smooge> understood
16:02:09 <jforbes> #info This is postponed, there will be a call set up to further discuss details on a longer term solution
16:02:11 <bowlofeggs> maybe since we are so powerful as FESCo, we can just order someone to maintain these packages!
16:02:12 <nirik> I think it's koji devs / mbs devs / releng and a tiny bit infra (to update koji/mbs, etc)
16:02:13 * bowlofeggs runs
16:02:14 <mhroncok> so, what about the delay?
16:02:33 <mhroncok> if we postpone this, shall we retire the packages in 2 weeks?
16:02:43 <bowlofeggs> i'm ok with a brief delay, at least until we have a plan
16:02:43 <zbyszek> mhroncok: no, let's wait
16:02:50 <jforbes> mhroncok: discuss it again after the call?
16:03:17 * contyk has to go afk, mostly
16:03:32 <mhroncok> zbyszek: if wait is what we do, I need it in writing
16:03:54 <bookwar> the call is about module in buildroot? and it won't affect f30?
16:04:12 <zbyszek> mhroncok: I'm voting +1 to your proposal in the ticket now
16:04:30 <jforbes> proposal: Delay retiring of java-packages is postponed a week until more information can be gathered on longer term solution and timeline.
16:04:45 <nirik> +1
16:04:56 <zbyszek> Can we make it 4 weeks like in the proposal?
16:05:13 <bowlofeggs> jforbes: +1
16:05:29 <mhroncok> a week makes no difference
16:05:31 <jforbes> zbyszek: What if it is 6 or 8? We aren't voting on the ticket at all, we are punting the ticket until we have more information
16:06:12 <zbyszek> Well, the retirement date is 2 weeks from now, so strictly speaking, we don't need to extend anything atm.
16:06:14 <jforbes> The week is not an approved delay of retiring, it is a delay of making a decision on that delay
16:06:40 <jforbes> I just want to punt the ticket until we have more info
16:06:59 <zbyszek> jforbes: "Delay ... is postponed", I was confused
16:07:11 <zbyszek> jforbes: +1
16:07:13 <bookwar> jforbes: +1
16:07:22 <jforbes> which is exactly why I used postponed instead of delay
16:07:30 <jforbes> Though yes, it is confusing
16:07:43 <mhroncok> I'm concerned that if we pospone our decision by a week
16:07:57 <mhroncok> it is possible that we are unable to make a decision before the dealine hits us
16:08:01 <mhroncok> *deadline
16:08:42 <jforbes> We have 2 weeks right?
16:08:51 <zbyszek> mhroncok: but you can wait with the orphaning after the next fesco meeting, no?
16:09:12 <mhroncok> by policy we have one
16:09:26 <mhroncok> I say 2 in the email, because I actually retire when it says 7 weeks
16:09:37 <jforbes> Well, that just seems wrong
16:09:54 <mhroncok> I can probably wait forever, but that's not the solution, is it
16:10:21 <mhroncok> jforbes: it is probably wrong, but i don't trust that script entirely, so I do it to better be safe than sorry
16:10:27 <nirik> proposal: do no retirements until after next fesco meeeting.
16:10:32 <zbyszek> nirik: +1
16:10:39 <mhroncok> nirik: +1
16:10:55 <bowlofeggs> nirik: +1
16:10:55 <jforbes> No, it is not. But coming up with some arbitrary number today isn't a solution either, we need the information that should come out of that call to make the right determination
16:10:59 <jforbes> nirik: +1
16:11:17 <otaylor> nirik: +1
16:12:05 <jforbes> #agreed Delay retiring of java-packages, do no retirements until after next fesco meeeting (+6,0,0)
16:12:22 <jforbes> #topic #2106  Activate "issues" on src.fedoraproject.org
16:12:22 <jforbes> .fesco 2106
16:12:22 <jforbes> https://pagure.io/fesco/issue/2106
16:12:24 <zodbot> jforbes: Issue #2106: Activate "issues" on src.fedoraproject.org - fesco - Pagure.io - https://pagure.io/fesco/issue/2106
16:13:17 <jforbes> I am not in favor of this personally, and agree with the issues that nirik brought up
16:13:22 <sgallagh> Is there any way we could get pingou to make "issues" just report a BZ? :)
16:13:41 <mhroncok> I agree with nirik, yet I'd be happy to have the ability to use it internally
16:13:41 <sgallagh> Or at least change the "issues" tab header to redirect to BZ?
16:13:42 <nirik> possibly? sounds like a good RFE
16:13:49 <pingou> sgallagh: that'd be a quite ugly hack, very Fedora-specific
16:14:05 <sgallagh> pingou: You don't need to repeat yourself. ;-)
16:14:17 <sgallagh> (Fedora and ugly hack)
16:14:28 <mhroncok> having issues in the tests namespace on the other hand :)
16:14:31 <pingou> we could hack the template to send/link to bugzilla
16:14:33 <sgallagh> pingou: Sure, but what about the issue tab redirecting?
16:14:41 <sgallagh> That could be fairly generic.
16:14:55 <cverna> in the container namespace it would be nice to have the issues in pagure, we currently don't have BZ for container images
16:14:55 <sgallagh> "Third-party ticket tracker URL" opiton
16:14:55 <pingou> easy for rpms, I'd have to check for the other namespaces
16:15:55 <nirik> cverna: ? we do I thought...
16:16:13 <cverna> nirik: for the base image only I think
16:16:23 <nirik> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20Container%20Images
16:16:40 <nirik> there are a bunch there...
16:16:42 <cverna> oh ok then not many people use it :P
16:16:49 <bowlofeggs> i also don't like the idea of yet-another-ticket-tracker
16:16:50 <sgallagh> Anyway, if it wasn't clear, I'm opposed to adding an extra tracker for src.fp.o
16:16:51 <nirik> thats likely true. :)
16:16:54 <cverna> for other container than the base image
16:17:05 <bowlofeggs> i wouldn't mind using it *instead* of bugzilla, but that would be a significant change
16:17:12 <bowlofeggs> lots of integrations would break
16:18:35 <nirik> right
16:19:00 <sgallagh> bowlofeggs: If that's something we want to consider, we can, but that needs planning, coordination and probably is an Objective-level task
16:19:15 <bowlofeggs> proposal: reject the ticket - fesco doen't want there to be more than one source of truth for issues with packages
16:19:23 <zbyszek> bowlofeggs: +1
16:19:25 <sgallagh> bowlofeggs: +1
16:19:29 <jforbes> bowlofeggs: +1
16:19:36 <bowlofeggs> sgallagh: to be clear, i'm not proposing that - we don't have the resources to do that at this time
16:19:36 <mhroncok> +1 (sad, but true)
16:19:42 <otaylor> bowlofeggs: +1
16:20:10 <bookwar> +1, and ask pingou to add thrid-party tracker link and third-party docs site for src.fp.org
16:20:19 <sgallagh> We *can* make this source of truth better linked from src.fp.o and I'll keep chatting with pingou outside this meeting about how we might do it
16:20:47 <mhroncok> good
16:20:55 <cverna> there is already a link to bugzilla in src.fp.o
16:21:07 <jforbes> #agreed Activate "issues" on src.fedoraproject.org is rejected, fesco doesn't want there to be more than one source of truth for issues with packages (+7,0,-0)
16:21:25 <jforbes> #topic Next week's chair
16:22:01 <cverna> ha no it links to https://apps.fedoraproject.org/packages/ bugs
16:22:16 <jforbes> Any takers?
16:22:40 <sgallagh> I'll be on PTO next Monday, but as I haven't done it in a while, I'll pick up April 1
16:22:50 <sgallagh> (no joke)
16:23:05 <jforbes> thanks
16:23:10 <jforbes> Anyone for next week?
16:23:16 <mhroncok> I'll be on pycon sk until very late Sunday, I can run the meeting, but not send the announcments before etc.
16:23:28 <zbyszek> I can do it.
16:23:28 <mhroncok> if somebody sends the agenda, i can run it
16:23:38 <jforbes> thanks zbyszek
16:23:42 <bowlofeggs> zbyszek++
16:23:44 <mhroncok> zbyszek++
16:23:54 <jforbes> #action zbyszek will chair next meeting
16:24:03 <jforbes> #topic Open Floor
16:26:29 <jforbes> Anyone have anything? If not I will close out in 2 minutes
16:28:07 <mhroncok> thanks jforbes
16:28:26 <zbyszek> thanks jforbes
16:28:28 <jforbes> #endmeeting