[opensuse-factory] Maintainer request: proftpd
Dear Users and packagers, It appears as if the package proftpd is in need of an additional (or new?) maintainer. The package has been unresolvable in openSUSE:Factory for a very long time. I did the work of upgrading and fixing this, all submitted as https://build.opensuse.org/request/show/849450 But seems nobody is picking up the pieces. There is currently only one maintainer assigned (Christian) and the devel prj maintainers (rightly) wait for the actual package maintainer. I'm sure Christian would welcome somebody else designated to co- maintain this package. Any volunteers? Your first act as maintainer would be to make the package build in Tumbleweed again :) cheers, Dominique
On Wednesday 2020-11-25 16:36, Dominique Leuenberger / DimStar wrote:
https://build.opensuse.org/request/show/849450 But seems nobody is picking up the pieces.
There is currently only one maintainer assigned (Christian) and the devel prj maintainers (rightly) wait for the actual package maintainer.
You can't claim a nopickup situation while people give the courteous wait time. Eventually, staging-bot will nag again via email (probably at the 7day mark?), at which point this would see attention by prj maintainers (ideally). When the wait time is >30d --and the SR is comment-free--, that's the point to get worried. The problem with extra pkg maintainers is that they tend to become overeager and not respect review roles, let alone the courtesy review periods. And open-build-service is doing little to help on that end.
Hi, Am 25.11.20 um 17:28 schrieb Jan Engelhardt:
The problem with extra pkg maintainers is that they tend to become overeager and not respect review roles, let alone the courtesy review periods. And open-build-service is doing little to help on that end.
could you elaborate a bit more or link to some guide, please? I have been in situations, too, where co-maintainers/devel project maintainers complained about accepting and forwarding too fast. On the other hand, I see packages updated by dedicated package maintainers directly without even going through a branched project and SR. Cheers, Ben
On Wednesday 2020-11-25 18:21, Ben Greiner wrote:
Am 25.11.20 um 17:28 schrieb Jan Engelhardt:
The problem with extra pkg maintainers is that they tend to become overeager and not respect review roles, let alone the courtesy review periods. And open-build-service is doing little to help on that end.
could you elaborate a bit more or link to some guide, please? I have been in situations, too, where co-maintainers/devel project maintainers complained about accepting and forwarding too fast.
The problem in detail: 1. OBS makes no distinction between "primary" package maintainer(s) and "secondary" package maintainers, which leads some secondaries to act like primaries. 2. OBS offers a way to add a {person=Primary, role=reviewer} role on a package, which can be used as a way to remind secondaries that a primary reserves judgement on submissions. When trying to accept such a request that is subject to such a role, OSC will initially reject the attempt, and OBS(webui) will at least display a "confirm forced action" dialog that they are overstepping. However, this dialog is just clicked away (presumably) without being read. -> basically terrible UI 3. OBS does make a distinction between package maintainers and project maintainers (which, in a sense become "tertiary" package maintainers), and OBS does present tertiaries with a yellow warning box that they are potentially overstepping. -> this design seems to work; the occurrences per year that lead to getting uptight seem minimal.
On the other hand, I see packages updated by dedicated package maintainers directly without even going through a branched project and SR.
In the above sense, the secondaries (and tertiaries) are meant to step in in cases of absence, but little else. Considering the "slowness" of the built-in OBS SCM — it's modeled like, and shares the latencies of, Subversion — eschewing the branch-submit-selfaccept dance if one oneself is the maintainer is a timesaver, and it does not needlessy notify the vacation squad. (Another shortcoming: the subsequent submit to factory _does_ notify them... which arguably could receive a tuning knob too.)
On 11/26/20 3:51 AM, Ben Greiner wrote:
Hi,
Am 25.11.20 um 17:28 schrieb Jan Engelhardt:
The problem with extra pkg maintainers is that they tend to become overeager and not respect review roles, let alone the courtesy review periods. And open-build-service is doing little to help on that end.
could you elaborate a bit more or link to some guide, please? I have been in situations, too, where co-maintainers/devel project maintainers complained about accepting and forwarding too fast. On the other hand, I see packages updated by dedicated package maintainers directly without even going through a branched project and SR.
There is no real guide here, generally its up to each project / team to make there own rules. Many of the larger projects have a rule where someone other then the author needs to review and accept the submission, through to small packages where there is only one maintainer that cares and can accept there own requests straight away. Generally for packages I co maintain, unless its a simple obvious fix, i'll give it 24hrs before accepting my own submission so others have some time to review the package if they want to. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
participants (4)
-
Ben Greiner -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Simon Lees