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. > What about the default point of contact. We need one packager to be the default > point of contact in bugzilla for every project/package. Currently we assume the > main-admin is that point of contact unless told otherwise via the bugzilla > overrides. > How would this work in a gitlab model if all the maintainers are at developer > level? > It won't. You'd need a separate application to maintain that information. > > - 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). > 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. > > - Question: could gitlab (inc) maintain a Community Edition GitLab > > instance that Fedora uses? > > - Answer: There is no plan to create custom versions of GitLab for > > customers. Instead, GitLab encourages paid customers and free users > > alike to contribute upstream to make sure that GitLab continues to > > work well for the most amount of users possible. As an open core > > company, GitLab has a public roadmap and works with its community > > members to build a great product. > > GitLab regularly engages with its community and takes into account its > > feedback. As a result, features are often ported down into lower tiers > > in order to make the Community Edition and Free tiers continuously > > more useful (see example of 18 features moved to open source). GitLab > > hosting is available to users of GitLab.com SaaS, but GitLab does not > > offer hosting and management for GitLab CE or EE instances. > > So, if I understand this correctly it means we have the choice between: > - self-hosting a gitlab instance > - have a dedicate space on gitlab.com > > Is that correct? > This is correct. GitLab discontinued their dedicated hosting offering (githost.io) last year to focus on the GitLab.com SaaS offering based on GitLab Ultimate. > > - 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. > > - 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. > > - Question: How would group membership be sync to GitLab? > > - Answer: We are still not 100% clear on that, since GitLab > > supports OpenIDC & we will need to investigate if we could make use of > > the group scope returned by AAA. Otherwise we will need a solution to > > sync the groups to GitLab most likely using API calls. > In my experience, you're going to need an application to sync them using the GitLab API. > > > I hope you find this helpful and it is going to take some time to work > > through everything so thank you for your patience and involvement in > > this, it is very much appreciated. > > Thanks for opening the discussion! :) > Indeed. -- 真実はいつも一つ！/ 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
