Fedora AMA Transcript Part 2

@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 :stuck_out_tongue:

@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? :slight_smile: getting too detailed anyway…

@amoloney: :question: 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: :+1: 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 :slight_smile:

@jlanda: and no burden for cpe :slight_smile:

@decathorpe: yay pkgdb3 …

@mattdm: this chat is confusing enough without sardonic suggestions please :slight_smile:

@mboddu: @mhroncok: You are not helping me :frowning:

@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: 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 :slight_smile:

@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 :slight_smile:

@amoloney: :rofl:
@amoloney: :alarm_clock:
@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: 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 :slight_smile:

@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 :slight_smile:

@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: 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 :slight_smile:

@lgriffin: haha :slight_smile:

@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 :slight_smile:

@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 :slight_smile:

@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 :slight_smile:

@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