12:59:36 <zack> #startmeeting
12:59:36 <MeetBot> Meeting started Thu Jul  9 12:59:36 2015 UTC.  The chair is zack. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:59:36 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:59:43 <clemux> hi
12:59:47 <zack> clemux: orestis: jpleau: matthieucan: ping
12:59:48 <orestis> hi
12:59:49 <zack> #topic roll call
12:59:59 <zack> who (else) is here? :)
13:00:21 <zack> matthieucan: jpleau: around?
13:00:49 <zack> not yet, it seems, they'll catch up I guess
13:00:56 <zack> #topic orestis - weekly review
13:00:59 <zack> no, sorry
13:01:03 <zack> #topic next meeting
13:01:15 <zack> next friday, usual time <- good for everyone?
13:01:16 <matthieucan> heya, sorry
13:01:21 <clemux> friday is fine for me
13:01:25 <orestis> yes
13:01:51 <orestis> (i mean friday is ok)
13:01:52 <matthieucan> I'm leaving on holiday on friday, won't be available much for 2 weeks
13:01:57 <matthieucan> wednesday*
13:02:02 <zack> oh, ok
13:02:07 <zack> so no need to change the meeting date
13:02:08 <zack> #agreed next meeting next Friday, usual time (back to usual schedule)
13:02:31 <zack> so it looks like there might be a week with neither me nor matthieucan
13:02:36 <zack> (but it's not next week)
13:02:43 <zack> matthieucan: when will you be back,exactly?
13:03:02 <matthieucan> exactly, at debconf, but I'll have a good internet in august
13:03:12 <zack> I'll be on vac July 27 -> debconf
13:03:13 <matthieucan> so let's say 1st of august, from abroad
13:03:34 <zack> matthieucan: if you can help with the first, say, ~10 days of august, it will helkp
13:03:35 <matthieucan> ok, could be worse!
13:03:39 <matthieucan> sure
13:03:44 <zack> cool
13:03:53 <zack> so, next topic
13:03:58 <zack> #topic orestis - weekly review
13:04:13 <orestis> so i worked on some templates and the online doc
13:04:20 <orestis> PR#25
13:04:35 <zack> and you got feedback from matthieucan, right?
13:04:38 <orestis> yeap
13:04:45 <matthieucan> yes, reviewed and I saw you fixd studd, well done
13:04:49 <matthieucan> stuff*
13:05:00 <zack> is that merge ready then?
13:05:05 <matthieucan> I'll check that, should be good to merge
13:05:08 <matthieucan> zack: almost
13:05:14 <orestis> i have to squash commits and rebase i guess
13:05:35 <matthieucan> yeah
13:05:45 <orestis> and i finished license statistics, but i can't PR atm
13:05:54 <zack> because it depends on PR#22?
13:05:57 <orestis> yeap
13:06:03 <zack> yeah, sorry about that, I suck :)
13:06:08 <matthieucan> whose blocker is the data in testsuite
13:06:20 <zack> fwiw, I'll be taking the week-end off, extended on monday
13:06:27 <zack> I'll _try_ to update the test suite before leaving
13:06:31 <zack> but I'm not sure I can manage
13:06:37 <zack> if someone thinks he can pick it up
13:06:40 <zack> it'd be great
13:06:45 <zack> otherwise it risks slipping into next week
13:07:07 <zack> (it would also be useful *in general* to have someone else that is able to update the db part of the test suite, in fact)
13:07:08 <matthieucan> not sure about my week end yet
13:07:11 <orestis> well i could PR just so you can review the code, but tests will fail and it will contain commits from PR#22
13:07:25 <zack> orestis: sounds like a good idea, yes
13:07:52 <zack> orestis: or, you can send the code via email, whatever you prefer
13:08:08 <orestis> there are a lot of commits there so i prefer PR..
13:08:09 <matthieucan> well, not a big deal if travis fails
13:08:24 <zack> orestis: I'm fine with the PR then; just mention in the comment what is already part of the other PR
13:08:29 <zack> so that we know which commits to look at
13:08:37 <orestis> ok sure
13:08:42 <zack> cool
13:08:49 <zack> anything else, or can we move to planning?
13:09:05 <zack> oh, there was SPDX
13:09:13 <zack> how did your research go?
13:09:18 <orestis> i am working on the spdx now.. i am reading their doc to understand which field are mandatory and i should have an export in the weekend
13:09:49 <zack> awesome
13:10:06 <zack> #topic orestis - next week
13:10:16 <zack> orestis: so, next week ?
13:10:21 <orestis> hehhe!
13:10:25 <zack> :)
13:10:34 <orestis> well one thing is the synopsis for the fancy rendering..
13:10:51 <matthieucan> javascript?
13:10:58 <orestis> and the s.d.n -> copyright link
13:11:03 <matthieucan> or am I lost?
13:11:14 <zack> orestis: I'm not sure what you mean either
13:11:24 <zack> (about the synopsis)
13:11:59 <orestis> we talked about it some weeks ago..
13:12:13 <orestis> for the moment i create a link to the whole synopsis
13:12:44 <orestis> i don't split by or.. and i just point ot opensource.org where i could create links to the license text within the page
13:12:57 <zack> oh, the full text of the license you mean
13:13:04 <zack> not the synopsis (which is a short version of it)
13:13:05 <orestis> yes..
13:13:09 <zack> ok
13:13:25 <zack> so, you already have the "parsing" code to split, that you used for the statistics, right?
13:13:42 <zack> you should use the same to add fine-grained links
13:13:47 <orestis> yes exactly... its not much work
13:14:00 <zack> ok, sounds like a good task then
13:14:19 <orestis> so then there's the link form s.d.n to copyright
13:14:22 <zack> please put it in a well-defined, separate function
13:14:33 <zack> as one day it will probably be replaced by a proper license field parser
13:14:44 <orestis> ok i ll do that..
13:14:54 <zack> orestis: the link sounds like a good task too
13:15:13 <zack> although I can't think of any good name for the link right now
13:15:17 <zack> maybe something like "analyze"
13:15:26 <orestis> besides those two i don't know what to do.. i am not sure what is suggested in the license scanner
13:15:30 <zack> associate to all files whose relative path is "debian/rules"
13:15:46 <zack> orestis: I think on the copyright.d.n front we are good now
13:15:46 <orestis> ok ll think of something
13:15:49 <zack> modulo bugs that we will find
13:15:57 <zack> (I have one in mind, which I'll point you to after the meeting)
13:16:06 <zack> I think you can start exploring patches.d.n
13:16:29 <zack> a good start would be: 1) reviewing the functionalities of the old patch tracker
13:16:36 <zack> and 2) review all existing source package formats
13:16:44 <matthieucan> (well, kudos for c.d.n!)
13:16:55 <zack> (we will probably support only dpkg (3.0) for now, but it would be nice for you to know that other exists)
13:17:02 <zack> matthieucan: orestis: yeah, absolutely, great work :)
13:17:12 <orestis> ok that sounds good!
13:17:17 <orestis> zack: matthieucan :)
13:17:23 <zack> we're good then
13:17:24 <zack> next topic
13:17:27 <zack> #topic clemux - weekly review
13:17:36 <zack> clemux: how are we doing in async-land?
13:17:53 <clemux> my first task was to update the testsuite for testing the async updater
13:18:02 <clemux> however those tests are not *unit* tests at all
13:18:27 <clemux> and quite useless to me as long as I haven't finished implementing all stages
13:18:34 <clemux> (or maybe I missed something)
13:18:39 <zack> so what do they test?
13:18:44 <zack> oh, you mean the existing ones
13:18:48 <clemux> yup
13:18:48 <zack> yes, most of them are not unit
13:18:57 <zack> but rather end-to-end feature tests, for the most part
13:19:02 <clemux> yup
13:19:11 <zack> but it is indeed what we want to preserve, no matter the updater policy
13:19:23 <clemux> yes, of course :)
13:19:27 <zack> if you need more, and specifically unit tests, you can certainly add them :)
13:20:15 <zack> what else?
13:20:16 <clemux> anyway, I managed to run one of those tests without a worker (with CELERY_ALWAYS_EAGER, for running synchronously)
13:20:23 <clemux> but I have up for now and moved on to
13:20:31 <clemux> 2. pass configuration to celery tasks
13:20:53 <clemux> that is done, there is no hard-coded configuration anywhere in the async updater
13:20:54 <zack> (back to the tests just for a sec: what didn't work? anything blocking or just code still in flux?)
13:21:01 <zack> good about the configuration, that's great
13:21:09 <zack> it means it now possibly better than the sync one...
13:21:47 <clemux> zack: well, there was no way to test only the extract new stage
13:21:57 <zack> right, good point
13:22:04 <clemux> so I had a huge number of errors that were not really readable
13:22:14 <zack> I now understand better what you meant with "useless"
13:22:23 <clemux> I need to write unit tests, but that's for next week topic :)
13:22:38 <zack> ok
13:22:41 <zack> what else for this week?
13:23:20 <clemux> one more thing about the removal of hard coded configuration: I'll submit a PR soon with changes to the documentation (celery.txt) about that
13:23:27 <clemux> ok, so next
13:24:13 <clemux> 3. I found out why the file_table was always empty, fs_storage.walk_pkg_files was failing silently because I put a relative path in etc/config.local.ini
13:24:25 <zack> ah, gotcha
13:24:30 <clemux> because it calls os.walk(), which returns an empty list when the directory does not exist
13:24:47 <zack> ok, so the fix is interpolating root_dir then, I guess
13:24:52 <zack> s/then/there/
13:24:57 <zack> good
13:25:12 <clemux> I'd put "root_dir: testdata" or something
13:25:25 <clemux> so after a chdir it wouldn't work
13:25:28 <zack> I see
13:25:46 <clemux> anyway, I think we could add a check for the directory existence, and print an error when that happens
13:25:51 <zack> yeah
13:25:55 <clemux> (maybe I should submit a bug on the BTS?)
13:25:58 <zack> or ensure that root_dir is expanded to abspath
13:26:03 <zack> clemux: please do, yes
13:26:09 <clemux> ack
13:26:12 <zack> making the code more robust is a useful thing to do in general
13:26:57 <zack> what else?
13:27:23 <clemux> so, next task(s), I converted former plugins' add_package and rm_package functions to celery tasks
13:27:56 <zack> nice
13:28:16 <clemux> everything works fine, I have the ctags, checksums, sloccount and metrics DB tables filled by the celery workers
13:28:23 <zack> awesome!
13:28:46 <clemux> there's another PR coming for celery.txt about that
13:28:51 <zack> np
13:28:58 <zack> which stages are missing then?
13:30:05 <clemux> all other stages
13:30:19 <clemux> (other than extract_new)
13:30:48 <zack> (let's see the list later when we pick tasks for next week)
13:30:52 <zack> anything else to report about for this week?
13:31:01 <clemux> that's it, we can move on to next week
13:31:10 <zack> #topic clemux - next week
13:31:23 <zack> ok, what's the next victim^W stage then? :)
13:32:11 <clemux> update_suites and garbage_collector should be the next tasks
13:32:30 <zack> ok, do you think they can both go in next week?
13:32:34 <clemux> yes
13:32:45 <zack> sounds good to me
13:32:48 <clemux> however:
13:33:01 <clemux> I think the priority is to write tests for what I've done
13:33:16 <clemux> and preparing the testing of the gc and update_suites stage
13:33:21 <zack> no objection
13:33:33 <zack> you think at actual unit tests for each stage, is that it?
13:33:37 <clemux> yes
13:33:48 <zack> that would be nice
13:34:01 <zack> if they work well, we can probably also get rid of the huge db test we have right now, which is hard to maintain
13:34:22 <zack> in fact, if you've a stable interface, we can even thing at merging them into the _current_ master
13:34:25 <zack> but that's up to you
13:34:33 <zack> if it gets too much in your way, never mind
13:34:48 <clemux> mhh
13:34:58 <clemux> I don't think unit tests for the async updater could be used by the sync updater
13:35:17 <zack> depdens on which interface you target
13:35:28 <zack> but sure, if you want to target the async interface never mind
13:35:41 <zack> we will just consider the current tests "legacy code", until we switch to async
13:35:48 <zack> (for the updated part, of course)
13:35:51 <clemux> ok
13:35:58 <clemux> I'll look into that and will let you know
13:36:03 <zack> ok, cool
13:36:12 <zack> anything else or can we move to misc? (I have 1 misc topic)
13:36:25 <clemux> so that makes 3 "big" (I'll probably have to split them up): 1. tests 2. update suites 3. garbage collector
13:36:32 <clemux> "big" tasks*
13:36:35 <zack> *nod*
13:36:42 <clemux> that's it for this topic :)
13:36:45 <zack> and, as usual, feel free to split as you see fit
13:36:55 <zack> #topic misc
13:37:00 <zack> my misc topic:
13:37:12 <zack> the "done" list was starting to get crowded, for various reasons
13:37:23 <zack> so I've added a "need review" list in between "done" and "merged"
13:37:29 <zack> ACKs/NACKs ?
13:37:38 <clemux> ack, seems like a good idea
13:37:49 <orestis> so in done we add things we did not PR yet?
13:37:57 <zack> for instance, yes
13:38:02 <matthieucan> looks good yes
13:38:12 <orestis> ok works!
13:38:21 <zack> and stuff under "need review" should have a pointer to where the stuff to be reviewed is ("PR#" in the title is enough)
13:38:26 <zack> cool
13:38:34 <zack> does anyone else have a misc topic?
13:38:41 <orestis> nop
13:38:52 <clemux> zack: not sure how I should handle my "need review" tasks
13:39:05 <zack> right
13:39:08 <matthieucan> just a random question: did any of you blog about GSoC?
13:39:25 <zack> clemux: (I'll get back to that in a minute)
13:39:34 <zack> matthieucan: not me, ENOWRITINGTIME :/
13:39:46 <zack> it is not "mandatory" for students this year, is it?
13:39:55 <clemux> it isn't
13:39:56 <orestis> matthieucan: kind of... http://oioannou.com/2015/blog/gsoc-updates/
13:40:00 <zack> matthieucan: of course, if you'd like to, please go ahead :)
13:40:05 <matthieucan> zack: nope, I don't think so, was just curious
13:40:15 <matthieucan> zack: yep I will probably
13:40:18 <clemux> planned to, did not find the energy; I probably blog about the async updater once it's finished
13:40:26 <matthieucan> clemux: great!
13:40:35 <zack> orestis: is your blog on planet.debian.org?
13:40:39 <matthieucan> orestis: thanks, I'll chek that
13:40:46 <orestis> i don't think so
13:40:49 <clemux> using my weekly reports and celery.txt as a starting point
13:40:51 <zack> it should! :)
13:41:14 <orestis> how should i do that?
13:41:15 <zack> I think olasd might've called for students to request planet.d.o addition for their blogs
13:41:25 <zack> orestis: check if olasd did, and if so follow the instructions
13:41:30 <zack> if he didn't, let me know and I can do that
13:41:41 <orestis> zack: yes i answered on that email.. don't know if i have to do something else
13:41:46 <orestis> i ll check again
13:41:59 <zack> then we will just blame all together olasd *g*
13:42:05 <orestis> !!
13:42:25 <zack> just kidding, we all love olasd
13:42:32 <zack> just nag him gently, otherwise I can do that
13:42:41 <zack> clemux: regarding review of async
13:42:41 <matthieucan> (another notification for olasd)
13:42:54 <zack> (lotsa notifications for olasd !!!)
13:43:01 <matthieucan> :D
13:43:06 <zack> clemux: we do _not_ want a huge code drop in the end
13:43:17 <zack> but up to now it seems to me that the code was still in flux
13:43:26 <zack> so my hope is that, when the code is realtively stable,
13:43:31 <zack> you can go back and prepare separate commits
13:43:37 <zack> with git add -p or equivalent
13:43:46 <zack> and I'll review individual commits
13:43:49 <zack> feasible?
13:44:08 <clemux> yup, I had already planned on rewriting the history of my branch
13:44:16 <zack> cool, we're on the same line then
13:44:26 <zack> it's then up to you to judge when you feel like it's the right moment to do that
13:44:41 <zack> I guess it will be as soon as you feel the design decisions are now ok
13:44:41 <clemux> having unit tests seems like a good milestone
13:44:46 <zack> and you won't need to throw away everything later on
13:44:57 <zack> (then, of course, sh*t happens, so if you we'll have to, we will)
13:45:13 <clemux> got it!
13:45:17 <zack> ok
13:45:20 <zack> anything else to discuss?
13:45:32 <clemux> nope
13:45:38 <matthieucan> fine with me
13:45:39 <orestis> nop
13:45:42 <zack> ah, yes, LET'S ALL HUG olasd
13:45:52 * orestis hugs olasd
13:45:53 <matthieucan> olasd: hug ;)
13:46:10 <zack> #agreed let's all hug olasd
13:46:15 <zack> #endmeeting