@andr3: If you’d like to share more details on the topic of guaranteeing order, I created a placeholder issue where we can gather your thoughts: https://gitlab.com/gitlab-org/gitlab/-/issues/247518 Feel free to jump on it. Thanks!
@misc: @mboddu: if the feed is in order, it would be, no ?
@zbyszek: @gregmyers: see https://pagure.io/fesco/issue/2383 ("=== Status quo") for a short high-level description.
@mhroncok: misc: we use the messages to trigger certain CI/CD events. I don’t think cron would do, this should happen “immediately” in ideal circumstances
@jlanda: what will happen if the exact needa are not doable? will fpc be forced to alter its policies?
@misc: @mhroncok: cron every 2nd is immediate 
@misc: second
@gregmyers: Thanks to @pingou for the diagram and @zbyszek for the details, I’ll join the mailing list @siddharthvipul @mattdm
@amoloney: #topic Namespace and issue tracking
@amoloney: two related questions:
@misc: @mhroncok: but something like use message, and also a cron to trigger message that might be down or something ?
@amoloney: 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.)
@mhroncok: misc: right, but maybe a while loop serves better than 2 second cron? 
getting too detailed anyway…
@amoloney: 
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?
@misc: @mhroncok: several loops, for HA, I think we are on a solution
@BrendanGitLab: For notifications, you have fine grained access control as a user to what you’re subscribed to and when. See https://docs.gitlab.com/ee/user/profile/notifications.html
@cverna: so about ticket and namespaces, currently in GitLab we can turn off the issue tracker at the project level
@BrendanGitLab: The GitLab issue tracker can be turned on and off by project to make it clear where issues are tracked: https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions
@decathorpe: But is it possible to map this notification status to BugZilla somehow?
@mhroncok: @cverna: project would mean rpms/foobar, right?
@cverna: so we could not configure this at the namespace (groups in GitLab)
@cverna: @mhroncok: yes
@BrendanGitLab: You can also control the issues_enabled setting through the GitLab API https://docs.gitlab.com/ee/api/projects.html#edit-project
@pingou: @cverna: can admins toggle that?
@decathorpe: wait, there would be an “rpms” group instead of an “rpms” namespace? :frown:
@cverna: @pingou: yes admins and owners, which should be only releng and sysadmin-main
@cverna: Fabio Valentini (@decathorpe): groups and namespaces are the same in GitLab
@BrendanGitLab: Group and Namespace are (almost) interchangeable in GitLab. A group refers to a group of people OR a group of projects
@mboddu: @decathorpe: Yes, in gitlab, namespace means groups
@gregmyers: 
Notifications can customized at the individual user level, per-project, per-group/sub-group, or globally. Narrower scopes override broader scopes.
@pingou: @cverna: hm, sounds good for the issue tracking, but that does raise a question to me about ACL management (how are packager/groups going to be added to packages?)
@mhroncok: @pingou: trough packagedb3
@ mboddu runs away
@pingou: @mhroncok: don’t joke about that please
@zbyszek: aaaaargh
@BrendanGitLab: You can share a group (or project) with a user or a group.
@jlanda: you in this case is releng/-mainers ?
@mhroncok: @pingou: I am not joking, IMHO it is the only way we will be able to have the pagure experience on gitlab – git on github, everyhting Fedora specific in pacagedb
@jlanda: since the user is not a project owner
@cverna: @pingou: yeah that’s something that needs more work, and possibly that GitLab ticket https://gitlab.com/gitlab-org/gitlab/-/issues/7626
@jlanda: so he can’t share anything with anyone
@mhroncok: we can use releng tickets for this, that was always a good idea
@jlanda: and no burden for cpe
@decathorpe: yay pkgdb3 …
@mattdm: this chat is confusing enough without sardonic suggestions please
@mboddu: @mhroncok: You are not helping me 
@pingou: @mattdm: I find it worrying that a few people had the same thought though
@amoloney: Next topic is Branches and will begin in 2 mins
@mhroncok: @pingou++
@decathorpe: I see no way to do this without a separate service that runs on top of GitLab to bridge this gap.
@mhroncok: not only a package maintainer needs to add new maintainers
@mhroncok: other packagers need to be abel to claim orphaned packages
@pingou: @cverna: so if I understand that ticket, the gitlab UI would build a policy engine to allow some section of the settings to be available on lower ACLs?
@jlanda: and transfer “ownership”
@jlanda: ownership from a packager view, not gitlab view
@cverna: @pingou: that would allow Packager to be maintainers and have policies in place to forbid changing some settings
@pingou: @cverna: hm, don’t we want to other way around though? To grant packager access to some of the settings?
@cverna: @pingou: or the other way around which is better permission wise
@amoloney: #topic Branches
@amoloney: Question: Branch level permissions? Can we set the above permissions at branch level? Esp can we set them with some regex matching?
@pingou: or are you thinking to make packager admins and restrict some of the settings at the instance leve through that policy engine?
@cverna: @pingou: I think both would work but less permission by default sounds more sane
@cverna: about branches permission a lot is covered by Protected branches in GitLab
@BrendanGitLab: GitLab’s concept of protected branches provides a lot of flexibility and configuration around this: https://docs.gitlab.com/ee/user/project/protected_branches.html
@cverna: I think that this is covering everything we need
@jlanda: centos sig included?
@pingou: who can change the protected branches?
@BrendanGitLab: You can restrict by specific branch name, a pattern match, etc.
@cverna: maintainers and owners
@mhroncok: @cverna: so assume carlwgeorge ask me to be the epel maintainer of python3.9
@BrendanGitLab: Who can push and merge (by person or group)
@mboddu: @cverna: Can we set f** and epel** as protected branches?
@mhroncok: @cverna: since I don’t trust him (in theory), I can go and configure the access for epel.* bracnhes to him?
@pingou: can we prevent the creation of f** branches?
@mboddu: @BrendanGitLab already answered, thanks
@jlanda: @BrendanGitLab: and can specify an user/group for an specific branch rule?
@cverna @mboddu: all branches would be set as protected since it disable force-push
@pingou: basically, we do not allow the creation of f** or e[pe]l** branches unless they exist in PDC
@BrendanGitLab: @jlanda yes you can specify who can push and merge for each specific branch rule
@mhroncok: so a s a package maintainer i can modify the branch protection rules, but I cannot modify them in all ways?
@pingou: to avoid the f35 branch to exist before we branch
@jlanda: thanks
@pingou: is that something we could still do w/ gitlab?
@mhroncok: i.e. I can say “this person can only push to epel.* branches” but I cannot say “I can push force to master”?
@cverna @mhroncok: did you get your answers ?
@mboddu: @BrendanGitLab: So, if f** is protected, how can we created one? (extension to pingou’s question)
@BrendanGitLab: @pingou people could only create the protected branches who are able to based on the rules
@BrendanGitLab: Because creating one would involve a “push” of the branch into the remote, even if it is with no changes
@mhroncok: @cverna: checking
@andr3: You can use wildcards :
@mhroncok: @cverna: not really
@mboddu: @BrendanGitLab: Can we set these rules at namespace(groups) level?
@mhroncok: this seem to mix 2 things that are related in gitlab but unrelated in pagure
@mhroncok: 1) who can push to what branches
@pingou: ok, so what does protected branch cover: no force-push, what else?
@mhroncok: 2) what branches can be force pushed to
@amoloney: Next topic is project naming with special characters, beginning in 2 mins
@BrendanGitLab: @mboddu those are at the project level, not the group level
@mattdm: @amoloney heroic effort with the clock
@amoloney: 
@amoloney: 
@cverna: @pingou: It prevents its creation, if not already created, from everybody except users with Maintainer permission.
@BrendanGitLab: There are also custom git hooks that can be used for much more custom rules:
@mboddu: @pingou: No creation of branches, pushes allowed by users with ‘allowed’ perms (I dont what that is) and preventing branch deletions
@cverna: @pingou:
- It prevents anyone from force pushing to the branch
- It prevents anyone from deleting the branch
- It prevents pushes from everybody except users with Allowed permission.
@mboddu: @BrendanGitLab: ^ What are ‘allowed’ perms?
https://docs.gitlab.com/ee/user/project/protected_branches.html are they part of developer access?
@amoloney: #topic Naming issues with +
@amoloney: Question: Fedora supports + in repo name, there is a ticket on it, but it seems to be closed with status being tracked in a private ticket. What is the status on it?
@zbyszek: " A GitLab admin is allowed to push to the protected branches." – sounds good, we would be able to do the occasional branch fixup.
@pingou: remains the question from mhroncok: as a packager, can I set who is allowed to commit/push to a protected branches? (since I don’t have access to the settings)
@jlanda: m, why are we looking ee docs, if fedora has a hard requirement on open source
@BrendanGitLab: @mboddu that refers to the “allowed to push” and “allowed to merge” permissions on protected branches
@jlanda: shouldn’t we use the ce docs?
@King_InuYasha: yes
@jlanda: all those links are on /ee/
@BrendanGitLab: @jlanda all of our docs on the web live under ee.
@King_InuYasha: approvals do not exist in ce
@cverna: @jlanda: these are ce features, duckduckgo just gives the ee doc
@nick-thomas: We do still have https://docs.gitlab.com/ce/ but the docs were unified some time ago
@nick-thomas: same content
@jlanda: ok, thanks
@BrendanGitLab: There are badges in the docs that refer to which features may be only in the EE edition
@amoloney: Final topic is feedback and will begin in 1 minute
@Arrfab: @amoloney: no answer from gitlab abut “+” in the name
@Arrfab: I think there are quite some projects/rpms with “+” in the name on src.fedoraproject.org
@amoloney: thanks @Arrfab!
@cverna: yeah about the + sign there is an open ticket that is now public
@jlanda:@ nick-thomas: then,
^ this is a non ce feature right?
@cverna: https://gitlab.com/gitlab-org/gitlab/-/issues/220528
@Arrfab: @amoloney: well, forgot the “?” at the end, so was asking gitlab answer for this
@pingou: matches 81+ in https://src.fedoraproject.org/extras/pagure_poc.json
@cverna: we can follow progress on that ticket
@amoloney: #feedback on AMA
@nick-thomas: @jlanda: that’s not in CE
@jlanda: so on foss edition, we can not protect branch with different users/groups ?
@jlanda: ok, then the previous answer from brendand is wrong
@amoloney: Question: how do you think this session went?
@jlanda: we will not be able to add protected branches per group/user
@mattdm: better than i expected at first given the chaos
@lgriffin: haha
@nick-thomas: protected branches are there, but not per-user rules
@jlanda: yep, that’s what I mean
@nick-thomas: (some of approvals made it to -foss recently too, but again, not all of it)
@amoloney: #feedback
@mhroncok: I am glad hat the answers will be provided async
@jlanda: so, we can’t say, allow mhronck to push just to epel, while we allow all python-sig on f**
14:28:17 amoloney: this should be held on the mailinglist, it was hard to follow and I don’t really feel a lot smarter
@amoloney: sorry added the # again as the bot didn’t seem to pick it up
@pingou: @amoloney: #topic feedback
@amoloney: damnit!
@mattdm: lol
@pingou: ding
@amoloney: #topic feedback on AMA
@mhroncok: @defolos++
@decathorpe: one hour was way too short …
@amoloney: @defolos: yes a mail thread discussion would be good for sure!
@lgriffin: By way of follow ups we are suggesting: 1. Share a hackmd with the other 20+ questions answered and open some devel threads on the meatier ones. 2. share a blog post on this, bcotton we might reach out to you. 3. Hold a follow on AMA if the community would like it
@mattdm: @lgriffin++
@zodbot: @mattdm: Karma for @lgriffin changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any
@jlanda: and no ml @lgriffin?
@pingou: @jlanda: see 1.
@mhroncok: @jlanda: “devel threads” == ML
@bcotton: @lgriffin++
@zodbot: @bcotton: Karma for @lgriffin changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any
@mboddu: @lgriffin: Maybe email each question as a separate email? Or else it will be overloaded and we might not be able to follow them
@pingou: I think we will need 1. for sure
@defolos: +1 on the ML thread
@jlanda: oh ok, nice
@defolos: and have gitlab folks reply there please
@mattdm: everyone: come join us for the last half of the hour at the Fedora Social Hour at https://app.element.io/#/room/#fedora-social-hour:matrix.org
@amoloney: We can always group them to themed emails
@mattdm: and thank you all!
@amoloney: so like one on branches
@amoloney: and another on message bus, etc
@jlanda: yep, could be better than individual per answer
@mboddu: @amoloney: That would work too
@amoloney: to keep conversations together as well
@jlanda: or we’ll end repeating the same on 3-4 threads
@mboddu: I would also vote for #3 for another AMA
@amoloney: ok Im more than happy to kick off those mails for discussion, with the help of my team and you all to group them into themes please
@amoloney: ok we are over time and I just want to say thank you to everyone who contributed today
@lgriffin: Thanks everyone
@amoloney: and thanks GitLab for joining us today!
@mboddu: Thanks everyone for joining, esp GitLab folks, thanks for taking time to answer our questions
@amoloney: #endmeeting