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/
