But as one of the members with the maintain role (higher than triage and write), he has access to bypass permissions. If you go look back in the PR where I explained the branch rules, I showed the checkbox that allows to bypass for example in PRs. Here is the public combined view of the rules that are active for releasebranch_8_3 https://github.com/OSGeo/grass/rules/270686?ref=refs%2Fheads%2Freleasebranch_8_3 and https://github.com/OSGeo/grass/rules?ref=refs%2Fheads%2Freleasebranch_8_3
Note how they are different than https://github.com/OSGeo/grass/rules?ref=refs%2Fheads%2Fmain It was made such as changing workflow requirements for main don’t restrict the older branches to be merged, or that changes in the CI infrastructure (outside of our repo) make it so they don’t work anymore. So they are kind of run on a best-effort basis, instead of religiously. Edouard Choinière Le 20 févr. 2024 à 06:45, Nicklas Larsson <n_lars...@yahoo.com> a écrit : On 20 Feb 2024, at 10:14, Markus Neteler via grass-dev <grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>> wrote: In fact the slowest CI run determines how much time I have to wait with each release step (i.e., editing VERSION file, wait 1:30hs, do some steps, wait 1:30hs, create tarball, wait 1:30hs, reset VERSION file, wait 1:30hs ... which is a pain). I agree this is a case where we have limited ourself too much, with all those required 1.5 hrs tests, approval, etc. (not even [skip ci] would work) . What you would need is a (ideally) direct commit access or at least “Rebase and merge” option to merge (thus enable a number of commits to be merged at one time, as opposed to "Squash and merge”). We must find a solution to improve this situation for preparing releases, I wouldn’t mind temporary lifting necessary constraints.
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
