16:03:00 <jcajka> #startmeeting Go SIG meeting
16:03:00 <zodbot> Meeting started Tue May 28 16:03:00 2019 UTC.
16:03:00 <zodbot> This meeting is logged and archived in a public location.
16:03:00 <zodbot> The chair is jcajka. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:00 <zodbot> The meeting name has been set to 'go_sig_meeting'
16:03:09 <jcajka> #topic Roll Call
16:03:29 <decathorpe> hi!
16:03:43 <jcajka> #chair decathorpe
16:03:43 <zodbot> Current chairs: decathorpe jcajka
16:03:46 <jcajka> hello :)
16:04:36 <jcajka> nim: welcome :)
16:04:47 <jcajka> #chair nim
16:04:47 <zodbot> Current chairs: decathorpe jcajka nim
16:04:49 <decathorpe> FYI, I'm stuck in a bus with my phone on screen keyboard, so I will read more than I write
16:05:51 <nim> .hello2 jcajka
16:05:51 <zodbot> nim: nim 'None' <nicolas.mailhot@laposte.net>
16:06:09 <nim> Hi;)
16:06:40 <jcajka> QuLogic, Son_Goku eclipseo meeting time
16:07:30 <Son_Goku> jcajka, I'm going to grab lunch and come back in a few
16:08:07 <jcajka> np
16:08:51 <jcajka> we have two topics in the issues, one from me and other from QuLogic
16:09:16 <jcajka> nim do you know what is up there? or should we wait for him?
16:09:38 <jcajka> https://pagure.io/GoSIG/go-sig/issue/24
16:10:31 <QuLogic> .hello qulogic
16:10:34 <zodbot> QuLogic: qulogic 'Elliott Sales de Andrade' <quantum.analyst@gmail.com>
16:10:42 <jcajka> #chair QuLogic
16:10:42 <zodbot> Current chairs: QuLogic decathorpe jcajka nim
16:10:43 <jcajka> :)
16:10:57 <jcajka> so let's dive in to it
16:11:12 <nim> ok
16:11:12 <jcajka> #topic Build the new *golist* package https://pagure.io/GoSIG/go-sig/issue/24
16:12:09 <jcajka> QuLogic: what you wanted to talk about?
16:12:26 <QuLogic> ok, as I posted on the ML, I tagged 0.10.0 a couple days ago and opened a review request
16:12:42 <nim> from my POW the golist code is good
16:13:01 <QuLogic> we also need to coordinate splitting it out from where it is right now
16:13:03 <nim> but eclipseo is the one who's exercising it a lot right now
16:13:31 <eclipseo> .hello2
16:13:32 <zodbot> eclipseo: eclipseo 'Robert-André Mauchin' <zebob.m@gmail.com>
16:13:56 <nim> from a packaging POW I'd like it to be closer to the package we tested in my copr or it will require reworks in the other specs
16:14:02 <QuLogic> review is https://bugzilla.redhat.com/show_bug.cgi?id=1714090
16:14:04 <jcajka> #chair eclipseo
16:14:04 <zodbot> Current chairs: QuLogic decathorpe eclipseo jcajka nim
16:14:25 <nim> hello eclipseo
16:14:41 <eclipseo> hello
16:14:59 <eclipseo> The new Golist works fine om my end
16:15:02 <eclipseo> *on
16:15:16 <jcajka> QuLogic: so if I understand that correctly you want me to drop golist from the compiler "meta" package(when the package will land in Fedora), right?
16:15:24 <nim> eclipseo, did you test 0.10.0 or the pre-version I pushed in my copr last week?
16:15:32 <QuLogic> jcajka: right
16:15:42 <eclipseo> nim yes the one with the new --template thingie
16:16:04 <jcajka> forks for me, and is it targeted for rawhide only?
16:16:11 <jcajka> works...
16:16:17 <nim> eclipseo, it was already in the pre-version QuLogic added a PR since
16:16:32 <nim> which is awesome BTW
16:16:57 <QuLogic> jcajka: I'd backport to fix tests, but might wait for it to bake a bit in Rawhide and we'll see how it goes
16:17:13 <jcajka> ok, sounds good to me
16:18:38 <nim> QuLogic, can you take a look at the spec in https://copr.fedorainfracloud.org/coprs/nim/macros-ng/build/912687/ and tell us where you want to diverge
16:18:51 <nim> it's your package so you can diverge if you want to
16:19:09 <nim> QuLogic, but if you diverge I need to take it into account in the other specs
16:19:23 <nim> and so far we've tested this spec, not yours
16:19:32 <nim> ?
16:19:45 <QuLogic> well, the main difference is I'm still using v1 macros of course
16:20:53 <nim> QuLogic, i was sort of hoping we could push the new macros and the new golist in devel in one go so eclipseo could work from a clean state
16:21:00 <nim> and not worry about the past
16:21:18 <QuLogic> also I named it by %{goname}, not golist, because I assume it's only 'well-known' to fedora go packages
16:21:41 <QuLogic> but if we decide otherwise, I can rename or Provides: golist (like Rust do)
16:22:16 <QuLogic> are new macros ready? there's no inherent reason to build simultaneously so far
16:22:35 <jcajka> QuLogic: IMHO that provides would be great for user/packager experience
16:23:30 <nim> QuLogic, they'rs 99% ready. i just need to test a little the --with-test fix you pushed in your latest PR to remove the corresponding workaround
16:24:18 <QuLogic> jcajka: sure, that's true
16:24:44 <nim> The code is written, I just need to build the package, use it for one or two pathological specs, and then ask eclipseo if it's ok with him
16:24:45 <nim> https://pagure.io/fork/nim/go-rpm-macros/tree/golist-with-tests
16:25:28 <nim> eclipseo tested all your new golist code except this part last week
16:26:19 <QuLogic> anyway, I'm not in a rush per se, just tired of having to patch mock when doing go package reviews
16:26:51 <nim> IMHO the srpm should be name golist, because it's a command, and I don't expect anyone to develop against the golist code
16:27:06 <nim> but, if you prefer it otherwise, that's ok
16:27:22 <nim> you just need to be 100% in sync with jcajka on the rpm name
16:27:51 <nim> otherwise the upgrade path from the golist embedded in the old macro set and your clean golist won't work
16:28:34 <jcajka> QuLogic, nim: would call that sync(I have no hard preference), I just need to know it for the switch in the end
16:29:14 <QuLogic> nim: actually, that's a good point, let's go for golist then, and not bother providing -devel either
16:29:42 <jcajka> QuLogic: +1
16:29:50 <nim> QuLogic, +1
16:30:01 <nim> to do the upgrade to your new package
16:30:05 <nim> cleanly
16:30:41 <nim> you need to put the golist binary in the go-compilers package in a subpackage named the same way as your new package (ie golist)
16:30:58 <eclipseo> any news on the redhat-rpm-config front?
16:31:35 <nim> and then it will upgrade gracefully to your new package, separately from the rest, as long as the temporary golist go-compiler subpackage has a lower evr
16:31:47 <nim> eclipseo, no news :(
16:32:09 <nim> Pharaoh_Atem has still not made his rpmdevtools change
16:32:31 <nim> he'll tell us when he's back
16:32:40 <eclipseo> yeah seems he's busy
16:32:44 <QuLogic> nim: why would I need that? just a new go-compilers with Requires:golist>=0.10.0 should work?
16:32:46 <nim> so since the rest of the changes are merged
16:33:20 <nim> I think we just need to request a redhat-rpm-config rebuild
16:33:43 <nim> and hardcode our side the directory Pharaoh_Atem was supposed to decide on
16:34:14 <nim> QuLogic, if you don't do it that way your package will conflict with go-compilers and nothing will build anymore
16:35:09 <nim> QuLogic, you need to separate the golist binary upgrade path from the upgrade path of the old go-compilers macros, or we'll have huge problems
16:36:09 <nim> QuLogic, just putting the golist binary jchaloup embedded in the go-compilers macros in a subpackage is sufficient to separate the upgrade paths
16:37:08 <nim> QuLogic, rpm does not care if a rpm is produced from the same spec or another spec, for upgrade paths POW subpackage = separate package
16:37:34 <jcajka> nim: I don't see that, if we correctly drop it and we will push it out at once, anyway I have to check that
16:38:06 <nim> jcajka, well check it in a copr before
16:38:14 <QuLogic> nim: yes, split package conflicts with old version and original starts requiring split one
16:38:22 <QuLogic> this should upgrade correctly
16:38:43 <nim> IIRC you had a chicken and egg problem, golist required the old macro set (golist included) to be built
16:38:43 <jcajka> QuLogic: I have same opinion, and that is what I need to check
16:39:26 <nim> so old golist needs to exist in the repo for new golist to be built, but as soon as new golist is built it conflicts if the old wone was not split before
16:39:48 <QuLogic> ok, bootstrap is a different problem, which is why building with old macros first might be easier
16:40:11 <nim> jcajka, but if the upgrade path works in copr it will work in koji, just do not do it blindly in koji before testing
16:40:25 <nim> I know the subpackage way works I tested it
16:40:42 <QuLogic> https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_splitting_packages
16:40:43 <jcajka> QuLogic, nim: so "new" macros are not backwards compatible?
16:41:15 <nim> jcajka, they're mostly backwards compatible
16:41:43 <nim> jcajka, the main problem is not macro compatibility, it's handling the upgrade paths cleanly rm side
16:41:46 <nim> rpm side
16:42:14 <jcajka> nim: we will handle that with QuLogic
16:42:22 <nim> ok
16:42:59 <nim> unless eclipseo reports problems macro-side, it's green for me too
16:43:49 <nim> just a few more hours of integration to make use of --with-tests macro-side, and I can ask eclipseo if the review request can go
16:43:58 <jcajka> ok, all sounds set to me, I guess we can move to next topic, right?
16:44:43 <nim> ok
16:45:20 <nim> BTW upstream rpm has finished merging the dynamic BR logic yesterday, so it should land in devel soonish
16:45:23 <QuLogic> #action QuLogic rename review to golist & drop -devel subpackage
16:46:09 <nim> https://github.com/rpm-software-management/rpm/issues/104#issuecomment-496447889
16:46:34 <jcajka> #action jcajka switch compiler meta package to stand alone golist, in sync with QuLogic
16:47:14 <jcajka> #topic Go1.13 https://pagure.io/GoSIG/go-sig/issue/30
16:47:39 <nim> #action nim make use of the latest golist fixes in the new macros, then push the result to devel
16:48:14 <jcajka> I have open for my self tracking issue for Go 1.13 re-base, there are more topics that we will need to address most notably modules, but I would leave that out for next meeting
16:48:31 <jcajka> thing that I want to talk about is Go proxy and sumdb
16:48:41 <nim> jcajka, I haven't had the time to look at it closely
16:48:51 <eclipseo> Don't know much about either
16:48:52 <QuLogic> what is sumdb? just a cache of Go.sum's?
16:49:09 <nim> jcajka, but it seems that upstream deferred all the "make module usable for others" to 1.14
16:49:23 <nim> jcajka, so we'll have to use 1.13 in non-module mode
16:49:57 <jcajka> nim: haven't seen that yet
16:50:09 <jcajka> QuLogic, eclipseo: basically https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md
16:50:15 <nim> jcajka, in particular, I think the multiple goproxy support, which was one of the core changes we needed
16:50:22 <nim> won't be in 1.13
16:50:31 <nim> even though upstream coded it for 1.14
16:51:04 <nim> but I haven't have the time to look at it deeply
16:51:19 <nim> I just seem to remember that upstream declared 1.13 finished
16:51:47 <eclipseo> oh it's the Notary renamed.
16:51:51 <jcajka> nim: that is cantered about what I wanted to talk about, I would like to have proxy in direct mode and sumdb in off by default in Go 1.13 in Fedora
16:51:51 <nim> and after that started announcing golang/x/mod = the fixes we needed
16:52:13 <jcajka> cantered -> centered
16:52:32 <jcajka> 1. reason are builds in koji
16:52:40 <jcajka> 2. reason is privacy of users
16:52:59 <eclipseo> who's brilliant idea was this
16:54:02 <nim> jcajka, even in direct mod it won't work in koji because direct mode = internet calls
16:54:14 <nim> and koji will block those
16:54:38 <nim> it will probably work outside koji on dev workstations however
16:54:52 <jcajka> nim: yeah, we will have to workaround it further in koji :/
16:55:13 <jcajka> this is for change that will be directly at compiler level
16:55:56 <eclipseo> sumdb will never work for us as we patch sounces relatively often
16:55:59 <jcajka> I will mention all of this in system wide proposal
16:56:36 <nim> IMHO whether we agree with sumdb or not it's not mature upstream. The rest of the module code, maybe, this part not
16:57:02 <QuLogic> I don't understand the rationale here for sumdb
16:57:22 <nim> and, assuming it matures technically for 1.14, it will need a very hard look
16:57:31 <nim> probably even FESCO side
16:57:46 <nim> to decide if it's something compatible with Fedora objectives
16:57:48 <QuLogic> are they really claiming that tls can be mitm, but not their site?
16:58:10 <nim> QuLogic, it's the usual others are bad, but we do not evil, trust us
16:58:19 <jcajka> eclipseo: IMHO it is nearly useless for any public use(as implemented by upstream instance), but it can have great value in individual private instance, especially in environments that require tight control about deps(and are not using any other form of packaging like rpm)
16:58:40 <nim> QuLogic, and windows dev situation is so poor, they're delighted Google takes care of it and do not worry about the consequences
16:59:03 <jcajka> QuLogic: in my personal view it is just MITM proxy purposed to track all Go user
16:59:11 <jcajka> users
16:59:45 <nim> that's why even if the technical part matures, the decision needs to be taken at least FESCO side
17:00:07 <nim> I'd love to have spot look at this. It's his kind of mess
17:00:33 <jcajka> without any added value, if I'm not mistaken nearly "anybody" will be able to add check sums to google's sumdb
17:01:27 <jcajka> ok, do I see correctly that we are not in disagreement, here
17:01:32 <nim> IIRC pretty anyone will be able to tell the Google robot: look at my code, and attest its sum
17:02:00 <nim> but, I'm also quite sure Google or Microsoft via GitHub
17:02:17 <nim> will couple sumdb with a code audit robot
17:02:33 <nim> and tell Go developpers
17:02:50 <eclipseo> I'm surprised how fast this was adopted upstream with little to no discussion
17:02:55 <nim> if you want your project to exist in sumdb and the Go universe, you need to conform to our rules
17:03:35 <jcajka> eclipseo: I have been surprised too and more that I have been only one rising any concerns
17:03:38 <nim> ie pretty much the same situation as in the android playstore, with no real security, but ultimate veto power Google side
17:04:40 <nim> jcajka, most Go devs are so busy not thinking about free software implications, they won't react
17:04:42 * Pharaoh_Atem is back
17:05:05 <Pharaoh_Atem> jcajka, nim: I've been very sick over the past couple of weeks
17:05:18 <Pharaoh_Atem> I've just barely recovered last week and still am not fully back up to 100%
17:05:24 <nim> Pharaoh_Atem, hope you will get better
17:05:31 <eclipseo> got2go brb later
17:05:32 <jcajka> Pharaoh_Atem: sorry to hear that, I hope you are getting better
17:05:38 <nim> Pharaoh_Atem, I was also quite sick last week, it sucks
17:05:52 <Pharaoh_Atem> yeah, I caught at cold at Red Hat Summit, which turned into bronchitis
17:06:12 <nim> bad weather this year :(
17:06:39 <Pharaoh_Atem> yeah
17:06:51 <Pharaoh_Atem> the small jaunt to Germany for the openSUSE conference last weekend wasn't too bad
17:07:00 <Pharaoh_Atem> but it definitely slightly inhibited recovery
17:07:22 <jcajka> eclipseo: ack
17:07:40 <Pharaoh_Atem> nim, jcajka: I did discuss with the openSUSE folks about our work on golang packaging
17:07:49 <nim> eclipseo, just tell me when I'm done if the result works for you, and we'll push it to devel
17:07:59 <Pharaoh_Atem> they're interested in adopting it, but we need to start being mindful of the restrictions of the openSUSE Build Service
17:08:00 <nim> Pharaoh_Atem, wonderful!
17:08:19 <Pharaoh_Atem> among other things, we can *never* make Dynamic BuildRequires mandatory
17:08:26 <Pharaoh_Atem> because their buildsystem can't handle it
17:08:59 <Pharaoh_Atem> we should also probably pull in the openSUSE/Mageia portability adaptations we had in rust2rpm into go2rpm as well
17:09:09 <nim> Pharaoh_Atem, well I don't really see how they could be made mandatory
17:09:09 <Pharaoh_Atem> and as rpm-config-SUSE maintainer, I should look into pulling in the forge macros
17:09:31 <Pharaoh_Atem> nim: I'm just pointing out that as a point of clarification
17:09:45 <nim> Pharaoh_Atem, however that means they won't be able to use the Fedora specs that autocompute BRs without computing those manually their side
17:10:10 <Pharaoh_Atem> I don't know whether we'll be able to use it anytime soon on the Fedora side either
17:10:18 <Pharaoh_Atem> given how slow Koji development is
17:10:46 <nim> Pharaoh_Atem, the code has been merged upstream rpm and mock side
17:10:51 <Pharaoh_Atem> yep, I know
17:11:01 <Pharaoh_Atem> I was talking with ffesti at openSUSE Conference about it
17:11:12 <Pharaoh_Atem> along with some of the OBS developers
17:11:19 <nim> Pharaoh_Atem, so only koji-specific things may need adaptation
17:11:33 <Pharaoh_Atem> yeah, I know... we'll see how that goes
17:12:19 <nim> and rpm upstream was very careful to make something that didn't require deep knowledge in the upper stacks
17:13:48 <nim> Pharaoh_Atem, anyway: I'm can work with you on the forge macro front if you need changes
17:13:57 <Pharaoh_Atem> cool, thanks
17:14:15 <nim> Pharaoh_Atem, and the dynbr thing will happen sooner or later in Fedora now the core infra is done
17:14:32 <jcajka> Pharaoh_Atem: +1 IMHO it would be great if dynamic BR part wouldn't be mandatory, there has been possibility to run with conservative BRs
17:14:39 <nim> Pharaoh_Atem, rpm devs have made it part of their rpm 1.15 change proposal
17:14:47 <Pharaoh_Atem> yeah, it's part of rpm 4.15
17:15:21 <nim> IMHO they will be very cross if Fedora does not start using it after all their coding and fixing
17:15:41 <nim> even if it is optional and not mandatory
17:15:57 <Pharaoh_Atem> jcajka: indeed, the point is that the packager is able to control what stuff is used as inputs for the build, and because OBS does pre-build dependency resolution to determine build cycles and such, they can't take advantage of dynbrs
17:16:33 <Pharaoh_Atem> and since OBS builds don't use a package manager to install packages (it has its own lightweight mechanism), there's nothing to call back and do it
17:17:06 <nim> Pharaoh_Atem, I'm sure the OBS people will find a solution if it works well Fedora-side*
17:17:19 <nim> Pharaoh_Atem, they just need to see it work first
17:17:22 <Pharaoh_Atem> perhaps
17:17:33 <Pharaoh_Atem> they didn't seem terribly enthused when we discussed it
17:17:35 <Pharaoh_Atem> but we'll see
17:17:52 <jcajka> Pharaoh_Atem: I agree, interesting, I don't know much about OBS
17:18:20 <Pharaoh_Atem> jcajka: it's an awesome system... just ask ignatenkobrain
17:18:29 <nim> Pharaoh_Atem, rpm upstream was the same, it took two years of explaining to make them seem the point, and now it's all done
17:18:48 <jcajka> Pharaoh_Atem: BTW do you know what openSUSE folks think about https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md ?
17:19:06 <Pharaoh_Atem> they didn't know about this until I told them last weekend
17:19:12 <Pharaoh_Atem> they're not happy about it
17:19:21 <Pharaoh_Atem> they've more or less said "we'll patch it out"
17:19:35 <jcajka> I guess same here ;)
17:20:13 <Pharaoh_Atem> we all basically agreed that Google doesn't give a damn about external consumers of their ecosystem :/
17:20:25 <nim> Pharaoh_Atem, they give a damn
17:20:27 <jcajka> but I would leave it in, just de-configured if there will be a way(it seem at the moment)
17:20:37 <jcajka> seems
17:20:43 <nim> Pharaoh_Atem, they just prefer the opportunity to be in the control seat
17:20:49 <nim> Pharaoh_Atem, to pleasing others
17:21:01 <Pharaoh_Atem> if there's a way to do that or let us introduce a local database server to contact, then I think it's workable
17:21:19 <nim> my personal objective is
17:21:30 <nim> 1. get to the pont we build our own modules
17:21:43 <nim> 2. get to the point we deploy those in a system directory
17:22:05 <nim> 3. set GOPROXY to point to this directory, without sumdb checks
17:22:19 <nim> in koji
17:22:22 <nim> and for users
17:22:42 <nim> propably something like our GOPROXY, with a fallback to direct
17:22:57 <nim> and sumdb only on the direct path
17:23:02 <nim> if any
17:23:19 <nim> IIRC the multiple goproxy thing will work in 1.1.4
17:23:22 <nim> 1.14
17:23:35 <nim> not sure how it interacts with sumdb however
17:24:22 <nim> with local system dir of modules, without sumdb, you don't need any special database
17:24:23 <QuLogic> why do we need multiple go proxy again? for testing the just built thing?
17:24:29 <nim> either Suse or Fedora side
17:24:37 <Pharaoh_Atem> nice
17:25:04 <nim> QuLogic, you need the multiple goproxy thing in koji
17:25:37 <nim> QuLogic, to be able to compose modules provided by other packages (in a ro system dir)
17:25:49 <nim> QuLogic, and the ones you're creating in the build
17:26:05 <nim> QuLogic, and on a dev system it's the same
17:26:15 <nim> QuLogic, you need multiple goproxy
17:26:27 <Pharaoh_Atem> jcajka, nim: btw, you guys might find this presentation by ignatenkobrain interesting: https://www.youtube.com/watch?v=izHUvjO0Jhw
17:26:28 <jcajka> QuLogic: as nim said :)
17:26:31 <nim> QuLogic, to compose the go modules provided by the os
17:26:52 <nim> QuLogic, with the ones downloaded from the internet and the ones created by the dev
17:27:09 <jcajka> Pharaoh_Atem: will check it out, thanks
17:27:28 <nim> QuLogic, without multiple goproxy enabling system go modules, disables everything else
17:27:43 <nim> QuLogic, wich is clearly unworkable
17:27:54 <nim> Pharaoh_Atem, thanks for the link!
17:28:46 <nim> QuLogic, in the original module design, there was a single goproxy, because you were supposed to download directly every tsingle module you needed to use
17:29:15 <nim> QuLogic, and the sumdb part was intended to make sure you only saw the Internet Google approved of
17:29:24 <eclipseo> (i'm back)
17:29:35 <nim> QuLogic, ie a walled garder, without Google paying for the walls
17:30:18 <nim> I think upstream relented on multiple goproxies because it made problems for everyone except them
17:30:40 <nim> not just free software guys, but also their partners closed software side
17:30:49 <nim> eclipseo, welcome
17:31:10 <nim> jcajka, anyway: +1 for disabling sumdb for 1.13
17:31:18 <jcajka> ack :)
17:31:35 <nim> jcajka, needs a close look (not only technical) before enabling it in 1.14
17:31:37 <eclipseo> I don't see sumdb going anywhere in distro
17:32:06 <nim> jcajka, I don't like mutch enabling the internet download pipeline before we have our own module repos
17:32:24 <nim> jcajka, but ptobably unavoidable to have something devs can use
17:32:33 <jcajka> nim: it will be in change proposal, in the mean time you can get Go "1.13" from https://copr.fedorainfracloud.org/coprs/jcajka/golang-rawhide/ with proxy and sumdb disabled
17:33:48 <nim> eclipseo, it may yet morph in domething useful if enough people make Google understand their solution is too Google-centric
17:34:12 <jcajka> let's move to open floor
17:34:21 <jcajka> #topic Open floor
17:34:30 <nim> however, it seems the GAFAM want to play the "who owns the code" game right now, with sumdb on Google's side and GitHub on Microsofts
17:34:46 <jcajka> nim: GAFAM?
17:34:58 <eclipseo> So for the packaqing side of things, I still have 235 packages to process
17:35:16 <eclipseo> means FAANG
17:35:21 <nim> Google Apple FaceBook Amazon Microsoft.
17:35:21 <eclipseo> in French
17:35:38 <jcajka> oh... ok
17:36:12 <eclipseo> oh speaking of Go 1.13
17:36:29 <eclipseo> jcajka: you plan to do a Change Proposal for it?
17:36:36 <jcajka> eclipseo: yep
17:36:54 <jcajka> I hope to get it done by next week
17:36:55 <eclipseo> do you plan a mass rebuild too?
17:37:19 <jcajka> eclipseo: yes as usual, if there won't be anything out of ordinary for macros
17:37:19 <eclipseo> 'cause I expect some tests/build failures from it too
17:38:09 <eclipseo> No but since we added a mass rebuild in our change proposal for implementing macros, we should just do one irstead
17:38:14 <eclipseo> *instead
17:38:46 <jcajka> eclipseo: ok, guess it is not necessary for Go on its own
17:38:51 <jcajka> then
17:40:19 <eclipseo> I haven't requested a mass rebuid yet, so if you want to do one for 1.13 that's fine, I'll skip mine, but we need to agree on a date
17:41:03 <eclipseo> because I need to update all Go packages first, hoping I will have the time to do all
17:41:40 <nim> eclipseo, I can probably finish integrating last week golist fixes in the new macro this evening
17:41:43 <QuLogic> split the work if you need to?
17:41:52 <jcajka> eclipseo: IMO it would be better if you do it on your own after me landing the Go 1.13, as I would expect that you will need to do more than the regular "dumb" one, but I can open rel-eng ticket for it though
17:42:05 <nim> eclipseo, and then it goes to devel when you geenlight it
17:42:22 <jcajka> and in general help with it
17:42:38 <eclipseo> ok
17:44:07 <jcajka> we are well on top of the hour, let's end the formal part of the meeting, any objections?
17:44:22 <nim> not from me
17:44:25 <Pharaoh_Atem> none from me
17:44:42 <eclipseo> wekre good
17:45:11 <jcajka> #endmeeting