<div dir="ltr"><br>> A small group of us (3-4 developers including me) have admin access to<br>> all QGIS repositories and we can bypass any check and merge all PRs<br>> without approval.<div><br></div><div>I have this power too -- and I use it on a daily basis to keep the whole CI setup flowing (ie restarting workflows in other's PRs, merging approved PRs when an unrelated workflow failure has blocked a merge, etc).</div><div><br></div><div>I'd like to point out that it's only used to keep the project humming along for EVERYONE's benefit -- it's not a conspiracy to create a set of "super committers" with extra power 😂 . </div><div><br></div><div>Nyall</div><div><br></div><div><div><br>><br>> I admit that I have been using these superpowers more and more often<br>> (IIRC three or four times) in the last year while I have never felt<br>> the need to use them before, in an ideal world it should not be<br>> necessary except for the same use cases I have pointed out for the<br>> direct pushes to master.<br>><br>> The bottom line is that the situation is not perfect and can certainly<br>> be improved but at the end of the day we are all doing our best to<br>> keep the process running as smoothly as we can.<br>><br>> Thank you for raising this point, you are absolutely right that it<br>> should be clearly documented, this has been in our TODO list for a<br>> long time.<br>><br>> Best regards.<br>><br>><br>> On Fri, Oct 13, 2023 at 6:42 PM Sandro Santilli via QGIS-Developer<br>> <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>> wrote:<br>> ><br>> > Hello all,<br>> > today I was finally able to more clearly see the problem that frustrates<br>> > me everytime a take part to a new QGIS bugfixing drive, and I would like<br>> > to share it hoping to find a solution togheter.<br>> ><br>> > The main problem:<br>> ><br>> >   - Despite having been granted write access to the QGIS repository in 2012<br>> >     [1], I cannot effectively use that power today<br>> ><br>> > It's not just me, I think, but I cannot tell for sure because the configuration<br>> > of the infrastructure currently in use (github) is not available for me to see<br>> > and the governance page on the official QGIS website does not contain this<br>> > information [2]. This being blind of course adds up to my frustration.<br>> ><br>> > From experience, I know that the reason why I cannot write to the QGIS<br>> > repository is because "branch protection" is active (for the master branch<br>> > at least) and a set of conditions are required to merge a PR, namely:<br>> ><br>> >   - All CI tests need to pass.<br>> ><br>> >   - Someone else (I don't know from which group of people) needs to<br>> >     approve the proposed change.<br>> ><br>> > While I do the above condition being a useful indication for "QGIS<br>> > core developers" to decide whether to accept or not a change request,<br>> > I find them representing an obstacle way more often than a service,<br>> > and in particular:<br>> ><br>> > 1. CI is often broken for reasons that are independent from the proposed<br>> >    change.<br>> ><br>> > 2. An aberration of the "review" condition is that a change proposed by a<br>> >    contributor and approved by me can be merged but a change proposed by<br>> >    me and approved by the same contributor can not be merged, effectively<br>> >    giving me ("core QGIS committer") less power than the power of a random<br>> >    contributor.<br>> ><br>> > The rules described above are not found from the governance page [2]<br>> > so it isn't easy for me to propose changes because I don't have a clear<br>> > picture of current rules (like, I believe some people in QGIS can<br>> > self-approve PRs but dunno how to tell who and why).<br>> ><br>> > I would personally welcome (and be able to help taking) the following actions:<br>> ><br>> >   1. Clearly document the roles and rules on the website<br>> ><br>> >   2. Allow those with "write access" to self-approve PRs<br>> ><br>> >   3. Define rules by which "write access" privileges to the repository<br>> >      are revoked<br>> ><br>> > Thanks for having read this in full, and I hope to hear your position<br>> > on the matter.  Happy hacking !<br>> ><br>> ><br>> > [1] <a href="https://lists.osgeo.org/pipermail/qgis-developer/2012-October/022715.html">https://lists.osgeo.org/pipermail/qgis-developer/2012-October/022715.html</a><br>> > [2] <a href="https://qgis.org/en/site/getinvolved/governance/governance.html">https://qgis.org/en/site/getinvolved/governance/governance.html</a><br>> ><br>> > --strk;<br>> ><br>> >   Libre GIS consultant/developer<br>> >   <a href="https://strk.kbt.io/services.html">https://strk.kbt.io/services.html</a><br>> > _______________________________________________<br>> > QGIS-Developer mailing list<br>> > <a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>> > List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>> > Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>><br>><br>><br>> --<br>> Alessandro Pasotti<br>> QCooperative:  <a href="http://www.qcooperative.net">www.qcooperative.net</a><br>> ItOpen:   <a href="http://www.itopen.it">www.itopen.it</a><br>> _______________________________________________<br>> QGIS-Developer mailing list<br>> <a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div></div></div>