13:00:44 <zack> #startmeeting
13:00:44 <MeetBot> Meeting started Thu Jun  4 13:00:44 2015 UTC.  The chair is zack. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:44 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:00:51 <zack> #topic roll call
13:00:53 <zack> who is here?
13:01:12 <orestis> lo
13:01:26 <matthieucan> yes
13:01:31 <matthieucan> hi everybody
13:01:40 <jpleau> hi I'm here
13:01:40 <zack> jpleau: clemux: ping
13:01:43 <matthieucan> jpleau: thanks for the info, I think we should use it then ;)
13:01:56 <clemux> zack: pong
13:02:00 <jpleau> zack: hi
13:02:01 <zack> awesome,veryone is here
13:02:09 <zack> #topic next meeting
13:02:15 <zack> next week, but on Friday, same time?
13:02:25 <orestis> yep
13:02:38 <matthieucan> ok for me
13:02:41 <jpleau> yes
13:02:42 <zack> #agreed next meeting next week, but on Friday (back to usual day), same time
13:03:06 <zack> who wants to go first for the weekly review?
13:03:20 <zack> should we standardize on last week schedule? (orestis first, clemux then)
13:03:57 <zack> (yes, let's do that, will be one fewer question every week ;))
13:04:00 <orestis> last week was the other way around, but any works :p
13:04:05 <clemux> ok for me
13:04:12 <zack> ah, bad memory
13:04:20 <zack> but whatever, it's arbitrary
13:04:25 <zack> #topic weekly review - orestis
13:04:35 <zack> orestis: stage is yours
13:05:00 <orestis> so jpleau and matthieucan started review my last work
13:05:09 <matthieucan> yes
13:05:26 <zack> "my work" is vague
13:05:35 <zack> let's stick to the items on trello
13:05:36 <orestis> on the trello board i have some things we can move to reviewed such as browse d/copyright since is merged
13:05:52 <zack> cool, please do that
13:05:54 <matthieucan> great, let's move that
13:05:59 <zack> matthieucan: is it deployed anywhere?
13:06:08 <matthieucan> zack: nope
13:06:17 <matthieucan> I didn't work on sourcesdev.d.n
13:06:21 <zack> matthieucan: can you deploy it on sourcesdev.d.n, or should I?
13:06:25 <matthieucan> I have no idea what's left to be done
13:06:27 <matthieucan> like apache, etc
13:06:36 <zack> nothing, it is up and running already
13:06:47 <matthieucan> oh, so git pull?
13:06:48 <zack> it should be just a "git pull"
13:06:55 <matthieucan> alright
13:06:56 <orestis> yeap ok.. so the PR#6 covers text dump of non machine readable, the use of python-debian and some fancy rendering..
13:07:02 <matthieucan> I can do it tonight, no ssh key here
13:07:04 <zack> matthieucan: but _not_ on /srv/debsources
13:07:11 <zack> in the other dir, dedicated to sourcesdev.d.n
13:07:15 <matthieucan> zack: yes, sure
13:07:24 <zack> ok, I'll let you do that, let me know if you find issues
13:07:30 <matthieucan> ack
13:07:39 <zack> orestis: ok
13:07:44 <zack> and there the review is still pending, right?
13:07:51 <orestis> oh and i refactoed the test_webapp
13:08:59 <zack> folks?
13:09:17 <orestis> i already got some feedback from matthieucan and jpleau but am waiting for more :)
13:09:26 <zack> ok
13:09:36 <zack> so: browse -> move to reviewed
13:09:42 <zack> while text dump + refactor -> in review
13:09:45 <zack> correct?
13:09:59 <matthieucan> orestis: yes I will comment later on your last commits, didn't have time yet
13:10:03 <orestis> yes
13:10:08 <zack> awesome
13:10:09 <jpleau> I only tested the functionality (from browser), haven't looked at code yet !
13:10:20 <matthieucan> exact opposite for me ;)
13:10:29 <zack> what a complementary team! ;)
13:10:47 <matthieucan> indeed!
13:10:48 <zack> orestis: next is use python-debian to parse; what's up with that?
13:11:02 <orestis> done.. in the PR as wlel
13:11:05 <orestis> well*
13:11:12 <zack> same PR?
13:11:31 <orestis> yes
13:11:44 <zack> orestis: can you maybe edit the title of all those cards, to include the PR number?
13:11:51 <zack> this way is easy to know where to look for the code
13:11:57 <matthieucan> good idea
13:12:14 <zack> matthieucan: jpleau: FWIW, I've been super busy this week, but it'll look better starting next week
13:12:17 <orestis> yes sure.. and rendering d/copyright files is 'done'.. meaning i amnot sure what else i can dto with that before feedback
13:12:22 <zack> so feel free to ping me if you need help
13:12:46 <zack> orestis: ok, then please move that to done as well, with the appropriate PR in the title
13:13:03 <matthieucan> zack: sure :)
13:13:06 <zack> #topic next week - orestis
13:13:14 <zack> orestis: what do you want to pick for next week?
13:13:46 <orestis> show license of individual files, license api
13:14:13 <zack> ok
13:14:26 <orestis> license api file by file is what? i wasn't sure about that
13:14:29 <zack> right
13:14:32 <zack> so there are 2 kinds of API
13:14:49 <zack> one is with the granularity of: "here is one file; tell me its license (or other copyright related stuff)"
13:15:08 <zack> another is "here are *many* files; tell me their copyright-related info"
13:15:28 <zack> in both cases the files can be specified in various ways, e.g., by sha256 or package/version/path
13:15:52 <zack> the point is that if you don't have the batch API; the only thing one could do to, say, analyze a bunch of packages; is hammering the file-by-file API, which is not nice
13:16:00 <matthieucan> sha256? what about 2 similar files with different licenses?
13:16:12 <zack> you mean _identical_ ?
13:16:21 <matthieucan> yes
13:16:24 <zack> that can happen!
13:16:31 <zack> license information are by no mean 100% correct
13:16:42 <zack> and it might even happen that the same file have different licenses in different context
13:16:50 <zack> (e.g. implicit upgrade from GPL2 to GPL3)
13:17:00 <zack> dealing with all this uncertainty right is part of the difficulty here
13:17:06 <zack> but to get back to orestis tasks
13:17:16 <zack> the main difficulty here will be designing the API right
13:17:17 <orestis> so this would only be api specific?
13:17:28 <zack> orestis: what do you mean?
13:18:23 <orestis> showing individual license of files corresponds to api file by file?
13:18:27 <zack> (in the mantime, what I wanted to say is: do not start with implementing the API right ahead; first step will be to design it, e.g. on a .txt file, and submit it to us for review)
13:18:33 <zack> (I'll try to be quick in reviewing it)
13:18:41 <zack> orestis: right, the above concerns would also apply to displaying
13:18:46 <zack> briefly:
13:19:01 <zack> - if we ask to show the license of a given file in a given package/version, there will be only one license; the one declared in d/copyright
13:19:15 <zack> - if we ask to show the license of a file specified by its checksum, multiple license might show up
13:19:28 <zack> so, one thing at a time
13:19:35 <zack> designing the UI for this might very well be a separate task
13:19:58 <orestis> so should i start the UI or the api?
13:20:10 <zack> orestis: I'd say start with the design of the API
13:20:18 <zack> as it'd help understanding better the underlying data model
13:20:25 <zack> YMMV
13:20:36 <zack> ok?
13:20:50 <zack> (and feel free to ping me explicitly about this any time)
13:21:37 <orestis> ok thats fine.. so first i submit a proposal for api and then start with file by file with package/version/path and then with checksum.
13:21:46 <orestis> my suggestion ^^
13:21:49 <zack> ack
13:21:50 <matthieucan> sounds good
13:21:59 <zack> although probably "proposal for api" will actually be 2 tasks:
13:22:04 <zack> one for the file-by-file, one for the batch
13:22:12 * zack loves separation of concerns
13:22:24 <zack> (and dijkstra)
13:22:31 <jpleau> ++dijkstra
13:22:39 <orestis> haha!
13:22:42 <zack> orestis: so, deal? :)
13:22:46 <orestis> ok i am going to update my board!
13:22:53 <zack> awesome
13:23:19 <zack> can we move to clemux, or did we forget anything?
13:23:49 <orestis> i have nothing to add :)
13:23:53 <zack> cool
13:23:59 <zack> #topic weekly review - clemux
13:24:10 * zack throws the mic at clemux
13:24:26 <clemux> ok, so for the task "figure out of to send source packages to tasks", I decided with zack to build a dict with the needed info and send only that to tasks
13:24:47 <clemux> this solved the problem with pickling SourcePackage
13:24:50 <zack> *nod*
13:25:03 <zack> is that implemented?
13:25:33 <clemux> yes, so the next task: I wrote a simple a skeleton of tasks for the updater
13:25:58 <clemux> it does not do much except printing each package in the extract_new and garbage_collector stages
13:26:07 <zack> ok
13:26:08 <clemux> and uses the dict'ed source_package
13:26:13 <zack> how can we review that?
13:26:27 <zack> I guess the code is not merge ready yet (it will take a while before getting there, I guess)
13:26:33 <zack> but it'd be nice to be able to comment on the design
13:26:45 <clemux> it's here https://github.com/clemux/debsources/blob/async/debsources/new_updater/tasks.py and https://github.com/clemux/debsources/blob/async/bin/debsources-async-update
13:27:07 <clemux> this is really simple, but will allow me to experiment stuff when writing the complete specifications for the updater protocol
13:27:10 <zack> I'm trying to think about how to best do the review work-flow for that
13:27:19 <clemux> yeah, I'm not sure either
13:27:21 <zack> clemux: can you mail all of us with a review request and the above two URLs?
13:27:26 <zack> we can do by email
13:27:29 <clemux> got it
13:27:40 <zack> but having an initiating email will help me not forgetting about it :)
13:27:46 <zack> (even though it cannot be a PR yet)
13:27:58 <clemux> next task, as a subtask of writing the specifications, I'm making a graph of dependencies of tasks
13:28:15 <zack> that's good, yes
13:28:18 <clemux> to determine which tasks can be run in parallel, and which must wait for other to finish
13:28:27 <zack> are dependencies handled natively by celery, or is some gymnastic needed?
13:28:40 <clemux> celery has several ways to design workflows
13:29:21 <clemux> for simple cases we can give a callback to a task
13:29:49 <zack> so I guess you're planning to have, say, extract package as a dependency for most other tasks
13:29:58 <clemux> if the task has subtaks, the callback will be executed once all subtasks have been executed
13:30:42 <zack> actually, now that I think of it: all this design work should correspond to .txt files under doc/ ; and we can have PR for them, no?
13:31:02 <clemux> yes we can, that'd be a good way of reviewing the design work
13:31:05 <clemux> indeed
13:31:08 <zack> they'd also provice nice deliverables, I think
13:31:32 <zack> clemux: so, can you do that (for both past and future design work), and submit them as PR?
13:31:40 <clemux> I'll write something about that after the meeting and submit a PR
13:31:47 <zack> sounds good
13:31:56 <clemux> well, I can do a PR immediately for what I've already written
13:32:08 <zack> do it after the meeting
13:32:09 <clemux> and add links/summary on the related celery documentation
13:32:14 <zack> (or when you feel it's ready)
13:32:19 <zack> we will not review it on the fly anyhow :)
13:32:27 <clemux> and later I'll do a PR for the dependencies graph
13:32:34 <zack> sure, they can be separate
13:33:00 <zack> can we move to next week planning?
13:33:07 <clemux> one moment
13:33:14 <zack> yup
13:34:22 <clemux> when thinking about the specs, I run into one problem: currently a hood failure will trigger a session rollback
13:34:43 <zack> currently = sync updater?
13:34:46 <clemux> yes
13:34:57 <zack> yes, so, I wanted to talk about that too
13:35:01 <zack> I know what nice properties we want
13:35:15 <zack> can we do that after the end of the meeting or is it a requirement for planning next week?
13:35:22 <clemux> not sure how to handle that in a distributed architecture (that would be a new task, so maybe we could have moved to the next week planning)
13:35:30 <zack> oh, I see
13:35:33 <zack> so, briefly:
13:35:46 <zack> when something fails, we want it to be retried at the next update
13:35:55 <zack> or until someone put it in a permanent failure state or something such
13:36:18 <zack> how to do that properly should definitely be something you should consider for the async arch
13:36:27 <zack> regression from that point of view would be blockers
13:36:30 <clemux> yup
13:36:45 <clemux> we can discuss that more thorougly after the meeting I guess
13:36:48 <zack> yes, sure
13:36:53 <zack> but please add a relevant task
13:37:07 <zack> having a detailed description of the failure module is totally desirable
13:37:12 <clemux> yes
13:37:25 <zack> cool
13:37:30 <zack> anything else from past week?
13:37:41 <clemux> I think that's all
13:37:46 <zack> #topic next week - clemux
13:38:10 <zack> (aside orestis: please assign to yourself the item you've picked)
13:38:15 <zack> clemux: what do you want to pick for next week?
13:38:58 <clemux> so, I'll push the dependencies graph today
13:39:12 <clemux> and then work on 1. define the the failure mode for hooks
13:39:38 <clemux> 2. write the specifications for the protocol (I hope to do that by saturday, since I've spent a lot of time thinking about it already)
13:40:14 <zack> ok
13:40:19 <clemux> 3. implement the "extract new" stage (without hooks) (should be doable over the WE)
13:40:33 <zack> this week-end I'll be at home grading exams /o\, so I can give feedback to change a bit of task if needed ;)
13:40:49 <clemux> 4. implement the "update suites" stage
13:41:03 <clemux> 5. implement the garbage collector stage
13:41:13 <clemux> 6. implement the update metadata stage
13:41:37 <clemux> (these coding tasks should be easy once the protocol is specified)
13:41:48 <zack> LGTM
13:42:16 <clemux> I just hope I don't run into new problems :)
13:42:31 <zack> by murphy (and sw.eng.) law, it will happen :-P
13:42:40 <clemux> indeed
13:42:55 <clemux> well, I can plan and hope, and we'll see
13:43:01 <zack> ok, let's move on:
13:43:05 <zack> #topic misc
13:43:13 <zack> anything else to discuss?
13:43:32 <zack> maybe, in particular: the work-flow looks good to everyone now?
13:43:44 <orestis> i forgot to say about the spdx research.. can i move that back as i didn't do anything on that and i prefer to do it when i ll do the export
13:43:49 <matthieucan> for me it does
13:44:02 <matthieucan> orestis: yes sure
13:44:07 <zack> orestis: oh yes, feel free to move it back either to this week (if you want to pick this up this week), or to backlog (if not)
13:44:13 <jpleau> works of me I'll be presnet a bit more upcoming weeks
13:44:26 <clemux> the workflow is now fine for me, with the "PRing celery.txt idea"
13:44:34 <zack> jpleau: thanks!
13:44:58 <zack> jpleau: if you're interested, I guess we can look into adding you as co-co-mentor for gsoc
13:45:07 <zack> although it might be late for the google web UI thingie
13:45:47 <zack> anything else?
13:45:52 <matthieucan> zack: I actually registered on that a few days ago, not sure how this will end up though
13:46:06 <zack> oh, I see
13:46:15 <zack> check with olasd, he is the melange-evil-god
13:46:36 <matthieucan> alright! ping olasd! :)
13:46:51 <olasd> nah, you can add mentors until the last day
13:47:02 <jpleau> (after meeting, can we take 2 minutes to check if we should swap the js code to jquery?)
13:47:09 <olasd> it might still be time to get a t-shirt
13:47:19 <matthieucan> olasd: are you in charge of validating them? I think I'm still pending
13:47:32 <matthieucan> yay tshirt :D
13:47:39 <zack> ok, let's close the meeting, and continue with what's left out-of-band
13:47:42 <zack> #endmeeting