[QGIS-Developer] QGIS repository management
Greg Troxel
gdt at lexort.com
Mon Oct 16 05:29:38 PDT 2023
As someone on the outside of the committer set (which is fine!) for
qgis, but familiar with the larger issues (and a packager):
I'm going to use the word committer. git has renamed things, but the
point is of course placing state in the branch that matters in the
repo that matters.
There's a question about how the rules evolved, and how they change,
and that's hard to answer, but it's not really a big issue.
The rules not being written down and understandable is a big
issue with an easy fix.
It is quite easy for someone who knows them to just put them in a
HACKING.md <humor> or CONTRIBUTING.md if you lean to github vs GNU</>.
Sandro's point about 1 committer approving a stranger's change has
some merit, but I think we have to separate:
- review to avoid bugs
- review to avoid injection of malware
Presumably, one would only approve/merge a chagne if it is clean,
neat, meets standards, works, etc., and if it were more complicated a
committer should ask others/wait/etc.
If we're going to insist on CI passing to merge, then it really needs
to pass essentially all the time. This means disabling parts of it if
they are flaky, or demoting them to a 2nd workflow that is not
considered a failure.
More information about the QGIS-Developer
mailing list