16:59:55 <djmitche> #startmeeting weekly
16:59:55 <bb-supy> Meeting started Tue Nov 13 16:59:55 2018 UTC and is due to finish in 60 minutes.  The chair is djmitche. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:55 <bb-supy> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:59:55 <bb-supy> The meeting name has been set to 'weekly'
17:00:01 <djmitche> aww, 5 secods early
17:00:04 <djmitche> #topic Introduction
17:00:09 <djmitche> http://bit.ly/2rup31x
17:00:21 <djmitche> This meeting has a 30-minute time limit
17:00:24 <djmitche> anyone is welcome to speak
17:00:30 <djmitche> and we follow the agenda listed above
17:00:33 <djmitche> #nick tardyp
17:00:39 <djmitche> who else is around?
17:00:46 <p12tic> hi!
17:00:48 <tardyp> hey!
17:01:06 <tardyp> nice to see you here p12tic
17:01:13 <p12tic> :)
17:01:24 * djmitche waves
17:01:26 <bdbaddog> Greetings!
17:01:35 <djmitche> wow, we're going to need more chairs!
17:01:45 <djmitche> #topic Week in Review
17:01:47 <tardyp> I guess p12tic will soon own the week in review, as he is becoming by far the first developer
17:01:53 <djmitche> awesome
17:02:15 <tardyp> I've been flooded by PRs from p12tic, sorry for late reviews..
17:02:26 <tardyp> lots of good stuff
17:02:27 <p12tic> I understand :)
17:02:35 <tardyp> some hairy stuff
17:02:49 <tardyp> which is hard to review.
17:03:06 <p12tic> yes, it's easier to write code than to properly review
17:03:24 <p12tic> which part of the meeting can I ask questions?
17:03:34 <tardyp> p12tic is reworking the canStartBuild part
17:03:39 <tardyp> not yet
17:03:43 <p12tic> ok
17:04:14 <tardyp> this part might have some gory details that nobody is mastering.
17:04:33 <djmitche> #info lots of PRs; p12tic working on canStartBuild
17:04:47 <djmitche> that's the thing that takes into account all of the reasons a buildrequest might not be ready to start?
17:04:56 <tardyp> I think I want to make the november release before this lands
17:05:13 <tardyp> djmitche: right
17:05:20 <tardyp> and there is also some customization points
17:05:26 <djmitche> #info November release coming soon
17:05:28 <djmitche> awesome
17:05:32 <tardyp> which is not very well documented
17:05:33 <djmitche> yeah, I remember that code being complex
17:05:46 <tardyp> so we don't know how we want to break that API, and if it is really one
17:06:07 <tardyp> I think part of the complexity is the willing not to break API
17:06:29 <djmitche> if it's not documentd, breaking's probably OK?
17:06:51 <tardyp> that was my ending conclusion after a while
17:07:01 <skelly> I wonder if canStartWithWorkerForBuilder can use canStartBuild
17:07:29 <tardyp> indeed it was an sgeestion I made then deleted
17:07:49 <tardyp> canStartWithWorkerForBuilder takes buildrequests while canStartBuld take buildrequest
17:08:01 <djmitche> #topic canStartBuild modifications and backward compatibility
17:08:14 <skelly> so, a loop maybe
17:08:22 <tardyp> without much evidence on why in current code
17:08:27 <djmitche> #info canStartBuild is complex and involves some barely-documented customization points that make it difficult to modify
17:08:36 <djmitche> #info considering breaking those customization points
17:08:52 <djmitche> #info also considering combining canStartWithWorkerForBuilder and canStartBuild
17:09:07 <tardyp> anyway other work from p12tic involve trying to fix the CI instabilities
17:09:23 <djmitche> oh, excellent
17:09:30 <djmitche> #topic CI instabilities
17:09:39 <djmitche> tell me more? like, bb PRs fail intermittently?
17:09:51 <tardyp> I also figured out yesterday that our unit tests was running in 25min instead of 5min since september
17:10:55 <tardyp> pylint fails from time to time
17:11:12 <tardyp> because buildbot reuses workers on hyper that were provisioned with less memoryn
17:11:37 <djmitche> ah, so just memory contention?
17:11:46 <djmitche> #info pylint fails sometimes
17:11:55 <tardyp> each job has its own size requirement and start a new hyper VM normally buildbot is not supposed to reuse
17:12:04 <djmitche> #info unit tests sometimes get provisioned on small Hyper instances and thus take a long time to run
17:12:06 <tardyp> but due to async vs sync race condition it does
17:12:11 <djmitche> eep
17:12:26 <tardyp> also some windows flaky tests have been marked flaky for windows
17:12:40 <tardyp> and also lot of work trying to make the e2e tests more reliable
17:13:04 <tardyp> those are the three major flakyness reasons
17:13:10 <djmitche> got it
17:13:11 <tardyp> pylint windows and e2e
17:13:22 <tardyp> each of them with very different root causes
17:13:23 <djmitche> #info some windows tests are flaky (and marked as such now)
17:13:35 <p12tic> also mysql has started to fail startup sometimes since yesterday
17:13:37 <djmitche> #info and e2e tests are flaky just due to including everything
17:13:40 <djmitche> ugh
17:13:47 <djmitche> #info p12tic working on these issues
17:14:15 <tardyp> I also gave hyper access keys to p12tic so that he can debug the builds
17:14:44 <djmitche> ++
17:14:51 <tardyp> he requested access to appveyor as well so that he can restart builds
17:14:56 <djmitche> so you mentioned asking questions -- what's up?
17:15:01 <djmitche> ++ to appveyor too
17:15:13 <tardyp> I think this is up to djmitche to give as you are the owner of that account
17:15:47 <p12tic> i was wondering whether we can remove old slave naming compatibility layer
17:15:59 <djmitche> oh
17:16:10 <djmitche> #topic Removing slave-naming compatibility
17:16:19 <p12tic> it's 2 years since the first release of 0.9.x already
17:16:19 <skelly> my vote would be to start the clock at 1.0 and wait some time after that
17:16:25 <djmitche> that feels like it should be in 2.0?
17:16:27 <djmitche> yeah
17:16:38 <p12tic> agreed
17:16:41 <djmitche> I think semver means you can increment that leftmost number quite a lot
17:16:51 <skelly> yes
17:16:54 <djmitche> no reason for 2.0 to take the .. 15 years? that 0.x -> 1.x took
17:17:18 <skelly> generally best to ensure the major API changes aren't traumatic to the community
17:17:22 <tardyp> I think this would also be a good reason to drop canStartBuild if we go for 2.0
17:17:53 <skelly> if everyone has transitioned to the worker name on workers, then no problem
17:18:12 <skelly> I doubt that has happened fully yet, I know we're still using 0.8 workers to support 0.8 and 1.x masters
17:18:19 <tardyp> I was thinking 2.0 was more for the worker protocol over websocket but that can be for 3.0
17:18:27 <skelly> or 2.1
17:18:42 <tardyp> I think we should keep the 0.8 worker compat scheme
17:18:43 <djmitche> I think metering out the breaking changes one at a time makes migrations a little easier
17:18:59 <skelly> yes, hello python 3
17:19:01 <djmitche> yeah, if that's not causing difficulty with development, it doesn't hurt to keep it
17:19:03 <djmitche> haha
17:19:04 <tardyp> just the double API is extra complexity for nothing
17:19:36 <skelly> dropping the old name for master API compat (e.g., not 0.8 workers) seems reasonable
17:20:09 <tardyp> I think we have an #agreement
17:20:47 <djmitche> I'm not sure what that means :)
17:20:51 <djmitche> #chair tardyp
17:20:51 <bb-supy> Current chairs: djmitche tardyp
17:20:55 <tardyp> git rm -master/buildbot/worker_transition.py
17:20:55 <djmitche> ^^ to mark the agreement :)
17:21:11 <tardyp> #agreed git rm -master/buildbot/worker_transition.py
17:21:36 <skelly> ensure 0.8 workers can connect to the post-rm masters is what I mean and sounds like tardyp agrees
17:21:51 <skelly> so, drop BuildSlave pointing to Worker, et al
17:21:55 <tardyp> #agree 0.8 slaves must still be able to connect
17:22:01 <tardyp> #agreed 0.8 slaves must still be able to connect
17:22:12 <djmitche> ++
17:22:41 <djmitche> I don't have an update on the hardware workers or the book chapter (the last two agenda items)
17:22:48 <djmitche> so .. other topics?
17:22:52 <skelly> I had one
17:22:52 <tardyp> 57 occurences of deprecatedWorkerModuleAttribute and reportDeprecatedWorkerModuleUsage
17:23:03 <skelly> I want to set up a discourse instance
17:23:17 <skelly> and "move" mailing list discussions there
17:23:35 <skelly> I wouldn't shut down the ML probably ever, but I feel like it'd get better traffic
17:23:51 <tardyp> discourse.buildbot.net?
17:23:57 <skelly> something like that, yeah
17:24:13 <skelly> I'd want to do this after integrating service1 back
17:24:15 <tardyp> sounds fine to me
17:24:40 <djmitche> #topic Adding Discource for Buildbot
17:24:43 <djmitche> #undo
17:24:43 <bb-supy> Removing item from minutes: <ircmeeting.items.Topic object at 0x806f61d10>
17:24:46 <djmitche> #topic Adding Discourse for Buildbot
17:25:06 <bdbaddog> Does discourse have open source version?
17:25:08 <djmitche> #info Proposal is to add a discourse instance for Buildbot, and move dicussions from the mailing list to that service
17:25:15 <skelly> it's only open source as far as I know
17:25:27 <bdbaddog> https://payments.discourse.org/pricing
17:25:38 <skelly> they have a hosted version for people that don't want to self-host
17:25:45 <tardyp> thats for saas
17:25:46 <skelly> I believe Rust opts for that
17:26:03 <skelly> if they have a $0 tier for OSS projects, I'd take it but I doubt it
17:26:30 <bdbaddog> ahh. I see. they have a docker install open source as well.
17:26:56 <tardyp> is it in freebsd?
17:26:58 <djmitche> I think this is a great idea - signing up for a mailing list is pretty old-school in 2018
17:27:08 <skelly> let me check
17:27:11 <tardyp> https://meta.discourse.org/t/discourse-doesnt-work-on-freebsd/30253
17:27:16 <skelly> ha ha
17:27:48 <skelly> is that only for the Docker install?
17:28:34 <skelly> well, I'll look into it
17:28:57 <tardyp> sounds fun project. not easiest
17:29:01 <djmitche> yeah
17:29:14 <djmitche> #info skelly will look into the technical aspects
17:29:27 <djmitche> probably worth bringing up on the users list, too?
17:29:31 <djmitche> oo, we are almost at time :)
17:29:31 <skelly> yes
17:29:40 <skelly> there's vm1 too and setting up a linux VM isn't too hard
17:29:46 <skelly> I've done it plenty of times
17:29:52 <skelly> (on FreeBSD)
17:30:01 <djmitche> yeah
17:30:06 <djmitche> ok!
17:30:07 <skelly> sorry, you're over
17:30:09 <djmitche> haha
17:30:12 <djmitche> #endmeeting