17:00:07 <djmitche> #startmeeting weekly
17:00:07 <bb-supy> Meeting started Tue Jan 22 17:00:07 2019 UTC and is due to finish in 60 minutes.  The chair is djmitche. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:07 <bb-supy> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:07 <bb-supy> The meeting name has been set to 'weekly'
17:00:12 <djmitche> dunno, it's getting intense :/
17:00:20 <djmitche> #topic Introduction
17:00:25 <djmitche> http://bit.ly/2rup31x
17:00:27 <djmitche> ^^ agenda
17:00:33 <djmitche> time limit 30 minutes, anyone is welcome to speak :)
17:00:43 <djmitche> #nick tardyp
17:00:46 <djmitche> who else is around?
17:01:46 <djmitche> haha, busy meeting then :)
17:01:50 <djmitche> #topic Week in Review
17:01:51 <djmitche> what's new?
17:02:27 <tardyp> We released 1.8.0 this week and had a great week with our new kube infra
17:02:47 <tardyp> it is still a bit slow, as we don't have many CPU, but this is improving
17:03:10 <tardyp> as we are also removing the support for 2.7, so this will remove a bunch of tests in the test matrix
17:03:15 <djmitche> congratulations!
17:03:22 <djmitche> #info Released 1.8.0
17:03:36 <djmitche> #info moving to Kubernetes on GCP, as previous hosting is shutting down
17:03:50 <djmitche> #info Dropping support for Python-2.7
17:03:52 <tardyp> There are then lots of 2.0 PRs which remove lots of 2.7 compat stuff
17:03:55 <djmitche> awesome
17:03:59 <djmitche> #info next up is 2.0
17:04:29 <djmitche> anything else to discuss re Python-2.7
17:04:30 <tardyp> I'll probably release 2.0 quickly after merging those
17:04:53 <djmitche> awesome
17:05:01 <djmitche> (I say that too often)
17:05:01 <rjarry> hi o/
17:05:03 <p12tic> slave api removal will be included there, right? :-)
17:05:10 <p12tic> hi!
17:05:16 <djmitche> hi!
17:05:22 <djmitche> as in, the old naming?
17:05:28 <tardyp> yes, this is part of the stuff to be merged
17:05:36 <p12tic> ok, just confirmed. ty
17:05:37 <tardyp> after I make my 2.7 removal PR work
17:05:54 <djmitche> #info also removing "slave" naming
17:06:13 <p12tic> another point, can we considering making any undocumented internal API private?
17:06:27 <djmitche> #topic Undocumented APIs
17:06:27 <p12tic> for 2.0
17:06:40 <rjarry> that does not seem too crazy
17:06:42 <djmitche> I think that's informally the case -- that's why I deleted teh apidocs way back when
17:06:48 <djmitche> but making it formally the case seems like a good idea
17:07:01 <p12tic> that would allow improvements that are not possible right now
17:07:05 <tardyp> so you mean adding a bunch of _
17:07:07 <tardyp> ?
17:07:08 <p12tic> due to locking us to existing apis
17:07:13 <tardyp> before non APIs?
17:07:22 <p12tic> i mean
17:07:23 <p12tic> e.g.
17:07:34 <p12tic> there's BuildRequestDistributor and I think it needs a refactor
17:07:47 <p12tic> right now we can't do that because it's public API
17:07:52 <rjarry> is it ?
17:08:02 <p12tic> i mean, it's named without _ prefix
17:08:09 <rjarry> ah
17:08:10 <p12tic> so people may consider it public
17:08:17 <rjarry> but it is not documented
17:08:22 <p12tic> yeah
17:08:30 <p12tic> I suggest we make that explicit in the docs
17:08:34 <djmitche> ++
17:08:40 <p12tic> That if you want to use anything not in the docs
17:08:42 <rjarry> yep, agreed
17:08:42 <p12tic> please open issue
17:08:48 <p12tic> and we'll review
17:08:49 <djmitche> I think a distinction between "using" and "subclassing" or the like
17:08:53 <djmitche> iirc that class is named in the docs
17:08:58 <djmitche> so maybe just more detail about what's OK and what's not
17:09:28 <tardyp> yes. Our policy is that everything that is not documented in doc, we can change it without notice
17:09:39 <p12tic> ok, I will make a PR making that explicit. thanks!
17:09:41 <rjarry> tardyp: is that written somehere?
17:09:50 <tardyp> we have some code that has the _ prefix, but this is not all
17:10:09 <tardyp> I don't know if it is worth to add _ prefix everywhere though
17:10:17 <rjarry> I feel that adding _ prefixes everywhere would be a bit too much
17:10:24 <tardyp> I don't know if this is written anywhere
17:10:34 <p12tic> I think it's worth having _ prefix as separate
17:10:45 <tardyp> this is more a policy that dustin started, and that I try to continue
17:10:52 <rjarry> especially if we "forget" to prefix a symbol that was not intended as public api, somebody may assume it is
17:10:52 <djmitche> this seems like a good 2.0 thing to firm up
17:10:54 <p12tic> so that we ourselves know what APIs other (internal) classes can use
17:11:15 <djmitche> are we agreed then?
17:11:18 <rjarry> yes
17:11:34 <djmitche> #agreed everything not documented is private, but that's not terribly clear right now, and should be clarified in 2.0
17:11:35 <tardyp> sa2ajj tried as far as he could to push people to use _ everywhere, but I have to admit that I am not very good at keeping up with this style
17:12:01 <rjarry> plus it makes code a bit ugly
17:12:06 <djmitche> indeed
17:12:11 <djmitche> shall we talk kubernetes workers?
17:12:18 <p12tic> say a class has _ method, if we don't use _ anywhere we can have a policy that these _ methods ary private to the class itself, not buildbot for example
17:12:20 <tardyp> http://docs.buildbot.net/current/developer/apis.html
17:12:27 <tardyp> This section documents Buildbot’s APIs. These are the interfaces against which externally-maintained code should be written.
17:12:37 <tardyp> I think this sentence could be more explicit
17:13:08 <tardyp> we can talk kubernetes workers
17:13:13 <djmitche> it's easy to miss, too -- a "Compatibility and Public APIs" section would be good
17:13:17 <djmitche> #topic Kubernetes Workers
17:13:30 <tardyp> I talked a little bit about it here: https://medium.com/buildbot/buildbot-1-8-0-f0b7f6a4c850
17:13:31 <djmitche> #info now running metabuildbot on GKE in Google Cloud
17:13:53 <tardyp> basically, the trial account forces us to only have 6 CPUs for our workers
17:14:12 <djmitche> so we're slightly oversubscribing the nodes
17:14:26 <tardyp> then we squeeze 7 workers on that, because the CPU monitor shown that we were at 70% cpu when using 6
17:14:37 <tardyp> then I tried to use 10, but I had strange flakyness
17:14:37 <p12tic> could recent test instabilities may be related?
17:14:49 <p12tic> oh, now i see
17:14:53 <tardyp> I used 10, then went back to 7
17:15:02 <tardyp> now, it looks better.
17:15:15 <tardyp> but I am not sure how those flaky ness would be impacted by that
17:15:17 <djmitche> is that "trial" free forever, or is that the $300 credit thing?
17:15:30 <tardyp> its $300 for 1 year
17:15:34 <tardyp> or $200
17:15:50 <tardyp> so we need to push SFC so that we can enable billing
17:15:55 <djmitche> got it
17:16:02 <djmitche> so we'd need an income stream in a year :)
17:16:05 <tardyp> then we can have much better peak aborbtion
17:16:31 <djmitche> #info will need to pay for compute resources after trial expires
17:16:31 <tardyp> well, we have a bit in our bank account, and this should be < $20 per month
17:16:53 <djmitche> ok
17:17:01 <tardyp> with the $4000 bounty we can have 16 years of GKE..
17:17:03 <djmitche> so that transition is 100% done now?
17:17:05 <djmitche> haha, true
17:17:25 <tardyp> yes, everything is in kube. no choice anyway
17:18:02 <djmitche> nice work!
17:18:05 <djmitche> that was quick
17:18:19 <djmitche> should we talk gsoc?
17:18:26 <tardyp> yes
17:18:45 <djmitche> #topic GSoC as a Python sub-org
17:18:54 <djmitche> I don't understand what that means..
17:19:03 <tardyp> mojca from macports suggested to be a python sub-orf
17:19:06 <djmitche> oh, I read the link
17:19:19 <tardyp> this means we just have to find mentors and don't need to find admins
17:19:45 <djmitche> awesome
17:19:55 <tardyp> I think this could be a good idea to try that. There is less engagement (and disapointment)
17:19:59 <djmitche> #info Mentoring for GSoC within the Python org means we just need to mentor -- not admin
17:20:04 <djmitche> indeed
17:20:06 <tardyp> and I think buildbot is perfectly fitting this
17:20:10 <djmitche> yeah, looks like it
17:20:18 <djmitche> how would we solicit mentors?
17:20:44 <tardyp> we can talk about it here
17:20:59 <tardyp> p12tic, rjarry rodrigc might be interrested to mentor
17:21:02 <tardyp> I can help too.
17:21:22 <p12tic> I could mentor
17:21:25 <rjarry> what does that imply ?
17:21:41 <p12tic> according to doc, 10 hours commitment a week for 3 months
17:21:59 <djmitche> awesome, that was easy ;)
17:22:08 <djmitche> #agreed let's do it
17:22:15 <p12tic> do we have a project that we could suggest to students?
17:22:17 <djmitche> #info p12tic interested in mentoring
17:22:26 <djmitche> we used to have an ideas page -- is that still somewhere?
17:22:29 <rjarry> ah mentoring students
17:23:01 <djmitche> one student :)
17:23:07 <rjarry> why not
17:23:10 <djmitche> haha
17:23:15 <djmitche> #info rjarry interested in mentoring
17:23:27 <djmitche> so yeah, project ideas are the next step
17:23:34 <djmitche> on https://github.com/buildbot/buildbot/wiki maybe?
17:23:38 <djmitche> or is there a better spot?
17:23:59 <tardyp> I think the next step is to candidate to the python admins
17:24:14 <tardyp> and then they might have some collab tools for the project ideas
17:24:15 <djmitche> ah, right
17:24:17 <djmitche> good point
17:24:33 <djmitche> #info next step is to let python project admins know, and follow up from there
17:24:36 <tardyp> I will do it.
17:24:51 <djmitche> #action tardyp to communicate with python admins
17:25:00 <djmitche> ok
17:25:06 <djmitche> I think that's the topics for today
17:25:08 <djmitche> anything else?
17:25:27 <tardyp> nope
17:25:32 <tardyp> good discussions!
17:25:42 <rjarry> debian has 1.8.0
17:25:44 <rjarry> btw
17:25:52 <djmitche> indeed
17:25:54 <djmitche> wow!
17:25:57 <djmitche> #endmeeting