[QGIS-Developer] QGIS repository management

[Nyall Dawson]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20231016/2fb95570/attachment.htm>