13:01:48 #startmeeting Fedora Source-git SIG 13:01:48 Meeting started Thu Apr 22 13:01:48 2021 UTC. 13:01:48 This meeting is logged and archived in a public location. 13:01:48 The chair is ttomecek. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:48 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:01:48 The meeting name has been set to 'fedora_source-git_sig' 13:02:04 #meetingname source-git-sig 13:02:04 The meeting name has been set to 'source-git-sig' 13:02:21 #chair csomh lbarczio mfocko Bennett flachman jpopelka Eighth_Doctor 13:02:21 Current chairs: Bennett Eighth_Doctor csomh flachman jpopelka lbarczio mfocko ttomecek 13:02:29 * Eighth_Doctor waves 13:02:34 hello everyone! 13:02:38 * csomh o/ 13:02:53 hello 13:03:02 Hello all 13:03:29 I'm wondering if I got the invitation right 13:03:48 malmond, welcome! sorry to wake you up so early 13:03:59 ttomecek: no problem, I made coffeeeee 13:04:21 #topic Introduction and Welcome 13:04:46 please use #chair to let us know that your participating :) 13:05:01 I already chaired a few people above which I knew that want to participate 13:05:31 .hello ngompa 13:05:31 Eighth_Doctor: ngompa 'Neal Gompa' 13:05:33 let's start with some introductions so that we get to know each other better 13:06:14 #meetingname source-git-sig 13:06:14 The meeting name has been set to 'source-git-sig' 13:06:22 * King_InuYasha waves again 13:06:41 #chair King_InuYasha 13:06:41 Current chairs: Bennett Eighth_Doctor King_InuYasha csomh flachman jpopelka lbarczio mfocko ttomecek 13:06:49 hey Neal, fancy meeting you here 13:07:17 #chair malmond 13:07:23 I guess? 13:07:35 malmond: Yo! Well, I figured I should be here since I've implemented this whole thing for work already, and so I can probably help avoid bad things from happening with this. :) 13:07:41 #chair malmond 13:07:41 Current chairs: Bennett Eighth_Doctor King_InuYasha csomh flachman jpopelka lbarczio malmond mfocko ttomecek 13:07:50 .hello2 13:07:50 jforbes: jforbes 'Justin M. Forbes' 13:08:04 hmm, I thought that everyone can do that - perform #chair 13:08:10 nope 13:08:10 #chair jforbes 13:08:10 Current chairs: Bennett Eighth_Doctor King_InuYasha csomh flachman jforbes jpopelka lbarczio malmond mfocko ttomecek 13:08:14 only chairs can 13:08:24 Can only stay for a bit, was supposed to leave for a trip this mornin 13:09:18 jforbes, oh, thanks for hopping in then! please give us a short intro 13:10:04 Eighth_Doctor, nice! I almost forgot you did that, it was a long time since I saw you last time :) 13:10:21 .hello malmond 13:10:22 malmond: malmond 'None' 13:10:30 Oh, I am Justin Forbes, Fedora kernel maintainer 13:10:49 yikes, I don't get out much, malmond = Matthew Almond 13:11:08 ttomecek: yeah, I think we spent half a day at Summit a few years back just talking about what I did and the pros and cons of the source-git approach 13:12:07 intro from me: I'm Tomas and I'm a product owner for project packit ( https://packit.dev ), our current focus right now is to create a source-based downstream maintenance workflow for CentOS Stream (both versions, 8 and 9) and after getting feedback from multiple places, we wanted to pursue the same thing in Fedora Linux to that we can have one source-based workflow across all Red Hat distros 13:13:18 Eighth_Doctor, yes! I recall you have in on your private gitlab, but back then we did not have any support for gitlab in our project 13:13:24 Yes 13:14:36 anyone else wants to introduce? 13:15:00 Hi all! I'm František. I am another member of the Packit team and was there from the very beginning and I am mostly responsible for the upstream part -- github/gitlab application. 13:16:25 oki, thank you for your introductions! 13:16:29 intro: I'm Matthew and I'm part of the team that work on packaging software/infrastructure at Facebook. We use CentOS and rpm, like to contribute to upstream first, but then do backports to CentOS Stream. We (well, dcavalca) set up the Hyperscale SIG so we can publish and share our backports. Doing backports is my main interest here, and expecially patch management. I'll admit I've not dug deep into this 13:16:35 yet but I think packit/source-git could help reduce toil. 13:17:37 malmond, wow, you seem to arrive to the right place :) is your current patch solution public? can we take a look? 13:18:51 #topic The purpose of the SIG 13:18:55 Our current patch solution is manually rebasing patches and working using cbs. We've only been using it for a few months. Previous to this we have an internal tool called 'yummy' which automated some stuff, but was entirely proprietry 13:20:03 malmond, ah, okay; because I recall that you had an organization on github with maintenance branches, all tracked as sources; so I was wondering if that's still the case 13:21:32 as for the next meeting topic, the purpose of this SIG: we would like to build a minimal viable product for the source-based workflow: https://fedoraproject.org/wiki/SIGs/Source-git#MVP 13:21:33 We do have a bunch of stuff on github. I think you might be referring to https://github.com/facebookincubator/rpm-backports/ - this is pre Hyperscale SIG and most things are now elsewhere (see https://github.com/facebookincubator/rpm-backports/blob/master/MIGRATION.md) 13:22:01 #link https://fedoraproject.org/wiki/SIGs/Source-git#MVP 13:22:08 #link https://github.com/facebookincubator/rpm-backports/ 13:22:16 #link https://github.com/facebookincubator/rpm-backports/blob/master/MIGRATION.md 13:22:39 * ttomecek is using zodbot for the first time as a meeting host 13:22:53 one more time than me :D 13:24:03 malmond, thank you! do you already have a custom kernel at facebook? 13:25:38 wow, this is pretty beefy: https://git.centos.org/rpms/systemd/commits/c8s-sig-hyperscale 13:26:19 Sort of: We have much "newer" kernels available for CentOS. The source work in upstream, but the patches are backported to point releases. I'm not super familiar with the process used by the kernel devs. I'd like to see the kernel included in the Hyperscale SIG, but I don't know about timelines or even if we're committing to it yet 13:27:10 We're definitely planning on a kernel for Hyperscale, we don't know which one yet 13:27:47 at this point in time, we're planning to maintain split source packaging (dist-git-style) rather than merged source packaging (source-git-style) 13:28:15 that was mostly from my experience contributing to kernel-ark, which kind of sucked :( 13:28:53 Eighth_Doctor, what was that didn't work for you? 13:29:00 oh god, pretty much everything 13:29:05 even cloning the repo was terrible 13:29:16 it timed out so often, and keeping track of commits is just impossible 13:30:05 yeah, cloning kernel is not easy, a lot of git forges just can't handle a repo that big ( flachman: hi :) 13:30:16 Eighth_Doctor, what do you mean by "keeping track of commits is just impossible"? 13:30:22 and the weird merge workflow means nobody outside of the kernel team can understand it 13:30:39 csomh: I cannot figure out how the kernel changes between upstream and downstream 13:31:11 I cannot figure out what is for what, how they landed, and importantly, what order they landed in 13:31:50 #info Complex merge workflows of kernel-ark make it hard for external contributors to perform correct contributions. 13:31:56 Eighth_Doctor: A lot of that has gotten better now, everything happens in os-build now 13:32:29 #undo 13:32:29 Removing item from minutes: INFO by ttomecek at 13:31:50 : Complex merge workflows of kernel-ark make it hard for external contributors to perform correct contributions. 13:32:38 yeah, but you are still merging things into that branch basically between upstream and downstream 13:32:48 so I can't easily derive patch series deltas 13:32:53 Order is pretty clear, but even if you don't want to dig through git, there is a Patchlist.changelog which lists the downstream patches, in order, with git hash 13:33:23 #info Complex merge workflows of kernel-ark made it hard for external contributors to perform correct contributions in the past. This is now better that things happen in os-build now. 13:33:57 anyway, this is a clear indication, that whatever we build, we need to make sure it is well documented and understandable 13:34:01 Yes, though that is supposed to get rebased every upstream release. Problem has been too many open MRs, but we got that from over 100 down to 35, so maybe we can start the rebase series for 5.13. Of course the fedora-5.11 branch was a rebase, fedora-5.12 will too 13:34:01 I guess I'll have to look at it again, but we originally dismissed ark for Hyperscale because it was too complicated to figure out 13:34:31 Cloning still takes a while, that is gitlab's issue, not sure what we can do about it 13:34:32 the idea would be that we'd work from a kernel branch from ark and contribute backports that we cared about 13:34:49 and use that for the hyperscale kernel 13:35:02 but none of us could figure out how to reasonably implement that workflow 13:35:49 jforbes: flachman is actually working on a caching solution right now so we can reuse git objects from a local clone during the cloning process in CI (and potentially for contributors locally as well) 13:35:52 e.g. assuming we went with 5.12, we'd work from that branched one and contribute backports as needed for things we cared about, like btrfs 13:35:53 Eighth_Doctor: I can help walk you through some of it. The docs need to be better, but it isn't too difficult 13:36:05 that'd be great :) 13:36:19 I am going on a motorcycle trip in a few minutes, will be back Monday 13:36:24 by jforbes :) 13:36:28 bye even :) 13:36:37 Well, around some in the AM, but from a hotel, so not sure how reliable 13:36:49 jforbes, thanks for joining and enjoy your time off! 13:37:13 but yeah, to make it clear, a big part of the goal for Hyperscale is to bring our expertise to the wider Enterprise Linux community and help support features and technologies we care about there 13:37:47 my hope is that the workflow we build here should be usable by kernel-ark and userspace packages at the same time 13:38:14 so in my case, virtualization and package management are my core concerns 13:38:21 in malmond's case, package management 13:38:23 Eighth_Doctor, nice, do you write some reports of work you are doing? would love to read about it 13:38:30 yup 13:38:33 one sec 13:38:51 #link https://wiki.centos.org/SpecialInterestGroup/Hyperscale 13:39:13 #link https://blog.centos.org/2021/04/centos-hyperscale-sig-quarterly-report/ 13:39:43 the first link covers the Hyperscale SIG effort, and the second covers what we've done so far 13:39:45 Eighth_Doctor, wow, that's really impressive, thank you 13:40:01 #link https://pagure.io/centos-sig-hyperscale/sig 13:40:21 And this is our project tracking repository where we do all our planning and work tracking 13:40:22 since we only have 20 minutes left, I'd love to discuss organization stuff before we part our ways 13:40:42 #topic how do we communicate and track work? 13:41:03 and I'd really appreciate some of your expertise here, Eighth_Doctor 13:41:19 what worked for you in terms of running SIGs, collaboration and communication 13:41:45 I've been driving a couple of SIGs that I chair using Pagure projects, video calls, and Matrix rooms for realtime chat 13:42:07 Workstation WG and KDE SIG work this way and it's been phenomenal 13:42:30 Hyperscale SIG is not quite up and going to do all that yet, but we're slowly getting everything set up 13:43:24 Eighth_Doctor, why did you choose Matrix over IRC? 13:43:53 I can see that a common practice is to create a pagure.io group and track work there 13:43:55 more accessible for people and accounts for the increasing usage of multiple devices 13:44:10 Fedora as a whole is migrating to Matrix very soon too 13:44:12 what would others prefer? 13:44:27 (IRC bridges are expected to be maintained, but Matrix is going to be the primary realtime chat) 13:44:39 #link https://discussion.fedoraproject.org/t/the-future-of-real-time-chat-discussion-for-the-fedora-council/24628 13:44:40 * ttomecek didn't know about Fedora using Matrix officially 13:45:03 we're waiting on Red Hat to pay for the server so we can start the process... 13:46:19 Eighth_Doctor, thanks for the update! 13:46:27 ttomecek: for pagure based project management, I'm particularly proud of the fedora-btrfs project: https://pagure.io/fedora-btrfs/project 13:46:47 you can see the issues and boards and how we've organized things 13:46:53 so would it work for everybody if we had a dedicated pagure.io group? (pretty much mirror how the Hyperscale SIG is organized) 13:47:00 and a dedicated IRC channel, for now 13:47:24 #link https://pagure.io/fedora-btrfs/project 13:47:29 I'm cool with that 13:47:41 +1 13:47:45 if you need help with setup, feel free to hit me up and I can help :) 13:47:48 +1 13:47:51 +1 13:47:52 #info Neal likes how the fedora-btrfs project is organized 13:48:37 oki, no minuses, so let's do that :) I'll set that up (unless anyone else wants to do that :D) 13:50:18 one problem with project management for us is that we already have somewhat-internal jira board, github project and a dozen of repositories with issues, internal gitlab repos so for our team, it would be _another_ source of work - I'll spend some time thinking how we to integrate that into our team's current development workflow 13:51:02 #action ttomecek to set up https://pagure.io/group/fedora-sig-source-git and #fedora-source-git @ freenode 13:51:38 Eighth_Doctor, thank you! 13:52:02 ttomecek: you should ask nb for help to plumb it through to Matrix 13:52:34 Eighth_Doctor, I'd need to poke Matrix first, I have never seen it :D 13:52:41 😀 13:53:08 #action ttomecek to check out Matrix and plug the IRC channel into it; ask nb for help 13:53:24 and finally: meetings 13:53:30 any preference? 13:53:46 I prefer video meetings, but text meetings are fine too 13:54:32 Eighth_Doctor, what platform you like the most? 13:54:47 we're used to google meet in our team 13:54:52 yep, video would be better indeed, with some notes that could be shared afterwards 13:54:55 Bluejeans or Google Meet are fine 13:55:11 Bluejeans is often easier for people who don't necessarily have google accounts 13:55:26 (which may be rare among us, anyway) 13:55:56 I can see that Hyperscale meets biweekly, which I'd prefer personally 13:56:04 +1 on the meetings sentiments 13:56:14 yeah, I don't know if source-git stuff would change so much to need weekly meetings 13:56:25 it also seems that a video meeting would be way more efficient if I look at the amount of information in here 13:57:17 awesome! another agreement, I hope that the workflow definition and implementation will go so smoothly as well 13:58:29 would it be better to start one hour later than we started this one? (meaning in 2 minutes) 13:58:47 +1 to that :D 13:59:56 I'll do another when-is-good for everyone who joined the meeting today so we can pick time in 2 weeks and do it via google meet 14:00:00 ideally not on Thursday then 14:00:13 since Fedora Social Hour every other Thursday is at this time 14:00:31 in the meantime, we can start discussions on irc and on the pagure issue tracker[s] 14:00:37 yup 14:01:14 we're one minute over, thank you all for joining! 14:01:31 I'm gonna end this, let me know if you have anything else to discuss 14:01:36 #endmeeting