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