On Wed, Oct 28, 2020 at 10:10 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > On Wed, Oct 28, 2020 at 09:56:11AM -0400, Neal Gompa wrote: > > On Wed, Oct 28, 2020 at 8:57 AM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > > > > > On Sun, Oct 25, 2020 at 09:17:04PM +0000, Aoife Moloney wrote: > > > > Hi everyone, > > > > > > > > Thanks again for your involvement in the GitLab AMA session on IRC in > > > > September. As promised, this is the first of a 5-part series breaking > > > > down main topics that came up during the session. I will send a topic > > > > every week for discussion to both Fedora and CentOS devel lists. I > > > > have pulled the relevant questions and answers from the original > > > > hackmd doc into one email. If you would like to discuss this topic > > > > specifically, here might be a good place to do so. I dont consider > > > > myself technical enough to weigh in on details, but I am happy to > > > > facilitate as best I can via email. And more importantly (for me), > > > > learn from the discussion too. > > > > > > > > Here are some links to resources as well: > > > > * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w > > > > * Chat log from session > > > > https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html > > > > * AMA Blog post > > > > https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346 > > > > * Here is this email in hackmd if you wish to view it there: > > > > https://hackmd.io/1pjX1cVnTjekOLVowj5UiQ?view > > > > > > > > ## Topic: Permission and Access > > > > > > > > - Question: Fedora has a group-based access system. People in the > > > > `packager` group have (commit) access to only the packages they > > > > maintain. People in the `provenpackager` group have (commit) access to > > > > all the active packages, but a few (for legal reason). People in the > > > > `releng` group have commit access to all the packages. Is this an > > > > access model that GitLab can support? If not, how would this work in a > > > > GitLab world? How would notifications work (Esp consider people in the > > > > `provenpackager` or `releng` group do not want to be notified for all > > > > the projects they have access to)? > > > > - Answer: What I explored was something along the lines of : > > > > - Packager → Using GitLab’s Maintainer or Developer role for > > > > the project they maintain (Maintainer have the ability to access > > > > project settings and change pretty much everything there, so that > > > > might be blocking here, Developer only have commit access, so we need > > > > another way to change some settings for Packagers) > > > > > > Considering the amount of settings we do not want packagers to change > > > (no-force-push, no-deletion, no FXX branch creation...), I agree that giving > > > maintainer access is likely not going to work for us and therefore it'll have to > > > be 'developer' access. > > > > > > > - Co-Maintainer → Using GitLab’s Developer role (commit access) > > > > - Proven-Packager → GitLab’s Developer role on all repo (expect 2) > > > > - Release Engineer/Admin/etc .. → GitLab’s Owner role on all repos > > > > - This is not an exact matching with what we currently have > > > > but should give us a way to experiment with this and look at what is > > > > acceptable or not. > > > > - There is also a GitLab ticket > > > > (https://gitlab.com/gitlab-org/gitlab/-/issues/7626) to implement > > > > policies for the project that could give more granular control of > > > > permissions. > > > > > > So if this gets implemented, we would be able to pick and choose which settings > > > are available to developer and which are available to admins only, is that > > > correct? > > > > > > > Maybe. I've been burned by GitLab scoping out all the actual things me > > and others ask for and building features that nobody wants and doesn't > > do enough. The Epic that replaced that issue > > (https://gitlab.com/groups/gitlab-org/-/epics/4168) seems to indicate > > that the implementation will mainly offer label and archive control > > and not much else. > > So if this ticket/epic does not get us what we want, we'll need a proxy service > to add/remove users/groups to a project? > Pretty much, yes. > > > > - Question: Fedora supports the concept of a retired `project` (ie: > > > > archived) that no-one can commit to. Does GitLab have an equivalent > > > > concept? (The retired status is not something project admins can > > > > change) > > > > - Answer: There is an option to have a “retired” group which is > > > > configured to have nobody with commit access. Then retiring a project > > > > would simply mean to move the project from the “rpm” group to > > > > “retired” group for example. > > > > There is also possibility to simply archive projects > > > > https://docs.gitlab.com/ee/user/project/settings/#archiving-a-project > > > > > > Does that mean that the URL of the project will change? (or are there redirects > > > that are automatically created?) > > > What if rpms/cockpit and container/cockpit both get retired? Can we do > > > retired/rpms/cockpit and retired/container/cockpit? Or should we do > > > retired/rpms_cockpit and retired/container_cockpit? > > > > > > > The URL would change, there would automatically be redirects when > > projects are moved (though this is glitchy and has a few caveats). > > May we assume the redirects work in both direction and clean themselves? > > As in, upon retirement: rpms/cockpit -> retired/rpms/cockpit > and upon un-retirement: retired/rpms/cockpit -> rpms/cockpit (w/ the first > redirect being removed to avoid looping (been there, done that...)) > In general, this is supposed to work, yes. > > > I figure only admins can move project between groups or archive/unarchive > > > projects. That means we'll need a way for packagers to indicate their wish to > > > retire a project and then a bot to actually do it. > > > > > > > Maintainer level and above can archive projects, since that means they > > have access to project settings. They also can move projects across > > groups that they have project creation rights (maintainer or above) > > in. > > Sorry I phrased this incorrectly. It assumed that only admins have access to > maintainer level and above (based on the first section that we cannot have > packager have more than the developer level). > > Thanks for pointing this out. > > The point about needed automation through a proxy still stands though, no? > Yep. Just wanted to clarify what we can actually do here in GitLab itself. > > > > - Question: Can project creation be restricted to a specific group of > > > > people in GitLab? > > > > - Answer: Yes this can be configured at the instance level > > > > (https://gitlab.com/help/user/admin_area/settings/visibility_and_access_controls.md#default-project-creation-protection) > > > > or at the group level > > > > (https://gitlab.com/help/user/group/index.md#default-project-creation-level) > > > > > > Does the instance level override the group level one? If not can group admins > > > change this setting? > > > If so, is there an access level in groups that allows to add/remove people from > > > a group without being allowed to toggle that setting? > > > > > > In other words, can we let the groups self-managed without "risking" someone > > > changing this configuration? Or do we need to figure out a process to add/remove > > > people to groups? (Like a ticketing system that is automatically process by a > > > bot) > > > > > > > The inheritance order for most settings (in my experience) indicates > > that project settings override instance settings (as they are only > > defaults). For example, if you configure CI or issue tracking as off > > in the instance wide settings, projects can override this and turn > > them back on. Same goes for artifact archiving policies and other > > instance level settings for projects. > > So another proxy needed to add/remove people from a group then I guess? > Yep. > > > > - Question: Can project (main project, not fork) deletion be > > > > restricted to a specific group of people in GitLab? (ie: project > > > > owner/maintainer must not be allowed to delete a main project, they > > > > can delete their own fork of course) > > > > - Answer: There is an issue > > > > https://gitlab.com/gitlab-org/gitlab/-/issues/233379 that could help > > > > with this by requiring an additional person approve the deletion & > > > > there’s a related issue > > > > https://gitlab.com/gitlab-org/gitlab/-/issues/227468 to create a list > > > > of authorized approvers for these types of changes (not MRs) that > > > > sounds aligned with this ask > > > > > > So we would need an admin person to delete a main project, that sounds fine. > > > What about forks though? Would we be able to let user delete their own fork > > > without supervision? > > > > > > > Forks are not special in GitLab like they are in Pagure, so rules > > applied to main projects will apply to forks. > > I'm starting to think that disabling project deletion to everyone but admins > and have another proxy service that let people request their fork to be deleted > may also be the way forward here. > I think we're looking at having a pkgdb3 web service if we move forward with GitLab, simply because there's no way to actually *implement* everything we need in GitLab itself. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
