Silly proposal: meta.merger for committers weakly caring about the package

Observing the recent-ish discussions,

  1. People prefer that maintainers are people who understand the package well and care as much as achievable etc.
  2. We welcome newcomers adding a package and becoming maintainers.
  3. Significant amount of people prefer even minor-impact merges to require attention from someone with some experience.
  4. Committers checking packages they know little about — seeing the changes are reasonable and someone claims having tested and OfBorg reports things build, then merging them — do a valuable service for the community. Which is, mostly, correctly perceived as such.

I wonder if meta.merger — «I don’t care enough about the package to be able to test it or fix it, but enough to perform the slightly-overdue merges of clean-looking tested-ish changes» or something in this vein could be a practical improvement?

Maybe auto-review-request from mergers if there is still space left below the request cut-off after maintainers (I guess «no committers requested to review» is more effort to check). And definitely maintainers know that if someone agreed to this level of involvement, it’s fine to poke to get things moving, positively or negatively, but at least not stuck.

I won’t even deny that this kind of preserves some kind of bad organisational practices, but the project has bad track record with «proper solutions» and pretty good one with «whatever hacks with controversial parts removed».

1 Like
  1. It was tried before:

  1. meta is not the best place for this attribute. passthru is best.

I don’t see how RFC 128 was about the same thing — here it would still be a committer, who has done dozens of changes and reviews before, pressing the button. It’s just for recording a middle ground outside things one is willing to claim maintainership for, but closer than reviewing-randomly-sampled-open-PRs.

And I think mergers and maintainers records are better off next to each other.