16:30:00 <djmitche> #startmeeting weekly
16:30:00 <bb-supy> Meeting started Tue Apr 12 16:30:00 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:00 <bb-supy> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:30:00 <bb-supy> The meeting name has been set to 'weekly'
16:30:14 <djmitche> #topic Introduction
16:30:20 <djmitche> Agenda: https://titanpad.com/buildbot-agenda
16:30:20 <infobob> http://paste.pound-python.org/show/eJPqXmJoyOGKtcp7hBrH/ (repasted for djmitche)
16:30:49 * sa2ajj . o O (that repasted is not really useful :/)
16:31:04 <djmitche> hawkowl: ^^ is that something you can fix?
16:31:12 <tomprince> I've pinged the maintainer of infobob about it again.
16:31:45 <djmitche> :)
16:31:50 <djmitche> #topic Bug 2340
16:32:05 <djmitche> #info per rutsky, buildbot-worker parts are underway, but no PR to look at yet
16:32:07 <hawkowl> huh what happened
16:32:26 <djmitche> it's repasting an etherpad (titanpad.com)
16:33:01 <hawkowl> I am not sure why you think I would know about infobob :P
16:33:13 <djmitche> oh, I'm mixed up then, never mind :)
16:33:23 * djmitche moves on
16:33:36 <djmitche> #topic Development Week in Review
16:33:51 <sa2ajj> re 2340: we still have `slave` dir, how do we get rid of it?
16:33:59 <sa2ajj> (sorry, i'm a bit slow)
16:34:14 <djmitche> sa2ajj: which dir specifically? top level?
16:34:20 <sa2ajj> yup
16:34:34 <djmitche> I don't think that work is done yet
16:34:41 <djmitche> I think it will go away when it's finished
16:35:07 <sa2ajj> what i'd like to understand (on a high level) what it takes to get it finished
16:35:26 * sa2ajj wants to help if possible
16:36:01 <sa2ajj> i understand it's a complicated task
16:36:15 <djmitche> I think http://trac.buildbot.net/ticket/2340 is the high-level summary
16:36:20 <djmitche> *best
16:36:31 <sa2ajj> if a small contribution here and there helps, i'd be willing to look into it.
16:36:44 <sa2ajj> ok, i'll check it after the meeting
16:36:58 <djmitche> rutsky is probably a good person to pull out a specific bit of work, yeah
16:36:59 <djmitche> cool
16:37:00 <djmitche> thank you!
16:37:03 <djmitche> in advance :)
16:37:27 <sa2ajj> pity he could not make it today. anyway, let's proceed :)
16:37:55 <djmitche> #info Pierre released buildbot-0.9.0b8!
16:38:04 <djmitche> I think a lot of the PRs this week were around 0.9.0 cleanup
16:38:27 <djmitche> but I haven't seen many of them
16:38:48 <djmitche> looks like a number of things are left to later agenda items :)
16:39:14 <djmitche> #topic Appveyor
16:39:28 <djmitche> #info Appveyor is enabled, but not quite fully configured for Buildbot yet
16:39:39 <djmitche> #info Vladimir requested org access today and I (dustin) approved
16:39:49 <sa2ajj> aha
16:39:57 <djmitche> that should allow us to enable builds of the buildbot/buildbot repo, rather than djmitche/buildbot
16:40:00 <djmitche> but, it's all very confusing
16:40:05 <sa2ajj> when i went to check what that was about it was "approved" :)
16:40:13 <djmitche> yes, sorry :)
16:40:18 <sa2ajj> no worries
16:40:21 <tardyp> hi sorry I'm late!
16:40:35 <djmitche> tardyp: want to say anything about beta8?
16:40:52 <djmitche> #info Should have appveyor up and running properly in a few days -- better windows testing!!
16:40:52 <tardyp> well. We released it..
16:41:02 <tardyp> and we had a bunch of fixes comming just after..
16:41:17 <tardyp> one on HttpStatus worried me
16:41:22 <djmitche> #topic Beta 8
16:41:27 <djmitche> how so?
16:41:48 <tardyp> well, it basically does not work in beta8, as for StashStatus
16:42:06 * sa2ajj hmms
16:42:15 <tardyp> I only tested on unit test, and mocked the wrong thing
16:42:18 <sa2ajj> was there a defect for that?
16:42:27 <sa2ajj> i could try to reproduce it locally
16:42:29 <djmitche> #info HttpStatus and StashStatus do not work in beta8
16:42:30 <tardyp> there is a PR that I merged in the we
16:42:42 <sa2ajj> for `wantXXX`?
16:42:56 <tardyp> mmh there is *also* that one
16:43:13 <tardyp> the other is status vs status_code
16:43:14 <sa2ajj> then i missed the other one
16:43:27 <sa2ajj> ah, i saw it and it looked good
16:43:49 <tardyp> https://github.com/buildbot/buildbot/pull/2097/files
16:44:02 <djmitche> so this was an accidental breakage, rather than something that might hold up 0.9.0?
16:44:18 <tardyp> yep, on a new feature of 0.9.0b8
16:44:27 <tardyp> which wasn't in b7
16:44:34 <tardyp> so nothing really big
16:44:48 <djmitche> ok
16:45:15 <djmitche> thanks for releasing that
16:45:23 * djmitche excited to see 0.9.0 draw closer :)
16:45:32 <djmitche> #topic Synchronous Testing
16:45:42 <djmitche> I'm not sure what this is about? sa2ajj?
16:45:54 <sa2ajj> this is not my topic
16:45:58 <sa2ajj> i added mine after AOB
16:46:21 <tardyp> I think this is from tomprince
16:46:28 * sa2ajj adds his thanks to tardyp for keeping releasing those betas
16:46:35 <djmitche> oh, sorry -- tomprince?
16:46:46 <tardyp> he added  some new unit test using SynchronousTestCase from twisted 13
16:47:15 <tomprince> I've picked up some contracting work and want to introduce some test and infrastructure to do tests without spinning the reactor.
16:47:19 <tardyp> https://github.com/buildbot/buildbot/pull/2102/files
16:48:08 <tardyp> I am not sure what are the benefits
16:48:22 <tardyp> much faster tests?
16:48:37 <tomprince> Also, I've got some wip integration tests that don't use a real reactor (so replacing threads with synchronous calls, for example).
16:49:04 <tomprince> Faster and more deterministic tests is a major benefit.
16:49:19 * sa2ajj nods
16:49:39 <tardyp> mmh looks interesting indeed
16:49:44 <sa2ajj> i don't quite understand the magic [yet]
16:49:46 <tomprince> You don't need to wait for things to timeout if a deferred fails to fire, for example.
16:49:55 <tardyp> you mean integration tests which does the full buildbot core?
16:50:07 <tomprince> Yep.
16:50:32 <djmitche> http://twistedmatrix.com/documents/13.0.0/api/twisted.trial.unittest.SynchronousTestCase.html really doesn't help me understand this
16:50:33 <tardyp> because for now, the problem of the current integration test is that its minimal 1s per test
16:50:34 <sa2ajj> that sounds good
16:51:08 <tardyp> 1s per run build actually
16:51:10 <sa2ajj> (integration tests that do full bb core)
16:51:26 <sa2ajj> (from description!)
16:51:41 <tomprince> I was also wondering about splitting the config loading code so that it doesn't need to read from a file, mostly so tests can just pass in the config dict.
16:52:11 <tardyp> sounds good as well to me
16:52:44 <tardyp> If improving integration tests requires dropping support for tw12, I am all for it
16:52:45 * sa2ajj motions to proceed w/ the PR
16:52:56 <djmitche> me too
16:53:11 <sa2ajj> once it's OK w/ automatic checks
16:53:14 <tomprince> Regarding the synchronous testing, it requires bumping the twisted version (or back porting the helpers).
16:53:16 <djmitche> #info SynchronousTestCase is a new feature in Twisted 13.0.0 that allows tests to run without a reactor
16:53:26 <djmitche> #info therefore faster and more deterministic
16:53:45 * sa2ajj motions to require 13.x+
16:53:59 <tomprince> 14.x
16:54:12 <tomprince> That had a bunch of SSL fixes.
16:54:16 <djmitche> when was 14 released?
16:54:22 <skelly> add 2000
16:54:33 <djmitche> I'm worried about queueing buildbot updates in downstream distros behind twisted upgrades
16:54:34 <bb-github> [13buildbot] 15sa2ajj pushed 4 new commits to 06master: 02https://git.io/vVNMa
16:54:34 <bb-github> 13buildbot/06master 147dba764 15Pierre Tardy: port ansicodes to coffeescript
16:54:34 <bb-github> 13buildbot/06master 14c5bd7be 15Pierre Tardy: support terminal color in the log viewer
16:54:34 <bb-github> 13buildbot/06master 147b9edd8 15Pierre Tardy: code cleanups and improvments
16:54:35 <tomprince> (The versions are date based
16:54:36 <tardyp> I have seen the doc in 13 this morning
16:54:56 <djmitche> so 14 is 2014?
16:55:03 <tardyp> djmitch just posted the URL
16:55:03 <tomprince> So sometime in early 2014.
16:55:07 <djmitche> ok
16:55:09 * sa2ajj didn't know that :/
16:55:10 <tardyp> http://twistedmatrix.com/documents/13.0.0/api/twisted.trial.unittest.SynchronousTestCase.html
16:55:32 <djmitche> so are we agreed we will drop master-side support for Twisted 11, 12, and 13 and require 14?
16:55:44 <tomprince> The second component is just a count of releases that year.
16:56:28 <tardyp> I did not realize that!
16:56:34 <sa2ajj> so there's something not so twisted in twisted :)
16:56:38 <djmitche> haha
16:57:16 <sa2ajj> anyway, who objects?
16:57:28 <tardyp> this will make the CI faster!
16:57:33 <tardyp> less tw to test
16:57:41 <djmitche> I don't think there are objections :)
16:57:54 <djmitche> #agreed we will drop master-side support for Twisted 11, 12, and 13 and require 14, to get this feature
16:58:14 <djmitche> #info Twisted 14 is from 2014, so distros should have upgraded already, and anyway most users use Virtualenv which makes upgrading easy
16:58:29 <skelly> FWIF, CentOS 7 is on 12
16:58:35 <djmitche> ready for "Latent Worker triggering builds disappear"?
16:58:43 <djmitche> skelly: I'm surprised it's not on 0.8.2 tbh
16:58:53 * sa2ajj is on CentOS7 :)
16:59:01 <skelly> Debian 8 does have 14.0.2
16:59:09 <djmitche> "grampa can't run that fast" is increasingly not a convincing argument :)
16:59:54 <skelly> if you're going to argue for something because distros have moved past it, it helps if they've actually moved past ;)
17:00:06 <skelly> (I'm in favor of updating, just saying)
17:00:50 <djmitche> heh, yeah, fair
17:00:52 <djmitche> ok
17:00:57 <djmitche> #topic Latent Worker triggering builds disappear
17:01:08 <tomprince> The other thing I was pondering (but haven't investigated yet) is allowing a Build to be created for latent workers that are starting (rather than being claimed without an associated build)
17:01:54 <djmitche> so right now, the build request distributor claims the build request, then instantiates the worker, and only creates the build when the worker is started?
17:02:29 <tomprince> I'm not sure what it would involve, but I wanted to get people's reactions before  investigating that rabbit hole.
17:02:52 <djmitche> I don't know the difficulty, either
17:02:58 * sa2ajj nods
17:03:01 <djmitche> but it would be nice to have a user-visible place to report issues instantiatiung
17:03:10 <tomprince> Well, the builder does it in workedforbuilder.prepare
17:03:16 <djmitche> so if the instantiation fails, you can mark the build RETRY and put the error information into the logs
17:03:21 <skelly> the latent worker bits are all rather murky at the moment
17:04:00 <skelly> UI-wise
17:04:40 <tardyp> agreed, all this does not had the full love that would be required
17:04:42 <tomprince> That would mean having a Build without a connected worker, which would be new,  but probably workable.
17:04:43 <sa2ajj> yup and that is reflect
17:04:48 <sa2ajj> oops
17:04:56 <sa2ajj> yup for "murky"
17:05:08 <sa2ajj> and that is reflected in the ticket i put in the agend
17:05:19 <djmitche> #info ght now, the build request distributor claims the build request, then instantiates the worker, and only creates the build when the worker is started
17:05:32 <djmitche> #info tomprince proposes creating the Build before instantiating the worker
17:05:46 <djmitche> #agreed sounds tricky, but like a good improvement
17:05:49 <djmitche> ^^ fair?
17:05:56 <tardyp> problem is if the worker can't build this
17:05:58 <tomprince> Yeah.
17:06:07 <tardyp> we have a build to put in "retry" state
17:06:22 <sa2ajj> i'd like to look at the code implementation
17:06:26 <tardyp> but I'm fine with it
17:06:34 <tardyp> its better than looking at twisted.log
17:06:40 <sa2ajj> that way i'd really understand the issue :/
17:07:04 <tardyp> so we put the reason for canStartBuild() in that build status_string
17:07:16 <djmitche> ++
17:07:36 <djmitche> ok, let's move on
17:07:39 <djmitche> #topic Plugins (is it a right way to go?)
17:07:47 <djmitche> haven't we already committed to plugins?
17:08:15 <sa2ajj> yes, we did
17:08:25 <sa2ajj> the topic is about certain properties of plugins
17:08:40 <sa2ajj> e.g. load one *only* when one is needed
17:08:53 <tomprince> I've noticed it breaks code completion.
17:08:56 <sa2ajj> (the current slave->worker transition does not support it)
17:09:16 <sa2ajj> so my idea/proposal is:
17:09:48 <sa2ajj> * introduce a generic mechanism to deprecate functions/classes and namespaces
17:09:55 <sa2ajj> (and implement tests for that)
17:09:58 <djmitche> #info the on-demand loading of plugins is broken with the slave -> worker transition work
17:10:26 <djmitche> so this would be a more generic version of the tools that rutsky has built?
17:10:29 <sa2ajj> * re-write current slave->worker transition stuff to use that
17:10:41 <sa2ajj> *much* more generic
17:10:48 <djmitche> what's the benefit?
17:11:03 <sa2ajj> * keep load-on-demand as a requirement
17:11:09 <sa2ajj> djmitche: ^^
17:11:40 <djmitche> does supporting load-on-demand require a complete rewrite of this?
17:11:47 <sa2ajj> i do not know whether such massive transitions will happen in future...
17:11:57 <sa2ajj> re re-write: yes
17:12:09 <sa2ajj> i looked at the output of test runs
17:12:35 <sa2ajj> the messages indicated that old names were *always* loaded
17:13:15 <sa2ajj> that's my reaction, hence i brought it up
17:13:24 <djmitche> ah
17:13:48 <djmitche> I'd prefer to find a way to fix that within the current framework
17:13:52 <sa2ajj> so if it doesn't look worth pursuing, then let's skip it.
17:14:00 <djmitche> IMHO the most important things right now are shipping 0.9.0 and finishing bug 2340
17:14:09 * sa2ajj nods
17:14:10 <djmitche> so distracting from those efforts feels counterproductive
17:14:23 <djmitche> can you talk to rutsky about the issues you're seeing?
17:14:28 <sa2ajj> i'm looking at this then
17:14:31 <djmitche> ok
17:14:44 <sa2ajj> we did partially, i wasn't in a proper mood though :(
17:14:48 <djmitche> if "rewrite" just means making the function names more generic and some minor behavioral changes, that's probably OK
17:14:50 <sa2ajj> rutsky: sorry about that
17:14:51 <djmitche> ok
17:15:18 <djmitche> It was some effort for rutsky to make a lot of these warnings work correctly, so I worry that a rewrite would re-encounter some of those bugs
17:15:24 <djmitche> /issues
17:15:30 <djmitche> ok
17:15:39 <djmitche> #agreed tabled for more discussion with rutsky and sa2ajj
17:15:52 * sa2ajj nods
17:16:05 <djmitche> #topic Add support for worker pools
17:16:23 <sa2ajj> my reasons to add this topic:
17:16:43 <sa2ajj> * understand if we can support this within current codebase
17:16:51 <sa2ajj> * what needs to be done if we can't
17:17:28 <djmitche> #info proposal is to add a concept of "worker pools" to configure many identically-configured workers; useful in latent worker situations
17:17:33 <skelly> they would be a big help for us
17:17:36 <tomprince> One thing I've wondered is whether there needs to be a single workerforbuilder for each worker-builder pair.
17:17:41 <djmitche> I think this would be a very popular feature
17:18:05 <tardyp> I've added some thoughs its the bug just before meeting
17:18:08 <djmitche> right, there are a lot of things that are O(n) and some O(n**2) in the number of workers
17:18:24 <djmitche> adding this as a configuration option is probably fairly straightforward
17:18:42 <tardyp> there are a lot of things that expect a constant number of worker
17:18:48 <djmitche> but when someone makes WorkerPool(.., n=1000) and their master suddenly uses 1000000x more resources, they will be sad
17:19:16 <djmitche> I wonder if this would be better handled within the latent worker code
17:19:24 <sa2ajj> nope
17:19:27 <tardyp> I think the best is to create the worker in the db on demand
17:19:35 <tardyp> with autoscaling algorithm
17:19:35 <djmitche> sa2ajj: why nto?
17:19:44 <tomprince> Are there actually things that expect a constant number of workers?
17:19:51 <sa2ajj> the core code would disconnect all (the only one) workers once an authentic one is connected
17:19:54 <tardyp> just add new workers to the slave manager if the pool is busy 90%
17:20:06 <djmitche> ^^ that's what I'm thinking, yes
17:20:21 <djmitche> tomprince: not necessarily constant, but changing the number of workers is an active process
17:20:27 <djmitche> add DB rows, create instances, etc.
17:21:00 <djmitche> Does this need some prototyping?
17:21:16 <djmitche> if we promise not to land the prototype on master :)
17:21:46 <djmitche> It sounds like a great 0.9.2 feature :)
17:22:16 <tardyp> agreed
17:22:38 * sa2ajj nods
17:22:53 <djmitche> #agree this would be a great feature, but it's not clear how to implement it -- prototyping is a good next step
17:23:10 <djmitche> #topic validate.sh
17:23:26 <djmitche> I'm guessing validate.sh has outgrown its usefulness?
17:23:56 <sa2ajj> not really
17:24:08 <sa2ajj> there's a number of small (i think) issues:
17:24:37 <sa2ajj> it uses `which` and the latter fails to find stuff in certain directories (~/.local/bin in my case)
17:24:52 <djmitche> #info validate.sh is a shell script that runs all pre-merge checks (tests, lint, etc.)
17:24:58 <djmitche> that's odd - is ~/.local/bin not in PATH?
17:24:59 <sa2ajj> there was a discussion yesterday (skelly thanks!) regarding some other things
17:25:04 <djmitche> ok
17:25:07 <djmitche> so minor fixups?
17:25:13 <sa2ajj> *it is* added
17:25:17 <djmitche> huh
17:25:53 <tomprince> `which` is weird, because there are a bunch of variants.
17:25:53 <sa2ajj> and the 2nd thing i found (later) is that it does not work when i use 'git add --patch' and leave some stuff "behind"
17:26:25 <bb-trac> [trac] #3518/enhancement (new) updated by dustin (This would be a great feature, especially for those using the latent worker support. ...) http://trac.buildbot.net/ticket/3518
17:26:41 <djmitche> yeah, it makes assumptions about the working directory
17:27:22 <sa2ajj> tardyp merged https://github.com/buildbot/buildbot/pull/2112
17:27:38 <sa2ajj> but it does not address suggestions of skelly (made on irc channel)
17:28:05 <djmitche> ok
17:28:29 <sa2ajj> anyway, it's just about making sure people know about it :)
17:28:51 <djmitche> ok
17:29:08 * sa2ajj is going to check it further to see if other skelly's concerns can be addressed
17:29:08 <djmitche> #info sa2ajj is making minor fixups to how this script works to make it more robust
17:29:19 <djmitche> #topic issues in main branches
17:29:31 <sa2ajj> that's another one of mine :)
17:29:38 <djmitche> (sorry/not-sorry to be rushing things..)
17:29:53 <sa2ajj> we seem to have test case breakages in master/eight
17:30:10 <tardyp> in eight, yes, but master?
17:30:21 <sa2ajj> in eight we have 3 (i think) issues that need to be looked at....
17:30:27 <djmitche> sigh, and http://buildbot.buildbot.net/grid looks pretty awful
17:30:30 <sa2ajj> master as well i *think*
17:30:32 <sa2ajj> one sec
17:30:51 <sa2ajj> just check http://buildbot.buildbot.net/console
17:31:23 <djmitche> equally red :(
17:31:31 <tardyp> indeed. the fact is I only look at travis :/
17:31:33 <tomprince> That is due to missing packages in the cache.
17:31:37 <djmitche> yeah
17:31:39 <skelly> all venv failures, can't find txaio
17:31:44 * sa2ajj hmms.
17:31:59 <tomprince> Do we need the cache theses days? What version of pip is being used.
17:32:05 <sa2ajj> what i referred were two (or 3?) test cases i saw failing in master
17:32:16 <skelly> 1.5.6
17:32:17 <djmitche> I think the pip version varies -- and the cache may not be necessary, no
17:32:36 <tardyp> probably is hurting more that it helps indeed
17:32:41 <tomprince> pypi is much better these days.
17:32:45 <djmitche> yah
17:32:49 <tardyp> we have few failure in travis because of pypi
17:33:00 <tardyp> actually none that I can remember
17:33:02 <djmitche> travis uses a cache
17:33:09 <tomprince> Particularly with a new enough pip that does its own cahcing.
17:33:11 <sa2ajj> this is what i referred to: http://buildbot.buildbot.net/builders/py26-tw1110/builds/436
17:33:59 <tardyp> the ec2 test case are broken for me two on my mac
17:34:04 <tardyp> but not the same error
17:34:19 <sa2ajj> and that failure seems to be consistent among other builders as well...
17:34:22 <tardyp> while travis looks like running them without issue
17:34:58 <djmitche> sa2ajj: can you get a bug on file?  If they're flaky, we can temporarily skip pointing to that bug
17:35:07 <sa2ajj> i will
17:35:13 <sa2ajj> let's go to the next topic
17:35:29 <djmitche> last topic! :)
17:35:37 <sa2ajj> (it's more than 1hr already :))
17:35:51 <djmitche> #action sa2ajj to file a bug about ec2-related test failures on master
17:36:02 <sa2ajj> anyway, i played with a PR template
17:36:11 <djmitche> #action djmitche to make PR to stop using a local package repo in metabuildbot
17:36:15 <djmitche> #topic new Github PR template
17:36:24 <sa2ajj> i liked the idea at first and then i started to feel doubts
17:36:27 <djmitche> https://github.com/sa2ajj/buildbot/blob/pr-checklist/PULL_REQUEST_TEMPLATE.md
17:36:30 <sa2ajj> what do people think?
17:37:16 <sa2ajj> the idea is that to merge PRs eligible people would *have* to use a script to make sure the content is correct :/
17:37:22 <tardyp> looks cool!
17:37:23 <djmitche> I like it
17:37:35 <tardyp> I think we should advertise here for make hooks
17:37:42 <tomprince> hmm.
17:37:52 <djmitche> I like the idea of providing a summary for the merge commit
17:38:33 <sa2ajj> that's what i like as well :)
17:38:44 <tardyp> [ ] I have run "make hooks" and fiximports, and al that stuff
17:38:49 <sa2ajj> what i finally do not like is a mandatory *external* tool :/
17:39:11 <sa2ajj> tardyp: that's easy to add
17:39:13 <djmitche> right
17:39:31 <djmitche> tardyp: is 'make hooks' really important?  That's just a means to an end
17:39:52 <tardyp> well, no, its just a way to make sure fiximports is always run
17:39:57 <djmitche> yeah
17:40:14 <tardyp> and autopep8
17:40:22 <tomprince> Just add a check (on travis or something) that makes sure that those are no-ops?
17:40:32 <tomprince> And then can enable required status checks on github?
17:40:37 <djmitche> I think you might be able to summarize much of this as "[ ] validate.sh succeeds (this will be verified automatically by services like TravisCI"
17:40:46 <djmitche> yeah, we already have that
17:40:55 <tardyp> right
17:41:20 <tardyp> we don't run validate.sh in travis, but we could run the auto* part
17:42:57 <djmitche> I thought we did :/
17:42:59 <djmitche> yeah
17:43:16 <sa2ajj> my "workaround" thoughts are:
17:43:23 <sa2ajj> * have a bot to do things
17:43:31 <djmitche> overall being consistent in what we check between (a) what it says when you submit a PR, (b) what travis/circle/appveyor/etc. do and (c) what we do to check before merging
17:43:52 <sa2ajj> * once a PR is marked "merge me" do the things (merge w/ right commit message, test and push)
17:44:04 <sa2ajj> a la bora
17:44:13 <djmitche> sounds like fun :)
17:44:27 <sa2ajj> *and* protect integration branches from us mortals :)
17:44:29 <djmitche> I think I have two worries
17:44:48 <djmitche> 1. are we making things more confusing for contributors ("OMG there's like 20 checkboxes before I can submit this PR")
17:44:50 <djmitche> and
17:45:00 * sa2ajj nods
17:45:09 <djmitche> 2. are we just piling more tools into an area where we already have a lot of tools?
17:45:33 <djmitche> (appveyor, codecov, circle, travis)
17:45:34 <sa2ajj> (1) is the point that made me think "should we really do this?"
17:45:52 <djmitche> yeah, I'm not really looking at PRs much, but from what I remember, this wasn't a huge problem
17:46:03 <sa2ajj> as for (2) all these tools are *post* PR not *pre* merge :/
17:46:07 <djmitche> and I think it was useful for a contributor to fix their actual issue, then get the "great, but it needs these things.." message
17:46:15 <djmitche> right
17:46:20 <sa2ajj> so i don't consider that pointm, sorry :(
17:46:45 <sa2ajj> s/pointm/points/
17:46:47 <sa2ajj> :)
17:46:48 <djmitche> anyway, I think all of these tools are checking slightly different things
17:46:54 <djmitche> some check import order..
17:47:00 <djmitche> all of them run tests
17:47:10 <djmitche> I don't think any verify reliably that there was documentation or relnotes
17:47:14 <sa2ajj> let's ignore this for now
17:47:16 <djmitche> (validate.sh warns for missing relnotes)
17:47:26 <sa2ajj> i wanted to see what discussion it'd generate, that's it
17:47:28 <djmitche> ok
17:47:29 <djmitche> :)
17:47:42 <djmitche> that was the last topic then..
17:48:13 <tardyp> for relnotes, I dont think we should enforce it
17:48:15 <tomprince> Oh .. do we want to support squash merges? If not, that should be disaled, probably.
17:48:25 <sa2ajj> djmitche: thank you for chairing such a long meeting :)
17:48:27 <tardyp> relnote patches are very annoying, because they dont rebase
17:48:36 <djmitche> tomprince: good point
17:48:48 <djmitche> tardyp: yeah, although the conflicts are pretty easy
17:48:59 <tomprince> https://warehouse.python.org/project/towncrier/
17:48:59 * sa2ajj disagrees
17:49:04 <tardyp> yes, but that adds delay to the user
17:49:13 <tardyp> I prefer to spend more time at release lookin
17:49:16 <djmitche> tomprince: disabled
17:49:17 <tardyp> at the git log
17:51:14 <djmitche> sounds like there's lots of room for improvement here, but I think a good high-level plan to start with would help
17:51:18 <tardyp> towncrier is another idea, but we have to train our contributors to annotate their commits
17:51:21 <djmitche> right
17:51:47 <djmitche> anyway, I need to run
17:51:52 <djmitche> so don't let this stop the conversation:
17:51:54 <djmitche> #endmeeting