Updating the dbus committers list

[Simon McVittie]

As you might have seen, the dbus freedesktop.org project is in the process
of migrating to the new freedesktop.org Gitlab. This project consists of:

- "core":
  - the D-Bus specification (hosted as part of the reference implementation)
  - the reference implementation, dbus (migration pending)
- language bindings:
  - dbus-java (inactive, migration pending)
  - dbus-glib (deprecated, already migrated)
  - dbus-python (semi-deprecated, already migrated)
  - dbus-mono (EOL, migration and archival pending)
  - dbus-qt (EOL, migration and archival pending)
  - dbus-qt3 (EOL, migration and archival pending)
- misc:
  - dbus-test (inactive, migration pending)
  - dbus-doc (EOL, migration and archival pending)

Our current hosting arrangements were set up many years ago, at a time
when code review and the merge-request workflow were a lot less
well-established than they are now. As a result, quite a lot of people
are members of the 'dbus' Unix group, which gives them direct commit/push
access.

For now, members of that group have been given "Maintainer" access in
the Gitlab group. However, I don't think all of these people should
retain direct commit access: these days we emphasize a workflow with
code review from maintainers (even if the author of the code is another
amintainer). On Gitlab, membership of the group also implies the ability
to read private issue reports (mainly used when a security issue is
reported), which is not something we really want to be spreading around
too much.

I think we should take this opportunity to cut down the maintainers list
so that it more closely resembles the active membership of the private
dbus-security mailing list. These are the people who are responding
to security issues in practice, and the people who are reviewing code
in practice.

If former maintainers want to come back and take an active role, we can
of course reinstate their access at any time, and I'll be happy to do so
(in Gitlab, this no longer needs sysadmin intervention and can be done
on a self-service basis by anyone with the Maintainer role). What I'm
trying to do here is to apply a more least-privilege access control model,
so that people have the access level they need to do what they do.

Please reply to dbus-security at lists.freedesktop.org (which is
closed-membership, but is open for public posting) if you are not already
a member of that mailing list but feel that you ought to be listed as
a D-Bus maintainer. Bear in mind that with power comes responsibility:
if you are a D-Bus maintainer, I'll expect you to help out with code
review, security fixes and/or bug fixes :-)

I'm assuming that anyone who isn't reading dbus@ any more is presumably
already de facto not a maintainer, so I'm deliberately not sending this
to individual developers.

The move to Gitlab also means we can grant additional privileges
on individual projects (git repositories), so we can make someone a
Maintainer or Owner of one project without needing to make them a
Maintainer or Owner of the whole dbus group. I'm intending to make use
of that to give the author dbus-java and dbus-test privileged access
to those two repositories.

Regards,
    smcv