fas username: @fab package: isync issues to fix: https://bugzilla.redhat.com/show_bug.cgi?id=2302132 nonresponsive maintainer bug: https://bugzilla.redhat.com/show_bug.cgi?id=2309914 fedora-devel mail: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZYZAEA2BUYHOZVT73CVLVCTRSTU23TXS/ comainainers: @lkundrak I am interested in comaintaining the package: yes additional notes:
This is a ticket for the Fedora's Policy for nonresponsive package maintainers.
He seems to be active on GitHub, but there's no activity in Fedora since July 22 that I can see.
+1
Metadata Update from @decathorpe: - Issue tagged with: nonresponsive maintainer
fab was unresponsive during the bringup of mailman in EPEL9 too, and his packages invariably had to require Stalled EPEL escalation to releng
Note that there was a bunch of activity in dist-git last week https://src.fedoraproject.org/user/fab
and the tracking bug was closed: https://bugzilla.redhat.com/show_bug.cgi?id=2309914
Being this hard to reach is still not good, but I'm not sure it still counts as "unresponsive" right now.
We have an exception policy for exactly this reason:
"There are some cases where it may be needed to reassign a package even if this procedure has not yet finished. Examples include [...] maintainer response prevents the non-responsive process from proceeding without actually resuming maintenance."
This seems like a case of that: the maintainer is still doing other work, so they're not entirely missing, but they aren't working on the package in question or responding to requests.
For reference, without any comment -- Nonresponsive maintainer: Fabian Affolter @fab from 2022.
Well, it depends on your point of view ;-)
You will find plenty of evidence in my 15 years (or so) as packager when I didn't react as fast as the requester wanted or in the way they wanted.
I have opened PR in https://src.fedoraproject.org/rpms/python-requests-pkcs12/pull-request/1 since June. And there was sjut one response from @fab in July https://src.fedoraproject.org/rpms/python-requests-pkcs12/pull-request/1#comment-210318
I know people are busy with other tasks.
But it is much more than 4 weeks mentioned in https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/#steps
@fab We need to strike some balance. Obviously, packagers are volunteers and are not required or even expected to respond quickly. But we need to keep the cart rolling, i.e. updates need to happen. In most cases, a delay of days or even weeks is not a big issue, but when other maintainers ask for an update, and they even provide a pull request, the expectation is that the update will happen without undue delay. If you are not able to process the updates, please allow other maintainers to help: either add them as comaintainers or orphan the package. We very much do not want to forcibly change ownership of packages, but if things are stalled to the point where the work of other packagers is blocked, we'd be forced to do that.
Obviously, packagers are volunteers and are not required or even expected to respond quickly.
Agreed with the first part, but packagers are actually required and expected to respond quickly.
I think we're getting into semantics of words here, but "in a timely manner" doesn't actually mean "quickly". For example, if I always handle a version upgrade bug within a month, I'd say that it satisfies "in a timely manner", but it also certainly doesn't satisfy "quickly". A complicating issue is that we have different expectations for different bug classes. For important runtime bugs, a response after a month is not "timely". But a response within a few days would be good enough. I still wouldn't call it "quick" though.
So our definitions are not precise and they vary between types of requests, but I stand by my premise that the responses in this case were not "timely", since we're talking about months with no reply.
Let's discuss this during a meeting. I put it on the agenda for today.
@fab If you could join the meeting in #fedora-meeting as 17:00 today, that'd be great.
Metadata Update from @zbyszek: - Issue tagged with: meeting
update: we're working on a stalled request policy inspired by EPEL's (but allowing for more response time, since this affects existing branches rather than getting a package branched) - we'll discuss the proposed writing next week but we expect to give maintainers a month to respond, and the end result is adding a comaintainer rather than the very disruptive "orphan all the packages"
@fab While you're here and we have your attention, can you please add me as a co-maintainer on python-requests-futures? It's blocking a chain of things in EPEL 10. I requested the build in rhbz#2322951, and have already followed up with a needsinfo flag. I have a calendar reminder to follow up and use the Stalled EPEL process to gain access on 2024-11-21 (three weeks after the bug was opened), but it would be great if you can go ahead and add me as a co-maintainer to move things along. I'm also happy to be set as the default EPEL bugzilla assignee.
PR for a lightweight alternative process filed: https://pagure.io/fesco/fesco-docs/pull-request/94
We have a pull request, but the progress on it has stalled. We're waiting for an update after a bunch of reviews.
Metadata Update from @zbyszek: - Issue untagged with: meeting
Can this ticket be closed? The PR for policy updates should be discussed there.
Closing this, there is a PR with changes to the policy, as well as a general ticket about this topic https://pagure.io/fesco/issue/3299
Metadata Update from @humaton: - Issue close_status updated to: Rejected - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.