On Mon, Nov 23, 2020 at 10:22:25AM +0000, Aoife Moloney wrote: > # GitLab AMA Session Topic - Namespace & Issue Tracking > > Hi everyone, > > Thanks again for your involvement in the GitLab AMA session on IRC in > September. This email discussion thread is on Namespace & Issue > Tracking. I have pulled the relevant questions and answers from the > original hackmd doc into one email and if you would like to discuss > this topic specifically, here might be a good place to do so so your > conversations don't go down a 'rabbit hole' :) > > 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/oZrDwbSeSWO-l_X65A1ndg?view > > ## Namespace & Issue Tracking > - Question: Currently dist-git in Fedora has several namespaces: rpms, > modules, containers, tests... All namespaces but the ``tests`` > namespace have their issue tracker in bugzilla. Would this work in > gitlab? Can we selectively enable/disable issue tracking per namespace > for the entire instance? (ie: w/o giving the possibility to ``owner`` > or ``maintainer`` to toggle that setting.) > - Answer: It may need to be checked again, but it appears you can > turn on/off the issue tracker at the project level. Which would be fine since only infra and releng would be admins, so "regular" packager could not turn this feature back on. > - Question: Currently dist-git in Fedora has several namespaces: rpms, > modules, containers, tests... All namespaces but the ``tests`` > namespace have their issue tracker in bugzilla. Would this work in > gitlab? Can we selectively enable/disable issue tracking per namespace > for the entire instance? (ie: w/o giving the possibility to ``owner`` > or ``maintainer`` to toggle that setting.) > - Answer: You can turn the GitLab issue tracker on and off by > project. See https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions > Namespaces map to “group” in GitLab. Here’s more info about them: > https://docs.gitlab.com/ee/api/namespaces.html Looks like a duplicated question, but the answer is the same :) > - Question: Fedora, as far as I understand, still plan on using > bugzilla as issue tracker. Currently default assignee and the CC are > gathered using the ``main admin`` (ie: the ``owner`` for GitLab iiuc), > the other maintainers (who did not ``unwatch issues`` in the project - > mechanism for them to opt-out of being in the CC list) and the people > having enabled ``Issue watching`` for the project (mechanism for them > to opt-in into being in the CC list). Would this work in a GitLab > world? > - Answer: There are a number of options related to that. For one, > users can control their notifications globally and by name space in a > fine grained way (see GitLab Notification Emails). This is not actually answering the question. We need two information for every project/package: - a default assignee (a single person) - a list of people to add on Cc Currently it is: - default assignee == main admin - Cc list == - all packagers with commit access and above who have not "unwatch" the project (which is the mechanism allowing packager with commits to not be included in the Cc list, this is used among others by the kernel folks) - everyone who "watches issues" on a package (even if they are not packagers). >From one of the previous threads, I believe the solution thought for this was basically: pkgdb3 It would be our central system to integrate gitlab with every other application that is package related in Fedora (anitya, bugzilla, new package requests, new branch requests, ACL requests). pkgdb2 was a glorified gitolite admin UI, pkgdb3 would be a glorified gitlab admin UI :) Pierre _______________________________________________ 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
