11:59:55 <zack> #startmeeting
11:59:55 <MeetBot> Meeting started Fri Dec 19 11:59:55 2014 UTC.  The chair is zack. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:59:55 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:59:59 <zack> #chair matthieucan
11:59:59 <MeetBot> Current chairs: matthieucan zack
12:00:10 <zack> #topic holiday planning
12:00:20 <zack> so, sophiejjj will be on vacation/traveling next week, right?
12:00:25 <sophiejjj> yes.
12:00:30 <zack> when will you be back?
12:00:36 <sophiejjj> 27
12:00:41 <matthieucan> I won't be able to hang out here the next 2 fridays
12:00:43 <sophiejjj> afternoon, flight to HK
12:01:00 <zack> ok, I'll be traveling too dec 23-30, but I'll be connected/emailing regularly
12:01:15 <zack> so, I propose that during this period we do not add anything new, and just finalize what's pending
12:01:19 <zack> sophiejjj: good for you?
12:01:27 <sophiejjj> good for me.
12:01:39 <sophiejjj> there are some pending tasks unmerged.
12:01:50 <zack> as the next meeting will in theory be during vacation, how about postponing it to mon 29, usual time?
12:01:56 <zack> (it will be good for me)
12:02:02 <sophiejjj> good for me too
12:02:15 <zack> #agreed next meeting decembr 29th, usual time
12:02:32 <matthieucan> I won't be here, I'll be traveling abroad this day so no internet
12:02:49 <zack> matthieucan: no problem, I can cover up
12:02:54 <zack> when will you be away, exactly?
12:03:41 <zack> matthieucan: ^^^
12:03:46 <matthieucan> 23/12 - 03-01
12:04:01 <matthieucan> 06-01*
12:04:03 <matthieucan> sorry
12:04:10 <zack> ok
12:04:20 <zack> #info matthieucan will be away 23/12 - 03/01
12:04:21 <matthieucan> I'll have more or less internet access, depending on the days
12:04:37 <zack> #topic debsources - weekly review
12:04:46 <zack> sophiejjj: shall we go through the items for this week one by one?
12:04:51 <sophiejjj> sure.
12:04:56 <zack> 1) test coverage
12:05:10 <zack> I gave you feedback by the 1st patch, but haven't heard back afterwards
12:05:15 <zack> what's the status there?
12:05:23 <sophiejjj> I sent you an email back
12:05:30 <sophiejjj> but with no reply.
12:05:38 <zack> uh?
12:05:46 <zack> I haven't seen that
12:05:59 <sophiejjj> oh. ...
12:06:10 <sophiejjj> I didn't notice your reply yesterday.
12:06:12 <zack> that thread terminates with a mail of mine, as of yesterday
12:06:14 <zack> ah :)
12:06:25 <matthieucan> this thread: [PATCH] increase test coverage on debsources.app.app_factory ?
12:06:40 <sophiejjj> yes.
12:06:44 <zack> matthieucan: yep, btw given it's your code, comments will be appreciated
12:06:49 <sophiejjj> so you think that test is not meaningful?
12:06:59 <sophiejjj> I think it's too trival.
12:07:14 <zack> sophiejjj: i just don't understand what it is actually testing. I.e., when will it (hypothetically) fail?
12:07:14 <matthieucan> zack: yes I will, I was busy the last days, will have time this week end
12:07:38 <zack> it is good that it exercises lines of code that weren't touched before, but it should also do something meaningful
12:07:43 <sophiejjj> zack: look at the code, so when KeyError occurs.
12:07:56 <sophiejjj> gimem a min.
12:08:22 <sophiejjj> dict(LOG_LEVEL="invalid-test")
12:08:43 <zack> sophiejjj: oh, I see, that makes sense now
12:08:44 <sophiejjj> "invalid-test" is a non-existing key. This will raise a KeyError.
12:08:56 <zack> so it's just a matter of test naming
12:09:08 <zack> the name of the test should be something like "reject invalid log level"
12:09:10 <zack> or something like that
12:09:14 <sophiejjj> just wanna coverage *cover* the exception.
12:09:25 <sophiejjj> zack: but I think
12:09:37 <zack> sophiejjj: does such a name make sense to you?
12:09:39 <sophiejjj> the test is not worth it.
12:09:59 <sophiejjj> test_invalid_log_level, there is no "reject"
12:10:05 <zack> sophiejjj: fine by me
12:10:09 <zack> (and I do think it is worth ;))
12:10:30 <matthieucan> a test will always be worth some day!
12:10:35 <zack> please rename the test and send us a new patch, then if matthieucan is OK with that, we'll integrate the patch
12:10:41 <sophiejjj> sure.
12:10:46 <matthieucan> I'm ok with that
12:10:50 <zack> good
12:10:58 <sophiejjj> so, test_invalid_log_level ?
12:11:02 <zack> sophiejjj: ack
12:11:04 <matthieucan> seems good
12:11:39 <zack> #action sophiejjj to rename test coverage patch and resend it
12:11:45 <zack> next item
12:11:54 <zack> 2) allow symlink within same package
12:12:05 <zack> I've reviewed but not yet tested the code, it looks good!
12:12:29 <zack> I haven't yet checked the "none" (lowercase, string) part, but your explanation of why it should work makes sense to me
12:12:42 * sophiejjj doubts it.
12:12:48 <sophiejjj> it's the *lang* bug.
12:12:57 <matthieucan> how can we properly test that an external symlink is still blocked?
12:12:59 <zack> ah, sorry
12:13:06 <zack> yes, I'm on (3) lang override --- sorry
12:13:22 <zack> let's do (3) first then we go back to (2) symlink
12:13:26 <sophiejjj> matthieucan: homemake one link?
12:13:47 <matthieucan> sophiejjj: create/destroy the link in the testsuite?
12:13:55 <matthieucan> seems fair to me
12:13:57 <zack> (ok, let's do (2), as you're both on it)
12:13:59 <sophiejjj> matthieucan: yes. that's what annoys me.
12:14:21 <matthieucan> as long as the suite doesn't have uncleaned side-effects, it should be fine
12:14:29 <zack> matthieucan: can you review/comment the patch for (2) too?
12:14:33 <sophiejjj> yes. it's quick to do, with only several loc.
12:14:48 <matthieucan> zack: sure, tonight or tomorrow
12:14:55 <zack> great, tnx
12:15:00 <zack> an important point about that patch
12:15:08 <zack> it should allow symlinks only within the same package *and* version
12:15:24 <zack> i.e. a symlink should not be able to go from /bash/1.2.3/foo to /bash/1.3.4/bar
12:15:24 <sophiejjj> zack: yes.
12:15:27 <zack> agreed?
12:15:32 <matthieucan> yes
12:15:34 <zack> ok, cool
12:15:36 <sophiejjj> the patch works in that way.
12:15:54 <zack> so, what's the next action here? sophiejjj to send an accompanying test or matthieucan to review what we have?
12:16:03 <zack> (or both? :))
12:16:18 <matthieucan> it looks great, I didn't test it but it's definitely the way to go
12:16:34 <sophiejjj> one thing to mention.
12:16:39 <matthieucan> sophiejjj: feel free to send the test if you write it before I have the chance to try the patch :)
12:17:02 <sophiejjj> The reason I postpone writing the test is, I have to *rewrite* the whole thing before it's merged.
12:17:18 <matthieucan> sophiejjj: what do you mean?
12:17:38 <sophiejjj> there generally will be something minor to change before merged. But I have already committed them on my local machine.
12:18:05 <sophiejjj> So I have to branchout from origin/master again, and add them changes again to make it clean.
12:18:14 <zack> sure, but that's easy
12:18:21 <zack> just do, e.g.:
12:18:32 <zack> git reset --hard HEAD^ (assuming your change is the last commit)
12:18:44 <zack> then you do git apply PATCH, where PATCH is the file you sent us
12:18:53 <zack> (or git am --no-commit on the email)
12:19:00 <zack> then you modify what you want to modify, commit, and send again
12:19:11 <zack> sophiejjj: ok?
12:19:18 <sophiejjj> hmmm.
12:19:28 <sophiejjj> but for some situation like.
12:19:28 <zack> that's not rewriting everything :), it's a bit of git fiddling
12:19:48 <sophiejjj> zack: aha
12:19:54 <zack> or, even simpler, you do the changes you want to do on top of the old commit
12:20:06 <zack> and you do git commit --amend
12:20:09 <sophiejjj> always separte the test and code change different commits.
12:20:35 <zack> if that annoys you, just send a single patch, I can separate them upon merging
12:20:37 <matthieucan> sophiejjj: when I'm in doubt, I git diff foo > bar, git reset, git apply bar
12:20:55 <zack> (but then, if you want, I can explain how to work with separate commits using rebase -i, but let's not do it now)
12:21:10 <zack> (just feel free to ping me here or via email with git questions during the week)
12:21:13 <sophiejjj> ok. I will consult you later.
12:21:24 <zack> so, actions here, AFAIU:
12:21:33 <zack> #action sophiejjj to send an updated symlink patch
12:21:47 <zack> #action matthieucan to review/comment the already submitted symlink patch and give feedback
12:21:54 <zack> anything else?
12:22:01 <sophiejjj> no.
12:22:06 <zack> so,
12:22:06 <matthieucan> looks great
12:22:11 <zack> (3) lang override
12:22:28 <zack> quoting what I said before:
12:22:29 <zack> (13:12:13) zack: I've reviewed but not yet tested the code, it looks good!
12:22:29 <zack> (13:12:37) zack: I haven't yet checked the "none" (lowercase, string) part, but your explanation of why it should work makes sense to me
12:22:46 <zack> sophiejjj: you still want to send an updated patch for the if/them/else minor change, right?
12:23:02 <sophiejjj> zack: yes.
12:23:09 <zack> ok, so, this should be:
12:23:22 <zack> #action sophiejjj to send an updated lang override patch
12:23:27 <sophiejjj> hi
12:23:35 <sophiejjj> regarding the readability
12:23:39 <KGB-1> 03Andreas Beckmann 05develop e32aaf3 06piuparts 10instances/piuparts.conf.pejacevic p.conf: cleanup+unify
12:23:39 <KGB-1> 03Andreas Beckmann 05develop ea2bf53 06piuparts 10TODO 10instances/piuparts.conf.anbe add some TODO items
12:23:39 <KGB-1> 03Andreas Beckmann 05develop ff74231 06piuparts 10debian/changelog 10instances/piuparts.conf.pejacevic p.conf: add wheezy2jessie-rcmd
12:23:40 <zack> #action zack to test/review the lang override code
12:23:57 <sophiejjj> could you give me more concrete thought towards this?
12:24:15 <zack> the if/then thing or more in general?
12:24:22 <sophiejjj> the if/then.
12:24:41 <zack> so, it is nice when, reading a piece of branching code, you can identify one and only one return statement that applies to you
12:25:01 <zack> in most cases, the best way to achieve that is a single return at the end of the function, using an intermediate variable to store the result
12:25:06 <matthieucan> there's a discussion about that http://www.reddit.com/r/learnpython/comments/2ch8hx/else_after_ifreturn_good_or_bad_practice/
12:25:25 <sophiejjj> matthieucan: bookmarked. will read it later.
12:25:35 <zack> in simple cases multiple returns might be ok, but if you have then/else it's better to have one return per branch
12:25:39 <sophiejjj> matthieucan: how do you google that?
12:25:49 <matthieucan> but I agree with zack, it avoids to have many return's when the code grows up later
12:26:00 <matthieucan> sophiejjj: "python if else drop else"
12:26:22 <zack> interesting link, thanks
12:26:32 <sophiejjj> zack: still thinks it's subjective. Will spend more time thinking upon it.
12:26:46 <zack> I agree it is (to some extent) subjective
12:27:05 <zack> but when contributing to an existing good code base, it is customary to follow the existing coding style
12:27:12 <sophiejjj> zack: sure.
12:27:15 <sophiejjj> that's a must.
12:27:23 <zack> so, next item
12:27:29 <zack> 4) make test work on sor
12:27:36 <zack> you did your part
12:27:40 <zack> I guess that's now blocked on me
12:27:50 <zack> anything else to mention here?
12:28:06 <sophiejjj> seems nothing.
12:28:11 <sophiejjj> The problem is manifest
12:28:17 <matthieucan> I should write a Puppet script for that, but I doubt I'll have time to in the near future
12:28:27 <zack> yes, I'll catch up during holyday
12:28:39 <sophiejjj> why can puppet solve it?
12:28:43 <zack> matthieucan: btw, DSA would like pull request to their Puppet recipes that configure sor.d.o as we need
12:29:00 <sophiejjj> got it.
12:29:05 <zack> sophiejjj: puppet won't solve the fact we need jessie's sqlalchemy
12:29:10 <zack> you're right
12:29:19 <zack> but it will help in replicating the machine if, say, it dies
12:29:21 <matthieucan> yes it's for the other steps
12:29:52 <zack> the remaining two items were reading stuff: 4) blueprints, 5) debian/copyright spec
12:29:55 <zack> sophiejjj: how about them?
12:30:08 <sophiejjj> zack: blutprint is like apps in django
12:30:18 <sophiejjj> just an aggregating component.
12:30:44 <zack> sure, just wanted to know if you had time to look at the doc :)
12:30:59 <zack> (to understand what to leave around for future weeks and what could be dropped)
12:31:13 <sophiejjj> I read it from: https://exploreflask.com/index.html
12:31:16 <sophiejjj> and the official doc.
12:31:24 <matthieucan> the difference with django is that blueprints are not the default with flask :)
12:31:44 <zack> eh, good point :)
12:31:47 <zack> sophiejjj: great!
12:31:51 <zack> how about (5)?
12:32:08 <sophiejjj> read your link and also from https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#copyright
12:32:38 <zack> sophiejjj: awesome!
12:32:52 <zack> here, I'm again lagging, as I haven't yet drafted the spec for the copyright.d.n web app
12:33:00 <zack> will catch up during holiday as well!
12:33:28 <matthieucan> can't wait to see this project! it looks really cool
12:33:39 <zack> #topic debsources - additional business
12:33:47 <zack> sophiejjj: anything else? blockers? happy? whatever...
12:34:09 * sophiejjj is thinking.
12:34:22 <sophiejjj> nothing at present.
12:34:31 <sophiejjj> aha.
12:34:35 <sophiejjj> one thing.
12:34:39 <sophiejjj> how to debug flask?
12:34:55 <matthieucan> there's a great page in the docs about that IIRC
12:34:56 <sophiejjj> I now manually print something in the console.
12:35:14 <sophiejjj> matthieucan: what's your workflow on that?
12:35:16 <zack> matthieucan is the guru there!
12:35:35 <esphon> hi :3
12:35:40 <matthieucan> http://flask.pocoo.org/docs/0.10/errorhandling/#debugging-application-errors
12:36:07 <zack> sophiejjj: but you should certainly have a look at cache/webapp.log
12:36:27 <zack> since some time, I've modified debsources to log by default to that file (at least if you're using the default development configuration)
12:36:36 <sophiejjj> I'd like to directly dropping into a certan some function.
12:36:44 <sophiejjj> and I can interactively see the variables defined there.
12:36:54 <matthieucan> there's a way to simulate an http request from the outside and block the app before it sends the answer, to manually inspect things
12:37:08 <sophiejjj> matthieucan: yes. that's what I want.
12:37:12 <zack> matthieucan: but plane old "print" should print on the console while running locally, no?
12:37:17 <zack> s/plane/plain/
12:37:31 <matthieucan> zack: yes, but it's not as good as an interactive interpreter
12:37:38 <zack> ack
12:38:04 <matthieucan> here http://flask.pocoo.org/docs/0.10/shell/
12:38:08 <sophiejjj> zack: plain is quick and actually enough for me. But an interactive interpreter is 21st century.
12:38:16 <zack> lol
12:38:32 <sophiejjj> bookmark.
12:38:54 <matthieucan> you can play around with bin/debsources-shell and simulate your context and requests interactively in there
12:39:11 <sophiejjj> got it.
12:39:36 <zack> neat
12:39:39 <zack> anything else?
12:39:42 <sophiejjj> no.
12:40:00 <zack> ok, happy xmas (or equivalent) everyone!
12:40:08 <sophiejjj> happy everyone.
12:40:14 <matthieucan> thanks! happy holiday!
12:40:18 <zack> #endmeeting