17:01:15 <zbyszek> #startmeeting FESCO (2023-01-17)
17:01:15 <zodbot> Meeting started Tue Jan 17 17:01:15 2023 UTC.
17:01:15 <zodbot> This meeting is logged and archived in a public location.
17:01:15 <zodbot> The chair is zbyszek. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:01:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:15 <zodbot> The meeting name has been set to 'fesco_(2023-01-17)'
17:01:15 <zbyszek> #meetingname fesco
17:01:15 <zodbot> The meeting name has been set to 'fesco'
17:01:15 <zbyszek> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, music, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:01:15 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mhayden mhroncok music nirik sgallagh zbyszek
17:01:18 <zbyszek> #topic init process
17:01:20 <zbyszek> .hello2
17:01:21 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
17:01:22 <nirik> morning
17:01:38 <dcantrell> .hello2
17:01:39 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
17:01:51 <zbyszek> it will be morning here too soon :)
17:01:52 <MichaelCatanzaro> .hello catanzaro
17:01:53 <zodbot> MichaelCatanzaro: catanzaro 'Michael Catanzaro' <mcatanzaro@redhat.com>
17:01:59 <Eighth_Doctor> .hello ngompa
17:02:00 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:02:13 <Eighth_Doctor> I am only going to be sort of here, things are a bit hectic
17:02:24 <bcotton> .hello2
17:02:24 <decathorpe> I am here o/
17:02:25 <sgallagh> .hi
17:02:25 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:02:27 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
17:02:37 <zbyszek> MichaelCatanzaro: thanks for joining
17:02:40 <mhayden> .hi
17:02:41 <zodbot> mhayden: mhayden 'Major Hayden' <mhayden@redhat.com>
17:02:51 <zbyszek> So we have quorum. I'll wait a minute more.
17:02:52 <AllanDay[m]> .hi
17:02:53 <zodbot> AllanDay[m]: Sorry, but user 'AllanDay [m]' does not exist
17:03:04 <zbyszek> AllanDay[m]: thanks for joining, even if you don't exist ;)
17:03:38 <zbyszek> #topic #2928 Change: Shorter Shutdown Timer
17:03:38 <zbyszek> .fesco 2928
17:03:39 <AllanDay[m]> existence is overrated
17:03:53 <zodbot> zbyszek: Issue #2928: Change: Shorter Shutdown Timer - fesco - Pagure.io - https://pagure.io/fesco/issue/2928
17:04:09 <cmurf> .hello2
17:04:10 <zodbot> cmurf: cmurf 'Chris Murphy' <chris@cmurf.com>
17:04:37 <zbyszek> dcantrell and decathorpe were against in the ticket.
17:04:40 <nirik> I'm still concerned that this will break too many users... :(
17:05:06 <decathorpe> I was especially concerned by the last comment on the ticket, to be honest
17:05:29 <decathorpe> if change owners don't want to be responsible for fixing fallout of this change, they should not have proposed it
17:05:44 <mhayden> would there be a way to collect data on this somehow to avoid kicking the can down the road? perhaps with abrt?
17:05:59 <mhroncok> I'm here, just forogot the time
17:06:03 <mhroncok> .hello churchyard
17:06:04 <zodbot> mhroncok: churchyard 'Miro Hrončok' <mhroncok@redhat.com>
17:06:33 <nirik> mhroncok: the change does send sigabrt now...
17:06:38 <nirik> sorry, mhayden
17:07:06 <mhayden> oh
17:07:23 <sgallagh> Is ABRT still running at that point?
17:07:51 <decathorpe> probably not, but it should process the coredump at the next boot?
17:07:53 <zbyszek> mhayden: only partially. The way we collect data is by killing the service. With the sigabrt change we would maybe collect more data, but the actual timeout is not changed, so in effect we *are* kicking the can down the road.
17:08:28 <mhayden> zbyszek: understood. thanks.
17:08:28 <cmurf> That's not what I said. And I'm not (yet) a change owner. Burdening change owners with fixing every app that won't quit in a timely fashion is an unreasonable request. Fixing fallout as a result of the change is a different matter, and reasonable one.
17:08:38 <nirik> It might help to run a test day to see if anyone can find new/unknown units that can't handle the timeout
17:09:05 <MichaelCatanzaro> mhayden: My expectation is that ABRT will notice core dumps when systemd crashes the services that failed to quit on time, yes
17:09:18 <decathorpe> cmurf: I apologize, I assumed you were one of the Change owners
17:09:39 <zbyszek> Yeah, what decathorpe and MichaelCatanzaro said. But it'd be good to verify that this really works. Sometimes abrt doesn't process things as expected.
17:09:56 <MichaelCatanzaro> decathorpe: The change ownership is murky. The names on the proposal are myself and aday, but the change is really proposed by the entire Workstation WG, so cmurf is kinda a change owner too. ;)
17:10:03 <dcantrell> cmurf: my expectation is that the change owners are not responsible for fixing the problem services, but that the actual source of the problem should be addressed rather than navigated around
17:10:14 <MichaelCatanzaro> Workstation WG has been tracking this for a long time.
17:10:20 <cmurf> As a member of the workstation working group I do support the change proposal. The working group has been working on this issue for years.
17:10:46 <sgallagh> Refresh my memory: can individual services override the timeout?
17:11:00 <nils> .hello nphilipp
17:11:01 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
17:11:08 <zbyszek> sgallagh: yes.
17:11:10 <sgallagh> For example, I might have a service that I know takes 45-60s to shut down. Can I except it from being killed?
17:11:16 <cmurf> dcantrell: seems reasonable to me
17:11:17 <sgallagh> OK, thanks
17:11:43 <MichaelCatanzaro> dcantrell: And in particular, I want to note that I modified the change proposal in response to similar feedback: instead of just killing hung services with SIGKILL, systemd will send SIGABRT first, then SIGKILL. This should avoid concerns that a shorter timeout will "paper over" or hide problems, since there will be core dumps and hopefully crash reports when a service takes too long to qui.
17:11:55 <decathorpe> I still think it would be much safer to not drastically change the global timeout but instead override problem services on a case by case basis (where determining what's safe should be much easier than check all of Fedora)
17:12:04 <nirik> might be nice also if the change/release notes said how to 'fix' a unit that needs more time.
17:12:32 <zbyszek> sgallagh: Also, there is a protocol to extend the timeout dynamically. This is actually nicer, because we can set a fairly low timeout which works if something hangs, but really allow services which which need more time to extend it.
17:12:41 <dcantrell> have maintainers of problem services been contacted?
17:13:25 <MichaelCatanzaro> zbyszek: Additionally you can configure an alternative timeout on a per-service basis. This only changes the default.
17:13:39 * sgallagh nods
17:14:08 <sgallagh> Assuming we approved this Change: is there any reason to believe that the owners of problem services won't just paper over it by setting manual, longer timeouts?
17:14:48 <decathorpe> sgallagh: I thought that's exactly the opt-out mechanism for services that need longer timeouts? :)
17:14:49 <dcantrell> right, hence my question above.  would make sense to include those maintainers in this change
17:14:52 <AllanDay[m]> dcantrell: not directly about the specific change. we've been in touch with packagekit about its issues over the years. and obviously this change proposal was intended to make maintainers aware
17:15:05 <MichaelCatanzaro> dcantrell: So the problematic services that I know of are podman (which has recently implemented some sort of change in response to this feedback) and PackageKit (the maintainer of PackageKit is a Workstation WG member and is aware but says it won't be fixed until PackageKit has moved to dnf5). But there are surely more problematic services too that we don't know about. I'm hopeful that adding a crash will help us find more
17:15:05 <MichaelCatanzaro> problems. In particular, while some services hang regularly, I bet some only hang rarely and are harder to notice/remember without crash reports.
17:15:21 <sgallagh> Fabio Valentini: Right, my point is that I'm not sure a shorter default timeout will really have a meaningful effect.
17:15:46 <dcantrell> if you have not been in touch with any of the maintainers but have been working on the problem for years, I would say that's a problem.  the assumption is this change proposal will make them aware, but a better approach would be to talk to them first
17:15:53 <nirik> does systemd record shutdown time anywhere? ie, could someone look and see if any of their existing units took longer than 15s to shutdown?
17:15:58 <nils> I know workstation etc., but what about database servers with open connections? In my experience they're quite reticent to shutting down quickly.
17:16:25 <MichaelCatanzaro> sgallagh: I guess that could happen, but I would be inclined to trust developers to be responsible. I don't expect this to be an issue for services that are installed by default.
17:16:29 <AllanDay[m]> dcantrell: packagekit is the main service that we're aware of, and we have been in touch with packagekit developers
17:16:47 <nirik> databases should set a longer timeout probibly.
17:16:55 <zbyszek> nirik: it logs, but it doesn't "save" this anywhere. There isn't a good place really.
17:17:05 <dcantrell> is that the only service of concern now or are there known others?
17:17:22 <nirik> zbyszek: humf, true. ;(
17:17:22 <sgallagh> Michael Catanzaro: Sure, but "responsible" may just mean "I know my service takes a while to shut down. I'll just say 'five minutes' to be safe"
17:17:53 <MichaelCatanzaro> We don't want to just fix PackageKit though, but to make Fedora generally more robust to hung services. And yes, we're aware that databases may need to request a larger timeout either statically or dynamically using the existing mechanisms.
17:17:56 <nils> sgallagh, sometimes that's all you can say up-front
17:17:59 <nirik> sgallagh: well, the timeout now is 2min... more than that seems odd.
17:18:04 <sgallagh> (To be clear: I support the intention to shorten shutdown times. I just don't know if this Change will accomplish that)
17:18:08 <nils> MichaelCatanzaro++
17:19:05 <AllanDay[m]> dcantrell: i'm pretty sure that there's been some interaction around podman, but i'd need to dig up the issue
17:19:08 <sgallagh> Do we have any easy way to identify packages that override the default timeout?
17:19:21 <nils> As a really minor datapoint, jackd started as a user process will trigger the 2min timeout to for me unless I kill it off first before shutting down
17:19:39 <sgallagh> We could potentially require FESCo approval to use non-default values.
17:20:09 <MichaelCatanzaro> sgallagh: Honestly I'm not concerned with services that override the default value. Most reasonable Fedora services are unlikely to do this by default, but the option should be available for use by databases, virtual machines, etc.
17:20:34 <nirik> podman sets 70sec apparently
17:20:35 <MichaelCatanzaro> So I would be surprised if Fedora services start abusing the timeout, but if so we can address it on a case-by-case basis
17:20:55 <zbyszek> nils: jackd almost certainly is fine with being killed early. So UX would be improved by this change, because you'll either get a faster timeout and/or maintainers will fix jackd.
17:21:04 <MichaelCatanzaro> 70 sec is higher than I'd prefer to see for podman, but not really unreasonable sans bugs
17:21:10 <nirik> libvitrd sets 0
17:21:31 <sgallagh> nirik: 0 == infinite?
17:21:38 <nils> zbyszek, of course, that was "here this would help me" (-> minor)
17:21:39 <MichaelCatanzaro> But if bugs with podman are not truly fixed, then we may need to revisit podman's choice of 70s
17:22:02 <zbyszek> nirik: libvirts wants to shut down virtual machines, which can take arbitrary long. So disabling the timeout is somewhat reasonable.
17:22:15 <nirik> sgallagh: yep
17:22:36 <MichaelCatanzaro> zbyszek: Also, I'm told systemd will repeat the timeout value three times before killing. Is that true? At least several users complained about the timeouts restarting. So the timeouts are actually longer than they look....
17:22:38 <nirik> so I guess I am a weak +1
17:22:49 <zbyszek> I agree with MichaelCatanzaro that abuse is not an expected problem.
17:22:58 <zbyszek> MichaelCatanzaro: no, that's just confusing output.
17:23:22 <zbyszek> Essentially, there might be two or three steps that "add up".
17:24:01 <MichaelCatanzaro> Hm, OK
17:24:20 <MichaelCatanzaro> And in particular, VMs can get really messed up if they're killed unexpectedly, so libvirt is reasonable to disable the timeout. We're really only concerned with defaults in this change, not with specific services.
17:25:07 <sgallagh> I guess I can be +1 to this, but with the option to revisit if we find that many services just decide to override the default.
17:25:41 <nirik> It doesn't look like postgresql does any change from the default... that might be something to look into
17:25:54 <nirik> oh no, it sets 0 too. great
17:26:37 <nirik> I think a lot of things that already are really slow (more than 2min) would have overridden the 2min timeout default already anyhow.
17:26:38 <nils> great or "great"?
17:27:30 <nirik> good. It should override it and shutdown normally no matter how long it takes.
17:28:09 <zbyszek> OK, should we discuss more, or are folks ready for a vote/
17:28:12 <zbyszek> ?
17:28:13 <mhroncok> 0 means never?
17:28:20 <mhroncok> or kill immediatelly?
17:28:33 <zbyszek> mhroncok: yes, it's a compatibility thing.
17:28:42 <zbyszek> Saying "infinity" explicitly is nowadays preferred.
17:29:21 <sgallagh> Sorry folks, I have to drop and go collect a sick kid from school. My +1 stands
17:29:40 <zbyszek> OK, let's vote on the proposal then.
17:29:44 <zbyszek> +1
17:29:59 <nirik> +1
17:31:15 * mhayden thinks furiously
17:31:24 <dcantrell> -1
17:31:29 <mhroncok> I am afraid I haven't paid enough attention to this change proposal and I don't want to vote based only on this meeting. I abstain for now (0) and if the proposal does not reach enough votes here because of me, I will dedicate some time for it
17:32:30 <mhayden> i'm -1 because i'd like to see if we can be more narrow/selective in how we apply it
17:32:31 <decathorpe> my -1 stands. I still think 1:30 -> 0:15 is too aggressive.
17:32:59 <mhayden> but i *have* been burned by sitting there waiting for a reboot and i have been burned by a misbehaving process being killed on reboot
17:33:15 <zbyszek> #agreed REJECTED (+2,1,-3)
17:33:24 <MichaelCatanzaro> decathorpe: The value is arbitrary. Could easily be 30s
17:33:35 <cmurf> Ok so what about 0:30?
17:33:37 <MichaelCatanzaro> zbyszek: there are three +1s but I guess that's still a reject?
17:33:40 <mhroncok> +3?
17:33:44 <zbyszek> #undo
17:33:44 <zodbot> Removing item from minutes: AGREED by zbyszek at 17:33:15 : REJECTED (+2,1,-3)
17:33:55 <zbyszek> #agreed REJECTED (+3,1,-3)
17:34:13 <MichaelCatanzaro> decathorpe: So for avoidance of doubt, if the exact value of the timeout is a concern... name your timeout and we'll change the proposal :P
17:34:38 <zbyszek> Should we also discuss just doing the SIGABRT change?
17:35:02 <decathorpe> zbyszek: I think that would be a good first step
17:35:13 <decathorpe> then fix timeouts for stuff that gets lots of crash reports
17:35:19 <decathorpe> then set default timeout lower
17:35:32 <decathorpe> doing it all at once does not seem prudent to me.
17:36:05 <MichaelCatanzaro> Fabio Valentini: Would you support a 60s timeout for now, so at least users would be stuck for only half as long?
17:36:44 <MichaelCatanzaro> Then we can come along and reduce to 30s or 15s in a future Fedora. Or do a sliding reduction like: 1m F38, 30s F39, 15s F40...
17:37:51 <decathorpe> Why are you putting me on the spot like this? ...
17:37:51 <MichaelCatanzaro> Hehe, because you voted -1 and specifically expressed concern about the exact value of the timeout :)
17:38:10 <MichaelCatanzaro> So yeah, would you support the change if it was 60s instead of 15s? Because if so let's do that and revote
17:38:16 <dcantrell> could we not do that now and move this meeting along?
17:38:26 <MichaelCatanzaro> Basically Workstation WG doesn't want to see this get completely thrown out, we're willing to compromise to get a lower timeout for users ;)
17:38:39 <cmurf> macOS went to 10s reboots around a decade ago, cold turkey. FWIW. A sequential approach is quite conservative.
17:38:41 <decathorpe> <pedantic mode>If you want to amend the change, it needs to be re-announced on the devel list, wait for another week, and have FESCo re-vote afterwards </pedantic mode>
17:38:55 <MichaelCatanzaro> In particular, if we're required to resubmit the change proposal, we hope it won't have to be delayed until F39...
17:39:06 <MichaelCatanzaro> Not concerned about a 1 week delay, that's fine
17:39:22 <Eighth_Doctor> +1 for current, 30s or 60s
17:39:39 <Eighth_Doctor> * current, 30s, or
17:39:39 <MichaelCatanzaro> Oh thanks, I forgot you hadn't voted yet :P
17:40:00 <Eighth_Doctor> Work chaos 🔥
17:40:03 <zbyszek> decathorpe: I think we were supposed to discuss changing the voting rules. Let's not jump before the bandwagon just yet.
17:40:31 <zbyszek> So… that puts mhroncok on the spot, because he said he'll reconsider if the vote is down just one.
17:41:04 <mhroncok> fuuu
17:41:10 <mhroncok> So close
17:41:50 <nirik> vote in ticket after you have had a chance to read up more?
17:42:18 <decathorpe> if it helps: I am -1 for anything < 45 seconds and ±0 for any 1 minute < new timeout < 1 min 30
17:42:34 <decathorpe> or maybe that's just making things more complicated :)
17:42:34 <mhroncok> that does not help at all :D
17:42:35 <decathorpe> 🤪
17:42:35 <decathorpe> sorry
17:42:43 <zbyszek> I think 45 s is a good compromise.
17:42:54 <zbyszek> I understand that it has support from the WG.
17:43:13 <decathorpe> * if it helps: I am -1 for anything \< 45 seconds and ±0 for any 45 s \< new timeout \< 1 min 30
17:43:27 <MichaelCatanzaro> Yes, we've no objections to 45s.
17:43:42 <decathorpe> that's basically half the current timeout, right?
17:43:46 <MichaelCatanzaro> Well we might come along next release and propose a lower timeout again, but incremental progress is good and conservative
17:44:17 <MichaelCatanzaro> decathorpe: I think system services use 2m timeout and user services use 1m30s timeout currently, but I don't remember for sure. The max timeout is currently 2m.
17:44:19 * mhroncok reads trough the discussion, seems like server WG ("on behalf of") does not like this...
17:45:12 <decathorpe> "I think" is doing a lot of heavy lifting here :D
17:45:41 <zbyszek> I think servers are more complicated. I'm pretty sure people want their VMs to shut down quickly. We get lots of complaints if anything with a VM takes more than a few seconds.
17:45:46 <nirik> I think the server use cases already have been overridden
17:46:04 <nirik> (perhaps not all of course)
17:46:20 <mhroncok> is this still targeted to all "editions"?
17:46:27 <MichaelCatanzaro> mhroncok: Yes, but ideally we would implement this in a way that would allow Server to opt-out if that's what they choose
17:46:42 <MichaelCatanzaro> Basically we are changing systemd default config, but you can always add another layer of config...
17:46:52 <mhroncok> my initial thought is: let's pull the plug and if services break we extend their timouts
17:46:56 <mhroncok> s/timouts/timeouts/
17:47:33 <mhroncok> serious people will switch to Ubuntu anyway because of the frame pointers change :D
17:47:44 <zbyszek> mhroncok: that is the general plan.
17:48:01 <zbyszek> (The first part you said. I'm not commenting on the second ;) )
17:48:17 <mhroncok> +1 to do it
17:48:50 <mhroncok> I also think a gradual approach is probably safer, but if 15 seconds has enough support, so be it
17:49:02 <cmurf> I've done a lot of reboot -f and have only ever had minor issues with VM guests using unsafe cache mode. It's possible server working group doesn't realize zero equals infinity.
17:49:02 <mhroncok> the times are quite arbitrary anyway
17:49:29 <mhroncok> I wonder what is the impact on slow hardware
17:50:11 <MichaelCatanzaro> mhroncok: Any time we choose will be arbitrary, yes. And we can change our minds in the future as well (for frame pointers too ;). If users complain about 15s, then we can increase to 30s...
17:50:35 <zbyszek> mhroncok: on slow hardware things go south. But not only during shutdown, you hit abritrary timeouts in other places.
17:51:04 <zbyszek> We have this issue in CI, where some operations are extended a thousandfold, and then machines just don't boot.
17:51:16 <MichaelCatanzaro> mhroncok: Well I don't know for sure, but my expectation would be that 15 seconds is enough for any hardware that can run Fedora unless the system is thrashing. Once you're running out of memory then everything slows to a halt and you're going to hit timeouts
17:51:43 <zbyszek> OK, if I'm counting correctly, we'd be at +5,1,-2 with 45 s.
17:51:48 <MichaelCatanzaro> systemd-oomd helps with that but it's not perfect
17:51:50 <zbyszek> Should we redo the vote?
17:52:27 <MichaelCatanzaro> zbyszek: Yes, or I believe +4,1,-3 with 15s as Fabio's vote would flip
17:52:28 <nirik> I don't know that anyone wants to change votes...
17:53:12 <mhayden> i think mhroncok was getting at what i was interested in -- if we could make this edition specific i could get on board
17:53:17 <dcantrell> I have a conflict at the hour mark, so I've got 7 more minutes
17:53:40 <mhayden> cutting off services on a workstation is different than a server
17:53:45 <nirik> I hope we can avoid making it edition specific.
17:53:52 <mhroncok> +3,1,-3 -> Neal +4,1,-3 -> me +5,0,-3
17:53:59 <mhroncok> for 45 seconds, +5,1,-2
17:54:16 <zbyszek> Proposal: change is approved with a timeout of 45 s and the caveat that editions must be able to override the change.
17:54:21 <decathorpe> I can vote +1 for 45s assuming that WGs can easily opt out.
17:54:50 <music[m]> .hello music
17:54:51 <zodbot> music[m]: music 'Benjamin Beasley' <code@musicinmybrain.net>
17:54:55 <MichaelCatanzaro> zbyszek: For Server to opt-out, it would just request a systemd drop-in config, right? Not difficult?
17:55:14 <music[m]> Sorry, preschool dropoff related things ran late.
17:55:19 <zbyszek> (After all the discussion, I think that going to 45s and then reconsidering 15s for next release is safer than jumping to 15 immediately.)
17:55:34 <zbyszek> MichaelCatanzaro: I think so. Whatever works.
17:56:11 <zbyszek> Please vote, or make an alternative proposal.
17:56:35 <nirik> +1
17:56:44 <zbyszek> +1 (for ease of counting)
17:57:31 <mhayden> +1
17:57:52 <music[m]> I am much more comfortable with this change now that the SIGABRT thing is part of it. I’m happier with 45s than 15s for an initial setting.
17:57:54 <music[m]> +1 for zbyszek’s proposal.
17:57:56 <zbyszek> music[m]: I guess you have access to the log if you're using element. Please holler if you need a copy though.
17:58:04 <mhroncok> +1
17:58:22 <zbyszek> dcantrell, decathorpe?
17:58:23 <decathorpe> +1, in case it was lost in the log.
17:58:33 <zbyszek> Eighth_Doctor?
18:00:37 <zbyszek> I'll count Eighth_Doctor as +1 as he was explictly supportive of 30–60s timeout, and dcantrell as -1 because he was consistently against.
18:00:47 <zbyszek> sgallagh:?
18:01:18 <Eighth_Doctor> +1
18:01:33 <nirik> zbyszek: he had to leave.
18:01:54 <MichaelCatanzaro> Stephen Gallagher had to step out, but he was +1 to 15s
18:02:09 <MichaelCatanzaro> Oh he's back
18:02:09 <sgallagh> +1 to 45s as well.
18:02:20 <sgallagh> Just now
18:02:24 <zbyszek> #agreed Change is approved with a timeout of 45 s and the caveat that editions must be able to override the change (+8,0,-1)
18:02:29 <zbyszek> Please check my counting.
18:02:47 <cmurf> looks correct
18:02:54 <mhayden> 👍
18:03:11 <zbyszek> I have another easy one for you…
18:03:11 <zbyszek> #topic #2930 Change: Rpmautospec by Default
18:03:11 <zbyszek> .fesco 2930
18:03:13 <zodbot> zbyszek: Issue #2930: Change: Rpmautospec by Default - fesco - Pagure.io - https://pagure.io/fesco/issue/2930
18:03:19 <nirik> easy!
18:03:27 <mhroncok> only took an hour \o/
18:03:50 <mhroncok> we should kill discussions in 15 seconds
18:04:00 <nils> mhroncok, was just thinking the same
18:04:01 <nirik> ha.
18:04:32 <mhayden> oh, i see the humor now 😜
18:04:32 <music[m]> Just for the record, assuming 45s goes well, I would be happy to see future changes incrementally decrease the timeout.
18:04:36 <decathorpe> I think the stuff about RHEL import and shallow clones has derailed the discussion a bit ...
18:05:03 <zbyszek> So… about the distrobaker imports that Eighth_Doctor pointed out:
18:05:07 <nirik> I'm in favor of this, but really it doesn't do much... just suggests more strongly for people to use it. In the end they will or not.
18:05:35 <zbyszek> I wrote some emails, and at least the right people are now aware of the issue. But I don't have anything more at this point.
18:06:04 <decathorpe> Changing documentation so that rpmautospec becomes the "default" way to do things i a small enough change with a very easy opt-out, so I'm +1
18:06:04 <sgallagh> FTR, it's my team at RHT that will likely be responsible for implementing the import. I'm in favor of this Change.
18:06:39 <sgallagh> Do with that information what you will.
18:07:42 <zbyszek> Eighth_Doctor: what do you think
18:07:49 <nils> sgallagh, thanks for stepping in the gap btw, you and I should get together so I can give you the tour
18:08:24 <sgallagh> Sounds like a plan
18:08:34 <zbyszek> We had four +1 votes in the ticket.
18:08:47 <zbyszek> Any questions or comments here before we vote?
18:09:54 <sgallagh> Is a pop-tart a calzone?
18:09:56 <sgallagh> (Sorry, please continue)
18:10:08 <zbyszek> If we don't discuss, we might not use the full hour that was reserved for this /:]
18:10:22 <zbyszek> Proposal: approve
18:10:27 <music[m]> I think I’m in favor of this. I like rpmautospec overall, and I use it on packages where I’m the primary maintainer. I think it’s generally helpful in most cases. I do have some concerns about how relatively inactively maintained it seems to be.
18:11:05 <sgallagh> music: I think that was an artifact of timing rather than indicative of its actual state of maintenance
18:11:24 <sgallagh> But as noted above, I'm volunteering to help nils maintain it.
18:11:44 <nils> sgallagh, tbh I've maintained it on and off as time permitted. Often it didn’t 😬.
18:12:20 <zbyszek> nils: so what about the future? Can you give sgallagh the right acls so he can fill the gaps?
18:13:05 <nils> zbyszek, I think I can.
18:13:44 <nils> I'm not main admin of the repo but that is just for historical reasons, but main or not shouldn't make a difference
18:14:28 <zbyszek> OK, I hope we can figure this out as we go.
18:14:50 <zbyszek> Let's vote so we can go home.
18:14:50 <music[m]> I don’t blame anyone for having “on and off” availability. Stephen’s offer to help is significant, and I appreciate it.
18:15:06 <decathorpe> I volunteered some of my time for this as well. With most Rust packages using it I'm probably the single package maintainer most affected my rpmautospec bugs anyway :)
18:15:25 <zbyszek> FWIW, I think the maintainance needs should go down significantly once we fix the outstanding issues.
18:15:49 <nils> music[m], yeah, but we (CPE) need to find a way to get this more "officially" maintained (same as other projects under the CPE umbrella…)
18:15:55 <nils> zbyszek, that, too
18:16:05 <sgallagh> zbyszek: "Maintenance needs should go down significantly once we get rid of all the bugs" is an optimistic take :)
18:16:37 <zbyszek> sgallagh: I think that is true for tools written in a high-level language that have a fixed scope.
18:17:12 <nils> sgallagh, have been dealing more with features than with bugs since this went live, just saying… 😁
18:17:29 <nils> At least if memory serves me well
18:17:42 <music[m]> A lot has been fixed since the original introduction. I’m mostly focused on having someone available to handle small bugs/fixes handled in a moderately timely way.
18:19:06 <zbyszek> I'll also dedicate some time to working on the code. I have some pull requests open and I need to do updates there.
18:19:08 <music[m]> I’m happy to go ahead and vote.
18:19:18 <zbyszek> music[m]: thanks
18:19:25 <zbyszek> +1 still
18:20:02 <music[m]> +1
18:20:10 <decathorpe> +1 still
18:20:32 <sgallagh> +1
18:20:48 <mhroncok> a hesitant +1 (counts as a normal +1)
18:20:56 <zbyszek> nirik, Eighth_Doctor?
18:21:02 <nirik> +1
18:21:46 <mhroncok> Eighth_Doctor was -1
18:22:06 <zbyszek> #agreed APPROVED (+6, 0, -1)
18:22:11 <mhroncok> he was afraid of more attributions lost in RHEL
18:22:38 <zbyszek> #action nils to work with sgallagh on maintainance access
18:22:56 <zbyszek> nils: thanks for being here
18:22:56 <zbyszek> #topic Next week's chair
18:23:05 <zbyszek> vlntrs?
18:23:07 <sgallagh> mhroncok: My hope is that we will retain attribution for CS10/RHEL 10.
18:23:28 <sgallagh> And full git history.
18:23:38 <sgallagh> I can't promise it yet, but I'm arguing strongly in that direction
18:24:17 <zbyszek> OK, I can do it again if nobody wants to.
18:24:25 <zbyszek> #action zbyszek will chair next meeting
18:24:29 <zbyszek> #topic Open Floor
18:24:42 <zbyszek> Waiting one minute
18:24:49 <decathorpe> victims?
18:25:01 <decathorpe> (as my English teacher was fond of saying)
18:26:00 <zbyszek> Let's wrap this up.
18:26:01 <zbyszek> #endmeeting