Re: on diverging memberships between alioth/salsa and unix group
Hi,
On Wed, 03 Jan 2018, Mattia Rizzolo wrote:
> One thing that always bothered me is that the QA unix group is totally
> mismatched from the alioth group, to the point that I am even in
> qa-core, but never was (and still am not) in the qa alioth team.
>
> I'm not sure we want to keep diverging on salsa as well, either we get
> a policy of sorts, or enforce that we won't add "devlopers" to the salsa
> team that are not in the unix group.
The "qa" unix group is the reference because it was the first thing we
used, plain unix group membership on shared code and data running on the
server. We did not have virtual machines and continuous delivery.
When we got a VCS, it was CVS then SVN and it relied on UNIX group membership,
so the use of the qa group continued but its role got extended.
Nowadays, the database (for VCS and for system administration) are
separate and so are the use cases. In my opinion, we should no longer
aim to sync both.
The "qa" unix group should be left as a the default (empty) group associated
to the "qa" user which is controlled by "qa-core" members (via "sudo -u qa").
Services should run as the qa user.
For most services, we already have some sort of "continuous delivery"
(under the form of "git pull" run by cron) so the "qa-core" group is
limited to the admins of the various services run by the QA team.
On the other hand, the "qa" group on salsa would be the place where all
persons with a broad interest in the QA team are. I don't think that we
should micro-manage access rights down to the project level... Debian
Developer working on some part of QA infrastructure can be added to the QA
group. Guest accounts on the other hand would be added on each project
depending on their implication.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
Reply to: