16:32:31 <djmitche> #startmeeting weekly
16:32:31 <bb-supy> Meeting started Tue Jan  5 16:32: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:32:31 <bb-supy> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:32:31 <bb-supy> The meeting name has been set to 'weekly'
16:33:08 <djmitche> #topic Introduction
16:33:19 <djmitche> https://titanpad.com/buildbot-agenda
16:33:20 <infobob> http://paste.pound-python.org/show/rcWtUzBxooeYuqMbtcTh/ (repasted for djmitche)
16:33:34 <djmitche> Happy new year :)
16:33:40 <djmitche> #topic MOSS / Bounties
16:33:43 <verm__> happy new year!
16:33:53 <rutsky> happy New Year! :)
16:34:13 <rutsky> bdbaddog1, you here?
16:34:20 <djmitche> #info rutsky is working hard on the renaming project
16:34:59 <djmitche> The "paperwork" is running a bit behind, both around potentially splitting the bounty and around getting a contract set with SFC and Mozilla
16:35:08 <djmitche> partly because of the holiday, i think
16:35:27 <djmitche> rutsky: anything you'd like to bring up?
16:35:48 <rutsky> I've made more tests and received feedback from djmitche and tardyp --- thanks!
16:36:15 <rutsky> yes, tardyp mentioned that new and old API probably should be tested at the same time
16:36:37 <bdbaddog1> here now..
16:37:00 <rutsky> initially I though not double main test suite to run it against old and new API at the same time
16:37:53 <rutsky> my idea was to test carefully that fallback from old API to new API works and test only new API in main test suites
16:38:09 <rutsky> of course fallback will be thoroughly tested
16:39:11 <djmitche> that's what we've typically done for compatibility
16:39:29 <rutsky> what do you think about it? Should main Buildbot test suite be run twice testing using old API names and using new API names? Or test intensively only new API and separately test fallback from old API  ot new API?
16:39:49 <djmitche> separately test
16:40:24 <rutsky> ok, that's much simpler
16:40:28 <djmitche> yeah :)
16:41:18 <rutsky> another question about fallback configuration --- tardyp noticed, that fallback switch (c['useSlaveNames'] = True or smth like that) will most probably be triggered after bunch of import and maybe even class instantiations
16:41:56 <rutsky> so if at the end of configuration old API will be set to, e.g. warning, then deprecation warnings should be displayed, otherwise --- not
16:42:05 <rutsky> how to achieve this?
16:42:26 <rutsky> one solution is to buffer all "slave" deprecation warning till end of configuration load
16:42:57 <rutsky> and dump them (if needed) when fallback settings will be established (e.g. after loading master.cfg)
16:43:07 <djmitche> that seems like a lot of work
16:43:17 <djmitche> you could put that configuration in buildbot.tac
16:43:34 <rutsky> another solution would be to move such switch either outside, or do some regexp-parsing of master.cfg
16:43:57 <djmitche> regexp-- :(
16:44:20 <verm__> +1 on regexp--
16:44:26 <djmitche> bdbaddog1: do you still want to try to split this bounty?
16:44:28 <rutsky> regexps actually be implemented pretty accurately in a way as "# encoding: utf-8" is parsed in Python 2
16:44:50 <djmitche> sure, but if your master.cfg is `from myconfig import BuildbotConfig as c`, then it won't work
16:44:55 <djmitche> that's not uncommon
16:45:20 <bdbaddog1> djmitche: yes. I'm not sure how much time I have this week though.
16:45:44 <bdbaddog1> +1 buildbot.tac
16:45:46 <djmitche> ok -- you should probably at least work out the parameters of that split with rutsky this week
16:45:55 <bdbaddog1> O.k. will do.
16:46:12 <djmitche> #info Bill still interested in splitting the renaming project with Vladimir
16:47:08 <rutsky> bdbaddog1, I would like to do most of work this week, so it's better if we be in contact for discussion
16:47:55 <bdbaddog1> rutsky: o.k.
16:47:59 <djmitche> #info Problem-solving around how to issue warnings while still parsing the config
16:48:21 <rutsky> bdbaddog1, I checked is worker would be a good split point and looks like is not --- it doesn't require new protocol and without it it's almost doesn't require any technical changes
16:49:14 <djmitche> let's move on
16:49:39 <rutsky> how you propose to set fallback in buildbot.tac? smth like m.slaveFallback = True?
16:49:42 <bdbaddog1> o.k. I'll catch rutsky after meeting if that's ok?
16:49:51 <djmitche> #topic CLI tool to talk to API
16:49:58 <djmitche> thanks guys :)
16:50:08 <verm__> ran into a problem with that.. need to talk with tardyp
16:50:15 <djmitche> what's up?
16:50:26 <rutsky> bdbaddog1, sure, I think others will be around here if the will be needed
16:50:31 <djmitche> #info Amar working on a command-line tool to interact with the Data API
16:50:32 <verm__> i figured out how to do it with just websocket and asyncio so python 3.4?+ there will be no deps
16:50:46 <verm__> well, when i subscribe to watch events i get none
16:51:14 <verm__> i connect to wss://buildbot.ntpsec.org/ws then send {"cmd":"startConsuming","path":"builds/*/*","_id":1}
16:51:18 <verm__> i get nothing
16:51:32 <verm__> i must be doing something wrong but as far as i know this is all the webclient does to get events
16:51:36 <djmitche> hm, that's no good
16:51:37 <djmitche> yeah
16:51:56 <djmitche> might be good to put that in a bug - even if it's a simple solution, then it will be discoverable
16:52:07 <verm__> i'm going to finish the minimal layout to get info like builders / slave info etc then put it into a repo
16:52:13 <djmitche> #info Having trouble subscribing to events via websocket
16:52:13 <verm__> so others can help debug this
16:52:18 <djmitche> cool
16:52:35 <verm__> hmm yeah a bug is a good idea i'll send him a quick note to see if it's something simple i was busy over the holidays..
16:52:42 <verm__> back on it as of yesterday though!
16:52:48 <djmitche> cool, great!
16:52:50 <verm__> hopefully i'll have something next week depending on what'sa wrong
16:52:52 <djmitche> I'll leave it on the agenda then
16:53:09 <djmitche> #info We'll revisit this at the next meeting
16:53:16 <djmitche> #topic Development Update
16:53:42 <djmitche> Most of the new PRs this week were rutsky's, regarding renaming and compatibility
16:54:02 <djmitche> #info Most of the new PRs this week were rutsky's, regarding renaming and compatibility
16:54:08 <verm__> how did the bug push go? i see the email go out
16:54:33 <djmitche> #info Bug push on nine helped -- 26 remaining 0.9.0 bugs
16:54:37 <djmitche> down from 31
16:55:13 <verm__> oh..
16:55:31 <djmitche> #info Pierre filed several bugs (3397 through 3400) about migrating to the new bd_base (UI based on material design)
16:56:09 <djmitche> I updated the mergeable-pull-requests script so it runs on the trac jail, and goes to devel@
16:56:35 <djmitche> Anything else?
16:56:39 <djmitche> sa2ajj: we haven't heard from you in a while :(
16:56:46 <verm__> what's the plan for the tickets?
16:56:51 <verm__> just keep on working then release .9?
16:57:18 <djmitche> it's sort of a non-plan, but yes, that's it
16:57:34 <verm__> ah, so the 'push all tickets forward and release' plan fizzled out?
16:58:26 <bdbaddog1> Should I try nine on my current projects then? I haven't had a chance yet.
16:58:44 <verm__> i've been using nine for a while on various projects both public and private
16:58:45 <verm__> it works great
16:58:58 <verm__> there are some nits but none that stop it from working..
16:59:01 <bdbaddog1> o.k. I'll try switching buildbot.scons.org then.
16:59:15 <djmitche> bdbaddog1: yaeh, that'd be great
16:59:23 <djmitche> verm__: well, we pushed as many tickets forward as we could
16:59:46 <verm__> ok, if all 28 are ones that must be done for .9 then...
16:59:46 <djmitche> the rest are things it would be irresponsible to release without addressing
16:59:52 <djmitche> (mostly "this doesn't work" documentation)
16:59:57 <djmitche> and that sort of thing
17:00:00 <rutsky> shouldn't worker "rename" project be included in 0.9.0 milestone?
17:00:21 <rutsky> I think we will be able to complete most of it in a few weeks
17:00:22 <djmitche> rutsky: yes
17:00:27 <verm__> the rename is going to be in .9?
17:00:32 <rutsky> at least my part with general API renaming
17:00:45 <rutsky> .9 is a good place for it --- API will be changed anyway
17:00:48 <djmitche> verm__: yes, it's a good time for the break
17:01:28 <verm__> makes sense.. do we want to make any rules or put a notice when creating a new ticket for .9?  eg if it is not critical put it on .9+?
17:01:49 <verm__> or maybe a note to the devel list would be better
17:02:39 <tardyp> sorry I'm late
17:02:56 <djmitche> verm__: the default is no milestone, so things getting put in that milestone need to be there
17:03:27 <verm__> i know, was just trying to think of a way to avoid 'chasing the release' scenerio where new bugs keep on getting added
17:03:45 <djmitche> I don't think that's what's happening here
17:03:55 <djmitche> so much as it's just slow going
17:04:14 <rutsky> I have another topic really bothering me --- spam filter on Trac. I'm not able to do almost anything --- it's always says that either my submission is a spam, or that my IP is blacklisted. Is there somethink like white list where you can put me?
17:04:30 <verm__> rutsky: i'm working on that now
17:04:43 <verm__> something changed in trac when it was upgraded
17:04:51 <verm__> so the plugin broke.. not sure what happened
17:05:29 <verm__> the spam filters are on really high to keep spammers away, i wrote a plugin to let users in the 'NOTSPAM' group bypass everything and have all their submissions added as ham
17:05:33 <verm__> that plugin is broken
17:05:48 <djmitche> ugh, sorry :(
17:06:23 <djmitche> #info Nine release is largely delayed by a low rate of work on the blocking bugs, rather than an accumulation of new bugs
17:06:31 <djmitche> #topic Spam filtering on Trac
17:06:42 <rutsky> hm... If I'm remembering correctly I was in some strange situation regarding groups, I think I was not in NOTSPAM group for some reason...
17:06:46 <djmitche> #info The "NOTSPAM" plugin, which lets us whitelist known non-spammers, is broken
17:07:10 <verm__> rutsky: you're not? hmm let me check
17:07:33 <rutsky> or I was in both NOTSPAM and some other group, just to test something...
17:07:50 <verm__> you're in the notspam group
17:07:55 <djmitche> rutsky 	= NOTSPAM, SPAM_ADMIN
17:08:05 <verm__> if you are in 'SPAM' then you are a spammer
17:09:04 <djmitche> #info Amar is working on this right now
17:10:02 <rutsky> ok, minimum karma is 8, and my last submission get karma 5, mostly due to "FSpamList (-15): FSpamList says this is spam (rutsky [100])"
17:10:22 <verm__> the problem is sometimes people work on things that trigger certain spam lists
17:10:25 <rutsky> and I don't see boost on 100 karma points, that were before with NOSPAM group...
17:10:30 <verm__> checkers, too
17:10:31 <verm__> yeah
17:10:36 <verm__> seems someone updated trac
17:10:38 <verm__> lots of things broke
17:10:41 <verm__> or upgraded a bunch of things
17:11:03 <djmitche> http://fspamlist.com/?c=profile&num=1315712 :(
17:11:27 <verm__> that would do it
17:11:32 <rutsky> oh, so I'm a spamer :)
17:11:45 <verm__> it's only been reported once just get it removed
17:12:35 <rutsky> should I register on fspamlist.com and claim that I'm not spamer?
17:12:42 <rutsky> or it doesn't work in this way?
17:13:51 <verm__> yeah you post here: http://www.temerc.com/forums/viewforum.php?f=72&sid=9d961fb79827daea1ce40fdcd1f5e9d7
17:14:11 <verm__> you need to register to the forum
17:14:19 <verm__> there's a list, too you could tyry that
17:14:20 <verm__> one sec
17:14:41 <verm__> fspamlist@it-mate.co.uk
17:14:54 <djmitche> still, the NOTSPAM flag should override that
17:15:05 <verm__> yep, trying to fix it now
17:15:05 <rutsky> djmitche, yep
17:15:20 <djmitche> skelly: ^^ would your upgrades have upgraded Trac too?  I thought Trac was not installed as a FreeBSD package
17:15:42 <rutsky> verm__, ok, I'll try to remove myself from spam-list a bit later
17:16:13 <verm__> djmitche: it's not but sometimes the deps can break trac or their plugins. :(
17:17:15 <djmitche> ok - I know Python got updated per the sysadmins list
17:18:20 <rutsky> I have few more questions about MOSS: 1) How deeply Trac should be updated? I think Wiki, milestones and other "long living" content should be updated, but *not* old tickets, they descriptions and comments.
17:18:58 <djmitche> I agree strongly with that :)
17:19:11 <rutsky> 2) Is there an agreement that new master/worker protocol is required? I've done POC test for that and pretty sure proved that point.
17:19:18 <rutsky> *is NOT required
17:19:22 <djmitche> anything that's historical will stay as-is, while anything users expect to be up-to-date should be fixed
17:19:28 <rutsky> *new master/worker protocol is NOT required
17:19:34 <djmitche> I agree it's not required
17:19:38 <djmitche> thanks to your good research
17:19:52 * djmitche ends meeting but we can keep talking about this
17:19:54 <djmitche> #endmeeting