[02:48] <wallyworld> wgrant: i've created a master bug for that suspected lock timeout issue, and duped the 3 examples against that. i think those 3 should now be marked as High rather than Critical
[02:49] <wgrant> wallyworld: Well, if you duped them then it doesn't matter
[02:49] <wallyworld> the bug count still has not reduced - how often is it updated?
[02:50] <wgrant> wallyworld: On webnumbr.com? Hourly
[02:50] <wallyworld> no, in the lp portal
[02:50] <wgrant> You can see the last update time down the bottom
[02:50] <wgrant> Usually 7-10 past
[02:50] <wgrant> LP portal?
[02:50] <wgrant> Oh, the portlet?
[02:50] <wallyworld> yeah, that
[02:50] <wgrant> That drops immediately
[02:50] <wgrant> It says 245 for me, which is roughly correct given the privacy skew
[02:51] <nigelb> How do I commit a merge? I seem to have forgotten bzr.
[02:51] <wallyworld> i could have sworn that it was 244 before i duped
[02:51] <wgrant> nigelb: Same as any other change
[02:51] <wgrant> bzr commit
[02:51] <wallyworld> and it was 244 after
[02:51] <wallyworld> maybe new bugs were filed in the time it took me
[02:51] <wallyworld> or i misremembered the number
[02:51] <wgrant> It was 251 yesterday
[02:51] <wgrant> So it's decreased roughly the right amount
[02:52] <wgrant> I know that dupes aren't included in that count, cause I rewrote it 3 months ago
[02:52] <wallyworld> i was definately 24x before
[02:52] <wallyworld> anyway, doesn't really matter, was just curious
[02:53] <nigelb> Hrm. The history doesn't look right.
[02:53] <wgrant> nigelb: Oh?
[02:54] <nigelb> wgrant: Shouldn't it show me as the commiter only and the branch author as author?
[02:54] <wgrant> nigelb: Remember that 'bzr log' supresses sub-revisions of merges by default. If you give it -n0 it'll expand merges.
[02:54] <wgrant> nigelb: No
[02:54] <wgrant> nigelb: Only if you use --author
[02:54] <nigelb> ahh.
[02:54] <nigelb> Am I supposed to do that so that history isn't skewed?
[02:55] <nigelb> well, skewed is the wrong word.
[02:55] <nigelb> I meant. History wrongly credits me.
[02:55] <wgrant> No
[02:55] <wgrant> You're credited for the merge, 'cause you did the merge :)
[02:55] <wgrant> You can use --author if you wan
[02:55] <wgrant> t
[02:55] <nigelb> ah.
[02:55] <wgrant> But the original author is still credited for all the revisions under the merge
[02:55] <nigelb> launchpad will show the right author?
[03:04] <wgrant> nigelb: No
[03:05] <nigelb> :(
[04:48] <wgrant> We're now back to the start of Sep 2011 :)
[05:54] <cjwatson> Has everyone stopped using 'ec2 land' or something?
[05:54] <cjwatson> Yesterday I tried twice to land a branch and got unrelated test failures both times
[05:57] <cjwatson> lp.soyuz.browser.tests.test_archive_webservice.TestArchiveWebservice.test_getAllPermissions_constant_query_count (OK, that's pretty sensitive anyway, but damn sure the PCJ model and tests shouldn't affect it), and pgbouncer syntax errors in lp.services.webapp.tests.test_dbpolicy.TestFastDowntimeRollout.test_master_slave_fast_downtime_rollout and ...
[05:58] <cjwatson> ... lp.services.webapp.tests.test_dbpolicy.TestFastDowntimeRollout.test_slave_only_fast_downtime_rollout (WTF)
[05:59] <cjwatson> Should I just lp-land and hope?
[06:00] <stub> cjwatson: The pgbouncer syntax error is interesting - it would mean you are using an old version of pgbouncer.
[06:00] <stub> cjwatson: I have used ec2 recently just fine
[06:00] <cjwatson> It was complaining about the DISABLE command
[06:00] <cjwatson> And I didn't do anything special in ec2, just the defaults
[06:00] <stub> cjwatson: Perhaps you have an old ec2 image overriding the correct one?
[06:01] <stub> DISABLE command wgrant added to me. We are currently running a fork of pgbouncer until it gets merged upstream, packaged etc.
[06:01] <stub> And this is enforced in the -dependencies package
[06:02] <stub> c/to me/for me
[06:03] <cjwatson> Don't suppose the PPA and CAT are out of sync or something?
[06:04] <stub> There seem to be lots and lots of CAT archives. I do know we are running the fork on staging and production, and I'm pretty certain it was rebuilt with the same version number
[06:04] <cjwatson> Oh, haha, the second run got "Connection failed" when trying to install pgbouncer, but because we're using --force-yes it ignored that
[06:04] <cjwatson> I WARNED YOU
[06:05] <stub> cjwatson: If the tests pass locally, lp-land will be fine btw.
[06:05] <cjwatson> Yeah, I haven't run the whole suite but as I say I'm certain the PCJ model won't affect the archive webservice tests.  Will lp-land.
[06:06] <wgrant> cjwatson: When was that?
[06:06] <stub> and the fdt tests should certainly pass locally for you. query count tests are certainly fragile though, and can be broken in unexpected ways
[06:06] <wgrant> It was probably while haetae was off the network
[06:06] <wgrant> (and yes, most people have stopped using ec2 for 90% of stuff)
[06:07] <wgrant> wallyworld: Hm, your projectgroup changes earlier in the week have caused some performance regressions
[06:07] <stub> cjwatson: bzr lp-land doesn't run tests, it will go straight to buildbot to choke on.
[06:08] <wgrant> wallyworld: eg. HasAnnouncementsView.announcements materialises an unbounded set of announcements, causing eg. https://launchpad.net/+announcements/+announcements to time out
[06:08] <cjwatson> wgrant: around 19:45 UTC
[06:08] <wgrant> cjwatson: Right, that's around when stuff was broken
[06:09] <cjwatson> I'm vaguely tempted to make that query count test use like ten additions in the second run instead of one, and loosen the query count requirement just slightly
[06:09] <cjwatson> To account for minor auth differences
[06:10] <wgrant> Yeah
[07:25] <wallyworld> wgrant: i'll take a look
[13:06] <adeuring> jcsackett: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/productseries-sec-adapter/+merge/130305 ?
[13:51] <adeuring> deryck: could you please take a look at this mp: https://code.launchpad.net/~adeuring/launchpad/productseries-sec-adapter/+merge/130305
[13:52] <deryck> adeuring, indeed
[13:52] <adeuring> thanks!
[13:57] <deryck> adeuring, my two branches that I'm trying to land add information_type to ProductSeries and Milestone via adaptation.  The approach conflicts with your approach here.
[13:58] <deryck> adeuring, mostly that the information_type property is not needed this way.
[13:58] <adeuring> deryck: ok. So, I'll merge your branch?
[13:58] <deryck> adeuring, yeah, I think so.  let me get the url for you….
[13:59] <deryck> adeuring, lp:~deryck/launchpad/series-information-type
[13:59] <adeuring> deryck: ack
[13:59] <deryck> adeuring, that is built on the milestone work.  so lots of changes, but they were reviewed separately.
[14:01] <abentley> deryck: We do have some examples of Union in the codebase.  It's only used about 6 times, though.
[14:02] <deryck> abentley, ah, cool.  Thanks for checking on that.
[14:02] <deryck> and yeah, I generally don't like using Union if it can be avoided.
[14:02] <rick_h_> cool, maybe I'll try to look at it real quick
[14:02] <jcsackett> adeuring: looking at yours now.
[14:03] <rick_h_> I hate having these rules defined multiple times
[14:03] <rick_h_> seems like a bug just waiting to get missed in some future tweak
[14:03] <wgrant> deryck, abentley: I'm a little concerned that we're seeing performance regressions across all views that respect blueprint privacy
[14:04] <wgrant> Because you're pushing new complex multi-level joins into these queries
[14:04] <wgrant> We avoided this in the bug and branch implementations by denormalising the access data
[14:04] <wgrant> The blueprint case is identical to the branch one
[14:04] <wgrant> So the branch implementation can be reused
[14:05] <deryck> wgrant, yeah, we have plans to focus just on performance after we hit beta.  and are saving denormalizing work until then.
[14:05] <deryck> wgrant, well, not *just* on performance.  but performance is one focus for us after beta.
[14:06] <deryck> wgrant, but thanks for the heads up about the branch implementation.
[14:06] <wgrant> It's a little worrying that we're knowingly regressing performance when it's roughly a day of work to fix it last week
[14:07] <deryck> how seriously are we regressing?  Are pages timing out?
[14:07] <deryck> adeuring, I'll wait on you to merge me before I review further, since it's worth reviewing the branch in the context of my work.
[14:07] <wgrant> We have a timeout exception for +specworkload which is no longer sufficient
[14:07] <adeuring> deryck: sure, nearly done.
[14:08] <wgrant> Anything that executes more than one specification-related query is likely to be a little sad now
[14:10] <deryck> wgrant, I don't see any timeout for +specworkload on lpnet.  Am I just overlooking it?
[14:10] <deryck> wgrant, timeout flag change, I mean.
[14:11] <wgrant> Huh, maybe it was removed and this just pushed it further over the edge of the default
[14:12] <deryck> wgrant, I understand your concerns, and appreciate that you wouldn't have approached it the way we are.  but I'm going to stick with the plan, and we can turn to performance stuff next week.
[14:12] <wgrant> But, in general, this is a very cheap change to make beforehand -- we have the code to do it, we know exactly the performance characteristics of both methods, and it's around a day of work to do
[14:12] <wgrant> OK
[14:12] <wgrant> I cannot agree with that, but OK :)
[14:12] <deryck> wgrant, I understand.  but hitting our milestones is very important to me.  and we don't have a day to spare right now.
[14:13] <wgrant> I understand that milestones are important
[14:13] <wgrant> But that makes about 9 critical regressions from this feature so far
[14:13] <wgrant> It's a bit worrying
[14:13] <deryck> wgrant, thanks for understanding.  but they're only worrying to me if they remain unfixed.  we're not releasing with those regressions.
[14:14] <deryck> wgrant, not final release I mean.
[14:14] <wgrant> They're critical because they're actively degrading Launchpad for non-beta users
[14:14] <deryck> wgrant, but we consciously allowed space for regressions along the way if we could move faster.
[14:14] <deryck> wgrant, hmmm, let me look at bugs then, I'm not aware of some of these, I bet.
[14:15] <wgrant> Ah, some of them are actually fixed now
[14:16] <wgrant> But there's still a number of private blueprint listing issues, plus the performance regression
[14:16] <wgrant> Hm, and one of them is incorrectly critical, since private projects aren't enabled on prod yet
[14:17] <adeuring> deryck: using IInforamtionType(productseries) leads to a permission problem: http://paste.ubuntu.com/1286974/
[14:17] <wgrant> Ah, nevermind, Aaron marked that one critical, so it's fine
[14:17] <wgrant> So not 9 any more, but still a few
[14:17] <wgrant> (that were predicted)
[14:18] <adeuring> deryck: I could use removeSecurityProxy(series).product but I don't like to do this outside tests...
[14:18] <deryck> wgrant, sure, but it's not as if we're not being sensitive to this.  we knew this could happen, but it has allowed us to move faster.  and in the most egregious cases, we've fixed them immediately...
[14:18] <deryck> wgrant, and we're committed to fix them all.
[14:18] <adeuring> erm, I mean IIformationType(removeSecProxy(series))
[14:18] <deryck> wgrant, so I respect that you would approach this differently, but please don't act as if we're being cavalier and not thinking about what we're doing here.
[14:19] <deryck> wgrant, we're making hard choices to try to finish this a month from now.  and sometimes we do let a critical bug through.  but we will fix them all.
[14:19] <deryck> adeuring, looking now...
[14:20] <deryck> adeuring, isn't that the XXX from abentley that you removed.  where he went info_type = productseries.product.information_type because adaptation didn't work.
[14:21] <adeuring> deryck: I think that was about another issue with the adaptation
[14:21] <adeuring> deryck: the permission problem is new
[14:23] <deryck> adeuring, ah right.  seems like I had something similar with milestone and a change in zcml to allow IInformationType fixed it.  but I could be recalling wrong.
[14:24] <adeuring> deryck: here, we would have to allow public access to productseries.product...
[14:24] <adeuring> well, let's, that _might_ be possible...
[14:26] <deryck> adeuring, hmm, are we sure the test is setup right?  maybe the unauthorized is accurate.  if you can view the product series you should be able to view to product.
[14:26] <deryck> adeuring, or maybe I'm misunderstanding what's happening.
[14:27] <adeuring> deryck: ah, right, we can login as the "right" user, that should fix the issue
[14:28] <abentley> adeuring: I'm not sure whether or not that's a symptom of same problem, because in my bug, adaptation did something evil to the Checker.
[14:29] <adeuring> abentley: well, is IInformationType(obj) supposed to provide all attributes of obj itself?
[14:30] <abentley> adeuring: No.
[14:30] <adeuring> abentley: sorry, mis-read your bug report.
[14:31] <adeuring> abentley, deryck: but then we two issues with IInfoType(obj)
[14:32] <adeuring> deryck: sees that my approach to simply implement InfoType in ProdcutSeries might be more reliable
[14:35] <deryck> adeuring, so it is easier/more reliable on one hand, but the view/ui work is easier with adaptation.  very little work to handle this with adaptation.
[14:35] <deryck> adeuring, are there other issues?  I didn't follow you a few lines back, or changing the test is sufficient?
[14:37] <adeuring> deryck: no, test works fine with a "with_person_logged_in()", but I am a bit concerned about the bug abentleyreported
[14:39] <deryck> adeuring, agreed.  but good lord, we have enough tests that anything worrying should be caught, I think. :)  Let's stay with adaptation and move ahead.
[14:39] <deryck> adeuring, and FWIW, I'm no fan of adaptation.  I think normal python properties are always better.  but in this case, it does help tie in to other parts of the system better.
[14:39] <adeuring> deryck: ok. I've pushed a new revision
[14:40] <deryck> adeuring, ok, cool, looking again.
[14:50] <abentley> deryck: I'm getting test failures on stable r16164.  Can you reproduce them? http://pastebin.ubuntu.com/1287026/
[14:51] <abentley> deryck: They also occurred on ec2, devel and my product-specifications-privacy branch.
[14:51] <deryck> abentley, ok, doesn't sound good. let me see….
[14:51] <wgrant> abentley: Were these from ec2 about 20 hours ago?
[14:52] <wgrant> You'll get them locally if you're running an old version of pgbouncer, and on ec2 if you started a run while ppa.launchpad.net was down 20ish hours ago
[14:52] <abentley> wgrant: 15 hours ago or so.
[14:53] <wgrant> abentley: Things were getting back to normal around then
[14:53] <wgrant> But this error basically means you couldn't talk to ppa.launchpad.net at the start of the run
[14:53] <wgrant> So I'd ignore it
[14:55] <abentley> wgrant: Okay, thanks.
[14:56] <wgrant> As for the local failure, apt-get upgrade should fix it
[14:56] <wgrant> Unless you're running something newer than lucid
[14:57] <abentley> wgrant: I'm running quantal, like a good little launchpad dev.
[14:57] <wgrant> Ah
[14:57] <abentley> wgrant: But I'd somehow missed restoring the launchpad ppa.
[14:57] <wgrant> I guess Blue's work made it a bit more feasible to run on 2.7
[14:58] <wgrant> abentley: I'm not sure if we have the patched pgbouncer for >lucid
[14:58] <wgrant> Oh, we do
[14:58] <abentley> wgrant: looks like.
[14:58] <wgrant> 1.5.2-2+lp2~24~quantal1
[14:58] <abentley> wgrant: And fixed.
[14:58] <wgrant> Great
[14:59] <deryck> abentley, so I don't see them locally, but I see wgrant helped sort it out.
[14:59] <abentley> deryck: Yup.  Thanks.
[15:02] <deryck> adeuring, sorry it's taking me a bit.  diff got huge with my branch. :)  Sorting through it all though.
[15:02] <deryck> adeuring, I still have a couple tests to fix in mine, too.  So not sure if you want to wait on me and re-merge.  or take your chances in ec2, too. :)
[15:03] <adeuring> deryck: right, there was a kind of a explosion in the diff size ;) And, right, I think I'll wait for your fixes
[15:03] <deryck> adeuring, shouldn't take me too long after the review.
[15:03] <adeuring> sounds good
[15:04] <deryck> mine branch was actually two branches originally, too. :)
[15:07] <deryck> adeuring, r=me.  good stuff, thanks!
[15:08] <adeuring> deryck: thanks :)
[15:08] <deryck> np!
[17:20] <rick_h_> deryck[lunch]: ping when you get back
[19:06] <abentley> deryck: chat?
[19:07] <deryck> abentley, sure.
[19:07] <deryck> abentley, meet you in the stand-up hangout.
[19:48] <abentley> deryck: The comment is the output of our chat: http://pastebin.ubuntu.com/1287627/
[19:49] <deryck> abentley, looking....
[19:51] <deryck> abentley, yeah, that looks right to me.
[19:53] <abentley> deryck: cool.
[19:55] <cr3> is there a way to get an archive of a private mailing list on launchpad?
[20:14] <maxb> WebOps have provided mboxes of public archives in the past - maybe file a question and see what they say?
[20:23] <czajkowski> cr3: if you file an answer on LP
[20:24] <czajkowski> we'll get web ops to look at it and see what it entails
[20:24] <cr3> czajkowski: will do, thanks
[20:37] <czajkowski> cr3: I#d say as a once off it'd be done but not on a regular basis
[20:38] <cr3> czajkowski: one off would be much appreciated, and I'll share with my team just in case it might interest them as well
[20:38] <czajkowski> nods
[20:38] <czajkowski> and then next time archive mail rahter than delete mail
[20:38] <czajkowski> mdz had a point about deleting mail :)
[20:39] <cr3> czajkowski: I never delete my personal mail though, just mailing list email
[20:39] <czajkowski> ah :/
[20:39] <jpds> People delete emails?
[20:40] <cr3> czajkowski: my process is partly based on the assumption that mailing lists use something like mailman where a tarball is always available
[20:40] <cr3> czajkowski: and I'm usually not interested in mailing lists that don't use mailman anyways, but the irony is that launchpad actually does use mailman in the backend :)
[20:41] <czajkowski> launchpad is unique :)
[23:07] <oalca_> anyone?
[23:07] <oalca_> im wondering,
[23:08] <oalca_> if somebody is working in a comment feature on diffs?
[23:08] <oalca_> not in the comment section, but the green/red highlighted sections of the diff
[23:16] <oalca__> i'm wondering, if somebody is working in a comment feature on diffs?, not in the comment section, but the green/red highlighted sections of the diff
[23:18] <oalca__> no?