[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