16:30:31 <djmitche> #startmeeting weekly
16:30:31 <bb-supy> Meeting started Tue Apr 19 16:30:31 2016 UTC and is due to finish in 60 minutes.  The chair is djmitche. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:31 <bb-supy> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:30:31 <bb-supy> The meeting name has been set to 'weekly'
16:30:41 <djmitche> geez, 31 seconds late and I get yelled at ;)
16:30:57 <djmitche> #topic Introduction
16:31:00 <djmitche> Agenda is at https://titanpad.com/buildbot-agenda
16:31:08 <djmitche> woo, infobob is our friend!
16:31:34 <djmitche> #info *lots* of pull requests this week
16:31:58 <djmitche> #info Many are finishing up 0.9.0 tasks by documenting a missing feature and bumping the bug to 0.9.1
16:32:27 <djmitche> #info We've upgraded the minimum Twisted version to 14.0.0 on master, as discussed last week
16:32:32 <djmitche> any other highlights from the week?
16:32:57 <tardyp> I got some  time last week, and be of this week, but I will be more busy end of week for other business
16:33:07 <djmitche> ok
16:33:46 <djmitche> #info down to 13 0.9.0 blockers!  http://trac.buildbot.net/query?status=accepted&status=assigned&status=new&status=reopened&milestone=0.9.0&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=version&order=priority
16:34:15 <tardyp> probably 5 of them are pending PRs
16:34:16 <djmitche> #topic Bug 2340 update
16:34:30 <djmitche> agreed -- looks like we're in good shape!
16:34:46 <rutsky> I'm working on buildbot-worker part
16:35:04 <rutsky> I want you guys to review https://github.com/buildbot/buildbot/pull/2105
16:35:29 <rutsky> its conflicting with my further changes and I want to get it resolved first
16:35:37 <djmitche> ok
16:35:43 <djmitche> I had a skim and it looks fine to me
16:35:49 <djmitche> I'll take another peek afterward
16:36:02 <rutsky> I ended up reverting  @jvlomax changes
16:36:14 <rutsky> djmitche: perhaps implementation changes since you reviewed last time :)
16:36:16 <djmitche> #info working on buildbot-worker, blocked by some logging requirements
16:36:26 <djmitche> in the last 5 minutes? :)
16:36:34 <rutsky> djmitche: no, this night :)
16:36:47 <djmitche> I have a timer set 45 minutes before this meeting, and basically spend that time looking at PRs and bugs :/
16:36:59 <djmitche> I think the revert is the best plan
16:37:17 <rutsky> perhaps anyone knows why those changes were introduced?
16:37:21 <djmitche> overall how are you feeling about bug 2340?
16:37:33 <djmitche> @jvlomax was mostly working on python-3 compatibility
16:37:51 <djmitche> so I expect he replaced a lot of `print ".."` with `log.msg("..")`
16:37:53 <rutsky> left part of 2340 is quite small, but has a lot of tiny tasks
16:38:09 <djmitche> #info left part of 2340 is quite small, but has a lot of tiny tasks
16:38:23 <rutsky> I want to get buildbot-worker working in the first place, and then fix tiny stuff
16:38:27 <djmitche> ok
16:38:49 <djmitche> I think it's totally legitimate for you to solve the small stuff in a way that is quick, and put a bug in to solve it better later
16:39:02 <rutsky> I think we can release (or do RC) after I finish buildbot-worker part
16:39:37 <tardyp> we will do the rc when all the 0.9.0 milestone are done
16:39:47 <tardyp> maybe we can do a beta9 in between
16:39:56 <bb-github> [13buildbot] 15djmitche commented on issue #2105: I suspect the `log.msg` changes were made as part of Python-3-ification, and the resulting hiding of important messages wasn't noticed at the time.  So I think this revert is the right course.... 02https://git.io/vwsWs
16:40:04 <tardyp> depends on how fast we can crash those 8 remaining bugs
16:40:12 <rutsky> tardyp: sure, I forgot we have not finished stuff for 0.9.0
16:40:31 <rutsky> tardyp: 8 bugs?
16:40:43 <djmitche> 13 open - 5 with PRs
16:40:44 <tardyp> 13 - 5 pending PRs
16:40:54 <rutsky> ah, good work!
16:41:27 <djmitche> #info Once the 13 open bugs (~5 of which have PRs) are finished, and the buildbot-worker rename is landed, it's RC/release time!!
16:41:46 <djmitche> damnit
16:41:49 <djmitche> #topic collapseBuildRequest=False by default
16:41:54 <djmitche> now, what WAS the topic
16:42:09 <tardyp> collapseBuildRequest=True right now
16:42:09 <djmitche> I shouldn't be allowed on irc
16:42:17 <tardyp> and this does not play well with triggered build
16:42:42 <tardyp> So people which use trigger step will all have the problem (I did 4 years ago)
16:42:46 <tardyp> and ed did this week
16:43:06 <tardyp> I would recommend to put it False by default, and to let people set it to true when they need to optimize
16:43:28 <djmitche> changing a default is pretty ugly though
16:44:17 <bb-github> [13buildbot] 15mention-bot commented on issue #2141: By analyzing the blame information on this pull request, we identified @tomprince, @djmitche and @rutsky to be potential reviewers 02https://git.io/vwsl3
16:44:28 <djmitche> is it possible to just disable it with triggered builds?
16:45:10 <djmitche> my worry is, changing the default is pretty subtle, and will change behavior even for people not using triggered builds
16:45:14 <tardyp> I tried to fix it that way, but there is no real way to be sure that a build is comming from a trigger step (from within the colapse br)
16:45:27 <cmouse> tardyp: i'm using the buildbot reporter myself, and it mostly works
16:45:37 <tardyp> it will change the optimisation
16:45:40 <cmouse> tardyp: the only thing that is not working is that it's not reporting start of build
16:45:47 <tomprince> The trigger scheduler could annotate the BR.
16:45:51 <cmouse> tardyp: i have no idea why it's not doing it :(
16:45:59 <tardyp> while for people using trigger step, it just skip builds
16:46:08 <djmitche> ^^ even as a temporary hack, I think that makes sense
16:46:35 <myheadhurts> So I'm running into the following issue: http://trac.buildbot.net/ticket/3528 and I'm thinking of approaching the fix in the following way: https://github.com/buildbot/buildbot/pull/2141
16:46:43 <myheadhurts> Would love any feedback on the approach
16:47:12 <tardyp> ok. So we change the True behaviour to : compatible sourcestamps *and* not coming from a Trigger step
16:47:18 <djmitche> #info build request collapsing and triggered builds do not get along well -- triggered builds end up skipped
16:47:42 <tardyp> I'm fine with that too.
16:47:49 <djmitche> tardyp: I think so -- that's even a good medium-term fix (since it sounds like this is architectural, not just a bug)
16:47:51 <bb-trac> [trac] #3528/undecided (new) updated by rutsky (Related PR: https://github.com/buildbot/buildbot/pull/2141) http://trac.buildbot.net/ticket/3528
16:48:05 <djmitche> #agreed will configure collapsing to skip triggered builds by annotating the triggered builds
16:48:09 <tomprince> If people want collapsing builds, then it isn't clear that skipping triggered builds isn't desired behavior.
16:48:36 <djmitche> myheadhurts: without looking deeply at the PR, I'm really happy to see you working on the latent worker support :)
16:48:39 <bdbaddog> so if you have multiple triggered builds waiting, they would no longer be collapsed?
16:48:54 <tardyp> tomprince: I dont see a usecase where people would like to skip triggerred build
16:49:22 <djmitche> a skipped triggered build has weird semantics if waitForFinish=True
16:49:25 <djmitche> or whatever that parameter is
16:49:37 <bdbaddog> yes.. deadlock..
16:49:52 <tardyp> well no deadlock
16:49:54 <tomprince> If you have a multi-stage build pipeline, but only care about results on the latest commit, if several triggers happen before the triggered build runs, there isn't a reason to run the earlier triggers.
16:49:57 <myheadhurts> djmitche: Hopefully soon (once company approves it) I'll have a PR for upgrading boto2 -> boto3 and handling cross-account support for AWS. :)
16:50:07 <djmitche> oo, very nice!
16:50:31 <djmitche> so regarding collapsing and triggering -- it sounds like this is something we should defer until 0.9.x
16:50:35 <bdbaddog> parent build would hang forever if triggered build gets skipped..
16:50:44 <tomprince> Probably doesn't make sense in the waitForFinish case (at least when that is being used for synchronization not just reporting).
16:50:52 <djmitche> right
16:50:55 <tomprince> Doesn
16:51:18 <tomprince> t it just wait for the buildrequest to be completed, which does happen for collapsed requests?
16:51:37 <tardyp> yes
16:51:37 * tomprince can't remember the code, but seems to recall that was how things worked
16:51:58 <tardyp> you will just see 4 builds when you awaited 8
16:52:21 <tardyp> because the colapsing dont create build, it directly skips the br
16:52:44 <tardyp> and that is fine with the waiting logic in trigger step, as it only waits for a complete event of the br
16:53:44 <bb-github> [13buildbot] 15tomprince commented on issue #2141: I don't think this a correct fix. I think the intent of `build_wait_timeout == 0` is that the worker will only run a single build. I don't think this change preserves that behavior. 02https://git.io/vws81
16:54:08 <tardyp> it actually waits for the buildset
16:54:21 <djmitche> so how badly broken is it right now?
16:54:31 <djmitche> It sounds like it works, it's just not the semantics you're expecting
16:54:48 <djmitche> as in, you're expecting every triggered build to actually occur, and instead they get collapsed
16:55:10 <tardyp> well you start 8 builds with trigger, you have no idea what collapsing is, and eventually you get 4 builds, and buildbot seems happy
16:55:17 <tardyp> that is for me very weird for a new commer
16:55:39 <tardyp> build request collapsing should for me be an advanced feature, that new commers should not be aware of
16:56:14 <tomprince> I think that not collapsing is probably a slightly better default, but it isn't clear wether it is enough better to warrant *changing* the default.
16:56:20 <djmitche> right
16:56:32 <djmitche> we're already changing so much other stuff
16:56:42 <djmitche> I think we should leave this be for now
16:56:55 <tomprince> Given the experience of python 3, that seems reasonable.
16:57:26 <tomprince> If you want to change the default, a slightly better option might be to deprecate having a default at all, and then remove the default.
16:57:36 <rutsky> can we somehow warn user that he might get not what he expected?
16:57:45 <rutsky> or add appropriate warning in docs?
16:57:56 <tardyp> that is a good idea
16:57:58 <tomprince> That seems sensible.
16:58:29 <bb-github> [13buildbot] 15aelsabbahy commented on issue #2141: Hmm, that's definitely not what I want then. Since it's very important for us that we only have single use workers.... 02https://git.io/vws4o
16:58:34 <tardyp> in the trigger step, if the triggered builder has True in collapse, we warn in the stdio
16:58:42 <djmitche> that sounds good
16:58:50 <cmouse> should write a trac issue about OpenStackLatentWorker not always killing the worker.
16:58:52 <tardyp> with link to the doc
16:59:01 <cmouse> or does someone know if it's intentional
16:59:28 <rutsky> then we agreed regarding collapsing?
17:00:04 <bb-trac> [trac] #3529/enhancement (v:master) created by tardyp (Add warning in trigger step if collapseBuild=True for the target builder) http://trac.buildbot.net/ticket/3529
17:00:08 <rutsky> cmouse: I think it's better to file a ticket
17:00:10 <djmitche> #agreed in the trigger step, if the triggered builder has True in collapse, we warn in the stdio
17:00:12 <tardyp> 14
17:00:16 <cmouse> rutsky: i suppose so.
17:00:38 * djmitche moves on
17:00:42 <djmitche> #topic isort instead of fiximports
17:00:56 <djmitche> This sounds like a good, more "industry standard" approach to consistency in imports
17:01:01 <tardyp> I'd like formal approval from the team vefore pushing this
17:01:18 <djmitche> I ain't signing anything without my lawyer reading it first
17:01:25 <djmitche> what's the downside?
17:01:26 <tardyp> hehe
17:01:48 <tardyp> difference is that fiximports separated import..from from import ...
17:01:55 <tardyp> in different paragraphs
17:02:03 <tardyp> isort does not have this feature
17:02:06 <djmitche> ok
17:02:09 <djmitche> so we'd drop some newlines?
17:02:15 <tardyp> isort has many more features, that sa2ajj wanted
17:02:28 <tardyp> like stdlib first, 3rdparty second, etc
17:02:30 <djmitche> anything that makes sa2ajj happy makes me happy :)
17:02:31 <djmitche> ok
17:02:33 <djmitche> yeah, that's cool
17:02:42 <djmitche> I'm convinced!
17:02:47 <rutsky> do we plan to use force_single_line?
17:02:48 <djmitche> are there any objections?
17:02:50 <bdbaddog> +1
17:02:56 <tomprince> Will incorrect orders get reported as github statuses?
17:02:58 <tardyp> yes I do
17:03:18 <tardyp> force_single_line=true, because it helps a lot merge conflicts
17:03:20 <rutsky> +1 for isort
17:03:29 <rutsky> tardyp: agree
17:03:34 <djmitche> ok!
17:03:36 <tardyp> tomprince: yes they will. I added isort --check in travis
17:03:58 <djmitche> #agree will use isort instead of the home-brewed fiximports.py to enforce import syntax and reduce churn at the top of python files
17:04:16 <djmitche> any other topics?
17:04:25 <djmitche> I think everything from last week got sorted?
17:04:34 <djmitche> with the possible exceptino of the ec2 related test failures
17:04:58 <djmitche> oh, we just agreed to file a bug, so that's sorted :)
17:05:04 <djmitche> the bug fairies will surely take it from there
17:05:19 <rutsky> what about PR template by sa2ajj?
17:05:47 <djmitche> #topic PR template
17:05:48 <djmitche> https://github.com/sa2ajj/buildbot/blob/pr-checklist/PULL_REQUEST_TEMPLATE.md
17:05:50 <rutsky> I see that topic, and see version of file in sa2ajj  repo, but don't see PR with this...
17:06:50 <djmitche> he had brought it up for discussion
17:07:13 <djmitche> the general sense, looking over last week's logs, was that this was complex and there were questions about what to include or omit from the instructions (e.g., `make hooks`)
17:07:36 <djmitche> it also involved some process for merging notes from the PR into the commit message
17:07:50 <djmitche> so I think sa2ajj was back to the drawing board
17:07:57 <djmitche> he can bring it up next week if there's progress
17:08:04 <tardyp> ok
17:08:05 <rutsky> ok, I see
17:08:16 <djmitche> cool
17:08:30 <djmitche> #info was brought up for discussion last week; no new information this week
17:08:34 <djmitche> #endmeeting