On Mon, 16 Oct 2023 at 09:44, Sandro Santilli <s...@kbt.io> wrote: > > On Mon, Oct 16, 2023 at 08:58:30AM +1300, Nyall Dawson wrote: > > On Sat, 14 Oct 2023 at 05:43, Sandro Santilli wrote: > > > > > 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? > > A recent example of urgency: I broke the pre-commit hook for most > developers, I could have pushed the fix earlier if I didn't have > to wait for a review.
That's a fair example, I'll concede that point! I wonder if tagging the commit with "[skip ci]" would still permit the merge request to be merged? It's worth a test. > > The other motivation is not about urgency but about a conflicting policy: > > - I can be the _only_ reviewer approving a complete stranger's > proposed change. > > - I can NOT be the _only_ reviewer approving my proposed change. > > Is trust given to _me_ as a "reviewer" or not ? > It is in the first case, it isn't in the second case. If you flip the situation, you'll see that yes, you do have trust! - a complete stranger CANNOT approve their own changes - a complete stranger CANNOT approve other stranger's changes - a complete stranger CANNOT approve an approved member's changes vs - an approved member CANNOT approve their own changes - an approved member CAN approve a complete stranger's changes - an approved member CAN approve a another approved member's changes I think the misunderstanding is all about naming. If we drop the confusing "core committer" label and change it to "approved reviewer", then everything becomes clear. (and then we have a separate "super user" group with repo admin level privileges, which should be kept as SMALL as possibly needed to keep the repository and CI working, and is unrelated to code/trust/experience/etc...) > Another policy I believe in is that whoever is allowed to apply > changes to the repository should take on the responsibility of > fixing bugs introduced by those changes. I'm a hesitant +0 to this. I do think we've all got a good track record of fixing our own mistakes within reasonable expectations. I'd be concerned that formalising this would put a lot of unreasonable expectations on developers (where's the limit? If it's found that I broke some esoteric workflow not covered by unit tests 3 years later, am I still responsible for fixing that? I'd argue not). Nyall > > --strk; _______________________________________________ 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