Hi Sandro,
Thanks for raising this discussion. I'll add my knowledge inline below.
But please keep in mind that all this stuff has just been set over time in
a reactionary/evolutionary process to keep things running smoothly, rather
than something which was designed and formalised by a committee in advance.
There's always room for improvement and revision to match current needs! 👍
On Sat, 14 Oct 2023 at 05:43, Sandro Santilli via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
> It's not just me, I think, but I cannot tell for sure because the
configuration
> of the infrastructure currently in use (github) is not available for me
to see
> and the governance page on the official QGIS website does not contain this
> information [2]. This being blind of course adds up to my frustration.
This page **definetly** needs an update. There's information on that page
which is ~decades out of date (eg Larry Shaffer hasn't been involved in the
project for around 10 years, the OSX packaging team is incorrect, and the
whole "testing" team is non-existent, etc).
I'm happy to help out here with removing old content. My gut feeling is
that a more exhaustive rework is needed and repository / process related
information doesn't belong on this page, and the page should be left to the
"organisation" level governance information alone.
> From experience, I know that the reason why I cannot write to the QGIS
> repository is because "branch protection" is active (for the master branch
> at least) and a set of conditions are required to merge a PR, namely:
>
> - All CI tests need to pass.
>
> - Someone else (I don't know from which group of people) needs to
> approve the proposed change.
Correct. And I would argue that both of these requirements are a valid
**MINIMUM** protection choice for introducing code into a project which has
real world cost impacts for users exceeding millions and potentially
impacting the lives and safety of others.
> 1. CI is often broken for reasons that are independent from the proposed
> change.
Definitely a valid issue, and a real PITA. I'm probably restarting that
mingw workflow ~20x a day for everyone's(!) PRs to keep it limping along.
That said, I'd still rather limp this workflow along vs removing it,
because I do believe that it adds value to our tests and gives end users an
easy way to test PRs prior to merge. I feel the same about the noisy
clang-tidy check: it has a LOT of false positives, but around 1 in 10
failures in that workflow is a valid bug which has been flagged prior to
introducing the code. That's still a net win in my view.
> 2. An aberration of the "review" condition is that a change proposed by a
> contributor and approved by me can be merged but a change proposed by
> me and approved by the same contributor can not be merged, effectively
> giving me ("core QGIS committer") less power than the power of a random
> contributor.
Maybe -- but I would argue that you're looking at the "core contributor"
privilege incorrectly. It's no longer a "you are trusted to put whatever
code you want into the project" vs a "you are trusted to peer review and
approve code proposed for introduction into the project".
Ie **everyone** is on the same level wrt to submitting code for review, but
only the trusted group of core committers are permitted to approve this
code for introduction to QGIS.
> 1. Clearly document the roles and rules on the website
+1
> 2. Allow those with "write access" to self-approve PRs
-1. What's the real motivation here? Why the urgency to get unreviewed code
into QGIS? Again, I am strongly of the opinion that more exhaustive code
merging policies protects our users and their trust in QGIS.
> 3. Define rules by which "write access" privileges to the repository
> are revoked
+1
Nyall
_______________________________________________
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
