13:31:04 <amoloney> #startmeeting AMA Session with GitLab
13:31:04 <zodbot> Meeting started Thu Sep 10 13:31:04 2020 UTC.
13:31:04 <zodbot> This meeting is logged and archived in a public location.
13:31:04 <zodbot> The chair is amoloney. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:31:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:31:04 <zodbot> The meeting name has been set to 'ama_session_with_gitlab'
13:31:17 <mboddu> .hello mohanboddu
13:31:18 <zodbot> mboddu: mohanboddu 'Mohan Boddu' <mboddu@bhujji.com>
13:31:21 <mboddu> 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 <amoloney> 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 <amoloney> 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 <Nuritzi> Hi everyone!
13:32:18 <mattdm> amoloney: that didn't work
13:32:28 <siddharthvipul> amoloney, \o :D
13:32:30 <gregmyers> Hi Fedora Community! ❤️
13:32:36 <mattdm> matrix translated it to "amoloney sent a long message" and a link
13:32:39 <amoloney> oh here we go hahahaha
13:32:48 <Arrfab> let's all use irc ? :)
13:32:48 <lgriffin> .hello
13:32:48 <zodbot> lgriffin: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
13:32:50 <cverna> Hi everyone
13:33:01 <amoloney> I'd like to introduce the panel for today's call:
13:33:02 <lgriffin> Hey everyone
13:33:02 <bstinson> hey all
13:33:03 <siddharthvipul> .hello siddharthvipul1
13:33:04 <zodbot> siddharthvipul: siddharthvipul1 'Vipul Siddharth' <siddharthvipul1@gmail.com>
13:33:07 <amoloney> Aoife Moloney - Product Owner, CPE
13:33:27 <lgriffin> Leigh Griffin - Engineering Manager, CPE
13:33:44 <Nuritzi> Nuritzi Sanchez - Senior Community Manager, GitLab
13:33:55 <carlwgeorge> .hello2
13:33:56 <zodbot> carlwgeorge: carlwgeorge 'None' <carl@redhat.com>
13:34:03 <bcotton> .hello2
13:34:03 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
13:34:05 <Lindsay> Lindsay Olson - Senior Community Advocate, GitLab ☺️
13:34:05 <mattdm> Matthew Miller - Fedora Project Leader, Red Hat
13:34:06 <andr3> 👋 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 <mgill> Michelle Gill - Backend Engineering Manager - Create: Source Code
13:34:27 <jayo-gitlab> Hi!  I'm Jason Young, a Support Engineer, GitLab, Support Counterpart for Open Source Program
13:34:41 <cverna> Clément Verna - Engineering Manager, Fedora CoreOS
13:34:46 <bcotton> Ben Cotton - Fedora Program Manager (and CentOS Stream Program Manager)
13:34:47 <nick-thomas> Nick Thomas - Backend Engineer - Create: Source Code
13:35:11 <siddharthvipul> what a great panel :) Thank you all
13:35:21 * marcdeop is present as a listener
13:35:34 <amoloney> 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 <amoloney> I will be adding questions from the hackmd and allowing a panelist to post their answer
13:36:14 <gregmyers> @siddharthvipul Happy to be here!
13:36:37 <amoloney> 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 <amoloney> so, lets begin! :)
13:37:08 <amoloney> 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 <amoloney> 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 <lgriffin> 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 <mattdm> ooh, let's do zodbot topics for these?
13:37:55 <mboddu> amoloney: Use #topic and followed by the question
13:38:01 <cverna> #topic permission and access in gitlab
13:38:07 <mattdm> sure that'll work :)
13:38:12 <mattdm> cverna++
13:38:12 <zodbot> mattdm: Karma for cverna changed to 24 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
13:38:20 <cverna> I ll take that one :)
13:38:27 <mboddu> cverna: Well, if you are part of the chair it will work :)
13:38:57 <cverna> So what we have currently looked  at mapping the FAS groups to the permission models in GitLab
13:39:36 <cverna> for now it looks like we will have something like :
13:39:58 <cverna> Packager and Co-Maintainer having a Developer role (commit access)
13:40:29 <cverna> Proven Packager having a Developer role on all projects expect 2 (firefox and thunderbird)
13:40:45 <cverna> then sysadmin and releng engineer having a Owner role on all projects
13:41:33 <cverna> 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 <zbyszek> 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 <King_InuYasha> No
13:42:00 <jlanda> and can owner alter the settings?
13:42:02 <King_InuYasha> Yes
13:42:06 <decathorpe> What about the "shim" and "kernel" packages?
13:42:11 <jlanda> or force push to an repo?
13:42:15 <cverna> 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 <jlanda> a*
13:42:17 <pingou> what about notifications?
13:42:19 <King_InuYasha> jlanda: kind of
13:42:41 <cverna> about notifications Gitlab’s notifications are quite granular and can be managed at the different levels (Merge Requests, Projects, Group, Global)
13:42:45 <King_InuYasha> force push, if protected branches are set, is disabled
13:43:00 <cverna> https://docs.gitlab.com/ee/user/profile/notifications.html#global-notification-settings
13:43:11 <King_InuYasha> notifications do not map to what we have today
13:43:16 <pingou> cverna: so provenpackager would have to adjust them for all projects (created and new ones)?
13:43:29 <pingou> or will this be set by default?
13:43:30 <pjones> 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 <pingou> or something we'll have to automate?
13:43:54 <amoloney> #chair cverna
13:43:54 <zodbot> Current chairs: amoloney cverna
13:44:08 <cverna> pingou:  no since notification can be adjusted at the group level, so the provenpackager group would have notification disable by default
13:44:15 <jlanda> 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 <King_InuYasha> the permission inheritance model in gitlab doesn't map to allow per project exclusions
13:44:31 <pingou> cverna: is there a hierarchie in the groups then?
13:44:32 <lgriffin> 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 <King_InuYasha> e.g., everyone in rpms/* group (which would be proven packagers) cannot *not* have permissions
13:45:05 <King_InuYasha> which means packages cannot block provenpackagers individually anymore
13:45:07 <cverna> pingou: the same user can be in different groups
13:45:19 <defolos> lgriffin: please no, the chat is already hard to follow
13:45:33 <BrendanGitLab> Users can be in many groups, and groups can also have subgroups
13:45:34 <lgriffin> Ok we are going to get maybe 3-4 questions covered if we keep this approach
13:45:37 <pingou> 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 <misc> King_InuYasha: that do not sound like a big problem, no ?
13:46:02 <King_InuYasha> misc: Firefox, Thunderbird, the kernel, and shim are exceptions that nobody wants to fix
13:46:14 <King_InuYasha> I personally hate those exceptions, but we're stuck with those
13:46:21 <zbyszek> misc: yeah, I'd say that losing this capability is a net win.
13:46:28 <cverna> pingou: yeah so provenpackager group = no notification, then you can manage the notification for each project you maintain as you wish
13:46:38 <pingou> cverna: ok, thanks
13:46:46 <misc> King_InuYasha: couldn't it be replaced by some CI / approval ?
13:46:49 <King_InuYasha> Nope
13:46:57 <misc> like, you can't merge unless you are authorized ?
13:46:59 <King_InuYasha> Nope
13:47:06 <King_InuYasha> you're authorized, full stop
13:47:18 <amoloney> Shall we move onto the next topic? Next question is around Message Bus :)
13:47:33 <jlanda> there are a bunch of questions about acls, will we return to them?
13:47:38 <rbowen> Hopefully questions can be answered async after our time runs out here.
13:47:43 <jlanda> and I asked about owners capabilities too :S
13:47:55 <King_InuYasha> jlanda: owners can do anything
13:48:00 <King_InuYasha> including bypass any restrictions
13:48:07 <mhroncok> "Shall we move onto the next topic?" I don't feel this was answered enough :(
13:48:19 <amoloney> 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 <King_InuYasha> jlanda: same goes for maintainers
13:48:24 <petersen> amoloney: +1
13:48:25 <jlanda> and alter history, or invite someone outside packager group to a repo?
13:48:31 <King_InuYasha> jlanda: absolutely
13:48:38 <jlanda> that's a big concern :S
13:48:39 <King_InuYasha> maintainers and owners have that power
13:48:54 <misc> 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 <mhroncok> cverna: so a s aprovenpackager I need to manually enable notifications on the packages I actually maintain?
13:49:03 <cverna> 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 <King_InuYasha> gregmyers: yes, but those are fraught with peril on upgrades
13:49:30 <King_InuYasha> having done those for my own instances before, they easily and regularly break
13:49:40 <misc> break in what way ?
13:49:50 <misc> cause if that break and block push, that will be detected fast
13:49:50 <King_InuYasha> misc: misfire, not fire, api changes, etc.
13:50:04 <cverna> 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 <mhroncok> cverna: ack
13:50:18 <mhroncok> cverna++
13:50:19 <rbowen> Question from CentOOS-land - Will git.centos.org be moving to gitlab?
13:50:19 <misc> King_InuYasha: wow
13:50:21 <Arrfab> 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 <rbowen> What Arrfab said. :)
13:50:50 <King_InuYasha> misc: there are no stability guarantees beyond the frontend UI
13:50:52 <cverna> Arrfab: afaik src.fp.o
13:50:53 <mboddu> Arrfab: This is for src.fp.o
13:51:00 <amoloney> #topic message bus
13:51:04 <amoloney> 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 <King_InuYasha> and it's arguable that the frontend UI doesn't have stability guarantees either
13:51:16 <pingou> there is also an ACL question for CentOS, and iirc there is a question for it
13:51:17 <Arrfab> 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 <cverna> Arrfab: I mean this AMA is mostly about src.fp.o
13:51:42 <King_InuYasha> gregmyers: riiight
13:51:47 <lgriffin> 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 <cverna> #topic message bus
13:52:02 <Arrfab> cverna: ah, because message to join was sent to centos community to join here for this ama
13:52:09 <King_InuYasha> gregmyers: that'd be an interesting change from gitlab's previous policy
13:52:46 <petersen> Arrfab: I believe it is in the longer term scope
13:52:50 <King_InuYasha> 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 <cverna> so currently GitLab does not support sending events to a message bus and that's unlikely to happen
13:53:04 <cverna> so we will have to have a bridge similiar to what we have with github2fedmsg
13:53:07 <bstinson> 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 <amoloney> Arrfab: yes as its important for both communities to be involved as we (CPE) are in both communities :)
13:53:35 <cverna> we have 2 options to do that either use webhooks or polling the events api
13:53:54 <King_InuYasha> *if* we go down this road, you will want to do webhooks
13:54:01 <decathorpe> wouldn't polling be brittle madness?
13:54:02 <King_InuYasha> polling the API will kill the system
13:54:12 <King_InuYasha> it can't handle the load and sidekiq will freak out
13:54:25 <King_InuYasha> since all requests internally are async through sidekiq
13:54:39 <jlanda> how much messages produces src.fp.o per hour?
13:54:41 <cverna> I said that there are 2 possible way forward, once might be better than the other :P
13:54:50 <jlanda> we have a bunch of things that depends on them :S
13:55:06 <King_InuYasha> jlanda: enough that I have a filter that sends all that mail to trash hourly ;)
13:55:13 <cverna> indeed I think the webhooks way should be preferred :)
13:55:14 <mhroncok> how would webhooks handle outages? currently, I believe that pagure will "eventually" emit the message to the bus
13:55:19 <jcpunk> 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 <King_InuYasha> mhroncok: they're lost
13:55:37 <misc> that's bad :/
13:55:38 <pingou> are the web hook notifications time-based?
13:55:41 <King_InuYasha> there is no eventual consistency guarantee
13:55:49 <King_InuYasha> there is no ordering guarantee either
13:56:00 <mhroncok> 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 <King_InuYasha> Yup
13:56:15 <decathorpe> that's awful
13:56:15 <King_InuYasha> it's the same thing that we have with github2fedmsg
13:56:22 <lgriffin> 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 <mboddu> Aouch, thats gonna hurt
13:56:31 <King_InuYasha> if github throws 500s for a day, we lose everything there
13:56:35 <mhroncok> King_InuYasha: except we don't use github for anything important in that regard :/
13:56:46 <King_InuYasha> sure ;)
13:57:05 <King_InuYasha> welp, I need to step away
13:57:10 <mattdm> any comments from the gitlab folks on this?
13:57:10 <mboddu> Is there a way that we can reply these lost messages?
13:57:11 <King_InuYasha> looking forward to seeing how this goes
13:57:13 <pingou> could our gitlab guest weigh in?
13:57:15 <jlanda> so we moved away from fedmsg because we lose messages, to come back to a message losing sceneario?
13:57:38 <lgriffin> Gitlab folks are chatting to confirm bear with us
13:58:04 <pingou> grizlly or teddy?
13:58:04 <mhroncok> mboddu: it could possible be webhooks + nightly api calls to retrieve the lost ones
13:58:08 <BrendanGitLab> I'm not sure it's guaranteed to be chronological.
13:58:23 <siXy> 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 <Nuritzi> Uploaded file: https://uploads.kiwiirc.com/files/450cc0392a741e8ee7fb3a84b1a3bef0/pasted.txt
13:58:38 <BrendanGitLab> Also, depending on the cause downtime you may or may not lose messages - they may queue up
13:58:48 <Nuritzi> 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 <Nuritzi> 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 <Nuritzi> Fedora Migration Tracker: https://gitlab.com/gitlab-org/gitlab/-/issues/217350
13:58:49 <Nuritzi> Feature template: https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal
13:58:50 <Nuritzi> Bug template:
13:58:50 <Nuritzi> https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Bug
13:59:06 <nick-thomas> 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 <BrendanGitLab> We also have an engineer who is going to add more detail as well, joining now
13:59:31 <pingou> nick-thomas: any proposal?
13:59:39 <nick-thomas> it would be useful to know what sort of events you're interested in
13:59:41 <lgriffin> 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 <mhroncok> nick-thomas: pretty much all :)
14:00:08 <Nuritzi> lgriffin yes, exactly
14:00:19 <mhroncok> nick-thomas: at least what is publicly visible
14:00:48 <pingou> 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 <nick-thomas> 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 <amoloney> just as an fyi, our next topic coming up will be around namespaces 👍️
14:01:56 <mboddu> nirik: How does events feed work?
14:02:17 <mboddu> nick-thomas: ^
14:02:18 <mattdm> gregmyers:  probably Fedora devel mailing list is better than irc
14:02:43 <siddharthvipul> mattdm, +1 on mailing list than IRC
14:02:47 <misc> I guess we could have a cron that pull the event feed and emit message ?
14:03:03 <pingou> 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 <jlanda> an * * * * * one misc? :D
14:03:04 <siXy> 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 <amoloney> Next topic will being in 5 mins
14:03:21 <mboddu> misc: But that doesn't reply in chronological order
14:03:49 <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!
14:04:00 <misc> mboddu: if the feed is in order, it would be, no ?
14:04:02 <zbyszek> gregmyers: see https://pagure.io/fesco/issue/2383 ("=== Status quo") for a short high-level description.
14:04:21 <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
14:04:21 <jlanda> what will happen if the exact needa are not doable? will fpc be forced to alter its policies?
14:04:39 <misc> mhroncok: cron every 2nd is immediate :p
14:04:43 <misc> second
14:04:50 <gregmyers> Thanks to  pingou for the diagram and zbyszek for the details, I'll join the mailing list siddharthvipul mattdm
14:05:20 <amoloney> #topic Namespace and issue tracking
14:05:24 <amoloney> two related questions:
14:05:30 <misc> mhroncok: but something like use message, and also a cron to trigger message that might be down or something ?
14:05:34 <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.)
14:05:39 <amoloney> and
14:05:42 <mhroncok> misc: right, but maybe a while loop serves better than 2 second cron? :) getting too detailed anyway...
14:05:49 <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
14:05:49 <amoloney> opt-in into being in the CC list). Would this work in a GitLab world?
14:06:08 <misc> mhroncok: several loops, for HA, I think we are on a solution
14:07:11 <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
14:07:44 <cverna> so about ticket and namespaces, currently in GitLab we can turn off the issue tracker at the project level
14:07:47 <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
14:08:01 <decathorpe> But is it possible to map this notification status to BugZilla somehow?
14:08:03 <mhroncok> cverna: project would mean rpms/foobar, right?
14:08:09 <cverna> so we could not configure this at the namespace (groups in GitLab)
14:08:19 <cverna> mhroncok: yes
14:08:21 <BrendanGitLab> 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 <pingou> cverna: can admins toggle that?
14:08:38 <decathorpe> wait, there would be an "rpms" group instead of an "rpms" namespace? :frown:
14:08:45 <cverna> pingou: yes admins and owners, which should be only releng and sysadmin-main
14:09:05 <cverna> Fabio Valentini (decathorpe): groups and namespaces are the same in GitLab
14:09:16 <BrendanGitLab> Group and Namespace are (almost) interchangeable in GitLab.  A group refers to a group of people OR a group of projects
14:09:23 <mboddu> 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 <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?)
14:10:14 <mhroncok> pingou: trough packagedb3
14:10:21 * mboddu runs away
14:10:27 <pingou> mhroncok: don't joke about that please
14:10:28 <zbyszek> aaaaargh
14:10:41 <BrendanGitLab> You can share a group (or project) with a user or a group.
14:11:07 <jlanda> you in this case is releng/-mainers ?
14:11:12 <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
14:11:16 <jlanda> since the user is not a project owner
14:11:17 <cverna> 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 <jlanda> so he can't share anything with anyone
14:11:56 <mhroncok> we can use releng tickets for this, that was always a good idea :)
14:12:21 <jlanda> and no burden for cpe :)
14:12:22 <decathorpe> yay pkgdb3 ...
14:12:28 <mattdm> this chat is confusing enough without sardonic suggestions please :)
14:12:32 <mboddu> mhroncok: You are not helping me :(
14:12:57 <pingou> mattdm: I find it worrying that a few people had the same thought though
14:13:09 <amoloney> Next topic is Branches and will begin in 2 mins
14:13:13 <mhroncok> pingou++
14:13:29 <decathorpe> I see no way to do this without a separate service that runs on top of GitLab to bridge this gap.
14:13:34 <mhroncok> not only a package maintainer needs to add new maintainers
14:13:45 <mhroncok> other packagers need to be abel to claim orphaned packages
14:13:49 <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?
14:14:32 <jlanda> and transfer "ownership"
14:14:40 <jlanda> ownership from a packager view, not gitlab view
14:14:50 <cverna> pingou: that would allow Packager to be maintainers and have policies in place to forbid changing some settings
14:15:18 <pingou> cverna: hm, don't we want to otherway around though? To grant packager access to some of the settings?
14:15:33 <cverna> pingou: or the otherway around which is better permission wise
14:15:36 <amoloney> #topic Branches
14:15:38 <amoloney> 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 <pingou> 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 <cverna> pingou: I think both would work but less permission by default sounds more sane
14:16:33 <cverna> about branches permission a lot is covered by Protected branches in GitLab
14:16:42 <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
14:16:42 <cverna> I think that this is covering everything we need
14:16:53 <jlanda> centos sig included?
14:16:57 <pingou> who can change the protected branches?
14:16:59 <BrendanGitLab> You can restrict by specific branch name, a pattern match, etc.
14:17:06 <cverna> maintainers and owners
14:17:06 <mhroncok> cverna: so assume carlwgeorge ask me to be the epel maintainer of python3.9
14:17:14 <BrendanGitLab> Who can push and merge (by person or group)
14:17:28 <mboddu> cverna: Can we set f** and epel** as protected branches?
14:17:36 <mhroncok> cverna: since I don't trust him (in theory), I can go and configure the access for epel.* bracnhes to him?
14:17:42 <pingou> can we prevent the creation of f** branches?
14:17:43 <mboddu> BrendanGitLab already answered, thanks
14:17:43 <jlanda> BrendanGitLab: and can specify an user/group for an specific branch rule?
14:17:50 <cverna> mboddu: all branches would be set as protected since it disable force-push
14:18:25 <pingou> basically, we do not allow the creation of f** or e[pe]l** branches unless they exist in PDC
14:18:26 <BrendanGitLab> jlanda yes you can specify who can push and merge for each specific branch rule
14:18:28 <mhroncok> so a s a package maintainer i can modify the branch protection rules, but I cannot modify them in all ways?
14:18:33 <pingou> to avoid the f35 branch to exist before we branch
14:18:35 <jlanda> thanks :)
14:18:59 <pingou> is that something we could still do w/ gitlab?
14:19:22 <mhroncok> 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 <cverna> mhroncok: did you get your answers ?
14:19:51 <mboddu> BrendanGitLab: So, if f** is protected, how can we created one? (extension to pingou's question)
14:19:52 <BrendanGitLab> pingou people could only create the protected branches who are able to based on the rules
14:20:19 <BrendanGitLab> Because creating one would involve a "push" of the branch into the remote, even if it is with no changes
14:20:28 <mhroncok> cverna: checking
14:20:46 <andr3> You can use wildcards https://docs.gitlab.com/ee/user/project/protected_branches.html#wildcard-protected-branches
14:20:57 <mhroncok> cverna: not really
14:21:02 <mboddu> BrendanGitLab: Can we set these rules at namespace(groups) level?
14:21:10 <mhroncok> this seem to mix 2 things that are related in gitlab but unrelated in pagure
14:21:21 <mhroncok> 1) who can push to what branches
14:21:21 <pingou> ok, so what does protected branch cover: no force-push, what else?
14:21:37 <mhroncok> 2) what branches can be force pushed to
14:21:39 <amoloney> Next topic is project naming with special characters, beginning in 2 mins
14:21:48 <BrendanGitLab> mboddu those are at the project level, not the group level
14:22:01 <mattdm> amoloney heroic effort with the clock :)
14:22:13 <amoloney> 🤣
14:22:18 <amoloney> ⏰
14:22:35 <cverna> pingou: It prevents its creation, if not already created, from everybody except users with Maintainer permission.
14:22:35 <BrendanGitLab> 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 <mboddu> pingou: No creation of branches, pushes allowed by users with 'allowed' perms (I dont what that is) and preventing branch deletions
14:22:50 <cverna> pingou:
14:22:51 <cverna> It prevents anyone from force pushing to the branch.
14:22:51 <cverna> It prevents anyone from deleting the branch
14:23:04 <cverna> It prevents pushes from everybody except users with Allowed permission.
14:23:06 <mboddu> BrendanGitLab: ^ What are 'allowed' perms? https://docs.gitlab.com/ee/user/project/protected_branches.html are they part of developer access?
14:23:09 <amoloney> #topic Naming issues with `+`
14:23:22 <amoloney> 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 <zbyszek> " 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 <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)
14:23:56 <jlanda> m, why are we looking ee docs, if fedora has a hard requiremente on open source
14:24:01 <BrendanGitLab> mboddu that refers to the "allowed to push" and "allowed to merge" permissions on protected branches
14:24:04 <jlanda> shouldn't we use the ce docs?
14:24:15 <King_InuYasha> yes
14:24:22 <jlanda> all those links are on /ee/
14:24:26 <BrendanGitLab> jlanda all of our docs on the web live under `ee`.
14:24:27 <King_InuYasha> approvals do not exist in ce
14:24:43 <cverna> jlanda: these are ce features, duckduckgo just gives the ee doc
14:24:51 <nick-thomas> We do still have https://docs.gitlab.com/ce/ but the docs were unified some time ago
14:24:53 <nick-thomas> same content
14:24:54 <jlanda> ok, thanks :)
14:25:08 <BrendanGitLab> There are badges in the docs that refer to which features may be only in the EE edition
14:25:22 <amoloney> Final topic is feedback and will begin in 1 minute
14:25:38 <Arrfab> amoloney: no answer from gitlab abut "+" in the name
14:25:52 <Arrfab> I think there are *quite* some projects/rpms with "+" in the name on src.fedoraproject.org :)
14:26:03 <amoloney> thanks Arrfab!
14:26:09 <cverna> yeah about the + sign there is an open ticket that is now public
14:26:10 <jlanda> 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 <cverna> https://gitlab.com/gitlab-org/gitlab/-/issues/220528
14:26:37 <Arrfab> 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 <cverna> we can follow progress on that ticket
14:26:44 <amoloney> #feedback on AMA
14:26:54 <nick-thomas> jlanda: that's not in CE
14:26:55 <jlanda> so on foss edition, we can not protect branch with different users/groups ?
14:27:04 <jlanda> ok, then the previous answer from brendand is wrong
14:27:11 <amoloney> Question: how do you think this session went? W
14:27:15 <amoloney> * Question: how do you think this session went?
14:27:16 <jlanda> we will not be able to add protected branches per group/user
14:27:22 <mattdm> better than i expected at first given the chaos :)
14:27:28 <lgriffin> haha :)
14:27:34 <nick-thomas> protected branches are there, but not per-user rules
14:27:49 <jlanda> yep, that's what I mean
14:27:58 <nick-thomas> (some of approvals made it to -foss recently too, but again, not all of it)
14:28:02 <amoloney> #feedback
14:28:03 <mhroncok> I am glad hat the answers will be provided async
14:28:10 <jlanda> so, we can't say, allow mhronck to push just to epel, while we allow all python-sig on f**
14:28:17 <defolos> 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 <amoloney> sorry added the # again as the bot didnt seem to pick it up
14:28:35 <pingou> amoloney: #topic feedback
14:28:44 <amoloney> damnit!
14:28:48 <mattdm> lol :)
14:28:53 <pingou> ding
14:28:53 <amoloney> #topic feedback on AMA
14:29:01 <mhroncok> defolos++
14:29:01 <zodbot> mhroncok: Karma for defolos changed to 10 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:29:02 <decathorpe> one hour was way too short ...
14:29:17 <amoloney> defolos: yes a mail thread discussion would be good for sure!
14:29:21 <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
14:29:32 <mattdm> lgriffin++
14:29:32 <zodbot> mattdm: Karma for lgriffin changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:29:50 <jlanda> and no ml lgriffin?
14:29:58 <pingou> jlanda: see 1.
14:30:07 <mhroncok> jlanda: "devel threads" == ML
14:30:10 <bcotton> lgriffin++
14:30:10 <zodbot> bcotton: Karma for lgriffin changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
14:30:15 <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
14:30:16 <pingou> I think we will need 1. for sure
14:30:19 <defolos> +1 on the ML thread
14:30:20 <jlanda> oh ok, nice :)
14:30:27 <defolos> and have gitlab folks reply there please
14:30:33 <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
14:30:34 <amoloney> We can always group them to themed emails?
14:30:36 <mattdm> and thank you all!
14:30:40 <amoloney> so like one on branches
14:30:49 <amoloney> and another on message bus, etc
14:31:04 <jlanda> yep, could be better than individual per answer
14:31:09 <mboddu> amoloney: That would work too
14:31:13 <amoloney> to keep conversations together as well
14:31:16 <jlanda> or we'll end repeating the same on 3-4 threads
14:31:53 <mboddu> I would also vote for #3 for another AMA
14:31:55 <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 :)
14:32:09 <pingou> /me waives to amoloney
14:32:25 <amoloney> Yep pingou I am looking at you hahaha! :)
14:32:25 <mboddu> amoloney: Sure :)
14:32:39 <amoloney> thanks @mohan :)
14:33:17 <amoloney> ok we are over time and I just want to say thank you to everyone who contributed toda
14:33:23 <amoloney> * ok we are over time and I just want to say thank you to everyone who contributed today
14:33:30 <lgriffin> Thanks everyone
14:33:42 <zbyszek> Thanks, bye.
14:33:50 <mhroncok> thanks for doing this
14:34:06 <amoloney> and thanks GitLab for joining us today!
14:34:07 <pingou> Thanks for joining and for your time!
14:34:08 <mboddu> Thanks everyone for joining, esp GitLab folks, thanks for taking time to answer our questions
14:34:18 <defolos> thanks everyone for joining
14:34:25 <cverna> thanks all
14:34:28 <jlanda> no need for a ml thread i think, but would be awesome to know how are you going to handle all the rgpd things with this too
14:34:48 <zbyszek> rgpd?
14:34:48 <amoloney> what does rgpd mean? :)
14:34:52 <pingou> gdpr
14:35:03 <amoloney> ah, that thing!
14:35:11 <pingou> and don't forget the ccpa ;-)
14:35:14 <mboddu> Ohh...
14:35:18 <mboddu> pingou: lol :)
14:35:22 <mhroncok> don't forget the fedora change proposal ;)
14:35:34 <misc> pingou: and the brasilian one, I forgot the name
14:35:51 <pingou> misc: oh! please tell me more (after the meeting)
14:35:57 <jlanda> er, sorry gpdr
14:36:03 <jlanda> rgpd is the spanish acronym :)
14:36:03 <pingou> jlanda: so close :)
14:36:06 <mboddu> jlanda: gdpr?
14:36:12 <mboddu> :)
14:36:13 <jlanda> yeah, that :D
14:36:14 <gregmyers> Thanks everyone for your time today, and for asking great questions. I look forward to collaborating asynchronously in the future, and helping find solutions to meet the Fedora community's needs.
14:36:14 <misc> jlanda: that's also the french one !
14:36:20 <siddharthvipul> Thank you all :)
14:36:37 <mboddu> pingou: ^^ You should know this
14:36:47 <pingou> mboddu: that's how I guessed ;)
14:37:02 <mhroncok> amoloney: #endmeeting ?
14:37:18 <pingou> but I didn't know the French and Spanish versions had the same acronyms
14:37:19 <amoloney> honestly, I dont know yet on GDPR or the Change Proposal, there will have to be much more discussion on those and your involvement on them is needed please :)
14:37:28 <mboddu> Oh sorry, I thought there is a specific French one rather than the EU one
14:37:41 <amoloney> and yep, I am ending this meeting now! thanks so much again everyone!
14:37:46 <amoloney> #endmeeting