=== StevenK changed the topic of #launchpad-reviews to: On call: StevenK || reviewing: - || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
thumperStevenK: we can talk in public you know :)02:55
StevenKWe could ... people might talk, then :-P02:57
lifelessor contribute03:03
StevenKthumper: I've addressed almost all of your concerns for db-add-ifp-job, I'm just having trouble writing InitialiseDistroSeriesJob.create() since DistributionJobDerived.create() has been binned, and could use some pointers. Or code. :-)03:10
thumperwhat isn't working?03:11
StevenKthumper: I'm not at all certain what create() should be returning -- and to answer one of your questions on the MP, the code in .create() was checking jobs so that if a job for a specific distroseries was already in the queue, a second wouldn't be created03:12
thumperwhy would you be calling it twice?03:13
thumperI suppose it is bad to try twice03:13
lifelessrace conditions03:13
thumperthe problem with that is that there is go guarantee that even with checking that you won't get two03:13
StevenKBecause InitialiseDistroSeries is one-shot. You take a empty distroseries and copy a lot of stuff03:14
thumperif you have two requests going to two different app servers at the same time03:14
thumperboth will look and not see the job there03:14
thumperand both will create it03:14
thumperif you have to be sure, you should add a database constraint03:14
thumperwith a unique partial index03:15
StevenKOkay, I'll keep that in mind03:15
thumperyou want the create method to return the new distibutionjob03:17
StevenKthumper: Doing that causes other tests to fail since DistributionJob doesn't have a run() method, but InitialiseDistroSeriesJob does03:20
thumperStevenK: take a look at model/branchjob.py line 27103:23
StevenKthumper: What should I RTFM for to add the database constraint?03:37
thumperStevenK: it is the create index syntax that has a where clause (I think)03:42
lifelessor you can just handle the job existing twice when it executes03:46
thumperlifeless: partial index would arguably be better03:50
lifelessthumper: why?03:50
thumperbecause it better represents the reality of the situation that there should be at most one03:51
lifelessso, a partial index means that a collision in the web ui will result in a collision error03:51
lifelesswhich is fugly03:51
lifelessand one that is caught outside the template code so can't be made to look good03:52
lifelesssecondly, its trading consistency for performance, its harder do queue things the more constraints you want up front03:52
thumperit means the second attempt will get retried03:52
thumperwhich can then find an existing one03:52
thumperand say "dumb ass, don't do that"03:52
lifelessthats ... interesting03:53
lifelessI sure hope we don't do that on apport uploads03:53
thumperthe db constraint error causes the request to be retried03:53
thumperI dunno about the apport uploads03:53
lifelessits then causing more work :)03:53
lifelessof a different sort, in a different context.03:53
lifelessI don't mind which way you do it.03:53
thumperyou gotta handle it somewhere03:54
lifelessIf/when we move to rabbit it will *have* to be done the way I'm describing.03:54
lifelessBut you're welcome to do whatever way makes more sense to you know.03:54
thumpernot necessarily03:54
thumperwe don't want to fire jobs to rabbit for a transaction that'll be aborted03:54
lifelesswhy not?03:54
thumperso it will have to hook into the transaction somewhere03:54
thumperisn't that obvious?03:55
thumperhow about the data not being there?03:55
thumperinconsistent expected stat03:55
StevenKthumper: So I'm expecting the test to now raise an IntegrityError if I've added the constraint right?03:55
thumperStevenK: depends how you've done it03:55
lifelessthumper: what data wouldn't be where? and what sort of abort are you expecting?03:55
thumperlifeless: I'm giving examples of why I think it is a bad idea to fire events for something that'll be aborted03:56
thumperI don't have concrete data03:56
lifeless2PC is pretty nasty perf wise; its almost certainly better to fire-and-check-when-executing.03:56
lifelessBASE rather than ACID03:56
thumperwhat 2pc?03:56
thumperwe don't have two phase03:56
* thumper walks away03:57
lifelessthumper: I think we're miscommunicating or something.03:57
lifelessthumper: as I said, right now, whatever makes sense, great.03:57
=== StevenK changed the topic of #launchpad-reviews to: On call: StevenK || reviewing: mmm, lunch || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
=== Ursinha-afk is now known as Ursinha
lifelessthumper: sorry about before, I was needlessly antagonistic; I think I need another neurofen.04:14
lifeless(but we're out)04:14
thumperlifeless: np04:16
=== Ursinha is now known as Ursinha-afk
=== jtv changed the topic of #launchpad-reviews to: On call: StevenK, jtv || reviewing: -,- || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
lifelessStevenK: / jtv: who wants this one ?06:04
jtvlifeless: I'll take it06:04
jtv…whatever it is06:04
jtv…assuming it's a Launchpad branch to be reviewed, of under 800 lines of diff.06:05
lifelessdiff coming up now06:05
jtvWhy do the active-reviews listings just have to get worse and worse?06:06
lifelessso the theme of this patch06:06
lifelessand I don't know how big it is06:06
lifelessis a prepatory patch to logging:06:06
lifeless - resultset iteration06:06
lifeless - email sending06:06
jtvdiff's here06:06
lifeless - memcached time06:06
lifeless - rabbit in future06:07
lifeless713 lines. whew :P06:07
lifelessthere is one particular bit of hair.06:07
lifelessI wanted to use request annotations06:07
jtvThat's okay—I submitted a 795-line one the other day06:07
lifelessbut we can't for anything that scripts use.06:07
jtvHave you looked at how we do this for oopses in scripts?06:08
lifelessso this has that code disabled, references to the bug about this, and instead works in with the existing thing in adapter.py06:08
lifelessjtv: I spent two and a half days trying to make it work06:08
jtvlifeless: it may be lack of context, but I don't understand the comment in line 65 of the diff.06:10
jtv# Requires poking at the API; default is to Just Work.06:10
lifelessits context06:10
lifelessthe new API creates a Timeline on demand06:11
lifelesswhich is particularly well suited for request annotations06:11
lifelesswhich we will eventually make work in scripts06:11
lifelesscheckwatches wants a limitedlist rather than grabbing all the queries06:11
lifelesswhich is odd, but to keep things scoped I just put in compat code06:11
lifelessI can expand on that, or remove the comment if you like.06:12
lifelessI wanted it to be clear why there isn't an else clause.06:12
jtvlifeless: be aware that you're at least 2½ days ahead of me in this; I'm having a very hard time following you.06:12
lifelessjtv: I started this last tuesday - so 8 days ahead :)06:13
lifelessjtv: I suggest starting with lib/lp/services/timeline/06:13
jtvOkay, 8 days plus the context I'm not seeing in the diff.  In other words: I haven't a frakking clue what you're on about!06:13
lifelessyou'll seem some ugliness about _local06:14
lifelessbut ignore that; the module and its tests should tell you what its on about06:14
jtvlifeless: lib/lp/services/timeline/__init__.py, diff line 355: "Because this part of [...],"—missing "is" I think.06:15
lifelessyes, will add06:16
jtvlifeless: in requesttimeline.py, diff line 366: if the Timeline in that docstring is a class name, please backquote.06:17
lifeless single or double?06:17
jtvAnd while you're there, please normalize __all__ to multi-line format.06:17
jtvBelow that, according to the standards I learned at the time, the XXX should go "XXX RobertCollins 2010-09-01 bug=623199: Undesirable but pragmatic."06:18
lifelessswitched around06:19
jtvIn diff ll. 389—390, why do you keep the dead code around?06:19
jtvIs it likely that we'll want to get back to it very soon, and that it won't have changed by then?06:20
lifelessfixing the mess up will be hard06:20
lifelessbut it makes a lot of stuff terrible.06:20
lifelessfeature flags06:20
lifelessrequest timing in general06:20
lifelesssecurity contexts06:21
lifelesscode clarity all through lib/canonical/launchpad/webapp06:21
lifelessI am generally an advocate of 'if we are deleting it, let the vcs remember'06:22
lifelessbut in this case I want folk looking at this code to see how it *should* look.06:22
jtvThe two approaches look quite similar to me, just structured slightly differently.06:24
lifelessone is thread local06:25
lifelesswhich has all sorts of caveats and issues; the other is zope interface based, which is more flexible06:25
jtvThat clarifies things.06:25
jtvSo two aspects get intermixed here: the way you get to the request, and the way you create the timeline on demand.06:28
lifelessI'm not sure I see what you mean06:30
jtvI think I said it wrong.  Would this be right?  "You changed two different aspects—where the timeline is supposed to be, and how you create it on demand."06:31
lifelessthere used to be an api to get the timeline in its less general form06:31
lifelessso this adds an api to get the timeline which lets other places than adapter.py write to it06:33
lifelesswhat existed before was a readonly api, as it were06:33
lifelessto make the new api easy to use, it creates on demand, but in practice, 'set_request_started' will still be getting used everywhere.06:34
lifelessso until we nuke that function, the new niceness won't really be visible06:34
jtvSo what you have is getter/setter functionality which you changed to use a different path to the variable, and on-demand creation which could work unchanged for both the old and the new model.06:35
lifelessfingers crossed :)06:36
lifelessI'd like to get rid of the setter, but its needed to migrate06:36
lifelesschicken and egg, or really big patches.06:36
jtvWhat confused me is that the dead code differs from the live code on both scores, yet only one of the two matters.06:36
lifelessoh, ah06:37
jtvHow about instead of keeping the dead code, you just have an XXX to say "in the future we will keep this in request.annotations['timeline'] instead of webapp.adapter._local.request_timeline"?06:37
jtvThen just keep the structure of the live code, and when the time comes, only change the place where you get/set the timeline.06:38
lifelessso, now I know what you were thinking06:38
jtvIt had a lot to do with that 8-day head start.  Doesn't necessarily make sense semantically.  :)06:38
lifelessthese two implementations of these two  functions are externally identically equivalent06:38
lifelessthat is, get_request_timeline autocreates in both cases06:39
jtvRight, but you're interleaving dead and live code that differ in multiple aspects, for no good reason.  Highly confusing!06:39
lifelessand set_request_timeline sets it06:39
lifelessjtv: they don't different in multiple aspects, except one thing: the return from set_, which is just for avoiding duplication because _local isn't a dict.06:40
jtvWell there's that too.06:40
jtvI'd *definitely* avoid that particular difference between the live and the dead code.06:40
lifelessI would rather you look at the hairy stuff06:41
lifelessthis seems really minor to me.06:41
lifelessI can make set_ return as well in the old code path, but there is no need.06:42
jtvThis _is_ really minor, but there shouldn't be such big obstacles to understanding the code.06:43
lifelessI don't understand the obstacles06:44
lifelessI guess06:44
lifelessits two lines06:44
jtvIt's more than two lines if you count the code that you'll want to remove later on; you just optimized for minimizing the dead code instead of for clarity.06:45
lifelessI'm optimising for vision06:45
jtvWell my vision is blurred right now!06:46
lifelessif the desired code is not visible06:47
lifelessthe reasons for the external import are less clear06:47
lifelessthe understanding of someone coming and saying 'why is this the way it is' will be less06:47
lifelessif adapter wasn't a terrible terrible global variable pita06:48
lifelessI wouldn't need to do this and noone would need to care.06:48
lifelessbrb, getting wood for the fire06:49
jtvOK.  Here's something simple you could do to make it clear what the intention of the code is: the "Disabled code path" comments say that the dead code is undesired.  If it's the desired code, make that clear.06:55
lifelesshere is a patch to increase the info in that file06:58
lifelessI'll add in the change you just suggested06:58
lifeless    # Disabled code path: bug 623199, ideally we would use this code path.06:58
_mup_Bug #623199: scripts do not establish valid zope partiticipations <Launchpad Foundations:New> <https://launchpad.net/bugs/623199>06:58
lifelesshows that06:58
jtvMuch better, but "ideally" suggests that this dead code can stick around indefinitely, until perhaps it no longer makes any sense at all.  Either you have an XXX saying that the code must change to this new form and soon, or the dead code is dead weight.07:01
lifelessthere is an xxx, right up the top of the file07:01
lifelesscan make them all look like that if you like, but they aren't going to vary independently07:01
lifelessonly the first one is needed for the XXX report07:03
jtvWho's going to make the change, and when?07:03
lifelessdon't know, as soon as I can arrange it07:03
jtvThe reason I ask is that the relative value of having the future code spelled out decreases with the time it takes to get to it; the effort involved; and how far removed the person doing it was removed from what you've been working on for the past 8 days.  The change you pasted me makes the intent clear, which is a much bigger help.07:09
lifelessWhen the future code shapes architecture, I disagree about the value diminishing; I think its very helpful to be clear about how things *should* be07:10
lifelessif it was just a different query on a maybe-table, it would be a bit of yagni07:10
jtvlifeless: that's all very nice, but the part you're documenting in the form of dead code is easily reconstructed from the intent.  Going the other way is harder: trying to figure out what the dead code is trying to say, and restoring it.07:19
lifelessI don't understand07:20
jtvIt's a shame to throw away better code that almost worked, but I think in a case like this it's for the best.07:20
lifelessI don't follow your argument for deleting it07:21
jtvWhat you have is dead code.  As a reader, I have to figure out why the dead code is there, and how it fits into the picture.  Then, if I want to fix the issue, I have to figure out how it relates to the live code.  The two sit slightly awkwardly together because the same code paths would work for both yet they follow different code paths.  But the fundamental change is one that's concisely expressed in one line, and everything else follows from there—y07:26
jtvSo now you're making the documentation better, which is good, but it makes the dead code entirely redundant.07:27
lifelesswell it doesn't07:27
lifelessa picture paints a thousand words07:27
lifelessthe code is exact. Its a direct statement.07:28
lifelessanything else is a pale shadow.07:28
jtvIt specifies irrelevant detail and leaves the essence implicit.07:28
jtvThe essential difference between the live and the dead code is that the timeline is kept in a different place.07:29
lifelessthats not the essential difference.07:29
jtvThen what is?  And can the code make it clearer to me?07:30
lifelessor rather, phrasing the different that way trivialises a huge change07:30
lifelesswebapp.adapter uses thread locals07:30
lifelessits not safe with:07:30
lifeless - twisted07:30
lifeless - threadpools07:30
lifeless - async of any sort07:31
lifelesswe do a tonne of crazy stuff07:40
lifelessall the work we deferToThread in the twisted apps we have could easily break in subtle ways, at any time07:40
lifelessits very important to me that we should the right way of doing it, even if we can't.07:40
jtvlifeless: No, those are the reasons behind the effort that produced the dead code.  The effort itself AFAICT is to keep the timeline in a different place, where it's thread-safe.  Moreover, the dead code in the getter and setter keeps all of this entirely implicit, and hides it among secondary differences because the two code paths avoidably use different idioms for on-demand setting.07:42
lifelessdo you mean unavoidably?07:43
jtvNo, I mean avoidably.07:43
lifelessones a dict07:43
lifelessone isn't07:43
lifelessI don't see how you can use the same idiom07:44
lifelessany still be writing code idiomatic to the type07:44
lifelessanyhow, this is driving me up the wall. I feel like you want to make it perfect in one particular slant, which destroys its value in other ways. I care about the other ways much more.07:45
jtvI'm glad we're agreed.  What I'm saying is: don't struggle so hard to keep 2 lines of dead code around if instead you can make the intent clear enough that the code follows automatically.07:46
jtvIf it was _just_ two lines of difference, it'd be defensible.  If all these non-essential changes follow, it becomes struggling.07:46
jtv(I'm counting the lines you'd delete in order to make the dead code live)07:48
jtvIf you really want to keep them, then I can live with that.  Just be clearer about the intent.07:50
lifelessWell, I've added the prose we discussed and rewritten docstrings etc as i pastebinned.07:51
lifelessI'm cooperating on achieving our mutal goals of good code and clean design07:51
lifelessthe 'non essential changes' you seem to be referring too, would become longer if those two lines of code are not there.07:51
jtvAnd even if it doesn't sound like it, I appreciate that and I do care about getting your improvements in.07:52
jtvFor the record, I don't object to nonessential changes per se.  Only the difficulty of figuring out how the "before" and "after" pictures of the code relate, if they are in the code side by side.07:55
jtv(In the tests I do very much like what you did for the same purpose: add a testable specification of how it _should_ work, even if that can't be implemented yet)07:57
jtvA TimedAction doesn't need a description?07:58
lifelessthere is a class docstring07:59
jtvSorry, I meant "category."08:00
lifelessits mandatory in the constructor08:00
lifelessits not evaluated by the object08:00
lifelesssame for detail08:00
jtvJust curious because I saw one of the tests pass None as a category.08:00
lifelesscan change, I was just only-filling-in-what-really-mattered08:01
* lifeless does the happy dance, the performance work from yesterday is merged.08:03
jtvI don't see a particular need to change it myself, just wondering if you might (from a more complete perspective)08:03
lifelessI think its fine08:03
jtvah, that reminds me of some queries I wanted to zap on one of our slower pages08:03
jtv…but that's for another time08:04
jtvI think my world would be just a tad nicer if right-click menus never immediately placed a potentially harmful action right under the mouse pointer.08:05
lifelessheh yes08:05
lifelessthat would be nice08:06
jtvI'm wondering if Timeline.baseline could ever mislead…  I could be wrong, but ISTM the timeline could be created explicitly, in which case it's meaningful; or when a first action came along, in which case it's basically the same as self.actions[0].start; or implicitly as a side effect of something indeterminate, in which case it's shaky at best.08:08
lifelessthats a good point08:09
lifelessI think we should a) move to a request.annotations model, and then b) make an IRequestStart hook trigger a timeline existence08:09
lifelessOh, and this is a reason to put an else block in adapter.py08:09
lifelesswhere you asked about originally.08:09
jtvWould it be easier perhaps to have a "start timeline" event?08:10
lifelessI don't think so, because the point is that you want requesttimeline to be /subscribed/ not /emitting/08:11
lifeless+    request = get_current_browser_request()08:12
lifeless     if request_statements is not None:08:12
lifeless         # Requires poking at the API; default is to Just Work.08:12
lifeless-        request = get_current_browser_request()08:12
lifeless         set_request_timeline(request, Timeline(request_statements))08:12
lifeless+    else:08:12
lifeless+        # Ensure a timeline is created, so that time offset for actions is08:12
lifeless+        # reasonable.08:12
lifeless+        set_request_timeline(request, Timeline())08:12
lifelessbah, haven't changed the first comment ther,e will do so - but you see the change08:12
jtvI used the wrong term again.  Forgive me.  A start _action_, so you never have to wonder whether the actions list is empty and don't have to keep a baseline time.08:12
lifelessinteresting idea.08:13
lifelesslet me think for a minute08:13
jtvHmm... I think I can find an easier spelling for the if/else you just pasted.  :-)08:13
lifelessoh, sure I can pull the set_request call out of it08:13
jtvset_request_timeline(request, Timeline(request_statements))08:14
lifelessbut its a line longer with another local variable08:14
jtvI think ^^ is equivalent to the entire if/else.08:14
lifelessI think that would mislead the eye08:14
lifelessits true that when it is None it is equivalent to not passing it because the implementation uses None as the sentinel08:15
lifelessok, start actions.08:15
lifelessI think that would need more special cases.08:15
lifelesslog_tuples are derived from the baseline, not the prior action.08:15
lifelessthey have to be because people may use a LimitedList (until we sort out checkwatches etc...)08:16
jtvWell, the baseline would just be self.actions[0].start08:16
lifelessand if you derived it recursively, the first action can disappear08:16
lifelessso, if you had a start action, you have to make sure it cannot magically go away when someone uses a LimitedList08:16
lifelesswhich would require gymnastics08:16
jtvSo then by all means don't do that.08:17
lifelessthe start is an instantaneous thing, not a blocking event, so its not interesting like other TimedEvents08:17
jtvMaybe though just pull the datetime.datetime.now(UTC) out into a method so it doesn't open you up to maintenance skew?08:17
lifelesswhat do you mean?08:17
jtvWell actually I have ulterior motives also.  I'll explain.08:18
jtvI sometimes get those annoying "hey you're mixing timezone-aware timestamps with timezone-naïve ones" errors.08:18
lifelessyes, they suck. This api is entirely tz aware because of that.08:19
jtvTo minimize that distraction while developing, I like having the code that "reads the clock" for one particular item concentrated in one place.08:19
jtvThe ulterior one is, of course, that it's a very easy way to mess with timestamps in tests.  There's supposed to be better ways to do that, but I haven't gotten around to them yet.08:20
jtv(And by "mess with," I mean "produce predictable")08:20
lifelesssure, a test double time source08:20
lifelessdo we have one system wide already?08:20
jtvI don't _think_ so08:21
lifelessIts a little complex to get right, and perhaps a simple mock is better.08:21
lifelessI defintely don't want to go down that hole speculatively here.08:21
lifelessI like the idea, I just think is very conceptually different, and as you can see, only one test would really benefit today.08:22
jtvNo… the main thing I'm driving at is "clock-reading code is often best extracted and concentrated."08:22
lifelessI'm agreeing.08:23
lifelesswe have it all over the place08:23
lifelessI'm saying 'Rather than start a new trend in this patch, we should do it separately'08:23
jtvWell starting a new trend is a different matter perhaps.08:24
lifelessWhen I have a strong opinion on the how of it I'll do that in small pieces (like this entire patch is)08:26
lifelessI don't for clock reading code; I can see at least three different approaches08:26
jtvSomething else: in the  summarize_requests output, maybe just generalize "queries" to "actions," and possibly replace "issued" with "performed" or somesuch?08:27
jtv(No strong feelings on the clock issue here, so do it the way you want it)08:27
jtvlifeless: any ideas on the baseline issue?08:32
lifelessjtv: whats the bsaeline issue ?08:32
jtvMaybe pass it explicitly based on request_starttime?08:32
lifelessthat it might be out of sync?08:33
* lifeless strongly suspects thats a misfeature08:33
lifelessso right now:08:33
jtvOh, that's not much good if you create on-demand, is it08:33
lifeless - no tests failed08:33
lifeless - production doesn't play tricks with time08:33
lifelessI think its a yagni, with the patch I pasted in here applied.08:34
jtvIf you're always creating the timeline early on, that solves it.08:34
jtvAnother small thing: in diff lines 229—232, the preferred way to access items in a tuple is to unpack it.  I think that'd be a lot clearer in this case.08:38
jtvThat's errorlog.py, starting around line 454 or so.08:38
lifeless-            log_tuple = action.log_tuple()08:39
lifeless+            start, end, category, detail = action.log_tuple()08:39
lifeless             statements.append(08:39
lifeless-                log_tuple[:2] +08:39
lifeless-                (_safestr(log_tuple[2]), _safestr(log_tuple[3])))08:39
lifeless+                (start, end, _safestr(category), _safestr(detail)))08:39
lifelessI have some habits from writing extremely tight python code08:40
jtvBelieve me, SteveA had to kick some of those habits out of me when I was new...08:40
jtvlifeless: I notice you have a few cases where you look for categories starting with "SQL-".  Is that something that's going away?  Or perhaps something to move into the timeline class?08:40
lifelesswell, I'm not sure these will get kicked out08:40
lifelessbut I will certainly be reminding myself when code is inner loop or not08:41
lifelessjtv: its going away, its the old API : I didn't want to have to update tests in this patch08:41
lifelesstests that consume the old API I mean.08:41
jtvYes, I understand.08:41
lifelessthe SQL- prefix in adapter.py will stay, but nothing will filter on it in the main lp codebase08:41
lifelessoopstools may, but the format is a disk format and tricky to evolve08:42
lifelessits a separate concern to the timeline anyway08:42
jtvThen it's not worth messing with.  I did have to squint at this one though:08:42
jtv262+    >>> for action in get_request_timeline(08:42
jtv263+    ...    get_current_browser_request()).actions:08:42
jtv264+    ...    if not action.category.startswith("SQL-"):08:42
jtv265+    ...        continue08:42
jtv266+    ...    print action.detail08:42
jtvWouldn't that be much clearer as:08:42
jtv>>> timeline = get_request_timeline()08:43
jtv[insert argument I forgot because of the line break in the original]08:43
jtv>>> for action in timeline.actions:08:43
jtv...     if action.category.startswith("SQL-"):08:43
jtv...         print action.detail08:43
lifeless6 of 1 I think08:44
jtvlifeless: In webapp/servers.py I see you're replacing sql_statements with nonpython_statements.  It could be helpful to standardize on a single term, for grepability etc.08:46
lifelesslike actions ?08:47
jtvYes, that's a good one.  :)08:47
jtvlifeless: thanks.  Then, in TestRequestTimeline, there's a pair of comments with --start-- and --end--.  Is that idiomatic?  I haven't come across it before, and tbh it's the sort of thing I might easily break if there were a few more tests between them.08:50
lifelessits grouping the tests to delete when we fix the bug08:51
jtvObvious once you know it. :)08:52
lifelessI'll add a one-liner reference to the bug on the top one08:53
lifeless     # Tests while adapter._local contains the timeline --start---08:53
lifeless+    # When bug=623199 is closed these should be deleted.08:53
lifeless     def test_new_request_get_request_timeline_uses_webapp(self):08:53
jtvGreat.  Maybe just "# Delete when bug=623199 is fixed" for impact?08:54
jtvOn our team at least we've been following somewhat different XXX practices: we'll happily add multiple XXX'es for a single bug, to mark all the places that need changing.  (They're meant to irk us, after all.)  This is one of the places where we'd do that.08:55
lifeless+    # Delete when bug=623199 is fixed and the timeline store moved to08:56
lifeless+    # annotations.08:56
jtvEven better.08:56
lifelessso, I don't think irking people helps stuff get done08:56
lifelessI think its important to find all the call sites08:57
lifelessand if you see a number that is actually for a fixed bug thats important too08:57
lifelessso - to me - having it in each context that its relevant is crucial08:57
lifelessswamping folk with it is just cruel08:57
jtvWell, it should reflect your intent to fix it.08:58
jtv We were supposed, once upon a time, to pursue XXX'es per se.08:59
jtvThen, the link to a bug became mandatory and we're supposed to pursue bugs.08:59
jtvBut yes, now we find that there are always more bugs than you can solve.  :)08:59
jtvSo maybe you're right and we shouldn't overdo that.09:01
jtvlifeless: on a different matter, in TestTimedAction.test_log_tuple, it _would_ be attractive to get rid of the indeterminacy in the timer.09:02
lifelessjtv: well, it is determinate :)09:11
lifelessthe test won't fail because of clock issues09:11
lifelessback shortly, organising foods09:11
jtvlifeless: in TimedAction, log_tuple doesn't meet our standard for method names.  But it does meet our standard for property names, and it looks relatively cheap to compute, so maybe just make it a property?09:21
lifelessI will have to bring this up, PEP8 is good.09:40
lifelessI will rename it09:40
lifeless(and no, it does computation, so its not suitable for being a property)09:42
lifelessjtv: this is btw, a pathology of the lp review process, I think.09:44
jtvlifeless: which one?09:44
lifelessspecification over outcome09:44
lifelessI will expound on it another time09:45
jtvOK, let's get this review done first.09:46
jtvlifeless: typo: s/sancrosant/sacrosanct/g09:48
jtvIn OverlappingActionError.09:48
jtvSpeaking of which, ISTM there are two separate basic cases where you'd run into the non-overlapping rule: failing to mark completion, and nesting.  For the former, I'd say the rule is more than just a way to simplify analysis—it detects potential bugs.09:50
lifelessit does, but not a worthwhile class to detect09:51
lifelessthose events won't be logged *anyway* in such a case.09:52
lifelessso the developer putting the notifier together will see it immediately.09:52
lifelessI mean, it nice as a bonus, but I'd take nesting, if desired, without argument09:52
jtvWhy won't those events be logged anyway?09:52
lifelesssomething that isn't finished has no OOPS representation today09:53
lifelessyou could fudge it09:53
jtvFor a query that probably won't matter much, since a failure normally aborts the transaction.  But for generalized actions, it may be worth catching if the exception path isn't handled properly.09:55
lifelessI'd like to call YAGNI here09:57
lifelessit can be added09:57
lifelessits not needed now, because every request ends with DB queries which will trigger if the thing before isn't closed off properly.09:57
jtvI don't see the argument for yagni.  The functionality is already there, is it not?09:58
lifelesswe'd need to add a close-off call, to say 'check that the last thing isn't finished', and call that at the end of the request09:59
lifelessnote that 'end of the request' its terribly badly defined today for scripts - see the bug I have been ranting about.09:59
lifelessits not that its terribly hard, its that it has no interesting use case today; you'd need to be using this in a situation that is outside of launchpad core for it matter in any practical sense.10:00
=== jelmer changed the topic of #launchpad-reviews to: On call: StevenK, jtv, jelmer || reviewing: -, -, - || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
lifelessand it is a bit hard to do properly, because of 'request' and 'scripts' mixing so badly.10:01
jtvWell in the case where it happens at the end of a request, it'll usually be fairly obvious that the action is there.  I'm thinking more of catch-retry cases.10:01
lifelesstry: action; except: actionagain10:02
jtvWell, probably more like except: alternativeaction.10:02
lifelessthat will raise already, so no changes are needed, if action() doesn't close off.10:02
jtvThat's exactly what I'm saying.10:02
lifelessthen I'm horribly confused10:03
lifelessI thought you were asking for a change10:03
jtvNo.  I'm saying, the check will detect potential bugs.10:04
lifelessok, so I acked that. I said it wasn't a deliberate feature.10:05
jtvYes.  I'm saying you shouldn't be so apologetic for the limitation.10:05
jtvBut anyway, I'm done and approving the branch.10:06
lifelessthank you very much for spending this time on the review.10:06
jtvIt's what OCRs are for.10:07
lifelessjtv: so you're clicky-clicking in the webui now ?10:14
jtvlifeless: yes, if you are using that term to describe the sound of my keyboard.10:14
lifelessjtv: oh, are there other changes I need to make?10:14
jtvFear not.  There were a few interruptions slowing me down.10:15
* lifeless wants to throw it at ec2 to find out what hidden braindamage I missed10:15
lifelessI ran the previous iteration through ec2 test10:15
jtvThe only thing is "make sure the comments on the dead-code lines aren't easily misread as saying the future code is obsolete."10:15
lifelesswhich is how i found out about that heinous bug10:15
lifelessjtv: did that10:15
jtvThat must've been a painful discovery.10:16
lifeless    # Disabled code path: bug 623199, ideally we would use this code path.10:16
_mup_Bug #623199: scripts do not establish valid zope partiticipations <Launchpad Foundations:New> <https://launchpad.net/bugs/623199>10:16
jtvAh yes.  Good.  Now let me finish my review so we can all get on.  :)10:16
lifelessjtv: it was unpleasant. Plus I was 1 day into caffeine withdrawal. Not a good combo.10:16
lifelesssory, I don't have that glyph10:17
jtvIt's "AAAAAAAAAAAAAA!" in Lao.10:17
jtvDo you have it in Thai?  อาาาาาาาาาาาาาาา10:18
lifelesslooks like hills or something10:18
jtvlifeless: it is done10:20
jtvtime for a break10:20
=== jtv is now known as jtv-afk
=== StevenK changed the topic of #launchpad-reviews to: On call: jtv, jelmer || reviewing: -, - || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
=== jtv-afk changed the topic of #launchpad-reviews to: On call: jelmer || reviewing: - || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
=== Ursinha-afk is now known as Ursinha
=== matsubara-afk is now known as matsubara
noodles775Hi jelmer! I've got one for your queue when you've time: https://code.edge.launchpad.net/~michael.nelson/launchpad/distro-series-difference-getByDistroSeries/+merge/3428913:18
=== noodles775 changed the topic of #launchpad-reviews to: On call: jelmer || reviewing: - || queue: [noodles775] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
jelmernoodles775: hey!13:18
jelmernoodles775: Of course13:18
noodles775Great, thanks.13:18
=== jelmer changed the topic of #launchpad-reviews to: On call: jelmer || reviewing: noodles775 || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
noodles775gar, forgot to push my lint fixes.13:22
noodles775r9735 is pushed now.13:23
=== Ursinha is now known as Ursinha-afk
=== jtv1 is now known as jtv
=== Ursinha-afk is now known as Ursinha
=== EdwinGrubbs changed the topic of #launchpad-reviews to: On call: jelmer, Edwin || reviewing: noodles775 || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
=== Ursinha is now known as Ursinha-afk
jtvEdwinGrubbs, customers!  Got time for this one?  https://code.launchpad.net/~jtv/launchpad/recife-findtranslationmessage/+merge/3429715:01
EdwinGrubbsjtv: I can do it15:07
=== EdwinGrubbs changed the topic of #launchpad-reviews to: On call: jelmer, Edwin || reviewing: noodles775, jtv || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
jtvEdwinGrubbs: diff still hasn't showed up.  :(15:24
EdwinGrubbsjtv: I ran diff myself against the recife branch.15:24
jtvsorry for the trouble!15:25
gmbjelmer, EdwinGrubbs: Can either of you gents review https://code.edge.launchpad.net/~gmb/launchpad/prompt-user-to-subscribe-to-master-bug-485627/+merge/34302 for me please?15:26
EdwinGrubbsgmb: If jelmer can't do it now, I can do it in an hour or two.15:28
gmbEdwinGrubbs, Thanks. I'll add it to the queue.15:28
jelmerI'll take it then, just wrapping up a review for noodles775.15:29
gmbjelmer, Thanks15:29
=== gmb changed the topic of #launchpad-reviews to: On call: jelmer, Edwin || reviewing: noodles775, jtv || queue: [gmb] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
EdwinGrubbsjtv: when makeCurrentTranslationMessage enumerates a list, is it expected that the list contains the plural forms in order of 0, 1, 2, etc.?15:30
jtvEdwinGrubbs: yes15:30
jtvSo a translation of a singular and a plural would be [singular, plural]15:30
jtvAnd a translation to a single-form language, or a translation of a string without a number in it, would be [translation]15:31
jtvBut in the API we're standardizing on, those are respectively {0: singular, 1: plural} and {0: translation}15:31
EdwinGrubbsjtv: findTranslationMessage() still has a potranslations parameter that appears to be unused since you set the potranslations variable in the method.15:57
gmbjelmer, I need to step out for a while, so please feel free to ask any questions on the MP and I'll reply when I return.16:03
jelmergmb: *nod*16:04
* gmb exits stage right16:04
jtvEdwinGrubbs: whoops—well spotted.  That was an intermediate attempt at solving the multi-format question.16:09
EdwinGrubbsjtv: ok, that was my only concern. r=me16:10
jtv\o/ thanks16:10
EdwinGrubbsjelmer: are you reviewing my branch already? https://code.edge.launchpad.net/~edwin-grubbs/launchpad/bug-597738-bug-service-status/+merge/3425016:15
noodles775Thanks for the review jelmer16:18
=== matsubara is now known as matsubara-lunch
jelmerEdwinGrubbs: Yes, I started on it before you were here but then switched to reviewing noodles'16:21
EdwinGrubbsjelmer: ok, I was going to ask if you could do that now. I'll take gmb's branch.16:22
jelmerEdwinGrubbs: Oh, ok. That works for me as well.16:23
jelmerEdwinGrubbs: btw, it's not really an issue for the review (seems like a formatting issue) but did you see your branch has a conflict?16:28
EdwinGrubbsjelmer: I can imagine that since I'm dependent on a branch that may have landed recently with some minor changes.16:30
=== salgado is now known as salgado-lunch
EdwinGrubbsgmb: r=me16:55
=== Ursinha-afk is now known as Ursinha
=== benji is now known as benji-lunch
gmbEdwinGrubbs, Thanks.17:15
=== matsubara-lunch is now known as matsubara
=== salgado-lunch is now known as salgado
=== benji-lunch is now known as benji
=== deryck is now known as deryck[lunch]
=== gary_poster_ is now known as gary_poster
=== deryck[lunch] is now known as deryck
bryceh On call: jelmer, Edwin || reviewing: noodles775, jtv || queue: [gmb, bryce] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews18:54
=== bryceh changed the topic of #launchpad-reviews to: On call: jelmer, Edwin || reviewing: noodles775, jtv || queue: [gmb, bryce] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
leonardrsalgado, can i ask you to take one more look at my branch (http://pastebin.ubuntu.com/486932/). it makes the changes you requested and fixes some test failures, partly by moving more code into the *Public interfaces20:44
salgadoleonardr, sure20:48
salgado       <require20:48
salgado           permission="zope.Public"20:48
salgado-          interface="canonical.launchpad.interfaces.IOAuthAccessTokenVerification"/>20:48
salgadoyou can use <allow interface="...">  instead of <require permission="..." interface="...">20:49
leonardrit's the same when the permission is zope.public?20:49
salgadowhat I meant is that20:50
salgadoyou can use <allow interface="...">  instead of <require permission="zope.Public" interface="...">20:50
salgadoif you want any other permission, then you should use <require>20:50
=== jelmer changed the topic of #launchpad-reviews to: On call: Edwin || reviewing: jtv || queue: [gmb, bryce] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
=== Ursinha is now known as Ursinha-afk
jtvI don't think EdwinGrubbs is really still reviewing my branch.  :)20:52
=== jtv changed the topic of #launchpad-reviews to: On call: Edwin || reviewing: - || queue: [gmb, bryce] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
jelmerah, ok :-)20:52
lifelessjtv: hi20:52
lifelessjtv: a) go to bed :) b) I had two tiny tests that needed a s/queries/activies/ that i missed20:53
=== EdwinGrubbs changed the topic of #launchpad-reviews to: On call: Edwin || reviewing: - || queue: [bryce] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
jtvlifeless: aye-aye.  :-)20:53
=== jtv is now known as jtv-zzz
salgadoleonardr, I've asked a few other questions on the m-p, in case you didn't see21:30
leonardrsalgado, checking21:30
leonardrsalgado: the permission isn't changing in this diff. the permission changed last week, and i only noticed the test failure today21:35
leonardrthe permission changed last week because we couldn't come up with a way to make the access level be 'write' for oauthtoken objects and 'read for everything else21:35
leonardri needed to remove the security proxy as soon as I changed the permission for the oauth token, but again, i only saw the test failure today21:36
leonardrsalgado, i've responded on the mp21:46
EdwinGrubbsjelmer: I have responded to your review.21:47
EdwinGrubbsbryceh: did you want a review of your branch besides the db reviews by stub and lifeless?21:51
EdwinGrubbsbryceh: I saw that you put your name in the review queue, but I didn't know if there was a different branch that I'm not seeing that you want reviewed.21:52
jelmerEdwinGrubbs, still there?22:06
EdwinGrubbsjelmer: yep22:06
jelmerEdwinGrubbs: Great, I'll have a look at the updated MP.22:07
brycehEdwinGrubbs, thanks.  The branch is stripped down to just db schema changes, so perhaps is just review of it by stub and lifeless sufficient, or should it receive regular review as well?22:17
EdwinGrubbsbryceh: it's fine if they just do the db review, especially since you already had a pre-imp call with somebody from the bugs team. I'll take your name out of the queue, since stub and lifeless aren't oncall reviewers.22:20
=== EdwinGrubbs changed the topic of #launchpad-reviews to: On call: Edwin || reviewing: - || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
brycehEdwinGrubbs, ok thanks22:20
lifelessactually I am22:34
lifelessI think I'm on this morning22:34
* lifeless checks timetable22:34
=== lifeless changed the topic of #launchpad-reviews to: On call: Edwin, Lifeless || reviewing: - || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
lifelessstub is ocr on monday asiapac fwiw22:35
=== matsubara is now known as matsubara-afk
=== EdwinGrubbs changed the topic of #launchpad-reviews to: On call: Lifeless || reviewing: - || queue: [] || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
=== Ursinha-afk is now known as Ursinha
=== salgado is now known as salgado-afk

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!