17:00:13 <sgallagh> #startmeeting FESCO (2022-09-13)
17:00:13 <zodbot> Meeting started Tue Sep 13 17:00:13 2022 UTC.
17:00:13 <zodbot> This meeting is logged and archived in a public location.
17:00:13 <zodbot> The chair is sgallagh. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:13 <zodbot> The meeting name has been set to 'fesco_(2022-09-13)'
17:00:13 <sgallagh> #meetingname fesco
17:00:13 <sgallagh> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, music, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:00:13 <sgallagh> #topic init process
17:00:13 <zodbot> The meeting name has been set to 'fesco'
17:00:13 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mhayden mhroncok music nirik sgallagh zbyszek
17:00:21 <sgallagh> .hi
17:00:22 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:00:24 <mhroncok> .hello churchyard
17:00:25 <Eighth_Doctor> .hi
17:00:25 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:00:28 <zodbot> Eighth_Doctor: Sorry, but user 'Eighth_Doctor' does not exist
17:00:39 <Eighth_Doctor> .hello ngompa
17:00:40 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:00:59 <mhayden> .hi
17:01:00 <zodbot> mhayden: mhayden 'Major Hayden' <mhayden@redhat.com>
17:01:03 <music[m]> .hello music
17:01:04 <zodbot> music[m]: music 'Benjamin Beasley' <code@musicinmybrain.net>
17:01:27 <sgallagh> That's quorum, but I'll wait a couple more minutes for others to file in
17:01:29 <nirik> morning
17:03:27 <bcotton> .hello2
17:03:28 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:04:19 <sgallagh> #topic #2865 Change: Strong crypto settings: phase 3, forewarning 2/2
17:04:19 <sgallagh> .fesco 2865
17:04:22 <zodbot> sgallagh: Issue #2865: Change: Strong crypto settings: phase 3, forewarning 2/2 - fesco - Pagure.io - https://pagure.io/fesco/issue/2865
17:05:23 <sgallagh> There hasn't been much chatter on this since last week, but I think we need to make a decision
17:05:28 <decathorpe> .hi
17:05:29 <zodbot> decathorpe: decathorpe 'Fabio Valentini' <decathorpe@gmail.com>
17:05:45 <nirik> I guess one question is if the change owners would be willing to not do the 'jump scare' thing?
17:06:16 <sgallagh> nirik: Not doing the jump scare just pushes the problem out until it hits users.
17:06:25 <decathorpe> still. I don't like the "enable it in prod see what breaks" part
17:06:43 <nirik> sure, but it seems... more honest?
17:06:44 <sgallagh> It has been enabled in Fedora ELN since around April
17:07:05 <decathorpe> Have we ever done that for any other change?
17:07:15 <sgallagh> Fabio Valentini: systemd?
17:07:29 <decathorpe> oh in the old days 👴
17:07:35 <mhayden> some of the issues with it could appear during package builds (if tests are enabled), but otherwise, the only way you know is to turn it on and see what doesn't work
17:07:45 <sgallagh> Exactly
17:07:55 <mhayden> i run into this a lot when i backport to EPEL
17:08:28 <sgallagh> So either we break a few developers (who know what they're doing and how to switch back to the old policies) or we wait and break hundreds of users.
17:08:32 <mhayden> i'm not sure if "jump scare" is the best term for this, but the idea of "let's enable it because we know we need to and try to sort out what breaks" sounds reasonable to me
17:08:35 <sgallagh> One of these seems wiser to me than the other...
17:08:45 <nirik> well, there's still a pretty long runway
17:08:59 * decathorpe reserves the right to say "I told you so" but won't block it
17:09:19 <sgallagh> Fabio Valentini: We *know* things will break. That's the whole point.
17:09:28 <mhroncok> what is the position of folks who haven't voted yet?
17:09:51 <nirik> also, the time period isn't great... it will be over the holidays a fair bit...
17:10:00 <sgallagh> We are (+1, 0, -2) in the ticket
17:10:02 <nirik> I'm leaning toward -1...
17:11:15 <music[m]> Coming into the meeting, my feeling is that it will be ugly both ways, but as a packager I would rather have the possibility of getting bug reports earlier and having more time to start pestering my upstreams, or planning to give up and retire the package. The active development window for a single Fedora release goes by fast, compared to the rate at which a lot of upstreams  move. So I would say I’m in favor unless somebody
17:11:15 <music[m]> changes my mind.
17:11:27 <nirik> If we do the jump scare we get now -> feb... if we don't, f39 gets feb -> aug
17:11:36 * mhayden put a +1 in the ticket
17:11:40 <sgallagh> incorrect
17:11:49 <sgallagh> If we do the jump scare, we get now->aug.
17:12:07 <nirik> sure. with most of december with no one around, thanksgiving, new year...
17:12:37 <music[m]> A lot of slow-moving upstream hobby projects only update over the holidays.
17:12:45 * nirik would also feel better if it was 'if we solve the problems we just land it in f38, otherwise we revert'
17:12:48 <sgallagh> nirik: That's a time period that has fewer developers but more testing going on, in my experience
17:13:23 <sgallagh> Part of the problem is that we can't solve all the problems.
17:13:34 <nirik> well, can we ever? ;)
17:13:47 <sgallagh> The point of doing a jump-scare is partly to make sure that problems get reported to OTHER projects that still rely on SHA-1
17:14:10 <sgallagh> Which may (probably will) include closed-source projects.
17:15:30 <nirik> developers/interested folks can test now with the TEST-FEDORA39 policy also
17:16:51 <sgallagh> Which I've been doing and have already found a couple problematic services, (that was behind my kerberos woes last week; I didn't realize the host policy was leaking into my containers)
17:17:15 <nirik> would anyone (besides me) support:
17:18:23 <nirik> drop the 'jump scare' name/term, and rework this as a f38 change. Before the beta freeze, fesco looks and decides if it needs contingency triggered (ie, reverting it). If not, it's just f38, if so, it's reverted and becomes a f39 change?
17:18:47 <sgallagh> As that's functionally identical, I'm okay with that.
17:19:31 <nirik> I really don't like 'jump scare' I think it will frighten people... and it seems more honest to try and land the change and if it's not working well enough revert it than to just plan to fail.
17:19:46 <mhroncok> I still don't like this but I lack a better idea
17:20:08 <nirik> shall I suggest that on the devel thread or in the fesco ticket? probibly devel?
17:20:29 <sgallagh> I do wonder if we should allow it to remain in the Beta release though, if only to get more testing
17:20:42 <sgallagh> And allow it to be relaxed for Final
17:21:24 <bcotton> it would take some convincing for me to be okay with that
17:21:29 <music[m]> I’m OK with nirik’s suggestion, assuming the change owners are prepared to move up the F39 part of the change if things go well. It’s really a more aggressive version of the change with less aggressive marketing.
17:22:09 <music[m]> I don’t think I like reverting after beta, because it interferes with testing other functionality of updates that may have been blocked on crypto breakage.
17:22:50 <sgallagh> OK, I suppose I can see that.
17:23:18 <sgallagh> I'd really like to see the Beta announcement include instructions on enabling TEST-FEDORA39 though
17:23:33 <nirik> I think a test day or two would be great for that.
17:24:50 <nirik> also, I wonder: can we get openqa to set it and run a second test on things?
17:24:55 <sgallagh> nirik: Can you take that pitch back to devel@ and see how asosedkin and others feel about it?
17:24:58 <nirik> but thats going to need a lot more capacity
17:25:37 <nirik> sure, I can
17:25:41 <sgallagh> Thanks
17:25:59 <sgallagh> #action nirik to bring proposal back to the devel list
17:26:24 <music[m]> Thanks, nirik.
17:26:30 <sgallagh> nirik++
17:26:30 <zodbot> sgallagh: Karma for kevin changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:26:30 <sgallagh> #topic #2863 Change: libsoup 3: part two
17:26:30 <sgallagh> .fesco 2863
17:26:34 <zodbot> sgallagh: Issue #2863: Change: libsoup 3: part two - fesco - Pagure.io - https://pagure.io/fesco/issue/2863
17:26:35 <mhroncok> nirik++
17:26:36 <zodbot> mhroncok: Karma for kevin changed to 11 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:26:41 <music[m]> nirik++
17:26:56 <sgallagh> mmm... soup...
17:27:26 <decathorpe> I already retired ~50 packages because of this fiasco so I'm not really sure I can be impartial here
17:28:19 <sgallagh> Retired or orphaned?
17:28:34 <mhroncok> retired
17:28:35 <decathorpe> I meant what I said.
17:29:22 <music[m]> As I understand this, upstream has put us in a bad situation: major API breakage is tied up with security fixes, the two versions can’t be linked from the same executable, and porting is not at all trivial.
17:29:29 <music[m]> https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html
17:30:17 <nirik> I think the change owner seemed open to changing things... but hasn't yet?
17:30:35 * nirik rereads
17:31:27 <nirik> I like mhroncok's outline...
17:31:31 <sgallagh> The only change I see is being willing to go the `deprecated()` route
17:33:14 <Eighth_Doctor> I'm personally a bit disappointed that upstream put us into this situation
17:33:25 <Eighth_Doctor> but that's more like screaming into the void :(
17:33:32 <Eighth_Doctor> I don't know how we can resolve this
17:34:34 <decathorpe> Yeah, it's especialy bad for applications that use some gnome libraries which were already ported and some that weren't yet.
17:34:39 <music[m]> I see how this is more urgent in some ways than the usual deprecation situation (joins in pointing fingers at upstream), but I agree with comments in the issue that a “motivating deadline” will pressure people who can’t do anything about it, given the changes are too drastic for a downstream maintainer to offer a patch in most cases.
17:35:49 <sgallagh> Perhaps we request that the Change Proposers offer one or more virtual hackfests to help projects port their code?
17:35:59 <music[m]> I think that if a proposal that involved retiring libsoup2 along with all remaining dependent packages were to be considered, it would only be reasonable to expect the change owner to list exactly what those packages are, and what packages should be considered “must-port,” i.e., regardless of who does the work, the retirement can’t proceed until they are ready.
17:36:11 <Eighth_Doctor> also, something that bothers me here: why is it that libsoup2 and libsoup3 can't be linked in the same app?
17:36:31 <sgallagh> I'm guessing symbol collisions
17:36:32 <music[m]> I think they broke ABI but re-used some of the symbol names.
17:36:34 <mhroncok> I think it's a namespace clash
17:36:43 <sgallagh> Like we had for libmodulemd 1 and 2
17:36:58 <Eighth_Doctor> unlike libmmd, libsoup is used everywhere... :/
17:37:19 <sgallagh> Yes, but it's a difference in scale, not in kind
17:38:02 <decathorpe> A hackfest can only do so much ... it won' t help upstream projects that are no longer active
17:38:18 <nirik> so what should we do here? reject this as written and suggest options to resubmit?
17:38:32 <Eighth_Doctor> well, they poison-pilled this Change
17:38:33 <sgallagh> Maybe upstream projects that are no longer active should be retired?
17:38:42 <Eighth_Doctor> if we don't accept it, they're going to retire the stack anyway
17:39:11 <nirik> well, we can unretire it... or anyone can...
17:39:14 <Eighth_Doctor> we kind of don't have a choice here, because the alternative is them gutting it anyway
17:39:48 <sgallagh> I would point out too that we're talking about a Red Hat sponsored team: chances are high that they're going to do much of the porting work (at least for those packages likely to be of importance to RHEL and maybe EPEL)
17:40:09 <Eighth_Doctor> Maybe?
17:40:10 <nirik> well, I'd be in favor of a controlled plan, ie... deprecate, track, try and get important things moved, revisit, then when enough is moved retire it.
17:40:16 <mhroncok> I like the "must be ported" list idea
17:40:56 <nirik> in the absense of a controlled plan what will happen is someone will take over libsoup2 and there won't be any pressure to move things... ;(
17:41:18 <sgallagh> mhroncok: Yeah, that at least is a concrete thing we can request/demand.
17:41:48 <decathorpe> And I doubt that moving those to a flatpak where they can stlll include libsoup2 will happen either (given that they're inactive)
17:41:48 <Eighth_Doctor> I suspect we're going to be stuck with libsoup2 as long as we've been stuck with gtk2 (and now with gtk3)
17:42:15 <Eighth_Doctor> because these new major versions all have the same problematic characteristics
17:42:35 <music[m]> There are very active projects that are still on libsoup2 at the moment. Darktable, for one.
17:42:40 <nirik> lets not forget gtk+ :)
17:42:41 <Eighth_Doctor> or I guess a more accurate comparison would be SDL1 and SDL2
17:42:55 <Eighth_Doctor> because it had the same problem until someone wrote a shim library
17:43:16 <decathorpe> oh. could we have a libsoup 2 API shim for libsoup3?
17:43:32 <sgallagh> From what I can tell, that's not realistic.
17:43:34 <Eighth_Doctor> theoretically, someone could write a libsoup2 shim that dlopens libsoup3
17:43:53 <Eighth_Doctor> that works around the symbol issues
17:43:53 <nirik> or vte. :( Theres a number of things like this where upstream has moved on, but a few inactive things are still using it and we still ship it. ;(
17:43:53 <TheExorcist[m]> .hello2
17:43:53 * decathorpe shrugs
17:43:53 <zodbot> TheExorcist[m]: Sorry, but user 'TheExorcist [m]' does not exist
17:44:01 <sgallagh> There are significant changes in how I/O is handled that would be nontrivial to handle
17:44:17 <decathorpe> beautiful.
17:44:27 <music[m]> porting guide again: https://libsoup.org/libsoup-3.0/migrating-from-libsoup-2.html
17:44:27 <music[m]> lots of removals
17:45:02 <sgallagh> Not impossible, but demanding that someone expend the effort to do it is... unlikely to be effective.
17:45:20 <Eighth_Doctor> Stephen Gallagher: it's probably more effective than getting the libsoup2 world ported
17:45:24 <Eighth_Doctor> not saying either are very likely
17:45:38 <Eighth_Doctor> but the likelihood of a shim succeeding is higher than dropping libsoup2 anytime soon
17:45:49 <Eighth_Doctor> they're both low though :(
17:47:02 * nirik notes there's no discussion on this list about this change, only in the ticket. ;(
17:47:02 <decathorpe> Still, I'd like to have a migration plan and/or a must-be-ported list.
17:47:22 <mhroncok> "The GNOME core dependencies and apps (flatpak-builder, geoclue2, geoclue-glib, gnome-calculator, gnome-music, gnome-software) will be ported upstream"
17:47:30 <Eighth_Doctor> there was discussion on the devel@ list
17:47:31 <nirik> how about we punt and ask everyone to discuss on list?
17:47:34 <mhroncok> "As for all the other stuff: I guarantee most of it will not be ported without a motivating deadline"
17:47:35 <nirik> was there?
17:47:46 <nirik> not for this change... for the previous one.
17:47:47 <mhroncok> I think I have a proposal
17:47:57 <sgallagh> Proposal: We require that the Change Proposers provide a list of must-port packages. Completion of this list is required or the Contingency Plan is activated. Once that is reached, libsoup2 may be orphaned, and any interested party may opt to maintain it.
17:48:35 * nirik waits for mhroncok's
17:48:58 <Eighth_Doctor> Stephen Gallagher: I would also add stakeholder/maintainer involvement also needs to be included
17:49:12 <Eighth_Doctor> this is effectively a massive system-wide change
17:49:16 <sgallagh> Feel free to rephrase. I just wanted to start a concrete proposal
17:49:39 <TheExorcist[m]> sgallagh: Yeah, I agree, may be it is a bit long process to exit libsoup2
17:49:45 * nirik notes this is targeting f39, so not sure there's a great rush here.
17:49:49 <mhroncok> Considering the change authors are quite sure "most" of the packages will be ported, FESCo request that there is some kind of definition of wht needs to be ported to proceed with retirement of libsoup2 and the remaining dependents. This can be a list of important packages that must be ported or a numerical criteria (e.g. "75% of packages must be ported") or a combination of those.
17:49:58 <mhroncok> sorry, I wasn't reading while typing
17:50:02 <music[m]> I would also like to see a list of affected packages that aren’t considered “must-port,” rather than having to tabulate that myself in order to understand the scope of the proposal.
17:50:43 <mhroncok> Stephen Gallagher: I dislike "libsoup2 may be orphaned once X happens" -- fesco has no power to tell people not to orphan packages
17:51:05 <mhroncok> and I agree with music about the list of the remaining affected packages
17:51:09 <sgallagh> That was meant to indicate that we are okay with orphaning, not retiring (immediately)
17:51:10 <Eighth_Doctor> we can tell them to not retire though
17:51:30 <sgallagh> I agree, probably not sufficiently clear on that
17:53:04 <sgallagh> Proposal: We require the Proposers to provide a complete list of affected packages as well as indicating which fall under the "must-port" category. We also require that libsoup2 not be immediately retired, such that other maintainers can volunteer to pick it up.
17:53:10 <sgallagh> Revision^^
17:54:01 <mhroncok> I am afraid that if we say "We also require that libsoup2 not be immediately retired, such that other maintainers can volunteer to pick it up." they will just orphan it and say they don't care
17:54:06 * TheExorcist[m] feeling killing mosquito is really a painful process..!
17:54:29 <nirik> I think we need more list discussion... and folks can ask them that. ;)
17:54:33 <sgallagh> mhroncok: And the problem with that is...?
17:54:35 <music[m]> I could actually support retirement if the porting situation reached some arbitrarily adequate status. There are good security reasons to want to avoid keeping an unmaintained version of a HTML parser in the distribution indefinitely.
17:54:42 <mhroncok> I'd pretty much prefer a coordinated effort to retire it than somebody who is not quite sure what they are doing taking the package
17:55:20 * nirik nods
17:55:26 <decathorpe> with "coordinated effort" != "retire it and let packages that aren't ported yet rot"
17:55:50 <mhroncok> sure
17:56:02 <mhroncok> I proposed a way forward in the ticket
17:56:17 <mhroncok> here I at least proposed we get a list of musts and pnt the decision until then
17:56:28 <mhroncok> (until we see the list)
17:56:34 <decathorpe> sounds good to me
17:56:44 <nirik> s/in the ticket/on the list/ ? :)
17:57:27 <sgallagh> Good enough
17:57:58 <mhroncok> I was referring to https://pagure.io/fesco/issue/2863#comment-815849
17:59:00 <sgallagh> Proposal: Request the creation of the affected package list and must-port requirements, then revisit.
17:59:25 <mhroncok> "Considering the change authors are quite sure "most" of the packages will be ported, FESCo request that there is some kind of definition of wht needs to be ported to proceed with retirement of libsoup2 and the remaining dependents. This can be a list of important packages that must be ported or a numerical criteria (e.g. "75% of packages must be ported") or a combination of those."
17:59:39 <mhroncok> was my proposal that kinda requested the list
18:00:02 <mhroncok> s/request/requests/
18:00:05 * nirik is for more discussion and revisit. ;) so, +1 to sgallagh I guess...
18:00:29 <mhroncok> but meh, +1 to Stephen Gallagher's proposal as well
18:00:37 <decathorpe> +1 to ~everything~ ✨
18:00:42 <nirik> ha
18:00:44 <mhroncok> same thing, less words
18:01:17 <nirik> 🪄
18:01:51 <music[m]> +1 to Stephen Gallagher’s version of mhroncok’s proposal 🤪
18:02:14 <sgallagh> #info FESCo requests the creation of an "affected package list" and "must-port" requirements. We will revisit then.
18:02:23 <sgallagh> #topic Next week's chair
18:03:26 <sgallagh> ... anyone?
18:04:26 <mhroncok> I could, but there is a 20% chance of me missing on the meeting
18:04:40 <mhroncok> happy to take it if I have a backup person :)
18:05:29 <sgallagh> OK, I'll pick it up if you can't make it.
18:05:34 <mhroncok> ok
18:05:48 <sgallagh> #action mhroncok to chair the next meeting, with sgallagh as a backup
18:05:54 <sgallagh> #topic Open Floor
18:06:00 <sgallagh> Anything for Open Floor?
18:06:42 <nirik> Congrats to everyone on F37 Beta going out this morning. ;)
18:07:28 <mhroncok> There is ~30 packages still requiring Python 3.10 in F
18:07:32 <mhroncok> in F37
18:08:12 <mhroncok> Should I try hard to retire them (and make some maintainers sad) or should I try to make the maintainrs happy an dleave their uninstallable packages in Fedora 37 GA repo?
18:08:33 <mhroncok> s/maintainrs/maintainers/, s/an/and/, s/dleave/leave/
18:08:55 <decathorpe> Are the FTI bugs in "stop pestering me" state?
18:09:24 <mhroncok> around a half of them is
18:09:36 <mhroncok> I think ~14 will be retired 1 week before the final freeze as the bugzillas are in NEW
18:09:43 <mhroncok> rest is in ASSIGNED
18:09:50 <decathorpe> meh
18:09:53 <mhroncok> (usually for months now)
18:10:13 <sgallagh> Is there a summary list available? (Apologies if I missed it on devel@)
18:10:28 <mhroncok> I nromally try to get every package rebuilt or retired, but it seems that some maintainers just don't see my pov that having the uninstallbale package in Fedora has no point
18:10:40 <mhroncok> can share on the list later
18:10:58 <mhroncok> cjdns datagrepper datanommer datanommer-commands dlib home-assistant-cli jpype kiwi-boxed-plugin mailman3 monkeytype muse paternoster profanity py4j python-calligrabot python-cu2qu python-django-mailman3 python-evic python-filecheck python-funcy python-haversion python-hyperkitty python-javabridge python-jep python-octave-kernel python-postorius python-Pympler python-requests-credssp python-sendgrid python-yappi renderdoc sigil
18:11:47 <decathorpe> at least cjdns is actively worked on ... sometimes. parts of it were rewritten in Rust and the maintainer is struggling but not accepting help either
18:11:50 <sgallagh> I'm in favor of aggressively retiring them
18:11:58 <nirik> I plan on working on data* but I keep getting fires
18:11:59 <mhroncok> +3 m,ore packages that only pop up in f37 but not in rawhide but I guess they are un testing now
18:12:03 <mhroncok> s/un/in/
18:12:10 <nirik> like our signing server certs all expiring yesterday. ;(
18:12:46 <mhroncok> actively worked on is fine, but if not done until final freeze, I'd retire it (even if we unretire it just after GA)
18:12:46 <decathorpe> I'm more concerned with ipsilon being orphaned TBH
18:13:05 <mhroncok> the infra packages are often orphaned. many of them have dead accounts as primary miantainers
18:13:16 <mhroncok> until nirik picks them up :D
18:13:52 <nirik> ipsilon got orphaned? oops.
18:14:05 <music[m]> As an example of how the situation can happen, I assigned myself the bug for python-fastapi (https://bugzilla.redhat.com/show_bug.cgi?id=2113625) and reported it upstream, but upstream never worked on it. The bug was finally fixed in python-pydantic, but still hasn’t been released upstream. I ended up retiring the package myself, but it could potentially be revived for F38 or later by another maintainer once an appropriate
18:14:05 <music[m]> pydantic update is released.
18:14:12 <decathorpe> zuul too ...
18:14:48 <nirik> I can take ipsilon. I really will try and work on these....
18:14:56 <mhroncok> zuul was orphend deliberately, they will not be using the RPM-packaged zuul for zuul
18:15:08 <decathorpe> beautiful ✨
18:15:45 <mhroncok> anyway, I will post the list of packages to devel and suggest that we retire those that are not fixed at final freeze
18:15:55 <decathorpe> mhroncok++
18:15:59 <music[m]> Are you wanting to forcibly retire F37+Rawhide for these packages, or just the F37 branch?
18:16:10 <mhroncok> heh
18:16:12 <mhroncok> I guess both
18:17:04 <mhroncok> nirik: ipsilon was orphaned and then I fixed it. so it needs no fix, just a new maintainer
18:17:14 <nirik> I just took it.
18:17:18 <nirik> thanks for fixing it!
18:18:04 <kalev> I think it makes a lot of sense to retire packages with broken deps before the final freeze, there's little point in keeping something that cannot be installed at all
18:18:45 <kalev> but I wonder if maybe the rules for bringing back retired packages are a bit too tight? maybe it would make sense to extend the time when no re-review is needed? that way maintainers might be more ok with retiring stuff
18:19:18 <mhroncok> I can volunteer to re-review their packages when reintorduced if you think it helps
18:19:35 <sgallagh> mhroncok: Not really, you're very picky ;-)
18:19:37 <mhroncok> honestly, I just don't get the fear of the review. reviews are good
18:19:48 <kalev> I don't know, I'm just brainstorming :)
18:19:49 <sgallagh> It's mostly that they take time
18:20:13 <nirik> 8 weeks is a pretty long window
18:20:17 <mhroncok> kalev: thanks :)
18:20:54 <sgallagh> Yeah, if someone hasn't noticed for 8 weeks that the package was retired... it was probably the correct decision
18:21:07 <kalev> ah, 8 weeks is pretty long, yeah, never mind me then :)
18:23:13 <mhroncok> (no more on this topic)
18:23:27 <sgallagh> Anyone opposed to me ending this meeting?
18:24:13 <sgallagh> Silence == consent
18:24:15 <sgallagh> #endmeeting