On Sun, 28 Jan 2018 09:42:02 +0100, intrigeri wrote:
> > So now we have
> > group perl-team: owners Dom ntyni and me
> > subgroup interpreter: owners (explicitly set) Dom and ntyni
> > subgroup modules: owners (explicitly set) Dom ntyni me and carnil [0]
> > subgroup packages: inherited members
> > subgroup attic: inherited members
>
> Looks great to me, thanks!
Thanks :)
Some observations, questions, and rants, from my work yesterday:
Sharing
=======
I wanted to make the repos accessible for all DDs, like we did on
Alioth. It seems that the term for that is "sharing with group
'Debian'". And it seems that it's not possible to share a (sub)group
but only individual projects, aka repositories.
Or did I miss something?
This is of course painful to do for all future 3500 repos, and then
for new repos, etc. And the API doesn't make it better:
- sharing and unsharing is terribly slow (several seconds before the
call returns), in the back of my head I saw busy tiny persons
running through a PostgreSQL database and adding/removing all the
IDs ...
- sharing/unsharing also has a delay, I had to wait for about a
minute until project_users showed the correct output
- sharing/unsharing are not idempotent, i.e. sharing fails when the
project is already shared, unsharing fails if the project is not
shared. That's not insane per se, but there doesn't seem to be a
method to list current shares. In dpt-salsa I now check if the user
with id 1 (that's the salsa administrator) is a project user
*cough*
Unless I missed something, that's all a bit tedious. Maybe we should
just forget about this sharing business?
Permissions
===========
AFAICS, access level "manager" is needed in a subgroup to allow the
members to add new projects, i.e. push new repos, which is what we
want. -- This seems to have the interesting side effect that all those
"managers" get all "join requests" (in the To: header) :/ It sounds a
bit unfortunate to send them to (in the future) 100 people.
Did I miss something here?
Join requests
=============
I turned off the possibility to ask for membership on the top-level
"debian-team" group and pointed to the "debian-team / modules"
subgroup in the description.
Given the issue mentioned above (recipients) and the unhelpful mails
generated by GitLab (user can't add a message to their request; no
info who actually requests access in From or Subject; no possibility
to reply or to find out user's email address; broken signature
delimiter -- ok, that's just aesthetic), I'm wondering if we should
turn off the join request feature and just point to the mailing list
and/or homepage (like other teams already do).
(Or, as carnil proposed in IRC, to turn them off at least while we're
still preparing the migration.)
Search restriction
==================
It looks like the search parameter of the API's projects method does
a substring match. So when I had added a 'testrepo' and a 'testrepo2'
project, the search for "testrepo" found both. [0] Not sure if this
bites us; and maybe going name->encoded-path instead of name->id
could solve this problem, if it is a problem.
Ok:
% gitlab-api-v4 project 7757 | jq .
and
% gitlab-api-v4 project perl-team/modules/packages/testrepo1 | jq .
do the same (gitlab-api-v4 does the URI encoding for us), so we can
use this in dpt-salsa. Good. </monologue>
[0] also https://forum.gitlab.com/t/gitlab-api-project-search-exact-match/4831
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Aimee Mann: I Should've Known
Attachment:
signature.asc
Description: Digital Signature