[QGIS-Developer] QGIS repository management

Nyall Dawson nyall.dawson at gmail.com
Sun Oct 15 14:03:40 PDT 2023


For completeness:

> - 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

A potential issue which has popped up a couple of times is whether
it's acceptable for another staff member from the same organisation to
approve their colleague's PRs. Is this acceptable or not? Is it a
conflict of interest? Does it lean toward lenient reviews and getting
a speedy merge? Or is it good practice because the organisation isn't
placing any burden on others outside of their organization? 🤷 Who
knows! But definitely work discussing if we are writing up formal
policies...

Nyall






>
> 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;


More information about the QGIS-Developer mailing list