13:31:04 #startmeeting AMA Session with GitLab 13:31:04 Meeting started Thu Sep 10 13:31:04 2020 UTC. 13:31:04 This meeting is logged and archived in a public location. 13:31:04 The chair is amoloney. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:31:04 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:31:04 The meeting name has been set to 'ama_session_with_gitlab' 13:31:17 .hello mohanboddu 13:31:18 mboddu: mohanboddu 'Mohan Boddu' 13:31:21 Hey amoloney 13:31:50 * amoloney sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/ONwdlcuTrErknDDyqbnheIwc/message.txt > 13:32:04 First a few thank yous - Thank you to both the Fedora and CentOS communities for adding your questions to the hackmd doc and GitLab forum in advance of this session. Any questions we do not have time to answer in today's session will be answered over the next week and published next Friday as a blog post on both Fedora and CentOS Community blogs with links to the session and a wrap up of how it went.And thank you 13:32:05 to our GitLab panelists for joining today and providing answers to some really great technical questions. I look forward to what will be a really insightful session on how GitLab operates and will help guide me and my team through our investigation and technical scoping of the possible migration to GitLab from Fedora. 13:32:07 Hi everyone! 13:32:18 amoloney: that didn't work 13:32:28 amoloney, \o :D 13:32:30 Hi Fedora Community! ❤️ 13:32:36 matrix translated it to "amoloney sent a long message" and a link 13:32:39 oh here we go hahahaha 13:32:48 let's all use irc ? :) 13:32:48 .hello 13:32:48 lgriffin: (hello ) -- Alias for "hellomynameis $1". 13:32:50 Hi everyone 13:33:01 I'd like to introduce the panel for today's call: 13:33:02 Hey everyone 13:33:02 hey all 13:33:03 .hello siddharthvipul1 13:33:04 siddharthvipul: siddharthvipul1 'Vipul Siddharth' 13:33:07 Aoife Moloney - Product Owner, CPE 13:33:27 Leigh Griffin - Engineering Manager, CPE 13:33:44 Nuritzi Sanchez - Senior Community Manager, GitLab 13:33:55 .hello2 13:33:56 carlwgeorge: carlwgeorge 'None' 13:34:03 .hello2 13:34:03 bcotton: bcotton 'Ben Cotton' 13:34:05 Lindsay Olson - Senior Community Advocate, GitLab ☺️ 13:34:05 Matthew Miller - Fedora Project Leader, Red Hat 13:34:06 👋 André Luís - Frontend Engineering Manager, Create: Source Code 13:34:21 * gregmyers Greg Myers - Support Engineer and Community Relations Support Counterpart 13:34:24 Michelle Gill - Backend Engineering Manager - Create: Source Code 13:34:27 Hi! I'm Jason Young, a Support Engineer, GitLab, Support Counterpart for Open Source Program 13:34:41 Clément Verna - Engineering Manager, Fedora CoreOS 13:34:46 Ben Cotton - Fedora Program Manager (and CentOS Stream Program Manager) 13:34:47 Nick Thomas - Backend Engineer - Create: Source Code 13:35:11 what a great panel :) Thank you all 13:35:21 * marcdeop is present as a listener 13:35:34 Firstly Id like to thank both the Fedora and CentOS communities for adding your questions in advance, and thank you to our panelists for attending todays session 13:35:56 I will be adding questions from the hackmd and allowing a panelist to post their answer 13:36:14 @siddharthvipul Happy to be here! 13:36:37 any questions that are not answered within this session will be answered over the next few days and we would like to publish the session as a blog post to the community forums 13:36:44 so, lets begin! :) 13:37:08 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? 13:37:08 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)? 13:37:08 Feel free also to ask questions in flight and we can answer ad hoc (there are enough of us here) and any we can't answer we can take from the log and follow up async on devel list 13:37:29 ooh, let's do zodbot topics for these? 13:37:55 amoloney: Use #topic and followed by the question 13:38:01 #topic permission and access in gitlab 13:38:07 sure that'll work :) 13:38:12 cverna++ 13:38:12 mattdm: Karma for cverna changed to 24 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 13:38:20 I ll take that one :) 13:38:27 cverna: Well, if you are part of the chair it will work :) 13:38:57 So what we have currently looked at mapping the FAS groups to the permission models in GitLab 13:39:36 for now it looks like we will have something like : 13:39:58 Packager and Co-Maintainer having a Developer role (commit access) 13:40:29 Proven Packager having a Developer role on all projects expect 2 (firefox and thunderbird) 13:40:45 then sysadmin and releng engineer having a Owner role on all projects 13:41:33 that means that Packager would not have access to the project settings so we will need to find a way for them to access settings that are needed for them 13:41:45 Does "Packager and Co-Maintainer" give permission management? Adding any packager? Not being able to add a non-packager? Not being able to remove PP? 13:41:52 No 13:42:00 and can owner alter the settings? 13:42:02 Yes 13:42:06 What about the "shim" and "kernel" packages? 13:42:11 or force push to an repo? 13:42:15 There is a gitlab ticket open that would allow to have a more granular permission model https://gitlab.com/gitlab-org/gitlab/-/issues/7626 13:42:17 a* 13:42:17 what about notifications? 13:42:19 jlanda: kind of 13:42:41 about notifications Gitlab’s notifications are quite granular and can be managed at the different levels (Merge Requests, Projects, Group, Global) 13:42:45 force push, if protected branches are set, is disabled 13:43:00 https://docs.gitlab.com/ee/user/profile/notifications.html#global-notification-settings 13:43:11 notifications do not map to what we have today 13:43:16 cverna: so provenpackager would have to adjust them for all projects (created and new ones)? 13:43:29 or will this be set by default? 13:43:30 decathorpe: those are protected from getting unauthorized signed builds done on the koji side as well as whatever is done in the repo, fwiw 13:43:34 or something we'll have to automate? 13:43:54 #chair cverna 13:43:54 Current chairs: amoloney cverna 13:44:08 pingou: no since notification can be adjusted at the group level, so the provenpackager group would have notification disable by default 13:44:15 cverna: does that allow to bulk disable all the notifications where someone is a developer because is a provenpackager while it keeps the ones because hi is a (co)maintainer? 13:44:18 the permission inheritance model in gitlab doesn't map to allow per project exclusions 13:44:31 cverna: is there a hierarchie in the groups then? 13:44:32 Topics are really going to slow us down we have 20+ questions and answers and I don't believe we can get through them all with the pace of answers, I'm going to propose we run 2-3 questions at once and use the persons IRC handle who is designated as answering it in any responses. Is that ok? 13:44:36 e.g., everyone in rpms/* group (which would be proven packagers) cannot *not* have permissions 13:45:05 which means packages cannot block provenpackagers individually anymore 13:45:07 pingou: the same user can be in different groups 13:45:19 lgriffin: please no, the chat is already hard to follow 13:45:33 Users can be in many groups, and groups can also have subgroups 13:45:34 Ok we are going to get maybe 3-4 questions covered if we keep this approach 13:45:37 cverna: I mean, if I'm provenpackager I've notification disabled, but I also maintain packages, so I need notification for these 13:45:39 King_InuYasha: that do not sound like a big problem, no ? 13:46:02 misc: Firefox, Thunderbird, the kernel, and shim are exceptions that nobody wants to fix 13:46:14 I personally hate those exceptions, but we're stuck with those 13:46:21 misc: yeah, I'd say that losing this capability is a net win. 13:46:28 pingou: yeah so provenpackager group = no notification, then you can manage the notification for each project you maintain as you wish 13:46:38 cverna: ok, thanks 13:46:46 King_InuYasha: couldn't it be replaced by some CI / approval ? 13:46:49 Nope 13:46:57 like, you can't merge unless you are authorized ? 13:46:59 Nope 13:47:06 you're authorized, full stop 13:47:18 Shall we move onto the next topic? Next question is around Message Bus :) 13:47:33 there are a bunch of questions about acls, will we return to them? 13:47:38 Hopefully questions can be answered async after our time runs out here. 13:47:43 and I asked about owners capabilities too :S 13:47:55 jlanda: owners can do anything 13:48:00 including bypass any restrictions 13:48:07 "Shall we move onto the next topic?" I don't feel this was answered enough :( 13:48:19 Im totally fine to wait if you want to focus on this topic a bit more, just bear in mind the time :) 13:48:24 jlanda: same goes for maintainers 13:48:24 amoloney: +1 13:48:25 and alter history, or invite someone outside packager group to a repo? 13:48:31 jlanda: absolutely 13:48:38 that's a big concern :S 13:48:39 maintainers and owners have that power 13:48:54 ACL is kinda the core of the community interaction, that's what define what you can and cannot do , so that's extra important 13:48:54 * gregmyers King_InuYasha: There are also Admin-only options, like custom push rules and server hooks. Maintainers and owners cannot modify these settings. 13:49:02 cverna: so a s aprovenpackager I need to manually enable notifications on the packages I actually maintain? 13:49:03 mhroncok: the thing is that we will need to have a Proof of Concept to test a lot of the special cases 13:49:18 gregmyers: yes, but those are fraught with peril on upgrades 13:49:30 having done those for my own instances before, they easily and regularly break 13:49:40 break in what way ? 13:49:50 cause if that break and block push, that will be detected fast 13:49:50 misc: misfire, not fire, api changes, etc. 13:50:04 mhroncok: no that will come by default, it is just that as a member of the proven packager group you will have notification disable for all the other projects 13:50:14 cverna: ack 13:50:18 cverna++ 13:50:19 Question from CentOOS-land - Will git.centos.org be moving to gitlab? 13:50:19 King_InuYasha: wow 13:50:21 just for my understanding, which git instances are we talking about ? src.fedoraproject.org, pagure.io and git.centos.org ? all ? , on e ? 13:50:34 What Arrfab said. :) 13:50:50 misc: there are no stability guarantees beyond the frontend UI 13:50:52 Arrfab: afaik src.fp.o 13:50:53 Arrfab: This is for src.fp.o 13:51:00 #topic message bus 13:51:04 Question: Fedora uses a message bus to integrate different parts of its infrastructure. How should we onboard GitLab into this message bus? 13:51:05 and it's arguable that the frontend UI doesn't have stability guarantees either 13:51:16 there is also an ACL question for CentOS, and iirc there is a question for it 13:51:17 cverna: oh, so git.centos.org would stay on pagure ? 13:51:26 * gregmyers King_InuYasha: if updates/upgrades to GitLab break custom server hooks and push rules, this would be prioritized a high priority high severity bug by our product team as the impact and scope would be large. If this happens in the future, we could create a bug report with reproducible steps and get our devs/engineers involved in finding a permanent fix. 13:51:37 Arrfab: I mean this AMA is mostly about src.fp.o 13:51:42 gregmyers: riiight 13:51:47 rbowen not for this conversation, git.centos.org is tied up with CentOS Stream and that will be a different Gitlab instance / configuration based on their needs. One hard need for Fedora was the Community Edition 13:51:57 #topic message bus 13:52:02 cverna: ah, because message to join was sent to centos community to join here for this ama 13:52:09 gregmyers: that'd be an interesting change from gitlab's previous policy 13:52:46 Arrfab: I believe it is in the longer term scope 13:52:50 I'm not sure that would be even sustainable given how much internal instability you have there (which is not necessarily a bad thing) 13:52:54 so currently GitLab does not support sending events to a message bus and that's unlikely to happen 13:53:04 so we will have to have a bridge similiar to what we have with github2fedmsg 13:53:07 i was about to say what lgriffin and cverna already did so i won't...but it's good to hear from the centos community if they're here. if nothing else because it may affect us at some point 13:53:30 Arrfab: yes as its important for both communities to be involved as we (CPE) are in both communities :) 13:53:35 we have 2 options to do that either use webhooks or polling the events api 13:53:54 *if* we go down this road, you will want to do webhooks 13:54:01 wouldn't polling be brittle madness? 13:54:02 polling the API will kill the system 13:54:12 it can't handle the load and sidekiq will freak out 13:54:25 since all requests internally are async through sidekiq 13:54:39 how much messages produces src.fp.o per hour? 13:54:41 I said that there are 2 possible way forward, once might be better than the other :P 13:54:50 we have a bunch of things that depends on them :S 13:55:06 jlanda: enough that I have a filter that sends all that mail to trash hourly ;) 13:55:13 indeed I think the webhooks way should be preferred :) 13:55:14 how would webhooks handle outages? currently, I believe that pagure will "eventually" emit the message to the bus 13:55:19 On the API front, will CPE build a tool to replace https://git.centos.org/centos-git-common/blob/master/f/centos.git.repolist.py to avoid too much polling? 13:55:22 mhroncok: they're lost 13:55:37 that's bad :/ 13:55:38 are the web hook notifications time-based? 13:55:41 there is no eventual consistency guarantee 13:55:49 there is no ordering guarantee either 13:56:00 King_InuYasha: so assuming the gitlab2fedmsg service is borken for a day, all events that happened on that day will never reach the bus, right? 13:56:05 Yup 13:56:15 that's awful 13:56:15 it's the same thing that we have with github2fedmsg 13:56:22 jcpunk we can certainly look at any tooling or service request from the community, route them through amoloney -- that's a general statement, we always welcome community requests 13:56:24 Aouch, thats gonna hurt 13:56:31 if github throws 500s for a day, we lose everything there 13:56:35 King_InuYasha: except we don't use github for anything important in that regard :/ 13:56:46 sure ;) 13:57:05 welp, I need to step away 13:57:10 any comments from the gitlab folks on this? 13:57:10 Is there a way that we can reply these lost messages? 13:57:11 looking forward to seeing how this goes 13:57:13 could our gitlab guest weigh in? 13:57:15 so we moved away from fedmsg because we lose messages, to come back to a message losing sceneario? 13:57:38 Gitlab folks are chatting to confirm bear with us 13:58:04 grizlly or teddy? 13:58:04 mboddu: it could possible be webhooks + nightly api calls to retrieve the lost ones 13:58:08 I'm not sure it's guaranteed to be chronological. 13:58:23 Currently this doesn't sound a sufficiently reliable solution. It'd be great to see a design of how this could be made to be eventually consistent, with some reasonable bounds on what "eventual" would look like. 13:58:35 Uploaded file: https://uploads.kiwiirc.com/files/450cc0392a741e8ee7fb3a84b1a3bef0/pasted.txt 13:58:38 Also, depending on the cause downtime you may or may not lose messages - they may queue up 13:58:48 As an FYI -- Fedora is part of GitLab’s Open Source program and we have a migration tracker issue that we are using to keep track of feature requests, bugs, etc that are important to Fedora. The Fedora migration team has been working with us at GitLab to maintain that and community members can add relevant issues there so we can track them. 13:58:48 It’s also helpful for our product managers to hear about why particular issues are important for the Fedora use case, and to have upvotes, so doing that will help! Here are some relevant links: 13:58:49 Fedora Migration Tracker: https://gitlab.com/gitlab-org/gitlab/-/issues/217350 13:58:49 Feature template: https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal 13:58:50 Bug template: 13:58:50 https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Bug 13:59:06 webhooks are out-of-order and there's no guarantee of them arriving. I wouldn't rely on it for something that needs those properties, we should think about alternatives 13:59:08 We also have an engineer who is going to add more detail as well, joining now 13:59:31 nick-thomas: any proposal? 13:59:39 it would be useful to know what sort of events you're interested in 13:59:41 Thanks nuritzi, this gives the Community (and CPE) a means to make requests for consideration on your roadmap for any gaps, correct? 13:59:57 nick-thomas: pretty much all :) 14:00:08 lgriffin yes, exactly 14:00:19 nick-thomas: at least what is publicly visible 14:00:48 nick-thomas: if you ask 10 people, you'll get 11 answer, so mhroncok +1, you can assume: all :) 14:01:02 * gregmyers For authentication and access control, there are a number of options and "best" solution will change depending on the specific needs and use case of the community. If we can get a better understanding of how your auth/ACL are currently, and how you'd like them to work, we can narrow-in on a solution. I'd like to open up a conversation and discuss this further, would #fedora-devel be the best place 14:01:02 * gregmyers to go? 14:01:15 the events feed might be better then. We do have an event log for geo that has in-order, guaranteed delivery, but it's designed for other stuff 14:01:40 just as an fyi, our next topic coming up will be around namespaces 👍️ 14:01:56 nirik: How does events feed work? 14:02:17 nick-thomas: ^ 14:02:18 gregmyers: probably Fedora devel mailing list is better than irc 14:02:43 mattdm, +1 on mailing list than IRC 14:02:47 I guess we could have a cron that pull the event feed and emit message ? 14:03:03 a little while ago I drafted the diagram of how commits get allowed/rejected: http://ambre.pingoured.fr/public/packager_commit_workflow.jpg 14:03:04 an * * * * * one misc? :D 14:03:04 nick-thomas: One usecase I'm aware of from centos: Due to the unreliability of src rpms being made available, larger users are consuming messages to know when an update is pushed to git, then generating the src rpm for their internal repo. 14:03:14 Next topic will being in 5 mins 14:03:21 misc: But that doesn't reply in chronological order 14:03:49 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! 14:04:00 mboddu: if the feed is in order, it would be, no ? 14:04:02 gregmyers: see https://pagure.io/fesco/issue/2383 ("=== Status quo") for a short high-level description. 14:04:21 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 14:04:21 what will happen if the exact needa are not doable? will fpc be forced to alter its policies? 14:04:39 mhroncok: cron every 2nd is immediate :p 14:04:43 second 14:04:50 Thanks to pingou for the diagram and zbyszek for the details, I'll join the mailing list siddharthvipul mattdm 14:05:20 #topic Namespace and issue tracking 14:05:24 two related questions: 14:05:30 mhroncok: but something like use message, and also a cron to trigger message that might be down or something ? 14:05:34 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.) 14:05:39 and 14:05:42 misc: right, but maybe a while loop serves better than 2 second cron? :) getting too detailed anyway... 14:05:49 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 14:05:49 opt-in into being in the CC list). Would this work in a GitLab world? 14:06:08 mhroncok: several loops, for HA, I think we are on a solution 14:07:11 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 14:07:44 so about ticket and namespaces, currently in GitLab we can turn off the issue tracker at the project level 14:07:47 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 14:08:01 But is it possible to map this notification status to BugZilla somehow? 14:08:03 cverna: project would mean rpms/foobar, right? 14:08:09 so we could not configure this at the namespace (groups in GitLab) 14:08:19 mhroncok: yes 14:08:21 You can also control the `issues_enabled` setting through the GitLab API https://docs.gitlab.com/ee/api/projects.html#edit-project 14:08:23 cverna: can admins toggle that? 14:08:38 wait, there would be an "rpms" group instead of an "rpms" namespace? :frown: 14:08:45 pingou: yes admins and owners, which should be only releng and sysadmin-main 14:09:05 Fabio Valentini (decathorpe): groups and namespaces are the same in GitLab 14:09:16 Group and Namespace are (almost) interchangeable in GitLab. A group refers to a group of people OR a group of projects 14:09:23 decathorpe: Yes, in gitlab, namespace means groups 14:09:26 * gregmyers 👍 Notifications can customized at the individual user level, per-project, per-group/sub-group, or globally. Narrower scopes override broader scopes. 14:09:51 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?) 14:10:14 pingou: trough packagedb3 14:10:21 * mboddu runs away 14:10:27 mhroncok: don't joke about that please 14:10:28 aaaaargh 14:10:41 You can share a group (or project) with a user or a group. 14:11:07 you in this case is releng/-mainers ? 14:11:12 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 14:11:16 since the user is not a project owner 14:11:17 pingou: yeah that's something that needs more work, and possibly that GitLab ticket https://gitlab.com/gitlab-org/gitlab/-/issues/7626 14:11:24 so he can't share anything with anyone 14:11:56 we can use releng tickets for this, that was always a good idea :) 14:12:21 and no burden for cpe :) 14:12:22 yay pkgdb3 ... 14:12:28 this chat is confusing enough without sardonic suggestions please :) 14:12:32 mhroncok: You are not helping me :( 14:12:57 mattdm: I find it worrying that a few people had the same thought though 14:13:09 Next topic is Branches and will begin in 2 mins 14:13:13 pingou++ 14:13:29 I see no way to do this without a separate service that runs on top of GitLab to bridge this gap. 14:13:34 not only a package maintainer needs to add new maintainers 14:13:45 other packagers need to be abel to claim orphaned packages 14:13:49 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? 14:14:32 and transfer "ownership" 14:14:40 ownership from a packager view, not gitlab view 14:14:50 pingou: that would allow Packager to be maintainers and have policies in place to forbid changing some settings 14:15:18 cverna: hm, don't we want to otherway around though? To grant packager access to some of the settings? 14:15:33 pingou: or the otherway around which is better permission wise 14:15:36 #topic Branches 14:15:38 Question: Branch level permissions? Can we set the above permissions at branch level? Esp can we set them with some regex matching? 14:15:41 or are you thinking to make packager admins and restrict some of the settings at the instance leve through that policy engine? 14:16:14 pingou: I think both would work but less permission by default sounds more sane 14:16:33 about branches permission a lot is covered by Protected branches in GitLab 14:16:42 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 14:16:42 I think that this is covering everything we need 14:16:53 centos sig included? 14:16:57 who can change the protected branches? 14:16:59 You can restrict by specific branch name, a pattern match, etc. 14:17:06 maintainers and owners 14:17:06 cverna: so assume carlwgeorge ask me to be the epel maintainer of python3.9 14:17:14 Who can push and merge (by person or group) 14:17:28 cverna: Can we set f** and epel** as protected branches? 14:17:36 cverna: since I don't trust him (in theory), I can go and configure the access for epel.* bracnhes to him? 14:17:42 can we prevent the creation of f** branches? 14:17:43 BrendanGitLab already answered, thanks 14:17:43 BrendanGitLab: and can specify an user/group for an specific branch rule? 14:17:50 mboddu: all branches would be set as protected since it disable force-push 14:18:25 basically, we do not allow the creation of f** or e[pe]l** branches unless they exist in PDC 14:18:26 jlanda yes you can specify who can push and merge for each specific branch rule 14:18:28 so a s a package maintainer i can modify the branch protection rules, but I cannot modify them in all ways? 14:18:33 to avoid the f35 branch to exist before we branch 14:18:35 thanks :) 14:18:59 is that something we could still do w/ gitlab? 14:19:22 i.e. I can say "this person can only push to epel.* branches" but I cannot say "I can push force to master"? 14:19:37 mhroncok: did you get your answers ? 14:19:51 BrendanGitLab: So, if f** is protected, how can we created one? (extension to pingou's question) 14:19:52 pingou people could only create the protected branches who are able to based on the rules 14:20:19 Because creating one would involve a "push" of the branch into the remote, even if it is with no changes 14:20:28 cverna: checking 14:20:46 You can use wildcards https://docs.gitlab.com/ee/user/project/protected_branches.html#wildcard-protected-branches 14:20:57 cverna: not really 14:21:02 BrendanGitLab: Can we set these rules at namespace(groups) level? 14:21:10 this seem to mix 2 things that are related in gitlab but unrelated in pagure 14:21:21 1) who can push to what branches 14:21:21 ok, so what does protected branch cover: no force-push, what else? 14:21:37 2) what branches can be force pushed to 14:21:39 Next topic is project naming with special characters, beginning in 2 mins 14:21:48 mboddu those are at the project level, not the group level 14:22:01 amoloney heroic effort with the clock :) 14:22:13 🤣 14:22:18 ⏰ 14:22:35 pingou: It prevents its creation, if not already created, from everybody except users with Maintainer permission. 14:22:35 There are also custom git hooks that can be used for much more custom rules: https://docs.gitlab.com/ee/push_rules/push_rules.html 14:22:38 pingou: No creation of branches, pushes allowed by users with 'allowed' perms (I dont what that is) and preventing branch deletions 14:22:50 pingou: 14:22:51 It prevents anyone from force pushing to the branch. 14:22:51 It prevents anyone from deleting the branch 14:23:04 It prevents pushes from everybody except users with Allowed permission. 14:23:06 BrendanGitLab: ^ What are 'allowed' perms? https://docs.gitlab.com/ee/user/project/protected_branches.html are they part of developer access? 14:23:09 #topic Naming issues with `+` 14:23:22 Question: Fedora supports `+` in repo name, there is a [ticket](https://gitlab.com/gitlab-org/gitlab/-/issues/220309) on it, but it seems to be closed with status being tracked in a private ticket. What is the status on it? 14:23:29 " A GitLab admin is allowed to push to the protected branches." – sounds good, we would be able to do the occasional branch fixup. 14:23:55 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) 14:23:56 m, why are we looking ee docs, if fedora has a hard requiremente on open source 14:24:01 mboddu that refers to the "allowed to push" and "allowed to merge" permissions on protected branches 14:24:04 shouldn't we use the ce docs? 14:24:15 yes 14:24:22 all those links are on /ee/ 14:24:26 jlanda all of our docs on the web live under `ee`. 14:24:27 approvals do not exist in ce 14:24:43 jlanda: these are ce features, duckduckgo just gives the ee doc 14:24:51 We do still have https://docs.gitlab.com/ce/ but the docs were unified some time ago 14:24:53 same content 14:24:54 ok, thanks :) 14:25:08 There are badges in the docs that refer to which features may be only in the EE edition 14:25:22 Final topic is feedback and will begin in 1 minute 14:25:38 amoloney: no answer from gitlab abut "+" in the name 14:25:52 I think there are *quite* some projects/rpms with "+" in the name on src.fedoraproject.org :) 14:26:03 thanks Arrfab! 14:26:09 yeah about the + sign there is an open ticket that is now public 14:26:10 nick-thomas: then, https://docs.gitlab.com/ee/user/project/protected_branches.html#restricting-push-and-merge-access-to-certain-users <-- this is a non ce feature right? 14:26:21 https://gitlab.com/gitlab-org/gitlab/-/issues/220528 14:26:37 amoloney: well, forgot the "?" at the end, so was asking gitlab answer for this 14:26:39 * pingou matches 81+ in https://src.fedoraproject.org/extras/pagure_poc.json 14:26:40 we can follow progress on that ticket 14:26:44 #feedback on AMA 14:26:54 jlanda: that's not in CE 14:26:55 so on foss edition, we can not protect branch with different users/groups ? 14:27:04 ok, then the previous answer from brendand is wrong 14:27:11 Question: how do you think this session went? W 14:27:15 * Question: how do you think this session went? 14:27:16 we will not be able to add protected branches per group/user 14:27:22 better than i expected at first given the chaos :) 14:27:28 haha :) 14:27:34 protected branches are there, but not per-user rules 14:27:49 yep, that's what I mean 14:27:58 (some of approvals made it to -foss recently too, but again, not all of it) 14:28:02 #feedback 14:28:03 I am glad hat the answers will be provided async 14:28:10 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 14:28:23 sorry added the # again as the bot didnt seem to pick it up 14:28:35 amoloney: #topic feedback 14:28:44 damnit! 14:28:48 lol :) 14:28:53 ding 14:28:53 #topic feedback on AMA 14:29:01 defolos++ 14:29:01 mhroncok: Karma for defolos changed to 10 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:29:02 one hour was way too short ... 14:29:17 defolos: yes a mail thread discussion would be good for sure! 14:29:21 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 14:29:32 lgriffin++ 14:29:32 mattdm: Karma for lgriffin changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:29:50 and no ml lgriffin? 14:29:58 jlanda: see 1. 14:30:07 jlanda: "devel threads" == ML 14:30:10 lgriffin++ 14:30:10 bcotton: Karma for lgriffin changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:30:15 lgriffin: Maybe email each question as a separate email? Or else it will be overloaded and we might not be able to follow them 14:30:16 I think we will need 1. for sure 14:30:19 +1 on the ML thread 14:30:20 oh ok, nice :) 14:30:27