Updating the dbus committers list
Simon McVittie <smcv-ZGY8ohtN/[email protected]>
| Newsgroups | gmane.comp.freedesktop.dbus |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] (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 _______________________________________________ dbus mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dbus