[02:07] <thumper> mwhudson: probably not tested
[02:10] <mwhudson> thumper: do you think it should be?
[02:10] <thumper> mwhudson: yes
[02:10] <mwhudson> damn :)
[02:11] <thumper> a simple click should be enough :)
[09:03] <al-maisan> hello stub, did you have a chance to look at https://code.edge.launchpad.net/~al-maisan/launchpad/psds-399186/+merge/13959 ?
[09:04] <stub> al-maisan: It looked fine. I'll do the real review now.
[09:04] <al-maisan> stub: thanks -- that's very much appreciated :)
[09:19] <stub> al-maisan: There is mention in the notes about renaming the tables to DistributionPackageSet and DistroSeriesPackageSet - is that going ahead at some point?
[09:20] <stub> (I'm quite happy with the current names myself)
[09:20] <al-maisan> stub: yes, but the renaming will occur later in a separate branch.
[09:21] <al-maisan> it is critical for this to go in and the renaming will increase the amount of work (particularly on the python side); that's why it's postponed.
[09:21] <stub> al-maisan: Can the same packageset in different distroseries have different names?
[09:22] <al-maisan> stub: the idea is to have a package set for each distro series i.e. we won't share package sets across distro series
[09:23] <stub> I'll rephrase that. Can two packagesets in the same packagesetgroup have different names?
[09:23] <stub> I'm just confirming that the name column should remain on the packageset table rather than move to the packagesetgroup table.
[09:23] <al-maisan> stub: yes
[09:24] <al-maisan> we expect that package sets will get renamed over time
[09:24] <al-maisan> i.e. each package set should have its own 'name' column independent of any others in the same group
[09:25] <stub> Yup. Just got to that in the meeting notes :)
[09:25] <al-maisan> :)
[10:15] <noodles775> Hi jml - if we've got a database constraint (say for a unique name), do we need to test that constraint?
[10:15] <noodles775> if so, what's the best way to do so... I'm having to do the following which looks ugly:
[10:15] <noodles775> http://pastebin.ubuntu.com/302669/
[10:16] <noodles775> (because the unique constraint isn't actually checked during the transaction until a subsequent db query is run).
[10:16] <noodles775> or stub ^^
[10:16] <jml> noodles775, from my pov, I'd want to know how the constraint itself is going to be used / avoided
[10:17] <stub> database constraints are safety nets that don't need to be tested. The python code that protects these constraints from ever being triggered needs to be tested (such as your validators).
[10:17] <jml> noodles775, in an ideal world, you'd get a DuplicatePackageSet error or something.
[10:17] <jml> noodles775, which is kind of what stub is saying :)
[10:20] <noodles775> Great - thanks guys. Of course - given that this will be used via the api we need to raise an exception.
[10:28] <bac> good morning
[10:28] <bac> bring out your dead!
[10:29] <bac> fresh, hot reviews!
[10:29] <noodles775> jml, so next question. Previously I've raised an exception by first hitting the db to check for a dupe - but is there not a way to rely on the unique constraint itself (but without committing the transaction - ie. something that does what the ugly hack in the above paste does - just accesses the db)?
[10:29] <noodles775> hi bac :)
[10:29] <bac> hi noodles775
[10:30] <jml> noodles775, what's the ugly hack in the paste above?
[10:30] <noodles775> jml,  see http://pastebin.ubuntu.com/302669/ line 13+
[10:31] <jml> oh I see.
[10:31] <noodles775> perhaps just reloading an object - but it's still not descriptive of what I'm actually trying to do (just trigger the unique constraint).
[10:32] <jml> noodles775, In other cases, we look before we leap
[10:32] <noodles775> Yeah, that's all I could find too... ok.
[10:32] <jml> noodles775, I wish I could think of something better
[10:33] <noodles775> Hmm... al-maisan just found store.flush() - looks perfect.
[10:36] <bac> hi jtv
[10:37] <al-maisan> stub: could you please push the "approve" button if you are done (and satisfied) with the schema patch?
[10:40] <stub> al-maisan: Getting distracted with production issues
[10:41] <al-maisan> stub: oh, I see.
[10:41] <stub> al-maisan: So packagesets can have a different owner to their packagesetgroup and other packagesets in the same packagesetgroup?
[10:43] <al-maisan> stub: I guess this will be true .. different people/teams creating package sets over time
[10:43] <stub> al-maisan: So it is registrant really? Or does the owner get special privileges?
[10:43] <al-maisan> for package set groups the intention was merely to capture who created them
[10:43] <al-maisan> stub: it's more of a registrant thing .. yes
[10:44] <al-maisan> no elevated privileges for the owner as far as I am aware
[10:46] <al-maisan> stub: sorry .. for package sets: the owner has "permission = 'launchpad.Edit'"
[10:56] <bac> hi jtv
[10:56] <jtv> bac: hi
[10:56] <bac> jtv: your in the queue.  is that accurate?  for your scale-message-sharing branch?
[10:57] <jtv> bac: seeing some question marks in the subject line... did you edit it in a non-utf-8-aware client?
[10:57] <jtv> bac: that's the one, yes.
[10:57] <bac> er, 'you are in the queue'
[10:57] <bac> jtv: really?
[10:58] <bac> jtv: i updated this client yesterday, so perhaps it is hosed.
[10:58] <jtv> bac: yes, I put emdashes in it (because I _can_, dammit!) and the question marks look like they might be what remains after deleting the respective first bytes of their utf-8 representations.
[10:59] <bac> jtv: why don't you fix and i'll see what it looks like here
[10:59] <bac> jtv: originally i saw an a+hat
[10:59] <jtv> bac: are you getting an emdash?
[11:00] <jtv> wow, that's definitely an encoding mismatch.,  :)
[11:00] <bac> no, a with a hat
[11:01] <bac> jtv: why don't you reset it and perhaps my editor won't mess it up going forward
[11:01] <bac> jtv: i'll start your review now
[11:01] <jtv> bac: I did reset it... how doese it look now?
[11:01] <jtv> oh, sorry, missed your latest
[11:01]  * jtv resets
[11:02] <bac> better
[11:04] <bac> jtv: your help message at line 67 says "remove some duplicates".  does it remove all duplicates?  if not, who picks?
[11:04] <bac> should 'some' be deleted from the description?
[11:04] <jtv> bac: oh, I could've sworn I documented that.
[11:04] <bac> maybe you did
[11:05] <jtv> The "some" is shorthand for "a particular class that if found, would otherwise get in the way of merging."
[11:05] <jtv> The class is: duplicates that are attached to "representative" potmsgsets.
[11:06] <jtv> The messages from less-representative corresponding potmsgsets in other templates are then added to the representative potmsgset.
[11:06] <jtv> Since that addition also eliminates duplication, any duplicates there will vanish as a side effect.
[11:07] <bac> jtv: i don't think that's very well conveyed if a person looks at the help message.  if i saw "remove some duplicates" i'd be pretty worried about which ones.
[11:07] <stub> al-maisan: review in
[11:07] <stub> al-maisan: Still need jml's stamp
[11:08] <jtv> bac: I'll get on that right away
[11:08] <al-maisan> stub: thanks -- the next patch will be more readable -- I promise :)
[11:09] <bac> jtv: i see there is no action for that parser option.  doesn't it need a a store_true?  is there a default action it is using now?
[11:09] <jtv> bac: heh, hadn't even noticed, but it did seem to work this way.  I'll add the action.
[11:10] <stub> al-maisan: old habits - I understand ;)
[11:10] <jtv> bac: well, I mean it _did_ work this way... but then again I didn't look very closely at what was stored in that option.
[11:10] <al-maisan> stub: :P
[11:12] <jtv> bac: ah... it defaults to "take an argument and store it."  So "-D -vvv" gobbled up the -vvv!
[11:13] <bac> jtv: so it assumes it is a string option.  not what you want!
[11:13] <jtv> right
[11:14] <jtv> bac: and for the option documentation... how about just "Remove *problematic* duplicate TranslationMessage"?
[11:14] <bac> that's better
[11:15] <bac> jtv: so if you run now with no action specified on the command line do you get the error message at line 95?
[11:16] <jtv> bac: "Select at least one action:" etc.
[11:18] <bac> jtv: at 141 was the txn.begin() not needed?  if not, why can you remove it now?
[11:19] <jtv> bac: it was never actually _needed_, and I had extensive discussions with stub about whether it was nicer to write it.
[11:19] <bac> jtv ok
[11:19] <jtv> bac: if I write it, the new transaction (probably) starts right away.  If not, creation of a new transaction (probably) gets deferred which may reduce transaction lengths a bit.
[11:23] <bac> jtv: the assignment at 158 is not needed
[11:26] <jtv> bac: you're right, I think I should go back and extend my testing a bit.
[11:26] <bac> jtv: how do you test for a superfluous assignment?
[11:26] <bac> jtv: or did you intend to do something with it?
[11:27] <jtv> bac: this one would basically lead to the wrong superfluous message being deleted...  hang on, I still have to figure out whether that has any consequences at all
[11:28] <bac> jtv: really?  'representative' is just reassigned when the loop starts
[11:28] <jtv> bac: ahhh, I mis-read.  You're completely right.
[11:32] <bac> jtv: the comment at line 291 needs to be cleaned up.  there may just be an extra 'the' in it but it makes little sense now.
[11:33] <jtv> bac: yup
[11:33] <bac> jtv: r=bac with those changes
[11:33] <jtv> bac: just made.  Thanks!
[11:34] <bac> jtv: unfortunately, i've written my comments referring to lines in the diff.  when you fix the branch and repush it, the diff will be regenerated and my comments will no longer make any sense, rendering this review useless for historical purposes.  :(
[11:36] <jtv> bac: oh well, it'll still be my mistake if something went wrong there.  :)
[12:09] <leonardr> bac: can you review https://code.edge.launchpad.net/~leonardr/launchpadlib/wsgi-fake-launchpad/+merge/14021 ?
[12:09] <bac> leonardr: sure
[12:29] <bac> leonardr: this looks great!
[12:29] <bac> leonardr: i'm still reviewing it, i'm just saying the ability to get rid of the browser interaction is cool.
[12:30]  * leonardr dislikes it, but it's better than letting everybody who hasn't thought out the security problem write their own code
[12:44] <bac> leonardr: wrong channel.  what is a 209 response code?
[12:47] <BjornT_> deryck: maybe you'd like to review my windmill fixes? https://code.edge.launchpad.net/~bjornt/launchpad/windmill-problems/+merge/14024
[12:48] <deryck> BjornT_, sure.
[12:49] <BjornT_> deryck: cool, thanks
[12:49] <leonardr> bac: Conflict
[12:49] <leonardr> it means someone else changed the thing you're trying to change
[12:50] <leonardr> or, in this case, _you_ already changed the thing you're trying to change
[12:50] <bac> leonardr: just curious, where is that  defined?
[12:50] <leonardr> bac: rfc 2616
[12:51] <bac> leonardr: it's not here http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
[12:52] <leonardr> bac: oops, i put the wrong number. it's actually 409
[12:52] <bac> ah, cool
[12:53] <deryck> BjornT_, in the updates for ensure_login, why didn't you use the timeout constants there?
[12:53] <bac> leonardr: i wasn't being coy, i thought there may have been an extension i couldn't find
[12:53] <BjornT_> deryck: mainly to keep the diff size down. i'll update it now, though :)
[12:53] <leonardr> bac: i think there is a 209 error code defined in an extension, but it's not conflict
[12:54] <deryck> BjornT_, ok :)
[12:54] <leonardr> bac: yes, it's Content Returned, defined as part of PATCH
[12:54] <deryck> BjornT_, also, line 38 of the diff has an extra space after the opening paren.
[12:54] <bac> leonardr: i wish we used the constants from httplib...but we don't.
[12:55] <bac> leonardr: the src directory is now empty and can be removed, right?
[12:55] <leonardr> bac: no, i moved it by mistake
[12:55] <leonardr> launchpadlib should still be in src
[12:55] <leonardr> i have no idea how that happened. i just changed it back because the tests were failing
[12:55] <bac> so you'll move launchpadlib -> src/launchpadlib?
[12:56] <leonardr> yes
[12:56] <bac> ok.  i was going to ask about impact on packaging but now that's moot.  :)
[12:56] <leonardr> in fact, i'm pushing that now
[12:56] <deryck> BjornT_, other than those two minors things, looks good to me. thanks for this! r=me
[12:57] <bac> and your import of the symbols from uris in launchpad.py for compatability.  that's just so they'll be exported, right?  if so would you add them to __all__
[12:58] <BjornT_> deryck: thanks. here are the changes: http://pastebin.ubuntu.com/302759/
[12:59] <BjornT_> deryck: the extra space was there because i had joined the lines by accident. there was supposed to be a line break there
[12:59] <deryck> BjornT_, ok, cool.  those changes look good too.
[13:07] <bac> leonardr: r=bac
[13:40] <abentley> bac: Could you please review https://code.edge.launchpad.net/~abentley/launchpad/merge-directive-namespace/+merge/13867 ?
[13:42] <bac> abentley: yes
[13:42] <abentley> bac: 
[13:42] <abentley> bac: thanks.
[13:55] <henninge> bac: I'll fling a little 39 lines branch on top of the pile, if you don't mind.
[13:56] <bac> henninge: fling away
[13:56] <henninge> bac: cheers!
[14:15] <bac> henninge: full stop on comment on line 8
[14:15] <bac> henninge: is the message at line 34 correct?  is 'translated' the right verb?
[14:16] <henninge> bac: lemme look
[14:17] <henninge> bac: "have no translation" might be better as it is just a dummy translation.
[14:18] <bac> henninge: ok.  r=bac with those changes
[14:18] <henninge> bac: thank you!
[14:22] <bac> abentley: the branch looks good.  curious as to why you requested an r-c but didn't get it cherry picked.
[14:23] <abentley> bac: I don't understand.  I'm waiting on a code review (and test run) before I can land it on production-devel.
[14:24] <bac> abentley: i was just confused that you got r-c approval four days ago but just now sought code review.
[14:24] <bac> abentley: i was unclear whether you still wanted a CP for this.
[14:24] <bac> abentley: either way, it is approved.  thanks for the fix.
[14:25] <abentley> Ah.  I finished it up around EOD on a Friday, and I was OCR on Monday, and kinda forgot.
[14:25] <bac> abentley: that'll do it
[14:26] <abentley> bac: It's been sitting in the queue since Friday, but no one's taken the initiative to review it.
[14:26] <bac> abentley: nudges are useful, as you see.
[14:26] <adeuring1> bac: can I add another MP to your queue?
[14:26] <bac> adeuring1: sure
[14:26] <abentley> bac: indubitably.
[14:26] <adeuring1> bac: thanks!
[14:34] <bac> adeuring: r=bac with one typo fix
[14:34] <adeuring> bac: wow, that was fast! thanks!
[14:41] <abentley> bac: Could you please review https://code.edge.launchpad.net/~abentley/launchpad/hide-numbers/+merge/13982 ?
[14:42] <bac> sinzui: is this ready to be reviewed?  https://code.edge.launchpad.net/~barry/launchpad/436503-privacy/+merge/13993
[14:43] <bac> sinzui: i think the 'abstain' knocked it off +activereviews.
[14:43] <bac> abentley: ok
[14:43] <sinzui> bac: yes it is. These are the same images I reviewed yesterday.
[14:43] <abentley> bac: Thanks!
[14:44] <bac> sinzui: i don't understand.  you reviewed what?
[14:44] <bac> sinzui: oh, you reviewed the screenshots...
[14:44] <sinzui> bac: barry showed me these images yesterday. I requested a true private team image
[15:00] <al-maisan_> jml: ready for the call?
[15:00] <jml> al-maisan_, indeed I am.
[15:01] <al-maisan_> jml: please give me 3 minutes.
[15:01] <jml> al-maisan_, their yours.
[15:04] <al-maisan_> jml: rrring
[15:11] <bac> abentley: regarding your changes to the dev config for mpcreationjobs, should those settings not be in production too?
[15:12] <abentley> bac: They are already in the production config.
[15:12] <abentley> bac: Production has been running mpcreationjobs just fine.  I couldn't run them in devel mode because there was no config.
[15:13] <bac> abentley: i don't see values for the OOPS prefix in the schema or in production configs
[15:14] <bac> abentley: never mind
[15:14] <bac> abentley: forgot the production configs are in a separate branch
[15:15] <abentley> bac: Ah, cool.
[15:24] <bac> abentley: can you give me some help demoing this fix locally?
[15:24] <abentley> bac: Sure.
[15:24] <bac> abentley: how do i create a MP with diff on lp.dev?
[15:24] <abentley> bac: Do "make run_all", so that you have a local codehosting.
[15:25] <bac> done
[15:25] <abentley> bac: Push up two branches, propose them for merging.
[15:25] <abentley> bac: Run "make sync_branches"
[15:25] <bac> abentley: can i just use a branch that mark owns in sample data?  one of the firefox ones?
[15:26] <abentley> bac: You can use a existing branches, as long as they have actual bzr branches.
[15:28] <bac> abentley: and i assume they do not.
[15:29] <abentley> bac: I don't know whether they do or not.
[15:31] <abentley> bac: You can certainly push branches to the firefox project as mark.  That's what I did.
[15:35] <bac> abentley: i've never tried that.  i assume i need to set launchpad-login to be mark?
[15:36] <abentley> bac: No, you should already be set up for that, and launchpad-login doesn't affect lp://dev
[15:38] <abentley> bac: Your .ssh/config should have https://pastebin.canonical.com/23897/
[15:39] <bac> abentley: yep.  i get connection refused on 5022
[15:39] <abentley> did you do "run_all", not just "run"?  Did it error?
[15:40] <bac> abentley: yeah, i did run_all
[15:40] <abentley> bac: And it's still running?
[15:40] <bac> abentley: rather than debug my setup, would you just confirm the toggly bits work with epiphany
[15:40] <bac> abentley: i need to move on to other reviews
[15:41] <bac> abentley: but i want to ensure webkit doesn't barf on the JS
[15:41] <abentley> bac: Checking...
[15:42] <abentley> bac: It works on Epiphany.
[15:43] <bac> abentley: ok.  it looks good. i'll finish up the review now.
[16:05] <leonardr> bac: another branch from me
[16:05] <leonardr> https://code.edge.launchpad.net/~leonardr/launchpadlib/json-token-format/+merge/14037
[16:17] <bac> leonardr: in your test at line 217 of the diff you say you're testing a script but you're testing the class the script calls.  i understand why but it would be nice if you stated that
[16:19] <al-maisan_> hello bac, could you please have a look at a branch of mine as well?
[16:19] <al-maisan_> It's here: https://code.edge.launchpad.net/~al-maisan/launchpad/psds-model-changes-399186/+merge/14038
[16:20] <bac> al-maisan_: yes, but i'm starting to wrap things up.
[16:20] <al-maisan_> bac: thanks a million!
[16:32] <intellectronica> leonardr: can i ask you for a mid-air review of my lazr.restful fix?
[16:33] <leonardr> intellectronica, sure
[16:34] <intellectronica> leonardr: http://pastebin.ubuntu.com/302895/ (which is a fix for https://bugs.edge.launchpad.net/lazr.restful/+bug/438802 )
[16:34] <mup> Bug #438802: UnicodeDecodeError changing 'Assigned to' field when summary contains non-ascii <oops> <post-3-ui-cleanup> <ui> <lazr.restful:In Progress by intellectronica> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/438802>
[16:45] <leonardr> intellectronica: ok, but what specifically was the problem? value.decode("utf-8") worked but unicode(value) didn't?
[16:46] <intellectronica> leonardr: yes, because unicode() will not use utf-8
[16:46] <leonardr> ok
[16:46] <leonardr> r=me
[16:47] <intellectronica> leonardr: as a reviewer i would have asked me to add a test ;) any tips on where i should test this?
[16:52] <leonardr> sorry, i guess i thought an existing test was failing
[16:52] <leonardr> you have a change in the full HTML representation and in the field representation
[16:52] <intellectronica> yes
[16:53] <leonardr> i would change example/base/tests/field.txt and example/base/tests/entry.txt
[16:53] <intellectronica> leonardr: cool. thanks a bunch
[16:53] <leonardr> there should be tests in there that change a field and then verify that the new field shows up in the representation
[16:53] <leonardr> change those tests so that you are setting the new field to a utf-8 value 
[18:53] <abentley> rockstar: Could you do a UI review for me? https://code.edge.launchpad.net/~abentley/launchpad/hide-numbers/+merge/13982
[20:17] <rockstar> abentley, done.
[20:17] <abentley> rockstar: Thanks.
[20:17] <abentley> barry: could you do a UI review for me? https://code.edge.launchpad.net/~abentley/launchpad/hide-numbers/+merge/13982
[20:18] <sinzui> abentley: barry is not available. I can do it though
[20:18] <abentley> sinzui: Cool, thanks.
[20:30] <sinzui> abentley: sorry for taking so long. make schema is now past 10 minutes
[20:32] <abentley> sinzui: No worries.
[20:52] <allenap> jml, mwhudson: Before I go any further, can I ask you to have a look at something I knocked up earlier: http://pastebin.ubuntu.com/303104/. It moves lib/devscripts into a package of its own, though still in the LP tree, and does some buildout tomfoolery to make it run with the right deps and python2.5.
[20:54] <mwhudson> allenap: on a trivial level, the comment before boto = 1.8d should stick with the bzr = ... line
[20:54] <allenap> mwhudson: Ah yes, good spot.
[20:55] <allenap> jml, mwhudson: It also uses trial for tests. Maybe that's not a great plan, or maybe it is. I don't really know.
[20:55] <mwhudson> allenap: for another, i think you need to do something about the utilities/ec2 and utilities/update-sourcecode entrypoints?
[20:55] <allenap> At the time it just seemed a lot easier to get trial to work that to figure out the zope test runner.
[20:55] <mwhudson> trial is a decent enough test runner i think
[20:56] <allenap> mwhudson: I think I did the utilities/ec2 one, but update-sourcecode I need to do. Another good spot.
[20:56] <mwhudson> allenap: if you move the update-sourcecode entrypoint, you'll need to change the ec2 
[20:56] <allenap> mwhudson: Okay, I'll check that.
[20:57] <mwhudson> allenap: in general, it probably makes sense to separate the devscripts code and the launchpad code a bit more
[21:13] <sinzui> abentley: I do not know how to create a merge proposal to view your branch. I created two real branches to test this, but branch-scanner does not seem to find them, and update_preview-diffs does not see anything to do
[21:54] <thumper> rockstar: https://code.edge.launchpad.net/~thumper/launchpad/bmp-inline-commit-message/+merge/13814 plz tick the ui review box :)
[21:57] <rockstar> thumper, ack.
[21:57] <thumper> rockstar: ta
[21:58] <rockstar> thumper, I still don't like the look of the unset commit message, but I don't know what to do about it.
[21:58] <rockstar> thumper, have you put any thought into it?
[21:58] <thumper> rockstar: yes, I thought best not to show anything if there isn't anything there
[21:59] <thumper> rockstar: the multiline editor doesn't support prompt-cues, although perhaps it should
[21:59] <rockstar> thumper, yea, but it looks crowded if there's nothing there.
[21:59] <thumper> rockstar: fyi a prompt cue is text in an empty field that goes away when it gets focus
[22:00] <rockstar> thumper, yeah, I think I've heard you use that term before.
[22:55] <jml> mwhudson, "decent enough test runner" indeed!
[22:56] <mwhudson> jml: i'm full of faint praise