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.

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.)