16:30:33 <djmitche> #startmeeting weekly
16:30:33 <bb-supy> Meeting started Tue Dec 15 16:30:33 2015 UTC and is due to finish in 60 minutes.  The chair is djmitche. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:33 <bb-supy> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:30:33 <bb-supy> The meeting name has been set to 'weekly'
16:30:46 <djmitche> #topic Introductions
16:30:48 <djmitche> #nick jaredgrubb
16:30:50 <djmitche> #nick verm__
16:30:54 <djmitche> #nick bdbaddog
16:31:01 <djmitche> https://titanpad.com/buildbot-agenda
16:31:07 <infobob> http://paste.pound-python.org/show/5sPY4u89Au8rg7ET5QBi/ (repasted for djmitche)
16:31:19 <djmitche> #topic MOSS Grant
16:31:46 <tardyp> Hi
16:32:13 <bdbaddog> So Bradley Kuhn at SFC is going to coordinate with Mozilla to get the funds in Buildbot's account.
16:32:15 <djmitche> #info We have been funded by Mozilla - US$5k to improve EC2 behavior around slave or master failure, $10k for removing use of the term "slave"
16:32:25 <djmitche> cool
16:32:49 <bdbaddog> One thing I guess I forgot to take into account for amounts was SFC's "cut". If I remember correctly they take some percentage of deposits as their service fee right?
16:32:51 <djmitche> bear in mind that we will lose 10% in the process ($1,500).  We can make that up from existing funds so the bounties can still be the full amount
16:32:59 <djmitche> yes
16:33:04 <bdbaddog> o.k.
16:33:09 <djmitche> suddenly I don't remember if it's 10%, but whatever it is
16:33:13 <verm__> it's 10%
16:33:23 <djmitche> ok thanks
16:33:54 <djmitche> so I think we need to figure out how to run a bounty program
16:34:25 <djmitche> I think GSoC is a good pattern
16:34:33 <verm__> yep
16:34:54 <verm__> and for this amount i think a short (1-paragraph) intro as to why they should do it would be nice
16:34:55 <djmitche> so, accept applications, evaluate, "hire" the best, mentor over the selected time range
16:35:01 <djmitche> yes
16:35:05 <bdbaddog> Does GSOC require that you complete the task to be "paid"
16:35:09 <verm__> no
16:35:19 <verm__> gsoc is about learning but we'll have to have a small contract
16:35:29 <djmitche> right, so that will be different, and I think teh applicants should write the completion condition
16:35:35 <verm__> for the 15k one we need to cut say it must be 5, maybe 6-8 milestones
16:35:40 <djmitche> as well as the timeline, and a rough outline of the schedule
16:35:46 <verm__> this way if someone does not do well we have a significant portion of our money to find someone else to do the work
16:36:29 <bdbaddog> Donno.. I'd say with removing slave, the success criteria would be pretty straighforward.
16:36:51 <djmitche> yes
16:36:55 <djmitche> and there's no 50% completion there
16:37:06 <bdbaddog> for the EC2 one it's likely there'll be no absolute "done" but basically making it better (hopefully handling most cases) than it is now.
16:37:37 <djmitche> yeah, and a few concrete promises would be good -- if we want to split the bounty along those lines, that's OK (but again I think teh applicant should do so)
16:37:44 <verm__> well for the slave renaming it can be chunked
16:37:46 <verm__> eg, documentation
16:37:54 <djmitche> so "I will fix X ($2000), Y ($1000) and Z ($2000)
16:38:13 <djmitche> verm__: yeah, but an update to the documentation that doesn't correspond to code changes is not useful
16:38:18 <djmitche> it's pretty much all or nothing
16:38:19 <bdbaddog> fair enough. pay per completion of atomic item.
16:38:34 <bdbaddog> probably compat, code, docs ?
16:38:54 <verm__> djmitche: it can sit in its own branch as a completed item and merged in when it's all done, how else would we pay it out?
16:39:05 <verm__> a lump-sum at the end? 10% up front and 90% at the end?
16:39:06 <bdbaddog> I"m assuming there'd be a compatibilty layer which would issue deprecation warnings for using "Slave", and that would be in for a release or two and them remoed
16:39:25 <djmitche> bdbaddog: yes
16:39:33 <verm__> yeah i was assuming that as well
16:39:34 <djmitche> verm__: I don't want to pay anything for an un-mergeable branch
16:39:39 <djmitche> that will bitrot in a matter of days
16:39:42 <bdbaddog> sure.
16:39:51 <bdbaddog> pay on successful merge and test run?
16:39:55 <bdbaddog> all or nothing..
16:40:07 <verm__> i think that's the only way
16:40:10 <djmitche> me too
16:40:13 <bdbaddog> yup.
16:40:15 <djmitche> and I don't think any up-front payment is necessary
16:40:19 <verm__> i was trying to see if there was a way to chunk it
16:40:22 <verm__> djmitche: agreed
16:40:31 <verm__> some bounties do work like this as a kind of "leave it out there"
16:40:37 <verm__> once done, paid out.. easy
16:40:38 <bdbaddog> yup. it's a bounty.. you don't apy a bounty hunter to go get the criminal.. you pay when they bring em in..
16:40:38 <djmitche> I think the inability to chunk it, and the rapid bitrot, are why this is the only way it will ever get done
16:41:16 <verm__> yes, so it will be paid out once it lands?
16:41:24 <bdbaddog> For EC2. it may be possible to break up the bounty to handle several cases where buildbot's currently "failing"
16:41:32 <bdbaddog> +1 pay when it lands.
16:41:44 <djmitche> ditto
16:41:59 <verm__> we should be able to give them a few days of 'no new patches' to give them a chance of doing this
16:42:01 <djmitche> #agree bounty payment will occur when the work lands in master
16:42:04 <verm__> merging to a moving target sucks
16:42:17 <djmitche> verm__: yeah, a few days should be fine
16:42:38 <djmitche> #agree OK for applicant to sub-divide the EC2 project, but the slave project needs to be all-or-nothing
16:42:51 <bdbaddog> +1 quiet period for landing slave-freedom-patch
16:42:56 <djmitche> #agree applicants will write an application, and we will select the application that is most likely to succeed
16:43:21 <verm__> will the EC2 work be targeted specifically towards EC2 or will that work cover other cloud services as well? i'm assuming there is a lot of abstraction there
16:43:49 <djmitche> I think it would go where the code fits best
16:44:08 <djmitche> yes, there's a good bit of abstraction already, so doing it only for EC2 might be harder than doing it generally
16:44:26 <verm__> ok, dangling instances is a problem with other services too i'd hate to see that targeted at EC2 specifically
16:44:37 <verm__> i figured that just making sure :)
16:44:52 <djmitche> cool
16:45:08 <djmitche> so, I can write up some application guidelines
16:45:28 <djmitche> should we have the botherders as a group be responsible for reviewing?
16:45:46 <djmitche> https://github.com/buildbot/botherders if you need to remember who those are :)
16:45:56 <verm__> i think that makes sense, it removes the pressure for reviewing
16:46:02 <djmitche> ok
16:46:18 <djmitche> #action djmitche to write application guidelines
16:46:25 <djmitche> #agree botherders will review applications
16:46:43 <djmitche> ugh I think I want #agreed
16:46:49 * djmitche will fix later
16:47:22 <djmitche> so I am also worried about the wrath of the Internet Hate Machine
16:47:27 <verm__> haha
16:47:30 <verm__> i was JUST thinking that
16:47:52 <djmitche> so far responses have ranged from jokes to reasonable arguments that the change is unnecessary
16:48:05 <verm__> i was going to suggest we have some kind of policy, maybe on the front of the devel and webpage simple stating the rename is happening and we have decided to do so as a project
16:48:17 <djmitche> ok
16:48:24 <djmitche> for the record we do have a code of conduct - https://github.com/buildbot/botherders/blob/master/policies/conduct.md
16:48:36 <verm__> that should close off  most debate..the ones that will speak up will do so under any conditions
16:48:43 <djmitche> right
16:49:01 <djmitche> and in a way they're just explaining why they don't want to do it -- that's fine, they don't get the $$ :)
16:49:07 <verm__> yeah.. but a blanket statement that we're renaming and have decided it as a final decision would be good
16:49:08 <verm__> heh
16:49:12 <djmitche> ok
16:49:19 <djmitche> I can put that in the bug
16:49:26 <djmitche> I'll make a bug up for the ec2 project too
16:49:40 <djmitche> and send an email to the devel mailing list
16:49:51 <verm__> cool
16:50:03 <djmitche> #action djmitche to make bug for the EC2 project
16:50:29 <djmitche> #action djmitche to explain that the decision is done for the terminology bug
16:50:39 <djmitche> #link https://github.com/buildbot/botherders/blob/master/policies/conduct.md
16:51:09 <djmitche> #info please bring any issues of conduct to the botherders immediately, whether they are private or public
16:51:25 <djmitche> anything else on this topic?
16:51:28 <verm__> that's a good point
16:51:31 <verm__> nope not for me
16:52:06 <djmitche> #topic failing tests - http://trac.buildbot.net/ticket/3387
16:52:20 <djmitche> I fixed this particular bug last week (I happened to have a half-hour free)
16:52:29 <djmitche> tardyp: I saw some failures yesterday -- are those anything to worry abotu?
16:53:02 <bb-trac_> [trac] #3387/defect (closed) updated by dustin (empty comment) http://trac.buildbot.net/ticket/3387
16:54:25 <djmitche> guess not :)
16:54:46 <djmitche> #topic CLI tool to talk to the nine API
16:54:52 <djmitche> verm__: you were going to talk about / demo this?
16:55:05 <verm__> heh, that was a huge rabbit hole for me.. i went down the path of asyncio and websockets
16:55:24 <verm__> i decided half way through to drop autobahn and go stock with asyncio and websockets which will be part of python 3.4+
16:55:29 <verm__> that way in the future we will have no dependencies
16:55:42 <verm__> no demo this week hopefully next week
16:56:05 <djmitche> can you describe the plan a bit?
16:56:17 <verm__> yep, it will have two settings
16:56:33 <verm__> one a simple horizontal scroll that will display the builder and status change -- i will work on this first
16:56:41 <verm__> so <builder> <step> <time since start> etc
16:56:49 <verm__> the next one will be a top-style view
16:56:59 <verm__> that keeps a list of active builders and updates them realtime via the websocket
16:57:13 <djmitche> very cool
16:57:17 <verm__> the 1st one is easy
16:57:25 <verm__> the 2nd i will solicit help or hack away at it myself
16:57:33 <djmitche> #info CLI tool to list status of builders, including top-like view of all builders
16:57:47 <djmitche> #info using asyncio and websockets support in python 3.4+
16:57:51 <djmitche> #info maybe a demo next week?
16:57:52 <verm__> the list status will scroll as updates come in via the websocket
16:57:59 <verm__> yeah maybe i hope so
16:58:08 <djmitche> so basically an event tail
16:58:19 <verm__> hey that's a great way to describe it
16:58:39 <djmitche> :)
16:58:56 <djmitche> that should be great, and a good model of a tool built around the API
16:59:07 <djmitche> ..on to the last topic..
16:59:12 <djmitche> #topic Nine Update
16:59:19 <djmitche> http://trac.buildbot.net/query?status=accepted&status=assigned&status=new&status=reopened&milestone=0.9.0&group=status&order=priority
16:59:22 <jaredgrubb> that will be very cool
16:59:51 <djmitche> I'm at a loss for ways to get nine out the door, tbh
17:00:06 <verm__> what's the problem?
17:00:16 <verm__> tickets?
17:00:38 <djmitche> there are 31 left (see link above)
17:00:48 <verm__> yeah looking
17:00:48 <djmitche> just not a lot of work going on
17:01:06 <verm__> how many of these can be pushed to a later release? maybe it's time to simply bring the hatchet down
17:01:16 <djmitche> we already chopped a lot of stuff out to 0.9.1
17:01:19 <verm__> once nine is out and public it will be easier for users to contribute
17:01:36 <verm__> maybe 9.1 should be 9.2 and most of this moves to 9.1?
17:01:40 <verm__> just throwing out ideas
17:01:49 <djmitche> I guess the question is, is it usable as-is?
17:01:56 <verm__> i've been using it perfectly fine for months
17:02:09 <djmitche> it's one thing to throw something half-finished out there in hopes the publicity will help get it finished
17:02:17 <djmitche> and another to throw something non-functional out there and do damage control
17:02:18 <Igloo> I am looking at setting a new BB up, and decided to go with 0.8 as 0.9 wasn't usable enough
17:02:19 <verm__> the only thing i've gotten stuck on is the perminant builders...
17:02:39 <verm__> djmitche: oh it's very usable
17:02:40 <djmitche> oh, yeah, did you find a bug for that? or file one?
17:02:42 <djmitche> hmm
17:02:43 <verm__> stable
17:02:45 <verm__> i filed one last week
17:02:47 <djmitche> getting two different opinions here :)
17:02:47 <djmitche> ok
17:02:53 <verm__> that's the only big issue i've seen
17:03:06 <bdbaddog> whats' the bug #
17:03:09 <djmitche> verm__: are you using master or the latest beta?
17:03:16 <verm__> i don't know why it's not on that list
17:03:31 <verm__> http://trac.buildbot.net/ticket/3386
17:03:36 <verm__> oh, i set it to 0.9.+
17:04:02 <verm__> djmitche: master
17:04:07 <djmitche> ok
17:04:15 <djmitche> yeah, that's definitely a 0.9.+ bug
17:04:18 <jaredgrubb> i personally havent tried nine in a while … when i tried it the waterfall hung … but amar suggested that the waterfall does hang until one build has been initiated … i havent tried that yet, tbh … so i have been a bad buildbot dev
17:04:28 <verm__> yep that's the problem
17:04:40 <verm__> you need to have at least one build for the waterfall to work
17:04:42 <Igloo> http://trac.buildbot.net/query?status=!closed&reporter=ian are two tickets I filed. I think also the UI just didn't work properly (ISTR the sidebar went on top of the forms to trigger builds, for example)
17:04:45 <verm__> hmmm did i open a ticket for that
17:05:13 <Igloo> It's been 2 or 3 months since I looked at it, so (a) I've forgotten the details, and (b) it's possible things have changed since then
17:05:44 <djmitche> those are likely still valid
17:06:03 <jaredgrubb> maybe we should do a "Release Candidate" build, and all of us slackers will promise to really try again? :)
17:06:22 <djmitche> An RC will really just generate more bugs
17:06:26 <verm__> yeah
17:06:28 <djmitche> well, bug reports
17:06:43 <verm__> we can have a notes for it.. include the waterfall bug
17:06:45 <jaredgrubb> if there's bugs, they'll come whether it's a RC, beta, or release
17:06:49 <verm__> and a list of tickets for 0.9.x
17:06:57 <verm__> asking for help.. also have the reasoning for releasing with so many bugs
17:07:01 <djmitche> and it isn't that I don't want to get a better picture of what the most pressing issues are, but .. I feel like our velocity is zero so more todo doesn't help
17:07:17 <verm__> when you have this large of a change sometimes it's best to just dive in and solicit help from the community
17:07:48 <verm__> it's usable and stable
17:08:06 <bdbaddog> so which bugs are "Must be fixed" for us to call 0.9.0 "usable"
17:08:15 <bdbaddog> just the crtiical?
17:08:35 <djmitche> something like that, yeah
17:08:44 <djmitche> we could probably do another cull
17:08:49 <bdbaddog> o.k so 4 bugs in that state now.
17:09:04 <djmitche> it's probably a bit more than that, but definitely less than 31
17:09:12 <verm__> http://trac.buildbot.net/ticket/2644
17:09:15 <verm__> is that really critical?
17:09:31 <djmitche> Apparently crossbar.io works now, so no
17:09:38 <djmitche> it was critical since without it, multimaster didn't work
17:09:45 <verm__> i don't think any of those critical bugs are critical
17:10:13 <djmitche> how about this
17:10:42 <djmitche> I'll put an email out to the dev list asking everyone to have a look at the 0.9.0 list
17:10:59 <djmitche> and moving as much as possible out, leaving only the "we'd be insane to release without this" list
17:11:10 <bdbaddog> +1
17:11:21 <djmitche> which should have the side-effect of focusing more devs on getting those last few bugs fixed
17:11:24 <djmitche> cool
17:11:25 <verm__> http://trac.buildbot.net/ticket/3374 <-this one should be fixed to not trip up users
17:11:33 <verm__> +1 too
17:11:37 <jaredgrubb> +1
17:11:59 <djmitche> #action djmitche to send devel@ email asking everyone to triage bugs out of 0.9.0 and focus on the remaining
17:12:15 <djmitche> verm__: meh, that one's easy but OTOH not critical
17:12:33 <djmitche> I think "critical" here means "more than half of the users will find the software completely unusable"
17:12:40 <verm__> ok, then yes bump it
17:12:50 <bb-trac_> [trac] #3374/defect (new) updated by dustin (empty comment) http://trac.buildbot.net/ticket/3374
17:12:50 <verm__> we can always say in the release announcements to look over the tickets
17:12:55 <djmitche> yeah
17:13:05 <djmitche> ok, well, this has been a long meeting
17:13:13 <djmitche> should we wrap up?
17:13:16 <bdbaddog> a big "Security notice" in release notes for any known gotchas..
17:13:23 <verm__> yeah
17:13:27 <bdbaddog> +1 to wrap :)
17:13:31 <bdbaddog> (Lunchtime)
17:13:33 <verm__> djmitche: yep i think it's fine to wrap up you did an amazing job as usual!
17:13:39 <djmitche> #action djmitche to add "security notice" to relnotes with a link to #3374 among others
17:13:43 <djmitche> ok!
17:13:55 <verm__> really excited to see .9 out!
17:13:59 <bdbaddog> Ditto!
17:15:02 <djmitche> #endmeeting