2024-03-25 18:28:22 <@mikelolasagasti:matrix.org> open to discussion I guess
2024-03-25 19:00:42 <@alexsaezm:fedora.im> !startmeeting Go SIG meeting
2024-03-25 19:00:43 <@meetbot:fedora.im> Meeting started at 2024-03-25 19:00:42 UTC
2024-03-25 19:00:43 <@meetbot:fedora.im> The Meeting name is 'Go SIG meeting'
2024-03-25 19:00:48 <@alexsaezm:fedora.im> !topic Roll Call
2024-03-25 19:00:52 <@alexsaezm:fedora.im> Welcome everyone!
2024-03-25 19:01:13 <@fale:fale.io> !hello
2024-03-25 19:01:19 <@mikelolasagasti:matrix.org> !hello
2024-03-25 19:01:25 <@zodbot:fedora.im> Mikel Olasagasti Uranga (mikelo2)
2024-03-25 19:01:26 <@zodbot:fedora.im> Fabio Alessandro Locati (fale) - he / him / his
2024-03-25 19:01:34 <@buckaroogeek:fedora.im> !hello
2024-03-25 19:01:35 <@zodbot:fedora.im> Brad Smith (buckaroogeek)
2024-03-25 19:02:41 <@alexsaezm:fedora.im> we are a few today! (we can wait until 05 to see if we are even more people)
2024-03-25 19:03:23 <@mikelolasagasti:matrix.org>  rushing home
2024-03-25 19:05:52 <@alexsaezm:fedora.im> We do have two tagged issues
2024-03-25 19:05:56 <@alexsaezm:fedora.im> !link https://pagure.io/GoSIG/go-sig/issues?status=Open&tags=meeting&close_status=
2024-03-25 19:06:11 <@alexsaezm:fedora.im> is there any one in particular that we want to talk about?
2024-03-25 19:06:55 <@buckaroogeek:fedora.im> Nothing from me to contribute to these topics
2024-03-25 19:06:57 <@alexsaezm:fedora.im> Also, I just saw issue #54 and I totally missed that one, I think it is worth to talk about it at some point (although I am still reading the information linked)
2024-03-25 19:07:06 <@mikelolasagasti:matrix.org> #53 is complete i think 
2024-03-25 19:09:12 <@mikelolasagasti:matrix.org> it requires go2rpm 1.11 to generate the correct names
2024-03-25 19:09:34 <@mikelolasagasti:matrix.org> And packages with wrong naming just work
2024-03-25 19:09:47 <@buckaroogeek:fedora.im> i missed the last meeting or 2. Was the proposal by @gotmax concerning vendoring discussed?
2024-03-25 19:10:19 <@mikelolasagasti:matrix.org> I don’t think so
2024-03-25 19:12:51 <@alexsaezm:fedora.im> I didn't attend last meeting (I think it didn't happened) and the preovious one was one month ago. Checking the logs I don't see anything, but I do recall talking about it. It might have happened outside the meeting
2024-03-25 19:14:00 <@buckaroogeek:fedora.im> ok. Seems like a necessary option at least for the packages i work on
2024-03-25 19:15:35 <@fale:fale.io> I have to admit that I've stop updating a bunch of packages due to the issues with dependencies hoping to propose months ago to allow vendoring, but obviously I did not proposed it due to lack of time on my end, so those packages are a little out dated
2024-03-25 19:15:58 <@mikelolasagasti:matrix.org> are they new packages or updates?
2024-03-25 19:17:21 <@mikelolasagasti:matrix.org> My main difficulty to update my packages is the requirement of new deps. I don't like to beg for them to be reviewed.
2024-03-25 19:18:26 <@alexsaezm:fedora.im> It's not the first time I have a little bit of time to kill and I check some "is available" issues... to stop doing them because I need to fix a bunch of dependencies :)
2024-03-25 19:18:48 <@mikelolasagasti:matrix.org> there are some complex stacks like grpc/genproto that require to be updated, but as they require new packages... it's not that simple
2024-03-25 19:20:09 <@fale:fale.io> I would be tempted to focus on the go-vendor stuff and drop those stack asap
2024-03-25 19:21:32 <@buckaroogeek:fedora.im> Updates - kubernetes and I help with cri-o, cri-tools, containernetworking-plugins
2024-03-25 19:22:34 <@fale:fale.io> I think the go-vendor issue is two folds: 1 is a priori: should we mass-vendor things? 2 is technical: is our implementation ok/when will it be ok/what is the current implementation missing?
2024-03-25 19:22:46 <@mikelolasagasti:matrix.org> I like the idea of vendoring to get things fast to Fedora. I did that with `opentofu` for example. Just one package and done. I would like to work on having all the packages... but that's complex because I depend on others to do the reviews. 
2024-03-25 19:23:46 <@mikelolasagasti:matrix.org> and I feel that if everything is vendored then we're duplicating tons of libraries with different versions and for security/rebuilds it can be tricky
2024-03-25 19:24:50 <@mikelolasagasti:matrix.org> now it's update one library && rebuild packages. Vendored means for each package either update the package if a new version is released or patch the package source before the vendoring
2024-03-25 19:25:38 <@fale:fale.io> in one hand is more tricky (since there are more things to scan), but in the other hand is easier, since when a vulnerable version is discovered: 1. less packages will need to be rebuilt and 2. it will be easier to rebuild them. Also, on average, we will have more updated packages, so less vulnerable packages
2024-03-25 19:27:04 <@alexsaezm:fedora.im> Also, for simple packages, Packit will help a lot here as updates are way easier if they are vendored
2024-03-25 19:27:13 <@mikelolasagasti:matrix.org> not sure about that Fale , the number of packages that would require rebuild would be potentially the same. But the work it's larger with vendored
2024-03-25 19:27:46 <@alexsaezm:fedora.im> my main concern is the first part, the criteria to vendor. I am eager to say let's mass vendor everything but I might be missing something
2024-03-25 19:28:30 <@fale:fale.io> my point on "less packages" is that only packages that will depend on a vulnerable version will need to be rebuilt, so if the vulnerable version is not the latest, we might already have a bunch of packages not vulnerable.
2024-03-25 19:29:40 <@fale:fale.io> I think that the advantages of those systems will be highest at the extremes, so either everything vendored or everything non-vendored. If we mix the systems we might get the worst of both worlds
2024-03-25 19:30:05 <@fale:fale.io> Though, I agree we might have some packages that will be vulnerable for longer time
2024-03-25 19:30:13 <@mikelolasagasti:matrix.org> I also wonder if at "Fedora Project" level vendoring by default can be considered a problem that requires discussion beyond go-sig
2024-03-25 19:30:44 <@fale:fale.io> I think we will need to propose a packaging guidelines change
2024-03-25 19:30:51 <@alexsaezm:fedora.im> I think we at some point should move the conversation to devel-
2024-03-25 19:31:13 <@buckaroogeek:fedora.im> alexsaezm: will go-sig need to make a formal recommendation on this topic? And also get FESCO concurrence if vendoring is widely adopted?
2024-03-25 19:31:54 <@fale:fale.io> I don't think that's a requirement, but it would surely make sense if the SIG has a recommendation
2024-03-25 19:32:13 <@alexsaezm:fedora.im> Once we know what we want to do, I think we should talk with FESCo and not do anything unilaterally
2024-03-25 19:32:53 <@alexsaezm:fedora.im> and as Fale said: the guidelines will change for sure
2024-03-25 19:34:02 <@buckaroogeek:fedora.im> ok. sounds reasonable. Since this is an ad-hoc topic today should it be on a future agenda? :)
2024-03-25 19:34:25 <@alexsaezm:fedora.im> let me check if we have something already in the issues...
2024-03-25 19:34:50 <@alexsaezm:fedora.im> nothing I can find...
2024-03-25 19:35:20 <@fale:fale.io> yeah, we discussed the topic multiple times in informal ways, but I think this is the first conversation in a formal location
2024-03-25 19:36:05 <@alexsaezm:fedora.im> !action Create an issue to properly discuss the vendoring issue
2024-03-25 19:36:23 <@alexsaezm:fedora.im> (not sure if action was the correct... action)
2024-03-25 19:37:57 <@alexsaezm:fedora.im> Any other topic that we want to discuss today?
2024-03-25 19:38:11 <@buckaroogeek:fedora.im> Nothing from me
2024-03-25 19:39:27 <@fale:fale.io> nothing from me
2024-03-25 19:41:54 <@alexsaezm:fedora.im> in that case... we can call it :)
2024-03-25 19:43:03 <@alexsaezm:fedora.im> I'll create the issue to gather all the stuff we want to discuss about the vendoring
2024-03-25 19:43:06 <@alexsaezm:fedora.im> thanks everyone!
2024-03-25 19:43:08 <@alexsaezm:fedora.im> !endmeeting