18:00:03 <alexsaezm> #startmeeting Go SIG meeting
18:00:03 <zodbot> Meeting started Mon Jul 18 18:00:03 2022 UTC.
18:00:03 <zodbot> This meeting is logged and archived in a public location.
18:00:03 <zodbot> The chair is alexsaezm. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:03 <zodbot> The meeting name has been set to 'go_sig_meeting'
18:00:21 <alexsaezm> #topic Roll Call
18:00:33 <smooge> here
18:00:35 <alexsaezm> o/
18:00:37 <copperi[m]> .hello copperi
18:00:38 <zodbot> copperi[m]: copperi 'Jan Kuparinen' <copper_fin@hotmail.com>
18:00:46 <mroche> .hello mroche
18:00:47 <zodbot> mroche: mroche 'Michael Rochefort' <mike@michaelrochefort.com>
18:00:47 <MarkEFuller[m]1> fuller
18:01:13 <MarkEFuller[m]1> .hello fuller
18:01:14 <zodbot> MarkEFuller[m]1: fuller 'Mark E. Fuller' <mark.e.fuller@gmx.de>
18:02:20 <alexsaezm> I'll give a few more minutes :)
18:05:09 <alexsaezm> We have 4 tagged items for this meeting but I think 3 of them were created by gotmax (He/Him) and looks like he is not going to be here with us today... well, let's check them
18:05:30 <jcajka> .hello jcajka
18:05:31 <zodbot> jcajka: jcajka 'None' <jcajka@cajka.dev>
18:05:34 <alexsaezm> #topic EPEL 9 https://pagure.io/GoSIG/go-sig/issue/37
18:05:49 <jcajka> hello, sorry for running a bit late
18:06:00 <alexsaezm> hi jcajka !
18:06:02 <gotmax> Can you see this?
18:06:25 <alexsaezm> this is the message? :P
18:06:33 <gotmax> Great!
18:06:58 <gotmax> I'm on a cellular connection in an area with bad reception, so I may be in and out
18:07:26 <eclipseo> .hello2
18:07:27 <zodbot> eclipseo: eclipseo 'Robert-André Mauchin' <zebob.m@gmail.com>
18:07:43 <gotmax> For the EPEL 9 issue, we wanted to discuss whether it was actually worth branching for it.
18:08:00 <gotmax> We planned to discuss more once eclipseo was here
18:08:06 <eclipseo> BRB getting back to my hotel room
18:08:20 <gotmax> I have qualms about it given the current state of the go ecosystem in Fedora proper
18:09:09 <alexsaezm> why? :)
18:09:26 <gotmax> Why do I have qualms?
18:09:42 <alexsaezm> yep
18:10:06 <alexsaezm> what kind of implications you think can affect ?
18:10:30 <gotmax> I'm just not sure how well we'll be able to maintain everything for 10 years, and I think we should focus on cutting down the amount of FTBFS packages first and foremost
18:10:57 <eclipseo> Well I'm not very available to update a lot of my packages
18:11:39 <gotmax> Technically, the EPEL policy allows you to retire packages at will and not have to maintain everything for 10 years, but that's not something that's exactly encouraged
18:12:03 <gotmax> eclipseo: Can you please look at https://bugzilla.redhat.com/show_bug.cgi?id=2106482 first?
18:12:16 <gotmax> .bug 2106482
18:12:18 <zodbot> gotmax: 2106482 – golang-grpc-go4: FTBFS in Fedora Rawhide - https://bugzilla.redhat.com/2106482
18:12:31 <alexsaezm> it's a lot of effort, that is for sure... I'm wondering about what can happen if we just don't branch...
18:12:31 <gotmax> If that doesn't get fixed by next month, it'll get retired and cause a lot of problems
18:13:25 <eclipseo> I can't check out them now, send me a mail, plenty of package got retired because I wasn't able to keep track
18:14:19 <alexsaezm> is there a way to help on that? not that I'm the best keeping track of package duties and you maintain A LOT of packages, but if there's a list of the critical ones where more work is needed...
18:14:59 <gotmax[m]> My other message didn't send, but I said the implications are no applications that people want or that we have to bundle
18:15:36 <gotmax[m]> alexsaezm: That one that I linked would be the first
18:15:45 <smooge> gotmax[m], you don't need to maintain for 10 years. you can update as needed and retire when no longer maintainable
18:15:47 <gotmax[m]> There's also another one up for retirement
18:16:09 <smooge> if you maintain it for 6 months and decide after that.. that is ok
18:16:19 <alexsaezm> gotmax (He/Him): I'll add that to my to-do list for this week
18:16:27 <gotmax[m]> Yeah, I know, but I'm not even sure how we'd define "maintainable"
18:16:54 <smooge> maintainable: I have time to fix this and the fix isn't going to take me days to do
18:16:58 <gotmax[m]> And it's not exactly possible to retire packages willy-nilly without breaking other things
18:17:50 <gotmax[m]> By that definition, most of the go packages in Fedora aren't maintainable
18:18:30 <smooge> well its a strawman definition
18:18:41 <smooge> anyway I am derailing things
18:18:45 <gotmax[m]> Here is the koschei page for the go-sig's packages: https://koschei.fedoraproject.org/groups/go-sig
18:19:36 <gotmax[m]> smooge: I don't think you really are :)
18:19:42 <smooge> doom gloom and agony on us
18:19:44 <eclipseo> The issue is that some packages are easy to fix, but some others could take days because of cyclic deps
18:20:04 <gotmax[m]> Yeah, I understand
18:20:21 <gotmax[m]> And then sometimes updating a single package adds tens of new deps which need to be packaged and reviewed
18:20:35 <eclipseo> The other issue is that we still haven't moved to go modules but that's a bigger problem
18:20:38 <gotmax[m]> See: golang-containerd-stargz-snaphsotter and golang-x-build
18:20:40 <smooge> that is the story of every language stack I have dealt with
18:21:22 <gotmax[m]> Go is especially bad
18:21:32 <gotmax[m]> I wanted to talk more about the containerd/moby ecosystem later, so I'll hold off on the for no
18:21:33 <gotmax[m]> *that for now
18:21:53 <alexsaezm> we can always move this item to the next meeting
18:22:00 <alexsaezm> or to the mailing list
18:22:05 <alexsaezm> to have a proper longer conversation
18:22:16 <gotmax[m]> Fine with me
18:22:22 <jcajka> gotmax[m]: actually under 10% FTBFS is good from historical perspective, not bad not terrible, but I don't wan to sound cynical, considering the amount of packages and work needed to get it let's say under 1% this is really good
18:22:42 <jcajka> sure it would be great if all is green
18:23:15 <gotmax[m]> I'm not sure what the best way forward is, but I'm not a huge fan of continuing to add more applications while not maintaining our libraries so well
18:23:29 <gotmax[m]> This is also a problem in the rust ecosystem
18:23:49 <gotmax[m]> (Based on what I've heard from the other Fabio)
18:24:13 <gotmax[m]> jcajka: I guess. I think it's a bit over 10%, but that's not too relevant
18:24:39 <gotmax[m]> The main issue I see is that if we don't fix the bugs in time, the packages will get retired and cause even more packages to FTBFS
18:24:59 <alexsaezm> so, your solution for now is to not approve new packages?
18:25:13 <alexsaezm> (and fix stuff)
18:25:15 <gotmax[m]> I'm not saying that
18:25:27 <gotmax[m]> I'm just pointing out a general pattern I see
18:25:38 <gotmax[m]> And even if I was suggesting that, that's not really something we can enforce
18:25:53 <alexsaezm> of course not, I was just asking
18:26:06 <alexsaezm> I think it's fancier to add a new package rather than fixing old ones
18:26:14 <gotmax[m]> Yeah, I probably took that too literally :)
18:26:23 <gotmax[m]> Yeah, that's exactly the problem
18:26:38 <gotmax[m]> But that kind of applies more generally to software devlopment :)
18:26:47 <alexsaezm> so I guess if we can, somehow, encourage fixing stuff...
18:26:59 <alexsaezm> some upstream communities usually run issue triage in chats or calls
18:27:11 <jcajka> I'm afraid that there is no perfect solution, at least none that would be really in our powers, i think that the cycle of forced retirement will help. If you don't want to go on culling the packages from go-sig.
18:27:12 <gotmax[m]> Yeah, I was wondering if we could add a Fedora Badge for fixing an FTBFS or FTI
18:27:14 <alexsaezm> to make the issues easier for everyone
18:27:59 <MarkEFuller[m]1> I, for one, being relatively new, don't know what needs fixing (the most) - can we try to develope a list of priority packages (based on dependent packages?)
18:28:08 <gotmax[m]> But not sure how encouraging that is :)
18:28:09 <gotmax[m]> We should at least mark the FTBFS bugs as `assigned`
18:28:13 <gotmax[m]> I guess that lengthens the amount of time we have to fix them
18:28:22 * gotmax[m] needs to refresh himself on the FTBFS/FTI policy
18:28:45 <alexsaezm> Mark E. Fuller: points something interesting... I don't really know if we have a place where people can look at that easily (I mean, there is one, but I don't know if it's documented)
18:28:54 <alexsaezm> https://packager-dashboard.fedoraproject.org/
18:29:38 * alexsaezm is always scare of activating the group view
18:29:38 <gotmax[m]> [Here](https://koschei.fedoraproject.org/groups/go-sig?order_by=state-f37%2Crunning%2Cfailing%2Cname)
18:29:40 <gotmax[m]> https://koschei.fedoraproject.org/groups/go-sig?order_by=state-f37%2Crunning%2Cfailing%2Cname
18:29:40 <gotmax[m]> That is koschei, which tracks whether a package FTBFS
18:29:41 <gotmax[m]> FTBFS stands for fails to build from source
18:29:41 <MarkEFuller[m]1> s/develope/develop/
18:30:23 <alexsaezm> if you use the packager-dashboard with your FAS name you can see the bugs and the sates and the FTBFS flag also
18:30:25 <alexsaezm> it's a nice tool
18:30:45 <alexsaezm> and sort by FTBFS
18:31:05 <gotmax[m]> These 92 packages will be retired before next release (F38) if we don't fix them or at least mark the bugs as ASSIGNED
18:31:08 <gotmax[m]> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&email1=go-sig%40lists.fedoraproject.org&emailassigned_to1=1&emailcc1=1&emailtype1=equals&list_id=12392650&query_format=advanced&short_desc=FTBFS&short_desc_type=allwordssubstr
18:31:13 <jcajka> IMO something like if go-sig is admin and package is FTBFS longer then X time period we will orphan it(and the whole sub tree if admined by go-sig), if nobody from go-sig will step up to fix it.
18:31:23 <gotmax[m]> Yeah, packager-dashboard is also a good place to look
18:31:48 <jcajka> That might be a solution, if still not perfect.
18:31:53 <gotmax[m]> And there's a couple that will be retired next month that were listed in Miro's email
18:32:08 <MarkEFuller[m]1> Yes, I know that we can identify the FTBFS packages, but can we prioritize this list?
18:32:23 <alexsaezm> based on what?
18:32:35 <MarkEFuller[m]1> I don't know - it's worth discussing
18:32:45 <gotmax[m]> Maybe we should prioritize lower level packages
18:32:52 <alexsaezm> the only "priority" can be the amount of dependencies
18:32:52 <MarkEFuller[m]1> perhaps simply the number of other packagesd which depend on it
18:32:55 <MarkEFuller[m]1> s/packagesd/packages/
18:33:19 <gotmax[m]> Like the `golang-x-*` ones that have a lot of dependents
18:33:40 <alexsaezm> it would be cool to have stats of how many times a package is downloaded in a system
18:33:44 <jcajka> IMNHO only priority is do you use the package or the dependencies or it is vital for Fedora to carry those.
18:33:57 <smooge> there is no way to get how many times a package is downloaded or installed
18:33:58 <gotmax[m]> YEah
18:33:59 <gotmax[m]> * Yeah
18:34:16 <alexsaezm> smooge: I know :( but it would be cool :D
18:34:20 <jcajka> otherwise will will be suck in situation trying to package the whole world
18:34:30 <gotmax[m]> My inner privacy advocate shudders
18:34:36 <mroche> jcajka: You mean similar to the way the Python system has shifted (IIRC)?
18:34:40 <smooge> i am saying it because it gets asked a lot and people rathole on trying to figure it out and I would prefer to go with things that can be done
18:34:52 <gotmax[m]> Yeah, I think PyPI has download stats
18:35:13 <gotmax[m]> Yeah, the mirror system makes that difficult
18:35:21 <jcajka> mroche: I don't know about the change in python
18:35:22 <gotmax[m]> that = tracking download stats
18:35:36 <smooge> even without mirrors it is difficult
18:35:41 <eclipseo> Download stats doesn't matter as we are the only consumers of the library packages
18:36:12 <gotmax[m]> Yes, for library packages, but 12% of the packages I rebuilt in f35 (only packages with binaries) FTBFS
18:36:13 <jcajka> gotmax[m]: Go upstream/Google should have them via sumdb/proxy, i'm not aware they published anything in this regard
18:36:41 <gotmax[m]> Not all of those are primarily applications, but it's still an okay measurment
18:37:02 <mroche> jcajka: I could be remembering wrong, I though there was a proposal or shift to reduce Python packages offered by Fedora to align more with what the core system needs, rather than replicating PyPI. But those are needed at runtime, so there's a bit of a difference here.
18:37:21 <gotmax[m]> jcajka: Not if you use `GOPROXY=direct` ;)
18:37:59 <gotmax[m]> Anyways.. we're getting a bit off track
18:38:10 <smooge> so instead of focusing on all the weight of things.. what are the core leaf packages people here need to run?
18:38:40 <jcajka> mroche: I would word it that we can only have as much as folks show up to maintain, it is really not feasible to package the world, especially with limited manpower and not much automation
18:38:47 <gotmax[m]> Well, many of the applications leaf packages, because other things import their code
18:38:57 <gotmax[m]> (See containerd, which I maintain, for instance)
18:39:30 <eclipseo> No idea the dependencies trees are so vast, I remember for building rclone there were like 500-600 lib packages as deps
18:40:03 <smooge> ah ok. I am coming to go as a newbie
18:40:53 <gotmax[m]> *are not leaf packages
18:41:03 <gotmax[m]> But I think you got my drift :)
18:41:26 <alexsaezm> we can set as a next action for the next meeting identify those leaf packages
18:41:58 <alexsaezm> Have a list of relevant packages among the vast amount of go packages sounds interesting to me
18:42:58 <gotmax[m]> I considered writing a script to mark all of go-sig's FTBFS bugs at once, but that feels like subverting the FTBFS policy
18:43:05 <gotmax[m]> And hiding the problem we have
18:43:13 <gotmax[m]> *Mark all of them as ASSIGNED
18:43:24 <smooge> i mean lets say we had to retire go because too much is FTBFS and people aren't fixing it.. what is broken.
18:43:33 <jcajka> alexsaezm: +1 this can drag for long time, it might be better to even move it in to ticket or on ML
18:43:51 <gotmax[m]> Who wants to bring it to the ML?
18:43:56 <smooge> gotmax[m], I would agree. if its not being worked on.. its better to not assign it
18:43:56 <alexsaezm> +1
18:43:59 * gotmax[m] calls not it
18:44:30 <smooge> Subject: F38 Proposal: Retire golang from Fedora
18:44:46 <alexsaezm> smooge: that helps :P
18:44:50 <smooge> (self-contained change)
18:44:52 <gotmax[m]> Well `golang` isn't broken, it's just a bunch of the libraries
18:44:55 <eclipseo> That would be less work
18:45:17 <eclipseo> Getting rid of 32 bits would help too
18:45:30 <gotmax[m]> Yeah, that was another thing we wanted to discuss
18:45:50 <smooge> I am +10 for retiring 32bit stuff
18:46:06 <gotmax[m]> It's not as easy as it seems
18:46:11 <alexsaezm> Now that the go sig meetings are getting a lot of action, we always reach the hour
18:46:23 <gotmax[m]> Yeah, I also noticed that
18:46:28 <gotmax[m]> Maybe we should move it weekly?
18:46:39 <gotmax[m]> (I think we were going to suggest scheduling)
18:46:47 <alexsaezm> maybe, and also probably use more the mailing list?
18:46:59 <alexsaezm> or the forums, not sure if the format is that helpful
18:47:04 <gotmax[m]> Yeah, the mailing list is not very active
18:47:16 <MarkEFuller[m]1> +1 mailing list discussions
18:47:30 <gotmax[m]> The project leadership has tried to encourage use of the forums, but I don't think it's really caught on :)
18:47:40 <smooge> what is the mailing list
18:47:59 <smooge> honestly it will be a cold day in Hades before I am regular on the forums
18:48:09 <alexsaezm> golang@lists.fedoraproject.org
18:48:23 <smooge> durh.
18:48:43 <copperi[m]> Forums is sort of ... hardish
18:48:59 <mroche> Is the go-sig@ list used at all?
18:49:03 <gotmax[m]> Do we want to move on to the moby or 32-bit issue
18:49:10 <alexsaezm> is there a go-sig list?
18:49:14 <gotmax[m]> mroche: That's for bugzilla CCs
18:49:17 <gotmax[m]> It's private
18:49:23 <mikelo> .hello mikelo2
18:49:24 <zodbot> mikelo: mikelo2 'Mikel Olasagasti Uranga' <mikel@olasagasti.info>
18:49:33 * gotmax[m] waves
18:49:38 <mikelo> o/
18:50:03 <mikelo> I was reading the discussion, I was wondering if we know if all the packages in FTBFS are still relevant
18:50:19 <mikelo> there may be old libraries that are not used anymore
18:50:41 <alexsaezm> gotmax (He/Him): whatever you prefer, although if we want to move things to ML to have proper (slower) conversations both moby and 32bit issue are good ones
18:50:49 <gotmax[m]> Yeah, that's a good point
18:51:00 <alexsaezm> mikelo: we should do some sort of triage over all of the packages
18:51:17 <gotmax[m]> Agreeded
18:52:14 <smooge> sent a subject
18:52:16 <alexsaezm> I think that for that specific case, we should ask the full devel ML for takes on how to do a full triage over all of the packages, perhaps other sigs have better answers
18:52:22 <mikelo> example, golang-github-marten-seemann-qtls-go1-16 FTBFS but *I* think it's not needed anymore in rawhide
18:52:56 <alexsaezm> smooge: thanks
18:53:06 * gotmax[m] wonders how hard to would be to write a script to find these old libraries
18:53:08 <gotmax[m]> It'd have to loop over the packages that don't provide binaries and check whatrequires them
18:53:35 <mikelo> I'm checking with dnf repoquery --disablerepo="*" --enablerepo=rawhide --whatrequires "golang-github-marten-seemann-qtls-go1-16-devel"
18:53:59 <eclipseo> Use whatrequires.c from Igor
18:54:09 <alexsaezm> smooge: I almost had an heath attack with the subject
18:54:35 <alexsaezm> what the hell I wrote...
18:54:49 <mikelo> alexsaezm, did he send the Retire golang from Fedora mail already?
18:54:51 <alexsaezm> heart*
18:55:14 <alexsaezm> mikelo: Subject: F38 change retire all FTBFS golang libraries and resulting dependencies (system-wide change)
18:55:15 <alexsaezm> lol
18:56:00 <alexsaezm> smooge also sent another mail for the Exclude golang from x86_32
18:56:02 <smooge> I changed it to cover the item that gotmax[m] said .. it is libraries versus golang
18:56:15 <smooge> well someone said to send things.. so I did
18:56:22 <alexsaezm> thanks :D
18:56:24 <alexsaezm> do we want to jump into another topic?
18:56:31 <alexsaezm> or do we want to just move everything to the ML?
18:56:57 <gotmax[m]> Doing that means breaking most of the go applications in Fedora
18:57:02 <mikelo> eclipseo, do you mind if I assign some of the packages that are FTBFS to me so I can track them? I wan to check the golang-x-* for example
18:57:31 <gotmax[m]> Not eclipseo but me my guest
18:57:56 <eclipseo> Nope feel free
18:57:57 <gotmax[m]> Really, anyone in the SIG can assign our bugs to themself
18:58:49 <gotmax[m]> I want to discuss the moby issue while eclipseo is here, but...
18:58:58 <gotmax[m]> We don't really need everyone here to do that
18:58:58 <alexsaezm> we can move to the moby then
18:59:33 <eclipseo> What's the issue in short?
18:59:42 <alexsaezm> #topic Discuss current docker/moby/containerd ecosystem brokenness https://pagure.io/GoSIG/go-sig/issue/43
19:00:02 <gotmax[m]> golang-github-docker and golang-github-docker-cli FTBFS and are impossible to update
19:00:19 <gotmax[m]> Because a broken golang-containerd-stargz-snapshotter was pushed
19:00:31 <gotmax[m]> And now we need to package 20+ dependencies to fix it
19:00:40 <eclipseo> Docker is the worse to build
19:00:50 <gotmax[m]> We might need to just bundle everything
19:00:55 <gotmax[m]> for docker and containerd
19:01:02 <mroche> Was just about to ask, is vendoring out of the question?
19:01:10 <gotmax[m]> It kind of feels like an exercise in futility at this point
19:01:19 <gotmax[m]> It's a SHOULD NOT in the guidelines
19:01:30 <gotmax[m]> Not a MUST NOT
19:02:03 <gotmax[m]> I believe NodeJS used to package everything, and then it became completely impractical so they now bundle everything
19:02:14 <mroche> Docs label it as a "by default":
19:02:20 <mroche> > At the moment golang projects packaged in Fedora SHOULD be unbundled by default. It means projects are built from dependencies packaged in Fedora.
19:02:29 <mroche> > For some project it can be reasonable to build from bundled dependencies. Every bundling needs a proper justification.
19:02:29 <eclipseo> The problem with that is that if you use a vendored package from an old version, and a newer package in your dep tree, it will fuck up
19:03:29 <gotmax[m]> Yeah, we'd have to remove everything
19:03:46 <jcajka> eclipseo, mroche: it is not optimal, but as long there are version bundled provides it is IMHO manageable, but getting the version might be hard some times
19:03:51 <gotmax[m]> This feels justified to me
19:04:35 <gotmax[m]> decathorpe has a good script for syncthing
19:04:41 <gotmax[m]> https://src.fedoraproject.org/rpms/syncthing/blob/rawhide/f/vendor2provides.py
19:04:56 <gotmax[m]> That we could use for other packages
19:04:59 <jcajka> need to package 10s+ more dependencies seems to be as a good justification, especially if one version can't be use across the whole distribution
19:05:09 <mroche> I feel like there should be a unified script for doing this. There's the one in golang, the butane package has it's own, I have mine based on that, etc.
19:05:24 <gotmax[m]> We could try to get a review exception from the FPC, but this solution feels better
19:05:32 <gotmax[m]> mroche: +1
19:05:45 <gotmax[m]> We could include it in go-rpm-macros or something
19:06:10 <gotmax[m]> It does make me sad, though
19:06:12 <jcajka> gotmax[m]: or go-sig repo, what would make most sense
19:06:30 <gotmax[m]> go2rpm is another option
19:07:30 <gotmax[m]> For moby-engine I have a separate file with all of the bundled provides that's written to by a script and then `%include`d in the specfile
19:08:35 <gotmax[m]> Anyways, we should probably coordinate further in the issue I created
19:08:47 <gotmax[m]> As I said, we have to be careful about removing things to avoid breaking other things
19:09:21 <jcajka> gotmax[m]: +1
19:10:53 <gotmax[m]> #idea Look into bundling moby-engine, containerd and the related packages due to their unmaintainable dependency sprawl
19:11:25 <alexsaezm> anything else from this topic or others?
19:12:35 <gotmax[m]> Not me. We can discuss the %ix86 thing more outside of the meeting
19:12:51 <jcajka> +1 again
19:12:56 <gotmax[m]> And look into adopting a single script
19:13:12 <gotmax[m]> Also, eclipseo: I submitted a PR (unrelated to this) to go2rpm. Can you please review it?
19:13:18 <alexsaezm> sounds like a job for the ML :)
19:13:38 <gotmax[m]> +1
19:13:50 <gotmax[m]> I updated the issue about moby
19:13:54 <gotmax[m]> But it was the wrong issue :(
19:14:00 <MarkEFuller[m]1> I also have a PR against the go-sig on pagure
19:14:09 <alexsaezm> right
19:14:13 <MarkEFuller[m]1> It updates the Matrix channel and calendar locations
19:14:21 <alexsaezm> let me change the topic
19:14:27 <eclipseo> Yup I can
19:14:27 <gotmax[m]> Let me fix that
19:14:44 <alexsaezm> #topic add matrix room
19:15:03 <gotmax[m]> We already have one
19:15:06 <eclipseo> We already have a matrix room
19:15:12 <gotmax[m]> It just needs to be mentioned in the README
19:15:14 <eclipseo> I'm in it
19:15:23 <gotmax[m]> (This is it :))
19:15:24 <alexsaezm> https://pagure.io/GoSIG/go-sig/pull-request/40
19:15:27 <alexsaezm> yeah
19:15:29 <alexsaezm> that's what Mark wants
19:15:34 <alexsaezm> to add it to the README
19:15:44 <alexsaezm> I just create the topic with the name of the PR
19:15:57 <gotmax[m]> I don't really think we need to vote on that
19:16:08 <gotmax[m]> I can try to review it later (I have to go after this)
19:16:18 <gotmax[m]> If someone else wants to, be my guest ;)
19:16:26 <alexsaezm> I can merge it, I already check it before the meeting
19:16:27 <alexsaezm> it's totally fine
19:16:35 <gotmax[m]> SGTM
19:16:35 <alexsaezm> didn't know that the URL of the calendar changed
19:16:50 <MarkEFuller[m]1> alexsaezm: that's why this is my first meeting...
19:16:55 <gotmax[m]> It happened a while ago I think
19:17:39 <alexsaezm> merged
19:18:09 <alexsaezm> thanks
19:18:20 <eclipseo> There's a calendar?
19:18:36 <alexsaezm> there used to be a ics thingy and now there is a proper calendar!
19:18:55 <alexsaezm> https://calendar.fedoraproject.org/SIGs/#m10012
19:19:18 <gotmax[m]> It's kind of confusing, because that only shows today's, even though it's recurring
19:19:30 <gotmax[m]> I think we should try and wrap up...
19:19:44 <alexsaezm> right
19:19:56 <gotmax[m]> But we should probably just put the time to the SIG's README
19:20:09 <alexsaezm> gotmax (He/Him): I'll do it :)
19:20:32 <alexsaezm> Thanks everyone for the meeting, let's the other topics on the ML and try to find some solutions :)
19:20:55 <alexsaezm> #endmeeting