there seems to be high interest i contributions to GRASS at the moment, I assume due to GSoC. This is great. Limits on CI resources in the GRASS repo / OSGeo organization however, may be perceived as a bottleneck and slow down time from PR creation to merging…
We should think about how to minimize that delay.
Personally, I have good experience with creating WIP-PRs in my fork, so I can see that all relevant checks pass before opening a PR in the GRASS repo for wider review and discussion… Maybe something to consider for this fase of GSoC?
Also, maybe worth deactivating flaky tests that fail every now and then for other reasons than code changed in the PR (like the SMAP test)…
Just some thoughts on how to mitigate current pressure on CI ressources…
I don’t have a lot of opinion on this, but I agree we could deactivate i.smap test. Note that at least for first-time contributors, a maintainer needs to activate the CI, which is sometimes annoying, but at least that protects the CI. Some contributors use the update branch button unnecessarily, worsening the situation, but I do like to have it there as a maintainer.
I don’t have a lot of opinion on this, but I agree we could deactivate i.smap test. Note that at least for first-time contributors, a maintainer needs to activate the CI, which is sometimes annoying, but at least that protects the CI. Some contributors use the update branch button unnecessarily, worsening the situation, but I do like to have it there as a maintainer.
