2025-11-03 19:00:03 <@alexsaezm:fedora.im> !startmeeting Go SIG meeting
2025-11-03 19:00:05 <@meetbot:fedora.im> Meeting started at 2025-11-03 19:00:03 UTC
2025-11-03 19:00:05 <@meetbot:fedora.im> The Meeting name is 'Go SIG meeting'
2025-11-03 19:00:09 <@alexsaezm:fedora.im> !topic Roll Call
2025-11-03 19:00:14 <@alexsaezm:fedora.im> Hi everyone! As always we'll wait ~5 minutes for everyone to join.
2025-11-03 19:06:04 <@alexsaezm:fedora.im> Looks like it is going to be a quick one :)
2025-11-03 19:06:17 <@alexsaezm:fedora.im> I'll wait a little more and if not, call it :)
2025-11-03 19:09:17 <@mikelolasagasti:matrix.org> !hello
2025-11-03 19:09:19 <@zodbot:fedora.im> Mikel Olasagasti Uranga (mikelo2)
2025-11-03 19:10:05 <@mikelolasagasti:matrix.org> I’m alive, but been busier than expected lately :(
2025-11-03 19:10:34 <@alexsaezm:fedora.im> I'm glad you are alive :)
2025-11-03 19:10:45 <@alexsaezm:fedora.im> (can't do anything about the busy part though)
2025-11-03 19:11:24 <@alexsaezm:fedora.im> Is there anything you want to bring to the meeting? It looks like nobody else will come
2025-11-03 19:11:44 <@gotmax:matrix.org> !hi
2025-11-03 19:11:46 <@zodbot:fedora.im> Maxwell G (gotmax23) - he / him / his or they / them / theirs
2025-11-03 19:11:48 <@gotmax:matrix.org> Sorry, me got distracted
2025-11-03 19:11:52 <@gotmax:matrix.org> Sorry, I got distracted
2025-11-03 19:12:05 <@alexsaezm:fedora.im> oh hi!
2025-11-03 19:12:33 <@mikelolasagasti:matrix.org> Nothing on my side. Tons of updates pending, will check them during the week
2025-11-03 19:13:10 <@mikelolasagasti:matrix.org> I saw gotmax23 announcing the new doc which is great. Sad I couldn’t help with it though 
2025-11-03 19:13:25 <@mikelolasagasti:matrix.org> (And I owe you a mail reply 🤦‍♂️🤦‍♂️)
2025-11-03 19:13:35 <@gotmax:matrix.org> :)
2025-11-03 19:13:41 <@gotmax:matrix.org> Yes, the new guidelines are out 🎉
2025-11-03 19:14:04 <@gotmax:matrix.org> And package retirements of orphaned golang libraries are starting again in six weeks
2025-11-03 19:14:44 <@gotmax:matrix.org> There's some small remaining tasks to do with Go Vendor Tools, but it's mostly complete now
2025-11-03 19:14:54 <@gotmax:matrix.org> I think we have 99 packages that have adopted it last i checked
2025-11-03 19:15:32 <@zodbot:fedora.im> mikelo2 gave a cookie to gotmax23. They now have 50 cookies, 1 of which were obtained in the Fedora 43 release cycle
2025-11-03 19:15:42 <@zodbot:fedora.im> alexsaezm gave a cookie to gotmax23. They now have 51 cookies, 2 of which were obtained in the Fedora 43 release cycle
2025-11-03 19:15:47 <@alexsaezm:fedora.im> that's great news!
2025-11-03 19:17:17 <@mikelolasagasti:matrix.org> Looking forward the retirement of those orphan packages to start having a cleaner packager-dashboard
2025-11-03 19:18:14 <@gotmax:matrix.org> We still have to rename https://gitlab.com/fedora/sigs/go/package-data/-/blob/main/go-vendor-tools-users?ref_type=heads#L47-58
2025-11-03 19:18:14 <@alexsaezm:fedora.im> yeah, the dashboards right now looks a little crazy
2025-11-03 19:18:26 <@gotmax:matrix.org> And I think there's the proposal about multiple golang versions
2025-11-03 19:18:44 <@gotmax:matrix.org> But other than that, we're in pretty good shape
2025-11-03 19:18:55 <@alexsaezm:fedora.im> if you are talking about mine, I was writing it right now
2025-11-03 19:19:00 <@gotmax:matrix.org> Everything has been a lot more stable without all the dependency churn from the -devel packages
2025-11-03 19:19:26 <@gotmax:matrix.org> Yeah
2025-11-03 19:19:43 <@gotmax:matrix.org> I still think updating the Go compiler to new major versions in the middle of a release is a bad idea
2025-11-03 19:19:55 <@gotmax:matrix.org> It always breaks some packages
2025-11-03 19:21:47 <@alexsaezm:fedora.im> Yeah, I am scare of that part to be honest but on the other hand, for example the golang-latest approach has a drawback, that maybe you know how to avoid. My concern with having a golang-latest package is a) duplication of the specfile (although I guess I can check the python approach for this), and b) if people point to that package to build their packages, the result is not that much different from having golang in the same version everywhere
2025-11-03 19:22:46 <@alexsaezm:fedora.im> to be fair, I am writing two proposals. The simple classic one for upgrading go to 1.26 and the unified version. I am not doing the clip technique and try to force the idea :D 
2025-11-03 19:23:10 <@gotmax:matrix.org> Right, but I think it's a problem if packages start to FTBFS in the middle of a release
2025-11-03 19:23:20 <@alexsaezm:fedora.im> 100%
2025-11-03 19:23:26 <@gotmax:matrix.org> But I also recognize the need for some packages to use a newer supported Golang version for security updates
2025-11-03 19:23:40 <@gotmax:matrix.org> So that's why I lean toward a compat package
2025-11-03 19:24:42 <@gotmax:matrix.org> Or it'd be nice if we could plug into the GOTOOLCHAIN=auto toolchain selection to use toolchains built by Fedora and shipped as RPMs instead of downloading binaries from Google
2025-11-03 19:25:15 <@gotmax:matrix.org> But I understand that either solution would create more work for you who actually maintains golang :)
2025-11-03 19:25:33 <@alexsaezm:fedora.im> hmmmm but the GOTOOLCHAIN would require internet during the build, or you mean change that and integrate it with our build system?
2025-11-03 19:26:24 <@alexsaezm:fedora.im> it would be way simplier with what I propose... but it will be simplier for me and that's not the point :D if I am going to make other's people miserable by FTBFS constantly... no thanks
2025-11-03 19:26:51 <@alexsaezm:fedora.im> I am not familiar with compat packages though, and I wonder if I can do the GOTOOLCHAIN approach, didn't think about that tbh
2025-11-03 19:27:27 <@gotmax:matrix.org> That compat package approach (two conflicting packages that each contain different version of `go`) would be easier
2025-11-03 19:28:13 <@gotmax:matrix.org> But it'd be kind of cool if GOTOOLCHAIN=auto could find toolchains built as RPM and installed somewhere on the filesystem instead of always downloading them from Google
2025-11-03 19:28:33 <@gotmax:matrix.org> But that is not a short term solution, since it'd require upstream code changes
2025-11-03 19:28:37 <@gotmax:matrix.org> But it would be nice :)
2025-11-03 19:29:43 <@alexsaezm:fedora.im> it would be cool... I understand you mean with that approach that our release system will be the same, a version of golang per fedora release, but GOTOOLCHAIN auto will pull rpms into the systems
2025-11-03 19:29:50 <@alexsaezm:fedora.im> only for the end user
2025-11-03 19:30:46 <@gotmax:matrix.org> Basically, but I envision that the user would have to install the RPMs but then `go` would be able to find toolchains installed in another directory instead of requiring the different versions to conflict with each other
2025-11-03 19:30:59 <@gotmax:matrix.org> But conflicting compat packages is a perfectly acceptable approach for now
2025-11-03 19:31:26 <@alexsaezm:fedora.im> I will give it a thought to the GOTOOLCHAIN idea, I like it.
2025-11-03 19:31:35 <@alexsaezm:fedora.im> Do you have an example of a compat package btw? 
2025-11-03 19:33:46 <@gotmax:matrix.org> There's a couple ways you can do it
2025-11-03 19:34:16 <@buckaroogeek:fedora.im> Late. Sorry. With respect to GOTOOLCHAIN: a short thread on this topic with kubernetes contributors: https://github.com/kubernetes/kubernetes/issues/135013#issuecomment-3481062906
2025-11-03 19:34:48 <@gotmax:matrix.org> Usually compat packages are named something like `golang1.25` (`<name><version>`) with no separator and they'd all have the appropriate Provides and Conflicts
2025-11-03 19:35:00 <@gotmax:matrix.org> Usually compat packages are named something like `golang1.25` (`<name><version>` without a separator) and they'd all have the appropriate Provides and Conflicts
2025-11-03 19:35:29 <@gotmax:matrix.org> Sometimes there is a default that is just `golang` (`<name>`) without a version suffix 
2025-11-03 19:35:43 <@gotmax:matrix.org> I think Brad Smith maintains some versioned compat packages like this for the kubernetes stack
2025-11-03 19:36:05 <@gotmax:matrix.org> https://src.fedoraproject.org/rpms/nodejs24/blob/rawhide/f/nodejs24.spec#_175 is what nodejs does
2025-11-03 19:37:03 <@alexsaezm:fedora.im> but does that mean we need multiple repos?
2025-11-03 19:37:15 <@buckaroogeek:fedora.im> Compat in the sense that kubernetes1.34 and kubernetes1.33 rpms install different versions of the same binary
2025-11-03 19:37:39 <@gotmax:matrix.org> No, the different packages are allowed to conflict with each other
2025-11-03 19:38:26 <@alexsaezm:fedora.im> but how does that work with for example the source file? 
2025-11-03 19:38:54 <@alexsaezm:fedora.im> like I don't see in nodejs24 any other version
2025-11-03 19:39:04 <@alexsaezm:fedora.im> so my understanding is that we would need several different repositories
2025-11-03 19:39:09 <@alexsaezm:fedora.im> one per go version
2025-11-03 19:39:38 <@gotmax:matrix.org> Oh, by repositories, you mean package/distgit repositories?
2025-11-03 19:39:42 <@alexsaezm:fedora.im> yes
2025-11-03 19:39:49 <@alexsaezm:fedora.im> git stuff :D
2025-11-03 19:39:58 <@gotmax:matrix.org> Ah right. Yes, each version would have a separate SRPM and spec file.
2025-11-03 19:40:19 <@buckaroogeek:fedora.im> This is what i do with kubernetes, cri-o, and cri-tools
2025-11-03 19:40:19 <@alexsaezm:fedora.im> then there is duplication of the code... and I wonder how it would affect ELN
2025-11-03 19:40:52 <@alexsaezm:fedora.im> also, go versions last for very few months, we would be deprecating packages each 6 months
2025-11-03 19:40:56 <@gotmax:matrix.org> Well, you could use templating or copy-paste, but naturally, there'd be some duplication since each package is different 
2025-11-03 19:41:19 <@gotmax:matrix.org> For ELN, the golang<version> packages would just be excluded from content resolver
2025-11-03 19:41:33 <@alexsaezm:fedora.im> oh right
2025-11-03 19:41:38 <@alexsaezm:fedora.im> because we still have golang
2025-11-03 19:41:46 <@alexsaezm:fedora.im> so the latest version is always in golang
2025-11-03 19:42:14 <@buckaroogeek:fedora.im> I use a template for the spec file. the template is the same across all kubernetes repos for example (or can be)
2025-11-03 19:43:01 <@gotmax:matrix.org> I would suggest having a `golang` package at Version `1.x` that stays the same throughout the entire release. Then, we could introduce `golang1.<x+2>` once the shipped version goes EOL.
2025-11-03 19:43:13 <@gotmax:matrix.org> So we would have at most two packages at any given time in a release
2025-11-03 19:43:36 <@gotmax:matrix.org> And I guess when we introduced the second version, if the first one is EOL, you would still only need to update one version
2025-11-03 19:46:07 <@alexsaezm:fedora.im> so if a package breaks during the mass rebuild, could the author go back and select the previous go version?
2025-11-03 19:46:36 <@alexsaezm:fedora.im> so we could find ourselves with go packages in different versions in the same fedora release?
2025-11-03 19:47:25 <@gotmax:matrix.org> I would personally prefer to start each Fedora release with the latest golang and create a compat package for a newer version later int he release cycle
2025-11-03 19:48:05 <@gotmax:matrix.org> I would prefer to not have older Golang versions that will go EOL less than half way through a Fedora release
2025-11-03 19:48:23 <@alexsaezm:fedora.im> that's why I was asking
2025-11-03 19:49:04 <@gotmax:matrix.org> If you feel strongly that having one Golang version that's always up to date is more logical, we can try to get an exception from FESCo, but it'd be important that the Go SIG does mass prebuilds and fixes things before pushing it
2025-11-03 19:49:27 <@alexsaezm:fedora.im> I think is a quite complex process and I am not sure about the benefits (apart from the obvious big one which is not create FTBFS in the middle of the release)
2025-11-03 19:49:47 <@alexsaezm:fedora.im> on the other hand, your compat idea would be the first step to try the GOTOOLCHAIN approach
2025-11-03 19:49:48 <@gotmax:matrix.org> And I guess with vendored packages using go modules mode that enforces compatibility with the minimum `go` version in `go.mod`, it'd be less disruptive
2025-11-03 19:50:19 <@gotmax:matrix.org> But it's just no fun when things break in the middle of a release, that why I'm pushing back a bit against the original proposal :)
2025-11-03 19:50:44 <@alexsaezm:fedora.im> I am only suggesting this idea because we now have the go vendor tools and ideally that fixes the main problem (very ideally of course)
2025-11-03 19:51:24 <@gotmax:matrix.org> I wouldn't say the compat approach is hugely complex once it's set up, but it is admittedly more to think about up frontand the Provides and Conflicts need to be thought out
2025-11-03 19:51:54 <@gotmax:matrix.org> But I guess we can try going forward with mass prebuilds and hoping that it won't find too much breakage now that we're building with go modules
2025-11-03 19:52:11 <@gotmax:matrix.org> But I don't think pushing new golang versions to stable releases that break existing packages is a good idea
2025-11-03 19:52:29 <@alexsaezm:fedora.im> I wish we could run the mass prebuild automatically though
2025-11-03 19:52:50 <@alexsaezm:fedora.im> I trully want to find a middle ground here (ok that sounds too much like a manager :-/ )
2025-11-03 19:53:17 <@alexsaezm:fedora.im> I will write the proposal and bring it to FESCo if you don't mind, and we can discuss it there, mostly because this meeting is getting long :)
2025-11-03 19:53:37 <@alexsaezm:fedora.im> just to be clear, I am not 100% sure about the idea because I don't want FTBFS everywhere
2025-11-03 19:53:49 <@alexsaezm:fedora.im> not trying to push it in any way
2025-11-03 19:53:59 <@alexsaezm:fedora.im> our current approach is nice to me and the golang-latest copr is fine by me
2025-11-03 19:54:06 <@alexsaezm:fedora.im> but discoverability is a problem I guess
2025-11-03 19:55:01 <@gotmax:matrix.org> I guess the middle ground between having no updates at all and making the main `golang` package rolling _is_ compat packages, but I'm not sure what's the middle ground between maintaining multiple packages and making the main `golang` package rolling
2025-11-03 19:55:11 <@gotmax:matrix.org> But I recognize all approaches have downsides
2025-11-03 19:55:25 <@gotmax:matrix.org> And I'm happy to discuss further async on the mailing list :)
2025-11-03 19:55:36 <@alexsaezm:fedora.im> epic, thank you <3
2025-11-03 19:55:59 <@alexsaezm:fedora.im> I will bring this to FESCo 
2025-11-03 19:56:08 <@alexsaezm:fedora.im> thank you
2025-11-03 19:56:31 <@gotmax:matrix.org> Yeah, sure, thanks for discussing it!
2025-11-03 19:56:43 <@alexsaezm:fedora.im> thank you for your ideas!
2025-11-03 19:56:48 <@alexsaezm:fedora.im> and I guess we can call it
2025-11-03 19:56:48 <@gotmax:matrix.org> One note is that FESCo tends to prefer RFCs to happen on the mailing list over in their issue tracker
2025-11-03 19:57:13 <@alexsaezm:fedora.im> ok then to the mailing list!
2025-11-03 19:57:17 <@gotmax:matrix.org> So unless you have a concrete Change proposal to submit using that process, following up on the ML is also fine
2025-11-03 19:57:32 <@gotmax:matrix.org> Works for me :)
2025-11-03 19:57:47 <@alexsaezm:fedora.im> I was writing the proposal in the wiki but too formal too soon I guess
2025-11-03 19:57:53 <@alexsaezm:fedora.im> I will send an email right away 
2025-11-03 19:57:59 <@alexsaezm:fedora.im> thanks everyone!
2025-11-03 19:58:15 <@alexsaezm:fedora.im> !endmeeting