on diverging memberships between alioth/salsa and unix group
So now we got matthieucan request to join our group on salsa. matthieucan was in the alioth team with his guest account, probably because the debsources repository lives in the qa namespace for some reason. 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. In cases like debsources, if they want to keep in the qa namespace (but why?), if think they should rather create the repository and then grant external, non-qa, debsources-only contributors access to the single repository, instead of the whole team. Or find a reason to have them join the whole qa group, with the unix group bit and all (on a separate note, I'd rather not add people randomly, we already have too many stale members). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: on diverging memberships between alioth/salsa and unix group
Hi, On Wed, Jan 03, 2018 at 10:52:56AM +0100, Mattia Rizzolo wrote: > So now we got matthieucan request to join our group on salsa. > > matthieucan was in the alioth team with his guest account, probably > because the debsources repository lives in the qa namespace for some > reason. > > 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. > > In cases like debsources, if they want to keep in the qa namespace (but > why?), if think they should rather create the repository and then grant > external, non-qa, debsources-only contributors access to the single > repository, instead of the whole team. Or find a reason to have them > join the whole qa group, with the unix group bit and all (on a separate > note, I'd rather not add people randomly, we already have too many stale > members). Sorry about that Mattia, just experiencing with salsa and preparing for the transition. I thought the salsa qa group would be similar to the alioth one and not the unix group. Cheers, -- Matthieu signature.asc Description: PGP signature
Re: on diverging memberships between alioth/salsa and unix group
On Wed, Jan 03, 2018 at 10:58:42AM +0100, Matthieu Caneill wrote: > I thought the salsa qa group would be similar to > the alioth one and not the unix group. That's the whole point of my email: I do not want the salsa group to be like the alioth one was :) Also, the alioth one had weird things, like there were file system ACLs to let me (with gid:qa coming from ldap, not local group db) commit to the repositories (that were otherwise group-owned by gid:qa_scm) despite not being in the alioth team (which grants you gid:qa_scm + gid:qa set by fusionforge to the local system) /o\ - please. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Uploaders statistics
[CC-ing Debian-QA list where UDD issues are probably placed most apropriately and to avoid hidden / private discussion] Hi Eriberto, thanks for providing the statistics page about uploads of maintainers https://people.debian.org/~eriberto/udd/uploaders_ranking.html I was a bit curious about the numbers since my team metrics of uploads has higher numbers. I realised that I'm counting single uploads (including different versions of the same package) which explains the different numbers. However, even if I'm counting only single packages my results are different when doing pure SQL queries (instead of doing some shell scripting magic as you do ;-) ). Feel free to check https://anonscm.debian.org/git/teammetrics/teammetrics.git/tree/eriberto_statistics.sql which does not vary in the ranking itself but the numbers are different in many cases. I have added some hints how to call psql to suppress some output you remove with "egrep -v". I did not dived deeper into this issue since I mainly got the reason for the difference of my statistics and yours. My suspicion is that the unfortunate duplication of carnivore_names might have some influence on the results. Thanks for providing the statistics page and feel free to ask me in case of any questions Andreas. -- http://fam-tille.de
Bug#886273: UDD: database table popcon_src no longer being updated
Package: qa.debian.org Severity: normal User: qa.debian@packages.debian.org Usertags: udd The database table popcon_src (used for determining which packages are key packages) is no longer being updated. Possibly related, from /srv/udd.debian.org/udd/rudd.log : D, [2017-10-29T13:43:15.348682 #2592] DEBUG -- : Finished running debian-popcon (duration: 0; status: 1) and always "status: 1" afterwards
Bug#886283: tracker.debian.org: please do NOT yell
Package: tracker.debian.org Severity: minor Dear Maintainer, tracker.debian.org/munin yells at me (and wrongly): The VCS repository is NOT up to date, push the missing commits. please change this (at least) to say: The VCS repository is not up to date, push the missing commits. or maybe better The VCS repository is not up to date, probably push the missing commits. as in the case of munin, all the commits are there. (just in the debian branch there is 2.0.34-1, while debian-experimental has 2.999.6-5, while master doesnt have any Debian relevance…) -- cheers, Holger signature.asc Description: PGP signature
Bug#886283: tracker.debian.org: please do NOT yell
On Wed, Jan 03, 2018 at 09:30:13PM +0100, Holger Levsen wrote: > as in the case of munin, all the commits are there. (just in the debian > branch there is 2.0.34-1, while debian-experimental has 2.999.6-5, while > master doesnt have any Debian relevance…) That's untrue, as the idea of Vcs-Git is that cloning what's pointed there would leave you with a checkout comparable to what's updated, which isn't case here. If the 'master' branch doesn't have any relevance please fix your repository to change the default HEAD to the 'debian' branch. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#886283: tracker.debian.org: please do NOT yell
On Wed, Jan 03, 2018 at 09:30:13PM +0100, Holger Levsen wrote: > or maybe better The VCS repository seems not to be up to date, probably push the missing commits. -- cheers, Holger signature.asc Description: PGP signature
Bug#886283: tracker.debian.org: please do NOT yell
oh wow… On Wed, Jan 03, 2018 at 09:38:09PM +0100, Mattia Rizzolo wrote: > On Wed, Jan 03, 2018 at 09:30:13PM +0100, Holger Levsen wrote: > > as in the case of munin, all the commits are there. > That's untrue, as the idea of Vcs-Git is that cloning what's pointed > there would leave you with a checkout comparable to what's updated, > which isn't case here. thats untrue given some conditional definition of reality? interesting. the repo has all the commits, that's definitly true, maybe some tool cannot find them, but then it shouldnt yell at maintainers. -- cheers, Holger signature.asc Description: PGP signature
Bug#886283: tracker.debian.org: please do NOT yell
On Wed, Jan 03, 2018 at 09:20:21PM +, Holger Levsen wrote: > oh wow… > On Wed, Jan 03, 2018 at 09:38:09PM +0100, Mattia Rizzolo wrote: > > On Wed, Jan 03, 2018 at 09:30:13PM +0100, Holger Levsen wrote: > > > as in the case of munin, all the commits are there. > > That's untrue, as the idea of Vcs-Git is that cloning what's pointed > > there would leave you with a checkout comparable to what's updated, > > which isn't case here. > thats untrue given some conditional definition of reality? interesting. > the repo has all the commits, that's definitly true, maybe some tool cannot > find them, but then it shouldnt yell at maintainers. Neither humans nor tools should have to guess which is the correct branch in a git repository corresponding to the packaging, when we have ways to specify this unambiguously. You can point master at the correct branch for the packaging, or if you prefer, you can add '-b foo' to your Vcs-Git field, as documented in Policy. The wording of the message on the tracker may be suboptimal, but I do think it's reasonable to ask that 'debcheckout' be given sufficient information to DTRT. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
