Hi @hainest, English is not my first language, so I apologize if this comment is too long and poor quality.

I tried to accelerate PR reviews. For this, I attempted to review pull requests building the changed packages, versions and variants. It wrote a prototype script to be ultimately used for CI.

Getting feedback faster than the gitlab-ci job would be great.

It was developed after many weeks of work on getting the changes from the PR and writing code to check the changes. Because of (very few) failed attempts where the build errors automatically reported in the PR by the script were confusing and contained some hints for package maintainers that weren't approved, this project was (hopefully only temporarily) stopped. The spack steering committee is expected to decide on its future next week.

In the meantime, because it is not integrated into CI (at least at the moment), it is also too time-consuming for me personally, so for now, I am not reviewing PRs until a solution has been found.

I would encourage you to continue reviewing PRs as you feel comfortable, but I understand wanting to be less active without an automated pipeline.

A big blocking issue that needs to be solved is that the project I started to build PRs needs approval from maintainers and packagers, and needs contributors. If you could be interested in helping to get this project afloat and (hopefully) integrated into CI properly, please join the repository I started to start this development. Pull requests for it would be very welcome. The fact that I started this project alone was described as an issue, so it needs participants. Meanwhile, it is usable and installable as an extension script on top of the GitHub CLI:

https://github.com/spack/gh-spack-pr

I'll try to help, if I can find some time. Right now, I would really like to get the Boost conditional variants finished up. I've found a large number of bugs across many packages as I've been testing my changes to Boost, so it's been a slow process.

Otherwise, please invite another spack reviewer for review, and you can ask for a review in #pull-requests. A spack Q&A Telcon is coming up, and anything about spack can be discussed (including CI and handling PRs): https://github.com/spack/spack/wiki/Telcon%3A-2024-11-05 The meeting invitation (using Zoom) to join the meeting is the #general Slack Channel of spack (the invitation is sent each week): https://spackpm.slack.com/archives/C5W7NKZJT/p1730331138729659?thread_ts=1728337005.104389&cid=C5W7NKZJT

Since you are a member of merge-to-develop, I would again encourage you to still work with PRs as you feel comfortable. The ratio of PRs to spack maintainers is almost impossibly large.

Pull requests submitted by a package maintainer would be really nice to have reviewed quickly as soon as the CI pipelines pass. That's definitely self-serving, but I think it's a place where you could be effective without needing to spend too much effort.

Pull requests submitted by a package maintainer would be really nice to have reviewed quickly as soon as the CI pipelines pass. That's definitely self-serving, but I think it's a place where you could be effective without needing to spend too much effort.

Great idea and point! My script https://github.com/spack/gh-spack-pr/blob/main/cli/check.py meanwhile has a check if a PR is submitted by the maintainer of the changed package(s), and it could show this information to reviewers by setting a label.

Spackbot is already an active, automated app that has the same information:
It also checks the maintainers of the changed packages.
When the PR author maintains all the changed packages, it could set a label to make his information visible and selectable to reviewers and mergers.

We should note this as an improvement for Spackbot so reviewers and mergers see this information immediately (and with labels, they can also select PRs for review/merge with this as a search query condition for prioritizing the review and merge of these PRs)

This could also provide a great incentive to the submitters of PRs to add themselves as package maintainers.
We should remember to take note of this as well.