16:00:52 <jcajka> #startmeeting Go SIG meeting
16:00:52 <zodbot> Meeting started Tue Apr 28 16:00:52 2020 UTC.
16:00:52 <zodbot> This meeting is logged and archived in a public location.
16:00:52 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:52 <zodbot> The meeting name has been set to 'go_sig_meeting'
16:01:11 <jcajka> #topic Roll Call
16:01:21 <jcajka> #chiar Eighth_Doctor
16:01:28 <jcajka> #chair Eighth_Doctor
16:01:28 <zodbot> Current chairs: Eighth_Doctor jcajka
16:01:31 <olem> .hello2
16:01:32 <zodbot> olem: olem 'Olivier Lemasle' <o.lemasle@gmail.com>
16:01:41 <Eighth_Doctor> .hello ngompa
16:01:42 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:01:59 <nim> .hello2
16:02:00 <zodbot> nim: nim 'None' <nicolas.mailhot@laposte.net>
16:02:29 <jcajka> #chair olem
16:02:29 <zodbot> Current chairs: Eighth_Doctor jcajka olem
16:02:34 <jcajka> #chair nim
16:02:34 <zodbot> Current chairs: Eighth_Doctor jcajka nim olem
16:04:29 <jcajka> #topic Open Floor
16:04:45 <jcajka> There are no tagged issue, so Open Floor be it
16:06:10 <jcajka> First of all I would like to introduce alexsaezm, he wants to become Fedora packager and help with packaging Go in Fedora, starting with compiler ;)
16:06:58 <jcajka> Sponsor would be welcomed. Also he is involved on the enterprise side of the RHEL's golang
16:07:07 <olem> Welcome alexsaemzm !
16:07:35 <nim> very much welcome!
16:07:40 <alexsaezm> o/
16:07:53 <QuLogic> .hello qulogic
16:07:54 <zodbot> QuLogic: qulogic 'Elliott Sales de Andrade' <quantum.analyst@gmail.com>
16:08:01 <QuLogic> welcome alexsaezm!
16:08:03 <nim> it is good to see more of the people working on Go @rh and Fedora working together
16:08:11 <jcajka> #chair QuLogic
16:08:11 <zodbot> Current chairs: Eighth_Doctor QuLogic jcajka nim olem
16:09:05 <Eighth_Doctor> alexsaezm: I'm happy to sponsor, though I'd like to see a package from him first ;)
16:09:41 <alexsaezm> Quick intro... I'm working in the golang team with deparker in the Golang and Delve packages
16:10:19 <alexsaezm> Eighth_Doctor, I have one around there, with a lot of stupid mistakes :D
16:10:44 <nim> alexsaezm, we all start like that
16:10:46 <nim> :)
16:11:00 <Eighth_Doctor> that's fine, my first package was awful
16:11:21 <jcajka> we also might see the Derek Parker/deparker (The delve one) around a bit more ;)
16:11:34 <nim> hourra!
16:11:35 <alexsaezm> I thought: meh, I worked with them in RHEL, lets do it for Fedora
16:11:38 <Eighth_Doctor> behold the shame: https://src.fedoraproject.org/rpms/oggconvert/c/3d6f79f513cbcb82e98b8302964f99d41271ced9?branch=master
16:12:02 <Eighth_Doctor> that's the right attitude :)
16:13:31 <alexsaezm> I think Derek is busy today, but yeah, the idea is to be more involve in Fedora :)
16:13:53 <jcajka> thank you all for welcoming alexsaezm :)
16:14:02 <alexsaezm> thanks :D
16:14:24 <Eighth_Doctor> that's absolutely wonderful to hear!
16:14:27 <jcajka> I guess meeting ;), that brings second thing  from me, this meeting slot time
16:14:28 <nim> alexsaezm, don’t hesitate asking questions, we have multiple layers of packaging tools, and some legacy leftovers, that may be confusing at times
16:15:00 <alexsaezm> got it :D thanks :D
16:15:49 <alexsaezm> I'm still getting use to the Fedora differences with RHEL
16:16:46 <Eighth_Doctor> alexsaezm: Fedora is what RHEL will eventually be
16:16:56 <Eighth_Doctor> you can think of RHEL as pasteurized Fedora :D
16:17:06 <nim> alexsaezm, basically, you have the official spec templates in go-rpm-templates that allow doing pretty much anything, and the common simple case go2rpm generates
16:17:21 <jcajka> safe to drink :D
16:18:03 <nim> hopefully :) not all is yummy right now, I will get to this after the slot part
16:19:36 <alexsaezm> so far seems pretty safe to drink :D
16:19:50 <nim> jcajka, slot us better :)
16:20:25 <jcajka> I will need a help from you for that :) I have created poll xoyondo.com/dp/Y9j5f0YpiF0a6fl to see if it is still in right slot for us all and it seems not really so far
16:20:28 <Eighth_Doctor> 🤣
16:22:41 <jcajka> please take few minutes to fill it, so far it seems that Sunday seems best for most(3) of us
16:23:46 <alexsaezm> oh crap, I filled it wrong
16:24:15 <jcajka> it use the US week, and also I assume CEST/CET TZ there
16:24:30 <jcajka> for the TZ pin too
16:24:41 <nim> jcajka, I most definitely do not want to think about packaging on sunday evening
16:25:07 <nim> jcajka, that’s when I realise I spent the week-end on fedora stuff and it is time for some relaxation
16:26:10 <jcajka> I'm not generally against it, but I don't disagree :)
16:26:47 <jcajka> and bit is back
16:26:57 <jcajka> bit->bot
16:27:24 <alexsaezm> schedule updated
16:28:01 <QuLogic> that poll kind of breaks when I change the time zone
16:28:20 <QuLogic> it goes 6, 0-5, 7-17, 19-23, 18
16:30:51 <jcajka> hm.. works for me, with changing TZ, it shifts as expected
16:31:13 <alexsaezm> yeah, changed to Europe/Madrid and worked
16:31:50 <nim> wonderful  Europe/Paris gives you 24H time. I did not know the USA had annexed Europe/Prague
16:32:25 <nim> jcajka, it seems the website misbehaves unless you force a TZ change
16:32:49 <jcajka> might be the format I had to input it, it insisted on am/pm
16:33:18 <jcajka> last time it worked better, seems that they have improved the UX :/
16:36:07 <nim> anyway, I’ve filled my line
16:36:42 <jcajka> thank you for filling it, I will send out the results to the ML in day or two and we can discus it there further, so far it looks like Mon CEST 1900h
16:37:41 <nim> jcajka, so the slotting is done for today?
16:38:28 <nim> I’m like to report on packaging automation present and future
16:39:28 <jcajka> if nobody want to comment, want to make a decision right away(I would wait a bit for eclipseo)
16:42:06 <nim> anyone? or should I go on?
16:44:28 <jcajka> feel free to continue
16:44:35 <nim> thanks
16:45:16 <nim> anyway, as far as I understand things, we are now using a 3rd gen set of packaging conventions
16:46:04 <nim> the first gen was using gofed, and had been created by jcajka and jchaloupka
16:46:52 <nim> the resulting specs did not age well and it all dependend on python2, and I wrote some unflattering things about the result a few years ago
16:47:09 <nim> but it was an heroic effort ro create something from nothing
16:48:00 <nim> the second gen was a rewrite by myself, structured around golist as requested by jcajka and jchaloupka
16:48:24 <nim> it worked fine for the SIG but was limited
16:49:18 <nim> the third gen, that we use now, is an evolution of the 2nd gen effort to handle building the complex software used by the openshift people
16:49:55 <nim> I’m not sure it has even been used to its full potential because jchaloupka left us right after I implemented his requirements
16:50:14 <jcajka> nim: can you get to the point without name calling?
16:51:07 <nim> jcajka, sorry I don’t want to call any names, just stating why things are the way they are
16:51:41 <nim> this is not an indictment or X or Y, everyone had the best reasons to do what he did at the time
16:52:01 <jcajka> nim: that is rather subjective and I don't want this to go down as another flame
16:52:21 <jcajka> and waste of time
16:52:27 <nim> anyway, eclipseo did fine work getting the 3rd gen approved by FPC
16:52:39 <Eighth_Doctor> yeah, can we not go down this read?
16:52:39 <nim> so it is fully official right now
16:52:41 <Eighth_Doctor> *road?
16:53:13 <nim> however the 3rd gen was written at the same time google designed go modules
16:57:18 <nim> and go modules reproduce the same mecanisms in slightly different ways
16:57:18 <jcajka> *cough* after *cough*
16:57:18 <nim> because Google hit the same problems and found similar solutions
16:57:19 <nim> so I’m not sure it is useful to bring to full potential the current 3rd gen macro set
16:57:19 <nim> I would like now to remove everything that is done some other way in upstream go modules
16:57:19 <nim> and make a 4th gen macro set that relies on go module mecanisms
16:57:19 <nim> with GOPATH sources created as just an unzip of what we put in Fedora go modules
16:57:19 <jcajka> that would be awesome
16:57:19 <nim> golang/x/mod is now complete enough modist no longer relies on semi-official copies of google internal module code
16:57:20 <jcajka> "Fedora go modules" as go modules in Fedora(i.e. no Fedora module involved)?
16:57:20 <nim> yes, modules in the Go sense
16:57:20 <jcajka> :)
16:57:42 <nim> so, I’d like to know if the SIG is ready for something like that
16:58:08 <nim> that means, for example, dropping the huge set of magic switches that inhibit part of a codebase
16:58:36 <nim> and just removing in %prep via rm or patch anything we do not want to end up in our version of a go module
16:59:36 <nim> and testing code with go test ./... or go test module/... not a loop driven by golist
17:00:14 <nim> in fact it would result in removal of the huge integration shell script, and of reliance on golist
17:00:56 <nim> and depend just on the minimal module code in modist (or some other better implementation of the same thing if people find my modist coding attempts horrible)
17:00:58 <nim> ???
17:01:56 <jcajka> I think eclipseo would be best person to provide feedback for that as he is literally doing most of the packaging nowadays(as jchaloupka did)
17:02:04 <QuLogic> wfm
17:02:16 <QuLogic> in theory, anyway
17:02:38 <nim> aside from the KISS simplification aspects, rpm broke backwards compat, and grandfathering previous quirks in the next gen like I did between 2nd and 3rd is unpalatable
17:02:58 <nim> QuLogic, obviously, not something to decide today and eclipseo is a key player
17:03:22 <nim> I just wanted the idea brought to everyone’s attention so people have the time to think on it a bit
17:03:30 <nim> and look at the state modist is
17:03:46 <nim> or propose better ideas is they have some
17:03:59 <jcajka> in theory yes, I would need to see a proposal and your manpower to do the leg work(not to dump it on anybody, eclipseo) of it
17:04:32 <Eighth_Doctor> honestly, I'm not sure if rpm actually broke anything in practice
17:04:47 <Eighth_Doctor> I see the theoretical breakage, but I haven't seen anything break yet in the distro
17:04:49 <jcajka> Eighth_Doctor: +1
17:05:26 <nim> Eighth_Doctor, they broke most of the advanced stuff which we had not have the time to use heavily, and which is redundant with what upstream did in modules
17:06:43 <nim> Eighth_Doctor, and, the advanced stuff was written to solve all the problems involved in building kubernetes in pre-module times
17:06:57 <Eighth_Doctor> so it may not matter then
17:07:06 <Eighth_Doctor> k8s will be completing their move to modules this year
17:07:25 <Eighth_Doctor> OpenShift codebases have already done it, and k8s upstream is nearly done too
17:07:26 <nim> Eighth_Doctor, it may not matter if we accelerate the switch to modules
17:07:37 <Eighth_Doctor> we probably should anyway
17:08:08 <nim> Eighth_Doctor, not that module oriented won’t use the same mecanisms as the current macros rpm-side
17:08:42 <nim> Eighth_Doctor, just that the additional constrains invented by rpm maintainers will be built in from the start up not retrofited later
17:09:05 <Eighth_Doctor> sure
17:09:46 <nim> Eighth_Doctor, and yes, most of what I wrote in the various tickets about the rpm breakage, was written after thinking hard of what would be needed in module mode
17:10:14 <nim> Eighth_Doctor, that means the redhat-rpm-config PR would be a building block not a retrofit
17:11:07 <nim> so anyway, that’s all I have to write about this today unless people have more questions
17:11:30 <nim> think on it and report back what you feel
17:11:38 <nim> I have weeks of coding to do anayway
17:11:42 <nim> anyway
17:13:08 <QuLogic> In the meantime, can you merge the PR on existing macros?
17:13:34 <QuLogic> we are missing some tests, and might as well catch any issues now before a bigger change
17:15:04 <nim> QuLogic, I will look at them, sorry. I am very afraid of breaking things by merging stuff I did not test a lot
17:15:36 <nim> QuLogic, if you tell me they work fine in your package testing, I would tend to trust your opinion
17:16:24 <QuLogic> it's been a while, but afair, they just add more imports to the tests
17:18:19 <nim> QuLogic, ok, I guess we may just add the imports, and do a mass rebuild in a side tag or copr to see if one of the existing specs objects to those imports
17:19:00 <nim> QuLogic, it would still take soem days to set up the mass rebuild
17:19:12 <jcajka> nim: some bigger, more technical write up would be best(distro wide change proposal, would be best)
17:19:43 <nim> jcajka, for the import thing ? or for new macros  ?
17:20:28 <nim> for new macros a proposal needs to wait for some actual coding to see what works and what breaks
17:20:35 <nim> as a first approximation
17:22:08 <jcajka> ok, I think until you have that there is nothing really to discuss provide relevant feedback apart, that it would be awesome if the current packaging macros would be module aware
17:22:24 <jcajka> or new one
17:24:10 <nim> jcajka, works for me, I prefer early heads up than dumping things on people at the last minute
17:25:13 <jcajka> if you will have that done, there is really nothing that you will dump on anybody, because it will be kind of done ;)
17:29:08 <jcajka> any other topics?  we are well on top of the hour
17:31:22 <jcajka> if none, thank you for attending today and I will end meeting in a few minutes
17:35:46 <jcajka> #endmeeting