[QGIS-Developer] QGIS repository management

[Nyall Dawson]

On Mon, 16 Oct 2023 at 09:44, Sandro Santilli <strk at 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;