16:30:08 <djmitche> #startmeeting weekly
16:30:08 <bb-supy> Meeting started Tue Dec 22 16:30:08 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:08 <bb-supy> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:30:08 <bb-supy> The meeting name has been set to 'weekly'
16:30:15 <djmitche> #topic Introductions
16:30:38 <djmitche> https://titanpad.com/buildbot-agenda
16:30:38 <infobob> http://paste.pound-python.org/show/5sPY4u89Au8rg7ET5QBi/ (repasted for djmitche)
16:30:48 <djmitche> gotta convince infobob to not do that..
16:31:01 <djmitche> #topic MOSS
16:32:06 <djmitche> I put together the documentation for MOSS last week
16:32:13 <djmitche> filed bugs, organized things in Trac
16:32:18 <djmitche> http://trac.buildbot.net/wiki/BountyProgram
16:32:37 <djmitche> I generalized it as a bounty program
16:32:50 <djmitche> although I didn't put much thought into how we'd accept other sponsorships
16:33:05 <djmitche> I have some emails out to see if we need to add more specific tasks to teh EC2 bounty
16:33:43 <djmitche> I haven't heard back from Conservancy yet
16:33:45 <djmitche> I'll remind them today
16:33:48 <tardyp> looks fine to me
16:34:11 <djmitche> once I hear back about EC2, I'll put the price on it -- I just don't want to "move the goalposts"
16:35:31 <tardyp> Do we have pretendents already?
16:35:58 <tardyp> bdbaddog: are you willing to take one?
16:36:11 <bdbaddog> I'm coming a bit late. Take one what?
16:36:28 <tardyp> one of the MOSS project
16:36:50 <tardyp> I think we now need to recruit
16:36:56 <bdbaddog> as a bounty judger, or as a doer?
16:37:07 <djmitche> doer
16:37:16 <djmitche> but you are also a "judger" as a botherder
16:37:38 <bdbaddog> sure. though I'd have to abstain from judging if I'm a doer.
16:37:44 <bdbaddog> for that bounty
16:38:12 <bdbaddog> though would it look bad if I was to collect a bounty when I helped with the filing?
16:39:13 <tardyp> It does not to me. It looks normal that you help finding the founding for your work on buildbot
16:39:30 <tardyp> as independent worker
16:39:50 <bdbaddog> o.k. as long as we (collectively) don't think that's bad form.
16:39:58 <tardyp> djmitche: ?
16:41:27 <bdbaddog> brb..
16:41:55 <djmitche> I think that would be fine
16:41:59 <rutsky> hi, all!
16:42:01 <djmitche> we'd just have to be transparent
16:42:02 <djmitche> hi rutsky
16:42:37 <tardyp> my concern is that we now need to find good applicants
16:42:44 <djmitche> rutsky is appy,ling :)
16:42:51 <rutsky> it's a little inconvenient to me to speak at this time, so sorry if I'll not answer quickly
16:42:58 <djmitche> it's OK
16:43:28 <tardyp> so that is good if we find people already from the community
16:43:39 <djmitche> yes
16:43:43 <djmitche> so I think we're in good shape now
16:43:55 <rutsky> If I'm not interrupting anyone, I would like to discuss scope of "renaming" project
16:44:00 <djmitche> yes, please do
16:44:51 <rutsky> since it has huge bounty I don't think it's just "smart renaming"
16:45:18 <djmitche> right - the compatibility will be the hard part
16:45:34 <djmitche> part of the reason for that to be so large is that it will also need to be done fairly quickly, since any patch will bitrot very quickly
16:45:39 <rutsky> this project depends on releasing of 0.9.0 so definitely part of nin issues will be included (e.g. new master/worker protocol)
16:45:51 <djmitche> yes
16:46:15 <tardyp> shall we rename master as well?
16:46:22 <rutsky> what is the estimate of 0.9.0 release? Is it weeks or months?
16:46:24 <tardyp> controller
16:46:33 <djmitche> tardyp: I don't think so
16:46:48 <djmitche> rutsky: probably months?
16:47:38 <tardyp> there is not much remaining work to do actually
16:48:02 <tardyp> we just have very few resource actually  working on it
16:48:21 <djmitche> we can move on to the nine status I suppose
16:48:27 <djmitche> #topic Nine update
16:48:41 <djmitche> http://trac.buildbot.net/query?status=accepted&status=assigned&status=new&status=reopened&milestone=0.9.0&group=status&order=priority
16:49:21 <djmitche> I don't think much has changed there
16:49:26 <djmitche> I didn't see a lot of triaging going on after my email
16:49:50 <tardyp> I am working on http://trac.buildbot.net/ticket/3231
16:50:24 <tardyp> which is the end of the gsoc project on buildbot-data
16:50:36 <bb-trac> [trac] #3231/project-idea (assigned) updated by dustin (empty comment) http://trac.buildbot.net/ticket/3231
16:50:43 <djmitche> great
16:50:51 <djmitche> and will do a lot for frontend functionality
16:51:17 <tardyp> looking at the bugs quickly, I think there are indeed a lot of thing that are not really blocking
16:51:28 <rutsky> Renaming interfaces with leaving backward compatible wrappers looks not hard to me, since its all in Python. So this part + documentation changes can be done (and merged) quickly IMO. Much harder with actual code rewriting stuff, like master/worker protocol. Do you know other tricky places were code will require reqriting?
16:51:35 <tardyp> The thing is, it is hard to take a decision alone
16:52:08 <djmitche> rutsky: why will that require rewriting?
16:52:24 <djmitche> tardyp: I think you've got a better sense for that than anyone else
16:52:51 <bdbaddog> is there a page which states the goals of the nine release?
16:52:55 <rutsky> djmitche: do we want to use new master/worker protocol or modify existing?
16:53:06 <bdbaddog> to use as a litmus test for what must be in the 0.9.0 and what doesn't?
16:53:28 <djmitche> bdbaddog: at this point, I think "supports most single-master functionality of 0.8.12"
16:53:48 <djmitche> rutsky: well, there's still only one protocol (PB) - it's just been re-implemented in a more abstract way in nine
16:53:49 <bdbaddog> rutsky: not sure why it matters, the name is just being changed, unless inside the protocol the words slave and master are used.
16:54:28 <djmitche> I think that abstraction will make the renaming easier, actually, since the class names that are part of the protocol are all under master/buildbot/protocol
16:55:07 <djmitche> the abstraction is still not quite done -- it leaks
16:55:24 <tardyp> leaks?
16:55:26 <djmitche> so fixing that leak may be part of the project, or not
16:55:37 <djmitche> it references some non-protocol-specific classes
16:55:40 <tardyp> I think I've cleaned it
16:55:52 <tardyp> when I worked on the wamp stuff
16:56:26 <tardyp> even if the final wamp slave was not merged, I merged the cleanup stuff
16:56:55 <tardyp> and we have a slave implementation without pb (which is no proof that it does not leak though)
16:57:04 <djmitche> for example remoteSetBuilderList - https://raw.githubusercontent.com/buildbot/buildbot/master/master/docs/developer/cls-protocols.rst
16:57:18 <djmitche> oh, cool - maybe the docs just need to have the "XXX" removed/
16:58:03 <rutsky> so new master/worker protocol already integrated into nine?
16:58:03 <tardyp> maybe I forgot to look at the doc :-}
16:58:10 <rutsky> and it doesn't depend on PB?
16:58:43 <djmitche> rutsky: the refactor to allow new protocols to be added has been merged
16:58:47 <tardyp> It does not depend on pb, but the only workable protocol is the impl based on PB
16:58:50 <djmitche> but the only protocol currently avaialble is PB
16:58:53 <djmitche> right
16:59:19 <rutsky> what "workable" means here?
16:59:31 <tardyp> means usuable in real life
16:59:38 <tardyp> the other implementation is more toy
16:59:47 <rutsky> protocol usage is not implemented in master and in the worker?
17:00:02 <tardyp> where master and worker are in the same python reactor
17:00:17 <rutsky> oh, I see
17:00:30 <tardyp> that is the 'null' protocol
17:00:39 <tardyp> where stuff are directly called
17:01:08 <tardyp> this is useful for integration tests as well
17:01:13 <rutsky> so the plan is to use new protocol over existing PB connection?
17:01:23 <djmitche> yes
17:01:34 <djmitche> I would call it a "new implementation" rather than "new protocol", but yes
17:01:39 <tardyp> https://github.com/buildbot/buildbot/blob/c252fde92ca6a4e95a432f84cb5c2c426add2435/master/buildbot/buildslave/protocols/null.py
17:03:00 <rutsky> ok, and "new implementation" already used in nine?
17:03:25 <rutsky> does nine handles workers over old API and new API at the same time?
17:03:43 <djmitche> rutsky: yes
17:03:52 <djmitche> it's the same protocol on the network
17:03:57 <djmitche> just different code implementing it on the master
17:04:32 <tardyp> yes. And I'd guess the "slave" word is part of the de-facto standard
17:04:57 <tardyp> we need to remove that, but keep accepting old implementation of slaves
17:05:16 <tardyp> a new master shall always be able to connect to old slaves
17:05:29 <tardyp> while new slave I dont bother they can connect to old masters
17:05:35 <tardyp> new worker
17:05:40 <rutsky> ok, that sounds great
17:06:05 <tardyp> so I'd say we can go worker without bw compat on the worker base, and go straight to a new python package
17:06:16 <djmitche> yes
17:06:21 <tardyp> but the master needs to stay compat
17:06:24 <rutsky> so I don't need to reimplement protocol/API, but need to 1) remove "slave" from new API (since it doesn't exist in 0.8.*)
17:06:30 <djmitche> so if you install buidlbot-slave, the most recent version is 0.8.12, but it will still talk to 0.9.0
17:06:42 <djmitche> if you install buildbot-worker, it's 0.9.0, and will only talk to a 0.9.0 master
17:06:52 <tardyp> yes
17:07:12 <djmitche> in particular, the word "slave" should not appear at all in the new buildbot-worker package
17:07:22 <rutsky> 2) port slave to new API and call it "buildworker" (old "buildslave" doesn't need any modifications)
17:07:38 <djmitche> I think just "worker" rather than "buildworker"
17:07:44 <tardyp> just call it worker
17:07:48 <rutsky> djmitche: agree
17:08:01 <tardyp> as it can do other stuff than build (e.g. test)
17:09:02 <rutsky> ok, I think I don't have question about master/worker protocol, what about other parts? Is there any tricky part that I'm missing?
17:09:17 <rutsky> (in context of renaming project)
17:09:17 <djmitche> config file compatibility
17:09:31 <djmitche> c['slaves'] should still work, but so should c['workers']
17:09:45 <bdbaddog> upgrade master (or new name) should point out changes need to be made in config file
17:09:56 <tardyp> we have a property named 'buildslave'
17:10:06 <rutsky> djmitche: but work exclusively, yes? We don't need to support 'slaves' and 'workers' at the same time
17:10:22 <tardyp> which imho should only be kept if c['slavecompat'] = True
17:11:20 <tardyp> I think it is a good idea indeed to be able to have a compatibility mode
17:11:29 <bdbaddog> initially though the usage of "buildslave" property shoudl throw a deprecated warning?
17:11:33 <rutsky> tardyp: I think it's better to work in 'slavecompat' mode by default and switch it to new API when first non-slave stuff found, e.g. c['workers']
17:12:08 <bdbaddog> disagree.. moving forward it's workers and not slaves and so using slaves shoudl by default throw warnings.
17:12:20 <rutsky> bdbaddog: I suppose *all* usage of 'slave'-stuff should raise warnings
17:12:24 <djmitche> yes
17:12:39 <djmitche> I don't think we need to have a "compat mode" that users must turn on
17:12:44 <tardyp> and the warnings should be disablable with an explicit line in the config
17:13:03 <bdbaddog> +1 no compat mode
17:13:05 <rutsky> tardyp: good point
17:13:09 <bdbaddog> +1 warnings disablable
17:13:32 <tardyp> nothing is more anoying than a deprecation warning you have no time to really fix now that is poluting your logs
17:13:56 <rutsky> bdbaddog: with "no compat mode" you mean no c['slavecompat'] = True option?
17:14:16 <tardyp> I hate twisted for making the warning about deferedGenerator not an option lately
17:14:24 <tardyp> I had to code a monkey patch for it.
17:14:28 <djmitche> rutsky: right
17:14:41 <djmitche> tardyp is suggesting something like c['silence_slave_warnings'] = True
17:14:58 <tardyp> I was more thinking about a enum option
17:15:00 <bdbaddog> rutsky: correct
17:15:08 <tardyp> c['slavecompat'] = 'nowarning'
17:15:14 <tardyp> c['slavecompat'] = 'errpr
17:15:26 <djmitche> I like that
17:15:28 <tardyp> c['slacecompat'] = 'warning' < default
17:16:05 <tardyp> and error mode is for the ppl that want to be sure that they code is clean
17:16:20 <bdbaddog> +1
17:16:27 <tardyp> probably will go 'error' by default for 0.9.2 or something
17:16:44 <djmitche> +1
17:16:49 <tardyp> (will we ever release a 1.0 version :))
17:17:56 <tardyp> so I'd guess next step is to re-take the old PR's sed method, and start looking at what we need
17:18:09 <tardyp> I doubt we can think of all the corner cases
17:18:10 <djmitche> yes
17:18:37 <rutsky> About testing "renaming" project. Do we have some large integration test suits or some kinf of testing systems? How do we plan to test that 0.8.* configuration will work on 0.9.0?
17:18:49 <djmitche> #info see logs for discussion of the interaction of nine and the renaming project
17:18:53 <tardyp> first POC, then a detailled plan, and we can split the bounty into several taks
17:19:01 <djmitche> rutsky: there's some code in there for configuration compatibility checking
17:19:31 <tardyp> rutsky: as the namespace will change
17:19:34 <djmitche> protocol compatibility will probably need some work to build tests for it
17:19:47 <tardyp> you will still be able to install worker and buildslave at the same time in the same env
17:20:17 <tardyp> maybe we should just create a new implementation 'workerpb' instead of pb
17:20:38 <tardyp> the integration tests are already testing different protocols
17:20:59 <tardyp> so I'd guess you can tweak them in order to both test against the buildslave and worker packages
17:21:13 <djmitche> I like that
17:21:56 <rutsky> and is there some kind of system tests? e.g. I have config for master and config for worker, and can I automatically start both of them, start jobs on worker and automatically check that they completed as I excepted?
17:22:21 <tardyp> the integration tests are more or less doing that, but in the same reactor
17:22:27 <tardyp> not spawning new process
17:23:06 <tardyp> spawning new process is a bit more complicated in term of 1/ speed 2/ stability
17:23:22 <tardyp> but that can be tried
17:23:25 <djmitche> and not necessary in this case I think
17:23:48 <tardyp> djmitche: agreed
17:24:07 <rutsky> ok, so as you suggested I'll stick with writing integration tests for new worker
17:24:08 <bdbaddog> so workerpb then ?
17:24:42 <tardyp> I am not sure if we can have several protocol at the same time
17:24:52 <tardyp> but I'd guess it would be needed
17:25:02 <tardyp> so c['slaves'] are only 'pb'
17:25:12 <tardyp> and c['workers'] are 'workerpb'
17:25:34 <tardyp> that would make it easy to distinguish the different worker kinds
17:25:40 <djmitche> we do support multiple protocols in the same master
17:25:44 <tardyp> ok
17:26:08 <rutsky> I don't think theese workers need to be separated in config
17:26:29 <tardyp> that can be detected at the time of connection, indeed
17:26:31 <rutsky> I think it would be nice to be able to transparently update part of build-machines to new worker
17:27:46 <tardyp> info = yield self.mind.callRemote('getSlaveInfo')
17:27:56 <tardyp> has to be replaced by getWorkerInfo
17:28:06 <tardyp> if this is failing, then this is a legacy protocol
17:28:15 <djmitche> yes
17:29:00 <djmitche> transparent update would be great - so c['slaves'] and c['workers'] are basically aliases for one another, and each one can use either the pb or workerpb protocol
17:29:09 <djmitche> detecting which is in use at startup
17:29:15 <djmitche> sorry, at connection
17:29:29 <tardyp> yes
17:30:23 <tardyp> bdbaddog: you were interrested in the worker project as well?
17:31:05 <bdbaddog> yes.
17:31:16 <tardyp> if yes, then we need to be clear on the work sharing
17:31:33 <tardyp> I dont think doing thing in a competitive way is a good idea
17:31:44 <tardyp> first one to finish gets all, second gets nothing!
17:31:56 <djmitche> the suggestion is to accept one proposal at a time
17:32:04 <djmitche> s/suggestion/plan/g
17:32:08 <djmitche> at least as I wrote it
17:32:11 <bdbaddog> that is the nature of "bounty", but perhaps as you say not in the best interests of the community
17:32:26 <tardyp> I understood the solution was to split into several
17:32:41 <tardyp> so that several ppl can work on different sub bounties
17:32:56 <djmitche> "OPTIONAL: If the project breaks down nicely into parts that are individually useful to the project, you may propose sub-bounties for those parts that sum to the total bounty. For example, a $1000 bounty that involves features A, B, and C could be broken down into a $400, $300, and $300 sub-bounty. If you then complete A and B but not C, we will pay out $700
17:32:56 <djmitche> and re-list C as a $300 bounty. "
17:33:26 <djmitche> the idea there is that the *applicant* can elect to split it, either to hedge his/her bets and get paid even if they can't finish the whole thing
17:33:28 <bdbaddog> right so the proposor would then sugguest the sub-bounties
17:33:33 <djmitche> or because they only want to work on part of it
17:33:33 <djmitche> right
17:33:53 <djmitche> so if bdbaddog and rutsky want to split it up and pre-arrange how the bounty gets split, that's fine too
17:33:59 <bdbaddog> sure.
17:34:10 <djmitche> the botherders aren't going to tell anyone "don't work on that"
17:34:20 <bdbaddog> :)
17:34:22 <djmitche> but we will say "so-and-so is working on that bounty right now"
17:34:27 <djmitche> once we accept a proposal
17:34:30 <tardyp> yes, we would like to avoid any drama here, so please collaborate! :)
17:34:39 <djmitche> collaboration would be awesome, but less $$
17:35:24 <tardyp> indeed
17:35:49 <djmitche> rutsky: any other questions/topics?
17:36:27 <bdbaddog> might make sense to do something like.  split into sections, then split those into implementation/testing.
17:36:48 <rutsky> +1 for collaboration, I think whole 10K bounty should be given only for a significant work, that should require *months* of full-time work
17:37:35 <bdbaddog> rutsky: as I mentioned in an earlier meeting. 10k=100hrs @ $100/hr
17:37:47 <bdbaddog> or 200hrs @$50/hr
17:38:11 <bdbaddog> Professional consultants in US $100/hr is likely a floor, or the lowest you'll get good quality.
17:38:32 <bdbaddog> months of work to earn 10k.. will eliminate that pool.
17:38:46 <rutsky> djmitche: I don't have any questions right now. My main question actually was "am I missing something in this project"
17:39:33 <djmitche> great
17:39:36 <rutsky> oh, last question
17:39:37 <bdbaddog> rutsky: I think this project has a suprising number of details, so on the surface it sounds simple, but you also have to deal with making the changes on a live code stream so it needs to be done fairly quickly.
17:39:52 <rutsky> how usable nine branch? :)
17:40:15 <tardyp> serveral ppl use it in production
17:40:21 <rutsky> is it in beta because it's almost ready all because it "all or nothing" if we don't release it soon?
17:40:30 <tardyp> The ui is a bit clanky, this is what I'm trying to fix
17:40:54 <tardyp> the ui works, but the automatic updating is not
17:41:01 <djmitche> tardyp: speaking of which -- is crossbar.io a working way to build a multimaster install?
17:41:19 <tardyp> so you need to hit f5 when it starts being clank
17:41:30 <tardyp> djmitche: yes
17:41:48 <tardyp> although I have not yet put it in prod
17:41:56 <tardyp> it is unit tested
17:42:04 <rutsky> tardyp: is this is a bug or new arch limitation? does nine arch allows all new features that were desired?
17:42:20 <tardyp> rutsky: its bug
17:42:27 <djmitche> ok
17:42:29 <tardyp> we have all the features
17:42:52 <tardyp> but they are not working as expected for all the corner cases
17:42:56 <bb-trac> [trac] #2644/enhancement (new) updated by dustin (Now that we have crossbar.io support, no, this is not a 0.9.0 blocker.) http://trac.buildbot.net/ticket/2644
17:42:58 <tardyp> that's the definittion of beta :)
17:44:41 <djmitche> ok, I'm going to wrap up the meeting, but this will be a good conversation to have in teh meeting archives
17:44:42 <djmitche> thanks!!
17:44:48 <rutsky> Is it OK if I'll post on etherpad?
17:44:51 <djmitche> #endmeeting