[QGIS-Developer] QGIS repository management

[Alessandro Pasotti]

Hi Sandro,

Disclaimer: these are my personal opinions and not the official PSC position.

I understand your frustration, CI is often failing for no reason and
we are wasting a lot of time (and CPU power) to re-run the failing
workflows, any effort to fix these issues is greatly appreciated.

About the merge constraints, I think that they are important and
useful because CI failing tests have proven to be a sign of a real
problem in the past, and also because peer review (PR approval) is
almost always useful to prevent mistakes and ultimately leads to a
better and safer code.

Coming to your questions, AFAIK whoever has commit rights can approve
someone else's PR but cannot self approve (see the exceptions below
about bypassing the blocks).

The QGIS organization has a budget for PR queue management (triage)
and a separate entry for reviews (budget is public
https://www.qgis.org/en/site/getinvolved/governance/finance/index.html)
, in the past this has been working well while I agree that recently
PRs have been pending without review for a (too) long time.

If I am not mistaken, everyone with commit rights can still push to
master directly without opening a PR, this is not generally
recommended (I think I have been doing this only once or twice in the
last few years), however a direct push to master is acceptable for a
few cases (e.g. to fix an one-liner change issue where the developer
is fixing his/hers own mess and is 100% sure there will not be side
effects, fix a typo in a comment, for last minute fixes done by the
package maintainers when making the releases etc.).

A small group of us (3-4 developers including me) have admin access to
all QGIS repositories and we can bypass any check and merge all PRs
without approval.

I admit that I have been using these superpowers more and more often
(IIRC three or four times) in the last year while I have never felt
the need to use them before, in an ideal world it should not be
necessary except for the same use cases I have pointed out for the
direct pushes to master.

The bottom line is that the situation is not perfect and can certainly
be improved but at the end of the day we are all doing our best to
keep the process running as smoothly as we can.

Thank you for raising this point, you are absolutely right that it
should be clearly documented, this has been in our TODO list for a
long time.

Best regards.


On Fri, Oct 13, 2023 at 6:42 PM Sandro Santilli via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> Hello all,
> today I was finally able to more clearly see the problem that frustrates
> me everytime a take part to a new QGIS bugfixing drive, and I would like
> to share it hoping to find a solution togheter.
>
> The main problem:
>
>   - Despite having been granted write access to the QGIS repository in 2012
>     [1], I cannot effectively use that power today
>
> 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.
>
> 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.
>
> While I do the above condition being a useful indication for "QGIS
> core developers" to decide whether to accept or not a change request,
> I find them representing an obstacle way more often than a service,
> and in particular:
>
> 1. CI is often broken for reasons that are independent from the proposed
>    change.
>
> 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.
>
> The rules described above are not found from the governance page [2]
> so it isn't easy for me to propose changes because I don't have a clear
> picture of current rules (like, I believe some people in QGIS can
> self-approve PRs but dunno how to tell who and why).
>
> I would personally welcome (and be able to help taking) the following actions:
>
>   1. Clearly document the roles and rules on the website
>
>   2. Allow those with "write access" to self-approve PRs
>
>   3. Define rules by which "write access" privileges to the repository
>      are revoked
>
> Thanks for having read this in full, and I hope to hear your position
> on the matter.  Happy hacking !
>
>
> [1] https://lists.osgeo.org/pipermail/qgis-developer/2012-October/022715.html
> [2] https://qgis.org/en/site/getinvolved/governance/governance.html
>
> --strk;
>
>   Libre GIS consultant/developer
>   https://strk.kbt.io/services.html
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



--
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it