16:11:51 <jcajka> #startmeeting Go SIG kickoff meeting
16:11:51 <zodbot> Meeting started Wed Sep 12 16:11:51 2018 UTC.
16:11:51 <zodbot> This meeting is logged and archived in a public location.
16:11:51 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:11:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:11:51 <zodbot> The meeting name has been set to 'go_sig_kickoff_meeting'
16:11:56 <Sir_Gallantmon> .hello ngompa
16:11:57 <zodbot> Sir_Gallantmon: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:12:09 <jcajka> .hello jcajka
16:12:11 <zodbot> jcajka: jcajka 'None' <jcajka@redhat.com>
16:12:14 <bhavin192> .hello2
16:12:15 <zodbot> bhavin192: bhavin192 'Bhavin Gandhi' <bhavin7392@gmail.com>
16:12:34 <nim> .hello nim
16:12:34 <zodbot> nim: nim 'None' <nicolas.mailhot@laposte.net>
16:14:02 <jcajka> #topic Introduction
16:15:13 <jcajka> I'm happy that you have come here to talk about Go in Fedora. It would be great if each of us can introduce themselves. I will start.
16:15:30 <eclipseo> .hello2
16:15:31 <zodbot> eclipseo: eclipseo 'Robert-André Mauchin' <zebob.m@gmail.com>
16:15:37 <jcajka> I’m Jakub Čajka, I work at Red Hat as SW eng in Fedora and multi-arch team. My interest are mainly in the Go compiler and low level(packaging) stuff along with making sure that we get all the stuff on all arches.  Also I’m currently looking in the openshift origin and containers (SIG).
16:18:07 <eclipseo> I'm Robert-André Mauchin. I started packaging in August of last year, notably rclone which pull 130 Go dependencies. I'm interested in maintaining our current Go packages up to date and help reviewing new ones. Also I'm looking to unbundle k8s and docker.
16:20:21 <bhavin192> Hello I'm Bhavin Gandhi. I work with InfraCloud technologies, Pune, India. I started learning Golang a month ago. Like to do  experiment around containers. Hope to contribute to Fedora more with help of Golang SIG and Container SIG
16:21:28 <nim> I'm Nicolas Mailhot, I've been gravitating aroud the RHL/RHEL/Fedora ecosystem for quite a while. Right now I'm working in the networking team of a utility, where we would like to use some infrastructure components originating from cloud operators, and coded in go. My interest is improving the state of the Go layer in Fedora so those components can be packaged in Fedora/EL using Fedora engineering practices. i have some limited leeway to use some
16:21:29 <nim> @work resources to get it done
16:22:44 <nim> I've spent some time last year reworking Fedora's Go packaging macros
16:23:41 <nim> Application tegrets: prometheus + grafana, outside containers
16:30:23 <jcajka> Thanks for introduction. I guess we can now move on to the next topic.
16:31:35 <jcajka> #topic Pagure
16:32:43 <jcajka> I have create the group and project at the pagure, https://pagure.io/group/GoSIG/ respectively https://pagure.io/GoSIG/go-sig . I think the issues will be great for tracking work and its progress(I have added fedora releases as milestones there) and also for proposing topics for meetings(tagging them with meeting keyword).
16:34:02 <jcajka> It would be great if you could open issues for any ideas, work that you can't commit to that you might have so other can pick it up.
16:34:29 <jcajka> I have already opened few there that popped on my mind.
16:34:53 <Sir_Gallantmon> Cool
16:36:12 <eclipseo> Shouldn't we create a group on https://src.fedoraproject.org/groups ?
16:36:44 <eclipseo> in order to have access to all Golang packages?
16:37:02 <jcajka> Probably, so we can group own packages
16:37:22 <jcajka> Do you know how to request that? I don't.
16:38:46 <nim> that's the kind of thing you can ask for help about in #fedora-admin
16:38:53 <eclipseo> I don't either
16:39:45 <jcajka> if it is via fedora-admin, I would guess that infra-ticket/issue will be way to go https://pagure.io/fedora-infrastructure
16:39:49 <eclipseo> But it would be great if we could federate packages through this group. Oftentimes packages depend on the update of another.
16:40:22 <jcajka> I totally agree, will you look in to it?
16:41:39 <jcajka> It will reduce need to be proven packager to resolve more system wide Go issues
16:43:28 <eclipseo> yes I will request the group and try to gather all Golang packages
16:44:25 <eclipseo> though I'm not sure how to list all Fedora Golang packages, a tip would be nice to list that.
16:45:51 <jcajka> awesome, IMO I would first start with voluntary addition of the group, rather than dump all the package in to it and then draft some guidelines
16:46:31 <jcajka> how it will work, i.e. only package that are fully written in Go need to be in it
16:46:51 <nim> eclipseo, try dnf repoquery --disablerepo=* --enablerepo=rawhide --whatprovides 'golang(*)' --qf "#%{name}|%{source_name}|%{evr}|%{provides}"
16:47:31 <nim> jcajka, almose any high-level go app will have some form of web ui with js code inside
16:48:15 <nim> even when the core is written in Go you can have other stuff around this Go core
16:48:49 <eclipseo> thanks nim
16:48:51 <jcajka> if you want to find all package that are using golang compiler https://fedoraproject.org/wiki/Changes/golang1.11#Dependencies, but nim's query will be probaly more correct as it will be for package that are truly Go, i.e. not only providing wrappers/bindings
16:50:28 <jcajka> eclipseo: so action for you "eclipseo will look in to packagers group for Go and add all Go based package in to it" are you ok with it?
16:51:09 <eclipseo> agreed, adding packages based on voluntary addition
16:52:03 <jcajka> ok, so  "eclipseo will look in to packagers group for Go and add Go based package in to it on request"?
16:53:28 <eclipseo> yes
16:53:45 <jcajka> #action eclipseo will look in to packagers group for Go and add Go based package in to it on request
16:54:14 <jcajka> can we move to the next topic?
16:54:20 <eclipseo> yes
16:55:12 <jcajka> #Meeting processes(voting,...)
16:55:32 <jcajka> I would like to propose to adopt same rules set as atomic wg and container SIG for voting https://fedoraproject.org/wiki/Atomic_WG#Voting
16:56:12 <jcajka> If you agree I will prepare it as PR before our next meeting
16:56:33 <jcajka> so we can iron out any details
16:57:10 <jcajka> IMHO I expect/hope that something like this will not be used often
16:58:19 <eclipseo> sounds good
16:59:48 <nim> will look at it
17:00:52 * Pharaoh_Atem is back at his desk
17:02:24 <jcajka> ok, if you agree "jcajka will look in to the process guidelines for Go SIG based on https://fedoraproject.org/wiki/Atomic_WG#Voting"
17:02:47 <nim> yes
17:03:21 <eclipseo> #agreed
17:03:44 <jcajka> #action jcajka will look in to the process guidelines for Go SIG based on https://fedoraproject.org/wiki/Atomic_WG#Voting
17:04:30 <jcajka> I guess next topic then
17:04:58 <jcajka> #topic Next Meeting
17:05:26 <jcajka> I think that we should meet every 3-4 weeks(period starting today). What do you think?
17:06:18 <eclipseo> okay, as long as we plan the topic to cover in advance
17:06:37 <bhavin192> eclipseo: +1
17:06:47 <nim> +1
17:06:52 <nim> time will tell anyway
17:07:19 <Pharaoh_Atem> sounds good to me
17:07:33 <Pharaoh_Atem> though I'm surprised we want to go as infrequent as monthly
17:07:54 <jcajka> I would suggest using mainly pagure issues tagged with meeting to plan the agenda
17:08:18 <jcajka> we can adjust next/any time
17:08:47 <jcajka> if there will be more things going on
17:09:39 <jcajka> ok so
17:09:58 <jcajka> #action next meeting will be in 3 weeks
17:10:16 <eclipseo> ok
17:10:37 <jcajka> #topic Open Floor
17:10:45 <jcajka> anyone anything?
17:11:45 <nim> just FYI, I'm currently reworking go packagin macros to fix some long-standing ùissing features
17:12:05 <eclipseo> yeah in the case of packaging, it would be good to have a tandem of packager/reviewer to speed things up
17:12:12 <nim> I've already sent some PRs
17:12:42 <jcajka> awesome
17:12:50 <eclipseo> also we need someone to finish writing the More Go packaging to brang it up to speed with the latest changes
17:12:55 <nim> however, jchaloupka owns some of the related projects, he's not here today, what are we going to do if he's not participating in the SIG?
17:13:46 <nim> eclipseo, /me runs
17:14:13 <jcajka> I will talk to him offline, but on Fedora side I have access to all the base packages as we have created them 3y ago so I will at least be able to merge the needed changes there
17:14:50 <nim> some of this stuff is on github though
17:15:47 <jcajka> yup, it might be worth while to migrate it to pagure under the GoSIG
17:16:28 <nim> jcajka, that would be awesome
17:16:54 <nim> jcajka, I can probably maintain all the shell/rpm/lua glue
17:17:15 <jcajka> I believe that you can do it as you are in the pagure GoSIG group, just create the projects
17:17:29 <nim> jcajka, but someone will need to look after the Go code jchaloupka wrote if he can't spare the cycles anymore
17:18:18 <jcajka> we can figure it out when it will be under the sig, tbh I haven't seen it fully yet
17:18:53 <jcajka> eclipseo: I think that best place for the guidelines discussion will be the pagure issues
17:18:54 <nim> ok
17:20:13 <eclipseo> all right
17:20:22 <jcajka> nim: are you ok with "nim will migrate all the macros bits form github to pagure under the GoSIG"?
17:20:36 <eclipseo> would be nice to have the guidelines approved too
17:20:58 <nim> I'm asking, because part of the stuff I'm finishing up is golang buildrequires automation, it's exercising bits of the go code we didn't use so much before, and I'm finding problems
17:21:31 <nim> jcajka, I can do the technical migration, but please ask before jchaloupka if he's ok with it
17:21:51 <jcajka> nim: sure, I will let you know
17:22:09 <jcajka> eclipseo: yeah, that is also my hope, I aspire to contribute to it on technical and multi-arch level
17:22:16 <jcajka> and review
17:23:00 <Pharaoh_Atem> I wonder if it'll become easy enough to package simple applications like aptly for Fedora
17:23:01 <nim> that's mainly https://github.com/gofed/go-macros and https://github.com/gofed/symbols-extractor
17:23:16 <nim> I wrote most of the first one, but it can't be used without the second part
17:23:19 <jcajka> #action nim will migrate all the macros bits form github to pagure under the GoSIG, jcajka will ask for jchaloupka's approval
17:24:36 <jcajka> nim: we should also look in to using goversion tool and go modules in general
17:24:44 <nim> Pharaoh_Atem, I can only promise you won't suffer because of the rpm part
17:24:52 <Pharaoh_Atem> :P
17:25:02 <nim> Pharaoh_Atem, the state of upstream Go code, that's something else entirely
17:25:08 <Pharaoh_Atem> yeah
17:25:27 <eclipseo> guys, I must go, have we everything we need?
17:25:36 <nim> Pharaoh_Atem, unbundling works surprisingly well, but you do hit complex cases now and then
17:25:59 <jcajka> I'm interested if de-bundling will be worth while for big apps
17:26:23 * jcajka aspires to debundle origin one time
17:26:55 <nim> jcajka, I'd like to get all the easy stuff unbundled at least, and keep vendoring only for the parts that are too awful to do at first
17:27:20 <nim> jcajka, too awful probably includes any part of the docker codebase
17:27:39 <jcajka> kube and origin :D
17:28:14 <nim> kube is unbundable IMHO, except for the docker parets it depends on
17:28:41 <jcajka> yeah and origin bundles kube+more
17:29:05 <nim> at least we did it (docker included) but never tried to actually run the resulting binary
17:29:20 <nim> but, the compiler was happy
17:29:57 <bhavin192> Hehe :)
17:30:27 <jcajka> and there will be issue with kube version skew, but maybe fedora modules will be able to help us to package Go apps, we should definitively investigate it
17:30:57 * jcajka hopes to package more Go version in f30 time frame as modules
17:32:01 <nim> I hope we can get to the part where most of the effort if spent on fixing upstreams codebases, not running after gi repo explosion
17:32:39 <nim> not sure we need to worry about modules yet, just get one baseline to work would be great
17:34:04 <eclipseo> any other topic to adress?
17:34:40 <jcajka> it could help us to completely avoid compat packages, at least I think
17:34:46 <jcajka> not from my side
17:34:58 <Pharaoh_Atem> oh, one last thing
17:35:01 <nim> probably need to set up some organisation to get go packages reviewed
17:35:08 <Pharaoh_Atem> there's interest from the openSUSE side to "share in the fun"
17:35:10 <nim> but that can wait for next meeting
17:35:21 <Pharaoh_Atem> so that we can unify Go packaging across RPM distros
17:35:52 <nim> jcajka, in practice, I found out you didn't need so many compat packages
17:36:08 <jcajka> nim: cool
17:36:17 <eclipseo> Do they have our macros at Opensuse?
17:36:21 <Pharaoh_Atem> not yet
17:36:28 <nim> no they have something else
17:36:31 <Pharaoh_Atem> they just razed their existing macro set (ruby based)
17:36:36 <Pharaoh_Atem> to newer bash based ones
17:36:53 <Pharaoh_Atem> https://github.com/openSUSE/golang-packaging
17:36:57 <nim> arg, bash is going to be a pain
17:37:01 <eclipseo> bash based macros :|
17:37:31 <nim> I'd be happy to contribute any macro code opensuse-side
17:37:37 <Pharaoh_Atem> cool
17:38:03 <Pharaoh_Atem> I'd like to see if a few of us could try to reach out to our counterparts in the SUSE distributions to have them be part of what we do here
17:38:06 <Pharaoh_Atem> like we did for Rust
17:38:16 <nim> some of it is in redhat-rpm-config due to the way Fedora is set up, but I wrote it alone so…
17:38:26 <Pharaoh_Atem> ehh, that part isn't a problem
17:38:37 <Pharaoh_Atem> they now have rpm-config-SUSE
17:38:46 <Pharaoh_Atem> https://github.com/openSUSE/rpm-config-SUSE
17:39:18 <jcajka> yeah, it would be awesome, not sure what are the differences between the SUSE/Fedora packaging though
17:39:21 <Pharaoh_Atem> but jcajka, could you try to reach out to your counterpart at SUSE who maintains the golang stack and see if they could join our channel?
17:39:38 <jcajka> Pharaoh_Atem: who is it?
17:39:46 <Pharaoh_Atem> one sec
17:40:38 <jcajka> nim: AFAIK redhat-rpm-config is just for the minimal build root, it depends how SUSE is managing theirs
17:41:39 <nim> jcajka, some of the heavy lifting is done by forgemeta, it's not Go specific, so I was asked to put in in redhat-rpm-macros
17:41:53 <jcajka> ah, ok
17:42:07 <Pharaoh_Atem> it looks like Aleksa Sarai (cyphar) and Jordi Massaguer (jordimassaguerpla) are the current lead maintainers of SUSE's Go stack
17:42:14 <Pharaoh_Atem> https://build.opensuse.org/project/users/devel:languages:go
17:43:53 <jcajka> Pharaoh_Atem: is there any ML or something to bring it on?
17:44:07 <Pharaoh_Atem> jcajka: also, Richard Brown (sysrich / RBrownSUSE) is another important person, as he runs Kubic (their equivalent to Atomic)
17:44:12 <Pharaoh_Atem> let me check
17:44:42 <Pharaoh_Atem> opensuse-go@opensuse.org: https://lists.opensuse.org/opensuse-go
17:44:54 <nim> jcajka, https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35 will show you the files involved redhat-rpm-config side
17:45:08 <Pharaoh_Atem> opensuse-kubic@opensuse.org: https://lists.opensuse.org/opensuse-kubic/
17:46:03 <Pharaoh_Atem> jcajka: also Valentin Rothberg (vrothberg) is another person to get in touch with
17:46:08 <jcajka> Pharaoh_Atem: maybe it would be best if you do the introduction :)
17:46:22 <Pharaoh_Atem> jcajka: the problem is they're all on your time zone :)
17:46:31 <jcajka> sent it cross ML
17:46:45 <Pharaoh_Atem> warning, openSUSE ML rejects non-plain text mail
17:47:00 <jcajka> and then we can talk on RC
17:47:02 <jcajka> IRC
17:47:08 <Pharaoh_Atem> yes
17:47:09 <jcajka> np to me, actually it is great
17:47:27 <Pharaoh_Atem> vrothberg actually is in the #buildah and #podman channels sometimes
17:47:38 <Pharaoh_Atem> and sysrich is in the #kubic channel
17:47:46 <jcajka> will you do the kickoff on the MLs golang@fp.org and the respective SUSE ones?
17:47:49 <Pharaoh_Atem> I don't know where cyphar and the other guy hang out
17:47:56 <Pharaoh_Atem> jcajka: sure, I can do that
17:48:05 <jcajka> awesome thanks
17:48:23 <Pharaoh_Atem> but real-time comms will need to be driven by someone not me
17:48:31 <Pharaoh_Atem> I can't be up at 2-3am every day for that :P
17:48:41 <jcajka> sure :)
17:49:08 <jcajka> i think for starter MLs will be better
17:51:52 <jcajka> I guess that is all for today, last call?
17:52:12 <Pharaoh_Atem> that's all for me
17:52:32 <nim> same for me, I have some Go macros to debug :)
17:53:18 <jcajka> I will end the meeting at 1955h
17:56:00 <jcajka> #endmeeting