[00:10] <lifeless> ugh
[00:10] <lifeless> lazr stuff uses the whle zope stack doesn't it :(
[00:15] <lifeless> can has review? https://code.launchpad.net/~lifeless/lazr.batchnavigator/keyoffset/+merge/56091
[00:17] <lifeless> thumper: ^ if you're around, its trivial
[00:22] <wgrant> lifeless: The branch name is a lie.
[00:23] <lifeless> it is
[00:23] <jelmer> lifeless, what does "newest = false" do?
[00:24] <jelmer> nevermind
[00:24] <jelmer> lifeless, r=me
[00:25] <lifeless> jelmer: thanks!
[00:43] <lifeless> seeking teddy bear for short design call
[01:33]  * wallyworld hates debugging 200+ line doc tests
[01:34] <lifeless> me too with s/200+ line//
[01:36]  * wallyworld meant to type 2000 not 200
[02:41] <huwshimi> A review for someone who has magic Monday reviewing powers: https://code.launchpad.net/~huwshimi/launchpad/ie-comment-button-414747/+merge/56094
[03:01] <thumper> huwshimi: done
[03:01] <huwshimi> thumper: Thanks :)
[03:04] <thumper> np
[03:36] <thumper> FFS
[03:36] <thumper> pgAdmin III fails on natty with trust authentication :(
[03:49] <wgrant> thumper: Were you looking at the hwdb OOPSes?
[03:49] <thumper> wgrant: nope, not right now
[03:49] <thumper> wgrant: I'm looking at branch stacking problems on rename
[03:49] <wgrant> Someone was talking about it on Friday.
[03:49] <wgrant> I don't recall who.
[03:49] <wgrant> thumper: Great!
[03:50] <thumper> I was talking about looking at it, but changed to look at the stacking issues
[03:51] <wgrant> Ah, right.
[04:13] <wallyworld> wgrant: lazr restful upgrade broke some tests. i've finally got them fixed. in ec2 now.
[04:14] <StevenK> Can haz review? https://code.launchpad.net/~stevenk/launchpad/dsd-cant-request-resolved/+merge/56097
[04:14] <wgrant> wallyworld: What broke/
[04:14] <wgrant> ?
[04:14] <wgrant> wallyworld: Note that we're RC, so it won't make it through PQM.
[04:15] <wallyworld> wgrant: a bugs doctest. the issue was not our stuff but another change in 0.18.1 which short circuited patch requests
[04:15] <wallyworld> wgrant: np. i'll land after rc if it passes ec2
[04:15] <wgrant> Ah, right.
[04:16] <wallyworld> wgrant: plus, the notifications stuff i did sometimes adds up to an extra 2 queries to a request to get the notifications from the session, so some query count tests needed tweaking
[04:16] <wgrant> wallyworld: Only for webservice requests?
[04:17] <wallyworld> wgrant: yes, afaik. only for requests come in via a WebServicePublicationMixin implementation
[04:17] <wgrant> Great.
[04:19] <wallyworld> StevenK: i'll grab it but someone will need to mentor it
[05:07] <wgrant_> StevenK: Are you going to harrass mawson?
[05:32] <wgrant> Hmmm.
[05:32] <wgrant> It is tempting to batchnavigate BugTask:+index...
[05:33] <wgrant> That and gandwanacide should just about finish off those timeouts.
[05:33] <wgrant> Making it pretty and AJAXy can come later.
[05:34] <poolie_> hi thumper
[05:34] <lifeless> wgrant: that would be cool
[05:34] <poolie_> hi lifeless,wgrant
[05:34] <lifeless> wgrant: still have the milestone gangcrush to finish off bugtask:+index
[05:34] <lifeless> hi poolie_
[05:37] <wgrant> lifeless: Mm, that's not so bad.
[05:37] <wgrant> Afternoon poolie_.
[05:40] <lifeless> wgrant: the milestone thing... the thing that was breaking cve:+index ? :)
[05:41] <lifeless> wgrant: its pretty shallow conceptually, but a bit ugly pragmatically
[05:45] <StevenK> wgrant: Updating code now.
[05:46] <wgrant> StevenK: Great.
[05:47] <StevenK> wgrant: jtv's branch is merged as of r10383.
[05:47] <wgrant> StevenK: I know,.
[05:48] <wgrant> We avoided merging it to devel.
[05:48] <huwshimi> Am I right in thinking we don't have any javascript link checks in Launchpad?
[05:49] <wgrant> huwshimi: What do you mean?
[05:49] <StevenK> wgrant: You said we need to check both, so should I avoid rf-get?
[05:49] <wgrant> StevenK: r10383 introduced a new script, but also changed the old one.
[05:49] <wgrant> StevenK: We need to test the cron.publish-ftpmaster still works, and that publish-ftpmaster.py does too.
[05:49] <wgrant> Speaking of the devil.
[05:50] <lifeless> StevenK: wgrant: also see my mail (just sent) to -devel about commingling of changes during complete downtime with stuff that really only needs partial downtime.
[05:50] <poolie_> thumper, i was wondering about your branch name on bug 377519
[05:50] <_mup_> Bug #377519: Stacked on location breaks if the stacked upon branch is renamed <branch-stacking> <lp-code> <Launchpad itself:In Progress by thumper> < https://launchpad.net/bugs/377519 >
[05:50] <StevenK> wgrant: make stop'ing, and merging
[05:50] <poolie_> are you planning to fix it by exposing the branch id?
[05:50] <huwshimi> wgrant: Well during our build process or anything
[05:50] <huwshimi> wgrant: Actually build would probably be a bad place to do it
[05:51] <wgrant> huwshimi: How does one check JavaScript links?
[05:51] <wgrant> Or do you mean lint?
[05:51] <huwshimi> wgrant: Ah crap. Yeah lint
[05:52] <wgrant> huwshimi: pocket-lint's JS checking is broken at the moment. sinzui was looking at that last week.
[05:52] <wgrant> It's meant to work, but broke at some point.
[05:54] <huwshimi> wgrant: Ah I see, there is a bug reporting the exact issue I'm trying to address (bug 742619)
[05:54] <_mup_> Bug #742619: JS syntax checking is broken in packaging <Launchpad itself:Fix Released by sinzui> <pocket-lint:Fix Released by sinzui> < https://launchpad.net/bugs/742619 >
[05:56] <jtv> StevenK: where do DSD.source_pub and DSD.parent_source_pub get set?
[05:57] <jtv> Oh, stupid question
[05:57] <jtv> They don't
[05:57] <jtv> properties
[05:58] <lifeless> poolie_: yes, he is
[06:00] <poolie_> :/
[06:01] <poolie_> i would have liked us to be involved in the preimplementation discussion of that
[06:01] <poolie_> since we'll have to support it
[06:01] <StevenK> wgrant: dogfood is up and running on r10388. Let's break it into tiny pieces.
[06:01] <wgrant> StevenK: Have you run the cronscript there before?
[06:01] <poolie_> i don't think it's an awful decision but i do wonder where the discussion happens
[06:01] <poolie_> if any
[06:01] <wgrant> poolie_: Why do you have to support it?
[06:01] <StevenK> wgrant: Once, I think
[06:02] <lifeless> poolie_: well, he was working on a complex scheme to rewrite all the branches affected by renames, and I asked if he'd considered just exposing the persistent id
[06:02] <lifeless> poolie_: we chatted a bit, compared races, vuln, implementation overheads, and decided this was simpler
[06:02] <lifeless> poolie_: here and in -ops for part of it
[06:02] <poolie_> wgrant, because people will report bugs about this against bzr
[06:03] <poolie_> just now?
[06:03] <lifeless> poolie_: on friday
[06:04] <lifeless> poolie_: so there are two discussions; meta and change specific. Lets have one at a time :) - which is your preference for first-up ?
[06:04] <poolie_> either; let's do the meta one
[06:05] <poolie_> i think, ideally, when people change an interface between two systems, they'd let people on the other side know
[06:05] <poolie_> obviously in this case you know a fair bit about the impact on bzr
[06:05] <poolie_> but, it's kind of disturbing
[06:06] <StevenK> wgrant: Stale lockfile found, and removed.
[06:06] <poolie_> i think we tend to post on the bug saying "i'm planning to fix this by responding to /+branchid/whatever and then rewriting the existing branches..." or whatever it is
[06:06] <poolie_> it doesn't need to take a long tihme
[06:07] <lifeless> poolie_: uhm, so I think that drives siloisation and adds a roadblock: we can debate the /size/ of the block (I'll acknowledge it could be quite low) - but what do we get for it ?
[06:07] <lifeless> poolie_: I'd rather encourage engineers to gather enough data to be confident - and socialise things sufficiently to be confident - and then get out and do it
[06:10] <lifeless> poolie_: I may be abbreviating the logic here; we can switch to voice if you want more bandwidth, or tell me to expand on stuff
[06:10] <StevenK> wgrant: set -x in this script sucks
[06:10] <StevenK> wgrant: And there's some partner errors
[06:10] <poolie> i'm not saying anyone needs affirmative permission from the other team to change things
[06:10] <poolie> that would cause siloization and blocking
[06:11] <poolie> i just find it disturbing there's no communication at all
[06:11] <lifeless> perhaps I'm categorising this differently
[06:12] <poolie> probably
[06:12] <lifeless> I see it rather like bzr choosing to use a different published api from lp - something that already exists
[06:12] <poolie> we need to work hand in hand to give a good system here
[06:13] <poolie> changing it without saying anything undermines the trust we need to do that well
[06:14] <lifeless> I'm extremely surprised now
[06:16] <jtv> I need to move to an English-speaking country.  Someone just told me something in Indonesian and I understood far too much.
[06:16] <poolie> :)
[06:17] <poolie> uh, maybe we should go to voice, but i should finish something here first
[06:17] <poolie> sorry to leave you hanging
[06:18] <poolie> wrt the actual change, is lp going to rewrite existing branches to use numeric ids?
[06:18] <lifeless> thats not entirely clear
[06:18] <lifeless> the basic plan is:
[06:19] <lifeless>  - do the work to expose numeric ids safely [secure, private branches support etc] on http and sftp and bzr://
[06:19] <lifeless>  - using a feature flag start offering the stacking targets numeric path rather than symbolic path, and see how it works
[06:20] <lifeless>  - we can look at a mass rewrite in future if it works well
[06:20] <poolie> ok...
[06:20] <lifeless> by offering I mean in the policy config file that bzr reads from LP
[06:20] <poolie> suggesting bzr stack on the numeric id
[06:20] <lifeless> yes
[06:21] <poolie> i think it's either something like this, or limiting renames
[06:21] <poolie> in a way, this is like introducing immutable names and then another set of names on top of them
[06:22] <lifeless> sure
[06:22] <lifeless> though we already have aliases for branches, so there is very little new stuff here
[06:23] <poolie> true
[06:23] <poolie> there's another bug about recipes breaking when branches are renamed
[06:23] <lifeless> its a duplicate
[06:23] <poolie> is it proposed to also rewrite recipes into numeric ids?
[06:23] <lifeless> recipes actually track branches by id in the db
[06:23] <lifeless> the breakage is when the thing that a recipe branch is stacked on is renamed, AIUI
[06:23] <wgrant> That's right.
[06:24] <lifeless> the recipe branch becomes unusable
[06:24] <wgrant> All the cases I've seen have been stacking breakage.
[06:24] <poolie> oh, ok
[06:24] <poolie> i see, it was just duped on the weekend
[06:24] <wgrant> Yeah, I missed that last week :/
[06:24] <poolie> will there be a public way to discover the id for a branch?
[06:25] <poolie> (or maybe there already is in the api?)
[06:25] <poolie> i guess this disturbs me because ... it seems like a lot of launchpad development happens behind closed doors
[06:25] <poolie> even from the point of view of someone about as close to the project as you can be without actually working on the team
[06:26] <poolie> i don't understand why people don't just say "the plan is X" on the bug
[06:26] <poolie> (to go back to the meta question)
[06:27] <poolie> it's fine for you guys to decide to just do this
[06:27] <poolie> it just feels wasteful to have all these "oh, when did lp start doing X?" questions, even after reading most of the bug mail and all of the devel list
[06:28] <lifeless> poolie: FWIW, I feel somewhat disconnected on recent bzr stuff; its much harder than I expected to track it unless I read all #bzr backlog
[06:29] <poolie> it may be a grass-is-greener thing
[06:29] <lifeless> poolie: I think a policy saying 'say what your intent is on the bug' is problematic in a few ways
[06:29] <lifeless>  - changing bugs leads to 'me too' and 'have you thought of X' comments [even from you!] which can be a bit of a drain to deal with
[06:29] <poolie> :) indeed
[06:30] <lifeless>  - the change is going to get reviewed during code review, and if its 'feature scale' jml, and if its important blogged about on the blog anyway
[06:31] <poolie> on the first point: that effect does happen, but it's pretty much saying "working in the open is annoying"
[06:31] <lifeless>  - plans often don't survive contact with the enemy^Wcodebase; theres some sort of balance between communicating eagerly and drowning in out of date data
[06:31] <lifeless> I disagree that its equivalent to 'working in the open is annoying'
[06:32] <poolie> on the 3rd; i agree, i'm just wishing for a bit more
[06:33] <poolie> well
[06:34] <poolie> having bug reports, or talking about what you're doing at all, encourages people to comment
[06:34] <poolie> some of those comments will be helpful and some will be noise
[06:36] <poolie> so do you see any value in such a policy, or do you think it's just a waste?
[06:37] <poolie> by policy i mean more like 'custom' than 'legally mandated'
[06:38] <lifeless> I think its a waste - its treating a symptom not a cause
[06:38] <lifeless> I don't know what the cause is
[06:39] <poolie> anyhow, the root request is
[06:39] <lifeless> but the fact you felt trust was betrayed by this suggests that its not at all about communication of intent
[06:39] <poolie> i'd like to know if launchpad's going to change the way it interacts with bzr
[06:39] <poolie> i realize in theory there is an abstraction, but in practice we deal with lots of things that cross that abstraction
[06:40] <poolie> probably several dupes of that bug were originally filed against bzr, for instance
[06:40] <lifeless> this gets my hackles up, and I don't know quite why
[06:40] <poolie> some possibilities:
[06:41] <poolie> * it really should be a shiny abstraction and i shouldn't need to know about it
[06:41] <poolie> * i ought to read the lp commits too
[06:41] <poolie> * i ought to find out about it on demand when it becomes a problem, not ahead of time
[06:42] <lifeless> The closest thing I am bringing to mind when I think about similar problems I face is my first statement as TA nearly a year ago: (paraphrased) I'm a resource not a control
[06:42] <poolie> * lp shouldn't describe this in the bug ahead of time but rather on the blog or release notes or something after it happens
[06:43] <poolie> yeah, interesting comparison
[06:44] <poolie> perhaps i should be asking myself why tim didn't choose to talk to or tell me about it
[06:44] <poolie> or you
[06:45] <poolie> ?
[06:45] <lifeless> I didn't because right now is the first time I saw you since the discussion with Tim on Friday; and it had slipped my mind since then because its not in my critical-quadrant : its vapourware [as its not done yet and may have sandtraps] and its [in my assessment] low risk right up to the point where we start changing the policy
[06:46] <lifeless> I was up to 4am this morning after Lynne had an asthma attack in the weekend - had to go into the 24 hour clinic.
[06:46] <poolie> sorry to hear that
[06:46] <lifeless> This tends to clear ones mind of dander
[06:46] <lifeless> shes ok, its just context.
[06:46] <lifeless> like, if the discussion happened monday and I saw you tuesday, vs this
[06:47] <lifeless> also we have serious scaling issues with batch nav, and most of my [shredded] brain today has been looking at that, dealing with stale trees that won't bootstrap on lucid, design etc
[06:47] <poolie> it's not an emergency, especially if it's not contemplated to be turned on suddenly
[06:48] <lifeless> and coordinating the downtime on wed [which is largely a communication exercise, but we're still in the process of changing to make it faster and more robust, so requires care]
[06:49] <poolie> so i guess overall
[06:49] <lifeless> I think to do our job well, the LP team needs tools and space; you need to trust that if an engineer thinks an LP change will impact the bzr *team*, that they, or their line manager, will raise it.
[06:49] <lifeless> just as LP needs to trust that bzr won't jump CPU use by 20% in a point release [for instance]
[06:50] <lifeless> if the LP team doesn't have that trust from you at the moment, we need to figure out why that isn't the case, and what we need to do about it.
[06:51] <poolie> yeah, that is the key issue
[06:51] <poolie> i wonder
[06:52] <lifeless> LP needs the room to make mistakes (and fix them rapidly) - because rapidly fixing things that do break is cheaper overall than avoiding every breakage [but different changes have different risks - there is no golden rule]
[06:52] <poolie> i'm trying to think of any other changes in lp that have affected us since orlando and the squad structure
[06:52] <poolie> i can't think of any
[06:53] <lifeless> there is the beta redirect
[06:53] <lifeless> bah
[06:53] <lifeless> edge
[06:53] <poolie> i don't think there have been a lot of changes there either way
[06:53] <lifeless> which failed and was reverted
[06:53] <poolie> yes, that was .. kind of ok, but kind of messy
[06:53] <lifeless> its queued up in RT
[06:54] <poolie> i guess at the moment i just come back to that being told this would change would have built more trust
[06:54] <poolie> if you tell me about the probably-won't-hurt thing, i know you'll tell me about the dangerous things
[06:54] <lifeless> I want the bzr integration in LP to be not at all special: special cases have higher friction and get less traction from self-directed folk unless they have a vested interest
[06:54] <poolie> agree
[06:55] <lifeless> poolie: still sounds like you have a lack of trust, or a need for control
[06:55] <poolie> it does
[06:56] <poolie> i have the impression lp has sometimes broken things in ways we could have avoided if we'd been asked
[06:57] <poolie> so, that causes a feeling of not trusting that they will ask quite enough
[06:58] <lifeless> it seems to me there are many things that could cause that:
[06:58] <lifeless>  - top down management [above both bzr and lp | above the relevant engineer] deciding something
[06:58] <lifeless>  - lack of knowledge [unknown unknown: engineers involved didn't know enough to know that they didn't know enough]
[06:59] <lifeless>  - lack of attention to detail / cavalier changes / something
[06:59] <lifeless>  - deadlines
[06:59] <poolie> i guess, in particular, stacking has had a lot of bugs that cross both systems
[06:59] <poolie> so, to me, it seems obvious to check on both sides before changing it
[06:59] <lifeless>  - previous miscommunication [thought that they were doing the right thing on a prior agrement about direction]
[06:59] <poolie> (even a pretty shallow change, like this)
[07:00] <lifeless> well, you've gone from general issue [trust] to specific issue [stacking is a special case]
[07:01] <poolie> we've probably seen all of those causes
[07:01] <poolie> ah, i'm saying stacking seems like a good example of the general issue
[07:03] <poolie> so looking at this list
[07:03] <lifeless> so, telling you about small changes as a predictor for telling you about dangerous changes, is a poor metric
[07:03] <poolie> this is perhaps a case where it's easy to put in more protection to guard against previous mistakes
[07:03] <poolie> indeed
[07:04] <poolie> (easy but possibly fallacious)
[07:04] <poolie> so, in short, you think i should just trust lp to tell us if it is dangerous?
[07:04] <lifeless> as its a poor metric, I don't think it would build trust - it would diminish it [because it would fail to predict, and you would feel betrayed]
[07:04] <poolie> seems pretty easy on both sides
[07:04] <poolie> how will we know if it's not working?
[07:05] <lifeless> poolie: it? this specific change?
[07:06] <poolie> let's back up
[07:06] <poolie> > so, in short, you think i should just trust lp to tell us if it is dangerous?
[07:06] <poolie> i meant that
[07:06] <lifeless> ok
[07:07] <poolie> that's a nice scalable algorithm
[07:07] <poolie> i had got the idea that it wasn't working well enough
[07:09] <lifeless> I expect failures in the algorithm.
[07:09] <lifeless> I think thats ok.
[07:10] <lifeless> I expect failures everywhere.
[07:10] <lifeless> A /huge/ chunk of my non-timeout-coding-changes work has been about making it easier for us to change, to undo things so we can get back to known good states; to reduce the number of things changed at once to make diagnosis easier etc.
[07:11] <lifeless> The risk is that a really dangerous change [high impact, high probability of going wrong, lots of user costs and black marks for lp and bzr] will get through
[07:12] <lifeless> the reason I say that *that* is a risk, not 'some bad changes will get through', is because that sort of change can be hard to recover from.
[07:12] <poolie> yeah
[07:13] <poolie> of course in the past changes were very hard to undo
[07:13] <lifeless> But OTOH thats why we have the oversight we do: most changes are seen by 2 people (engineer, manager, or engineer, reviewer), larger ones have sysadmins see them, more chance of random eyeballs on the diffm etc
[07:13] <poolie> both through the deployment cycle, and because people would have moved on
[07:13] <lifeless> right
[07:13] <lifeless> thus the squad structure & nodowntime deployments
[07:14] <poolie> so small-medium size problems can be tolerated more
[07:15] <lifeless> right
[07:15] <lifeless> not appreciated, but tolerated
[07:15] <lifeless> what we trade to get that is [we hope] less churn on engineers, more focused time looking at the problem - things that *help* with flow, with analysis and good solutions.
[07:16] <poolie> thanks for talking it over
[07:16] <lifeless> I'm happy to
[07:16] <poolie> so the short story is, relax, poolie, trust people will ask if something really does need external input or risk-assessment or coordination
[07:16] <poolie> and if it turns out things are actually slipping through too much, we can debug then?
[07:16] <lifeless> right
[07:17] <poolie> fair enough
[07:17] <lifeless> I realise the outcome of a messup is likely to be dramatic and widespread with bzr
[07:17] <poolie> probably this new setup is different enough we should have a blank scorecard
[07:17] <lifeless> ditto the archive / ppas though
[07:17] <poolie> yeah
[07:17] <poolie> and, rightly or wrongly, i feel we field a lot of the user support and complaints
[07:17] <poolie> certainly some fair fraction of it
[07:17] <poolie> anyhow, let's try that
[07:18] <lifeless> I'm sure you do
[07:18] <lifeless> the best thing we can do to reduce that is to fix bugs like this so that folk don't encounter problems ;)
[07:18] <poolie> indede
[07:19] <lifeless> we have mearly 400K branches on LP
[07:19] <lifeless> thats a looooot of room for bugs to cause support tickets
[07:20] <maxb> On the topic of mentioning possible solutions on bugs, I'm pretty sure I mentioned this possible option (branchid in URLs) on a bug several months ago :-)
[07:21] <maxb> lifeless didn't like it much at the time, I recall
[07:21] <poolie> i thought so too :) so that added to my surprise
[07:22] <poolie> i thought there was a religious prohibition against exposing database keys
[07:22] <poolie> though, i guess mps already break that, and perhaps also others
[07:22] <StevenK> poolie: Talk to MPs
[07:22] <lifeless> sometimes the simplest thing is the best thing
[07:22] <lifeless> bug ids
[07:22] <lifeless> merge proposals
[07:22] <lifeless> questions
[07:22] <StevenK> Bugs and questions are already "special" anyway
[07:22] <StevenK> How else are you going to identify them?
[07:23] <lifeless> StevenK: ask for a unique name
[07:23] <poolie> so in some ways i actually wanted to ban renames, because they break people's bzr checkouts etc in confusing ways
[07:23] <lifeless> StevenK: like e.g. stack exchange
[07:23] <poolie> possibly avoiding that is better
[07:23] <StevenK> lifeless: Oh, awesome. I just fixed bug nmnfgolwnpgwnepgnwgp
[07:23] <maxb> Banning renames is quite harsh
[07:23] <poolie> people can re-push if they want to change ownership etc
[07:23] <lifeless> poolie: my experience with users is that when you ban something, they will do it by hand
[07:23] <lifeless> poolie: and make the situation even worse
[07:23] <poolie> lifeless, stackexchange's primary key is a number
[07:23] <poolie> the name is just icing, i'm pretty sure
[07:23] <poolie> yeah, maybe so
[07:24] <poolie> i'm happy to give this a try
[07:24] <lifeless> put it this way; if the lp team cannot make sensible decisions as a bzr hosting site, sourceforge and savannah have /no hope/
[07:24] <poolie> or i should say happy for you to give this a try
[07:24] <poolie> i think the main place this comes up is in changing ownership, and perhaps we should address that more directly
[07:24] <poolie> :)
[07:24] <poolie> indede
[07:24] <lifeless> we need to debug and fix *that* problem, if it exists.
[07:25] <maxb> poolie: Do you think this is actually going to break anything? Other than involving stacking at all, it seems pretty un-scary
[07:25] <lifeless> stub: we forgot to speak on thursday
[07:26] <lifeless> stub: is now convenient ?
[07:26] <poolie> maxb, i reckon it will have a couple of non-critical bugs
[07:26] <poolie> if i could tell you exactly what they will be i would
[07:26] <lifeless> StevenK: you know that lp:~stevenk/launchpad/unmatched-brackets-annoyance is breaking a half-open range, right ?
[07:26] <poolie> anyhow, to draw a line under it, i'm not trying to veto the change; thanks for talking it over; i'll trust lp more
[07:27] <lifeless> poolie: cool, thanks.
[07:27] <poolie> we can talk tomorrow if you'd like to catch up on bzr
[07:27] <lifeless> poolie: thursday would be good actually, I have a tonne of bits to sort out
[07:27] <StevenK> lifeless: wgrant already pointed out the fail and the branch and MP are already deleted.
[07:27] <stub> lifeless: Gimme a minute... the coffee is still kicking in.
[07:28] <lifeless> stub: ping me in a few then
[07:32] <lifeless> hmm
[07:32] <lifeless> UDS coming up
[07:32] <lifeless> I suspect we'll see more of https://bugs.launchpad.net/launchpad/+bug/735970 soon
[07:32] <_mup_> Bug #735970: Person:+specworkload timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/735970 >
[07:34] <poolie> :) probably
[07:38] <lifeless> ! 5% of open LP bugs were reported by me
[07:39] <StevenK> I would have expected higher
[07:39] <wgrant> Bah, only 3% are mine.
[07:40] <lifeless> StevenK: it is, I'm rounding
[07:41] <lifeless> 7.7M requests yesterday
[07:41] <wgrant> Interesting.
[07:41] <lifeless> non-opstats
[07:41] <lifeless> previously these were spikes
[07:41] <wgrant> Hmm. 3.1% of open bugs are mine, and 3.0% of all bugs.
[07:42] <wgrant> Oddly stable.
[07:42] <lifeless> I think we're either in UDS swell, or we've got some new api clients [most of the growth is api.]
[07:42] <wgrant> But you said there were 500M new non-API requests.
[07:42] <lifeless> yeah
[07:42] <lifeless> we were tending to do 6M a day
[07:43] <lifeless> so growth of 1.7M and 1/3 is non api. domains
[07:43] <lifeless> wgrant: StevenK: wallyworld__: was my post on our capacity planning/deployment changes useful ?
[07:44] <lifeless> should I do more such things? less? include other details?
[07:44] <wallyworld__> lifeless: haven't read it yet sorry
[07:44] <lifeless> wallyworld__: no need to apologise
[07:44] <wallyworld__> lifeless: was it email? i'm a bit behind
[07:44] <lifeless> email
[07:44]  * wallyworld__ looks
[07:44] <wgrant> lifeless: Wasn't really useful for me, since I've been following it all pretty closely anyway.
[07:45] <wgrant> lifeless: But I think it was probably generally useful.
[07:46] <lifeless> wgrant: NullBT is truely dead right ?
[07:49] <wgrant> lifeless: The number of instances of that string in the tree is 0.
[07:49] <wgrant> So I presume so.
[07:49] <lifeless> we can trim a feature rule then
[07:49] <wgrant> Ah, forgot about that.
[07:50] <wgrant> Assuming we get nodowntime out before tomorrow morning, we should be able to drop the timeout on Wednesday.
[07:50] <lifeless> wgrant: thursday
[07:50] <lifeless> wgrant: IFF it looks good
[07:50] <StevenK> To 8s?
[07:50] <wgrant> Oh?
[07:50] <wgrant> Oh, right, release.
[07:50] <lifeless> wgrant: downtime please :)
[07:50] <wgrant> lifeless: Also, we can drop the publicrestrictedlibrarian rule after the release.
[07:50] <wgrant> lifeless: true, true.
[07:50] <lifeless> cool
[07:51] <StevenK> Can we remove edge now?
[07:51] <lifeless> StevenK: no
[07:51] <wallyworld__> lifeless: i found it really useful. i had never seen that information anywhere before (it may be on the wiki but i haven't seem it). thanks for posting it
[07:51] <lifeless> StevenK: we need to do the redirect for everything but bzr and api clients
[07:51] <lifeless> wallyworld__: cool, thanks
[07:52] <StevenK> lifeless: I've been thinking about it. Couldn't we hack the prod apache's to also answer for edge?
[07:52] <wgrant> lifeless: We can drop the Archive:+index override, I think.
[07:52] <wgrant> The latest PPR shows nothing above 12s.
[07:53] <wgrant> And even that is a tiny fraction of 0.1%.
[07:53] <wgrant> 99% under 6.81
[07:53] <lifeless> sob - src/lazr/batchnavigator/README.txt is not end user docs.
[07:53] <lifeless> wgrant: cool!
[07:53] <lifeless> StevenK: no
[07:54] <lifeless> StevenK: for apis, the wadl includes the domain and thats hashed
[07:54] <lifeless> StevenK: you cannot serve the wadl for domain A from a server that thinks its domain B
[07:54] <lifeless> StevenK: and, LP doesn't believe in multiple root-urls, its a server wide config
[07:56] <lifeless> stub: yo
[07:57] <stub> lifeless: yo. Caffeinated, showered, human (fsvoh)
[07:57] <lifeless> \o/
[07:58] <lifeless> calling
[07:58] <stub> lifeless: skype just hung
[07:59] <lifeless> wops
[07:59] <stub> Wow... needed -9
[07:59] <lifeless> -o-
[08:00] <lifeless> must be running zope
[08:09] <LPCIBot> Project windmill build #138: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill/138/
[08:39] <adeuring> good morning
[08:39] <StevenK> henninge: Hi! Would you like to mentor wallyworld__'s review of https://code.launchpad.net/~stevenk/launchpad/dsd-cant-request-resolved/+merge/56097 ?
[08:42] <henninge> StevenK: sure
[08:44] <thumper> poolie: sorry, just back for a stint
[08:44] <thumper> poolie: had caitlin at the doctor, and now she is at the emergency dept awaiting an xray
[08:44] <thumper> I'm home making dinner now
[08:44] <thumper> after talking with lifeless, we are going to stack on the branch id yes
[08:44] <thumper> using a particular alias
[08:45] <poolie> thumper, sorry to hear that
[08:45] <poolie> hope she's ok
[08:45] <poolie> that sounds good
[08:45] <poolie> thanks for working on it, it's quite a headache bug
[08:54] <henninge> StevenK: r=me
[08:54] <StevenK> henninge: Thank you!
[09:18] <lifeless> wgrant: https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-timeout-candidates.html still has plenty of risky pages
[09:19] <lifeless> oh wow
[09:19] <lifeless> https://launchpad.net/ubuntu/natty/+cve
[09:20] <lifeless> notice htat all the cves for a source package are listed against each bug for that selfsame package
[10:09] <allenap> lifeless: Thanks for reverting the state of that test runner bug. I thought that --no-qa would leave the bug alone, but that was a stupid assumption. Gah, I hate tracking QA in bug tags.
[10:09] <lifeless> no worries
[10:09] <lifeless> if you don't want it linked, don't link it ;)(
[10:10] <lifeless> noqa does what it says on the box - no qa needed
[10:10] <lifeless> allenap: I'm really glad you did that patch
[10:11] <lifeless> allenap: It might be worth mailing the list to let folk know that test ids are changing - it will affect folk using testr run --failing
[10:13] <allenap> lifeless: Okay, good idea (to email). Fwiw, I like linking related branches even if they don't fix the bug; their presence may help others understand the problem better, and it's a shame not to link them because of the QA process we have.
[10:16] <wgrant> bigjools: Evening.
[10:16] <bigjools> helleau
[10:17] <wgrant> bigjools: We're now running entirely on poppy-sftp, and it seems to be working fine.
[10:17] <lifeless> allenap: its not the qa process thats the issue; its the 'close bugs that were linked
[10:17] <lifeless> '
[10:17] <lifeless> allenap: that is a separate bug related process
[10:18] <bigjools> wgrant: \o/
[10:18] <lifeless> s/bug/but/
[10:18] <bigjools> wgrant: when it's settled for a bit we can stop it throwing oopses for badly-signed uploads
[10:18] <wgrant> bigjools: Yup.
[10:22] <allenap> lifeless: Okay, yes. At the moment we QA each branch, and tracking that in the bug seems wrong unless we restrict ourselves to one branch per bug. We may also want to consider QA on a fixed bug as a whole, and that makes sense to track on the bug. You know all of this already, I just want to express that I find it frustrating and interrupting.
[10:28] <bigjools> wgrant: I'm rather pleased that it seems to only have had that one bug :)
[10:29] <wgrant> bigjools: Well, plus at least one other non-critical.
[10:29] <wgrant> (the DB user)
[10:29] <bigjools> e_notabug
[10:33] <jtv> henninge, dear former teammate, are you up for a review?  http://launchpad.leankitkanban.com/Boards/Show/14028617
[10:33] <jtv> Ahem
[10:33] <jtv> I *said*
[10:33] <jtv> "Copy"
[10:33] <jtv> https://code.launchpad.net/~jtv/launchpad/bug-745542/+merge/56106
[10:34] <jtv> Good thing that didn't happen on schoolgirlswithdungeondimensionbeasts.com
[10:34] <jtv> Hmm I sense potential there
[10:34] <henninge> jtv: interesting board, much more sophisticated than ours.
[10:35] <jtv> What do you know, that domain name's still available!
[10:35] <lifeless> allenap: sure, I agree its suboptimal
[10:35] <henninge> who would have guessed
[10:35] <henninge> jtv: Anyway, I'll have a look at your MP in a minute.
[10:35] <jtv> thanks
[10:35] <lifeless> allenap: In this particular case though, even if we had an entirely separate qa system, we'd still not want the bug linked, because we close linked bugs
[10:39] <allenap> lifeless: I guess there's a tension there: the convenience of automatically closing bugs restricts us from linking related branches to bugs.
[10:39] <lifeless> allenap: yes
[10:39] <allenap> If I break up a bug fix into multiple branches (via a pipeline say) to make review simpler I either have to file bugs for each step, or wait until the end to land it as one.
[10:39] <lifeless> allenap: huh, no
[10:40] <allenap> So there's a motivation to create larger branches to avoid the bureaucracy.
[10:40] <lifeless> allenap: I disagree with your assertion that you need bugs for each step
[10:41] <allenap> lifeless: If I want to land each step then I do.
[10:41] <lifeless> allenap: why?
[10:41] <allenap> lifeless: QA.
[10:41] <allenap> And auto-closing.
[10:41] <lifeless> so lets separate them
[10:41] <lifeless> autoclosing is I think generally something we should remove
[10:42] <lifeless> because more and more bugs are not fixed by the deploy
[10:42] <lifeless> but by enabling a feature flag to expose the thing
[10:42] <allenap> Good point.
[10:42] <lifeless> for qa, we can only qa one thing on a bug at a time, but that doesn't preclude multiple landings
[10:43] <allenap> Okay, fair. Without auto-closing that works.
[10:43] <lifeless> as long as you say clearly somehow [e.g. we could use tags, or comments, or whatever] that the landing is incremental
[10:43] <allenap> Ah, there is an incremental tag already :-/
[10:43] <lifeless> then the human coordinating the deploy [ wgrant, me, matsubara etc etc etc ] can not close it for you
[10:43] <allenap> Which I had forgotten all about!
[10:43] <wgrant> allenap: --incr is a bit broken at the moment :(
[10:43] <lifeless> the --incr to lp-land seems broken
[10:44] <allenap> Oh, okay.
[10:44] <lifeless> but thats a small matter of code
[10:45] <allenap> Is that in qa-tagger?
[10:45] <lifeless> IIRC yes
[10:45] <lifeless> it currently doesn't tag at all
[10:46] <lifeless> but it needs to say something like incremental-rev-XXXX, and then in the deploy report treat that as qa-untestable [or better yet have it be orthogonal to qa'ability
[10:46] <lifeless> I haven't hit frustration-powered-fixing level yet
[10:46] <lifeless> hopefully someone else will beat me to it
[10:47] <wgrant> Exactly, I just go along and tag them untestable.
[10:47] <allenap> I'll see if I can get bothered enough :)
[10:47] <wgrant> It is irritating, but not worth fixing it :P
[11:50] <jml> bigjools: hello
[11:51] <bigjools> yo
[11:54] <jml> bigjools: today is the day
[11:54] <jml> bigjools: the day that is happening right now
[11:54] <jml> bigjools: would you like to talk about derived distros?
[11:54] <bigjools> jml: I would
[11:55] <jml> bigjools: is now good?
[11:55] <bigjools> it is
[11:55] <bigjools> I'm enskypeinating
[11:56]  * jml waits
[11:57] <bigjools> jml: "call refused"
[12:02] <deryck> Morning, all.
[12:22] <henninge> jtv: r=me
[12:22] <jtv> henninge: dankeschön
[12:22] <henninge> bitteschön
[12:54] <jtv> henninge-lunch: I followed up to your review… please let me know if that satisfies you!
[12:54] <jtv> I'm off soon myself.
[13:09] <gary_poster> jml, hi.  Sorry, I did not forget to prep Friday for today's mtg, but I did run out of time.  I should have prep ready for you within an hour or an hour and half, with other stuff going on.  For better and worse, I don't think I have a lot to write up.
[13:11] <jml> gary_poster: ok, thanks.
[13:27] <dpm> hi all, I was trying to find out what's going on with the gdm translations, which don't seem to get imported from package uploads. My guess is that translations for gdm are now being imported from bzr upstream branches. However, the branch set for https://launchpad.net/ubuntu/natty/+source/gdm is not correct, as we're not using 'master' for natty, but 'gnome-2-32'.
[13:28] <dpm> Could someone confirm if this makes sense?
[13:28] <dpm> Can LP do imports of upstream branches other than the main upstream branch?
[13:30] <james_w> dpm, for git?
[13:30] <dpm> james_w, yeah, gnome's git in this case
[13:30] <james_w> dpm, that's not currently possible
[13:31] <dpm> thanks james_w, just to have some background info, do you (or anyone else) know if this is a planned feature or something getting worked on?
[13:31] <james_w> dpm, it is being worked on, but I don't know what's left to do
[13:32] <james_w> #bzr could tell you
[13:32] <jelmer> james_w, dpm: It's very close
[13:33] <dpm> james_w, ah, cool, thanks. jelmer, is this a bzr feature, rather than a LP one, then?
[13:33] <jelmer> I have one lp:bzr branch that needs fixing and there's some fairly trivial changes that have to be made in bzr-git
[13:33] <jelmer> dpm: Yes - you'll be able to specify e.g. "git://git.samba.org/samba.git,RELEASE_3_5" as a URL on Launchpad
[13:33] <jelmer> sorry, "git://git.samba.org/samba.git,branch=RELEASE_3_5" as a URL on Launchpad
[13:34] <dpm> jelmer, excellent. Is there any way I can track find out when the feature is completed? Is there e.g. an open bug I can subscribe to?
[13:35] <jelmer> dpm: bug 380871 covers it (but is broader than just this)
[13:35] <_mup_> Bug #380871: support for colocated branches <code-import> <lp-code> <Bazaar:In Progress by jelmer> <Bazaar Git Plugin:Fix Released by jelmer> <Bazaar Hg Plugin:In Progress by jelmer> <Launchpad itself:Triaged> < https://launchpad.net/bugs/380871 >
[13:36] <dpm> ok, thanks jelmer!
[13:37] <danilos> benji, btw, have time to review that branch of mine? :)
[13:37] <benji> danilos: I'll trade reviews for voice lessons.
[13:37] <danilos> benji, haha, it's a deal
[13:52] <rvba> henninge-lunch: benji: Hi, I'd appreciate a review of https://code.launchpad.net/~rvb/launchpad/dds-add-missingpackages-page2/+merge/56136
[13:55] <henninge> jtv-afk: agreed and replied
[13:55] <henninge> rvba: looking
[14:00] <deryck> henninge, ping for standup
[14:00] <henninge> deryck: yeah, setting up mumble right now ...
[14:21] <jml> anyone seen this librarian test failure before?
[14:24] <jml> *ahem*
[14:24] <jml> _this_ test failure: http://paste.ubuntu.com/589261/
[14:25] <deryck> jml, I've seen that before.  Once.  It's been awhile, though.
[14:25] <deryck> jml, I don't recall what it was, sorry.  I *think* it was masking another failure somewhere....
[14:25] <deryck> but could be recalling wrong.
[14:26] <jml> deryck: ok, thanks.
[14:26] <jml> deryck: I can't see any bugs filed for it, so I'll file one just in case.
[14:26] <deryck> jml, thanks, I know I didn't file a bug.
[14:28] <rvba> jml: if I remember correctly I've been told this is a spurious failure ....
[14:28]  * rvba checks his logs
[14:29] <wgrant_> jml: Known spurious... I thought it was filed.
[14:31] <jml> filed https://bugs.launchpad.net/launchpad/+bug/750274
[14:31] <_mup_> Bug #750274: librarian.txt fails sometimes <build-infrastructure> <librarian> <spurious-test-failure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/750274 >
[14:37] <deryck> bac, ping
[14:38] <bac> hi deryck
[14:39] <deryck> hi bac.  lib/lp/app/javascript/tests/test_accordionoverlay.html is failing because the linked test file is missing....
[14:39]  * bac looks
[14:40] <deryck> bac, yeah, just wondering if this was intentional.  Or if I'm stupid and doing something wrong.
[14:40] <bac> deryck: oh, i'm sure it isn't the latter
[14:40] <bac> or the former, either
[14:40] <deryck> heh
[14:43] <bac> deryck: that test is deprecated and should've been removed
[14:44] <deryck> bac, ok, cool.  I'll do a branch to drop it then.  Thanks!
[14:44] <bac> deryck: thanks
[14:48] <gary_poster> jml, I'm feeling like I'm behind the times today :-/ but I have a first draft of what I intended to have for you.  https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications/FeatureReviewNotes
[14:48] <gary_poster> I suspect the parts with "XXX" are the parts that you want to see most.  I'm trying to get those filled in now.
[14:49] <bac> mrevell: ping
[14:49] <mrevell> hello bac
[14:51] <jml> gary_poster: thanks. :)
[14:53] <wgrant_> sinzui: Morning.
[14:53] <sinzui> I am afraid it is
[14:53] <bigjools> jml: I updated the LEP with my NRCP interpretations
[14:54] <wgrant_> sinzui: spm unbroke lists.staging.launchpad.net this afternoon, so I was able to mostly QA the mhonarc changes.
[14:54] <sinzui> \o/
[14:54] <sinzui> how was it unbroke?
[14:56]  * sinzui was going to ask a losa to make ~launchpad the team to access all lists in staging to satisfy the retarded code
[14:56] <wgrant> sinzui: It was running the new apache_openid, rather than the old mpopenid.
[14:56] <wgrant> sinzui: Yeah, I suggested whitelisting ~launchpad, but then decided we should try to unbreak it properly first.
[14:57] <sinzui> thank you very much. I think staging should be running what we run in production
[14:57] <wgrant> sinzui: So the old module (dpkg name apache-openid, python name mpopenid) was installed, and the config updated to match the old values in prod.
[14:57] <wgrant> This means that private teams are broken, but at least public teams work :)
[14:58] <wgrant> sinzui: There is some very odd syncing going on.
[14:58] <wgrant> sinzui: It has twice today overwritten the archives with prod ones... but apparently not the mboxes.
[14:58] <sinzui> ?
[14:58] <wgrant> https://lists.staging.launchpad.net/launchpad-users
[14:58] <wgrant> I've twice sent mail to that list today.
[14:59] <sinzui> I think I am familiar with the script that should do that
[14:59] <wgrant> Each time it updated to the new theme, using an mbox from December + my new message.
[14:59] <wgrant> But then an hour later it was on the old theme.
[14:59] <wgrant> And I tried creating new lists.
[14:59] <sinzui> I can follow up...since I had dedicated my day to getting that qaed
[14:59] <wgrant> They worked for a while, but then the MX rejected them after the archive was erased.
[15:00] <wgrant> (the ML still exists in the DB)
[15:00] <wgrant> So I think the mailman update script in fact does a mailman restore, even if it was just for an upgrade.
[15:00] <wgrant> sinzui: It would also be great if this was easily transferrable to qas.
[15:00] <sinzui> The restore script does an rsync
[15:01] <wgrant> It should probably only do that on a full restore.
[15:01] <sinzui> I agree, and will work on the test.
[15:01] <wgrant> Thanks :)
[15:01] <wgrant> LOSA ping.
[15:02] <sinzui> The test is one of the few that still want to be on the mailman layer, but a solid unitest on a lower layer is all that is needed
[15:02] <Chex> wgrant: hello there
[15:02] <bigjools> ooo what is this new AJAX Log
[15:02] <sinzui> Maybe I will abolish the mailman layer tests today. That would be very satisfying
[15:03] <wgrant> Chex: Hi! We merged db-stable into devel 12ish hours ago, so qastaging needs a bit of hand-holding which spm didn't have time to complete.
[15:03] <wgrant> Chex: I believe the DB is probably patched -- could you try restarting the services and see if they come up?
[15:03] <Chex> wgrant: sure thing, hang on
[15:04] <wgrant> bigjools: I take that to mean that the deployment just finished.
[15:05] <wgrant> bigjools: The AJAX log isn't completely awesome yet, but it will be soon.
[15:05] <wgrant> bigjools: (eg. it doesn't log URLs yet, since YUI makes them impossible to get)
[15:05] <bigjools> is it just showing the XHR requests?
[15:05] <wgrant> Right.
[15:05] <wgrant> Timings and status and OOPS information for now.
[15:06] <wgrant> (yes, a bug page makes like 10 requests on load)
[15:06] <bigjools> it's one way of not timing out single requests :D
[15:07] <bigjools> it needs a close button or click-outside-the-box-to-close event
[15:08] <wgrant> Does anyone have a bug description that they need to edit?
[15:11] <Chex> wgrant: ok, looks like the restart worked OK
[15:11] <wgrant> Chex: Indeed, thanks a lot.
[15:12] <benji> danilos: I got some tests failures and had a couple of very small comments on https://code.launchpad.net/~danilo/launchpad/refactor-overlay-setup/+merge/56146
[15:13] <wgrant> deryck: Thanks for cleaning up the windmill stuff. How did it go in ec2?
[15:14] <deryck> wgrant, 5 failures remaining.  Working through them today, then handing off to wallyworld when I EOD.
[15:14] <wgrant> deryck: Great!
[15:15] <wgrant> Its return to the default test run will be a mixed blessing, though :(
[15:15] <wgrant> Slooow.
[15:15] <deryck> yeah, it really is.
[15:15] <deryck> Once this is done, I turn my attention to an alternative.
[15:20] <danilos> benji, regarding the switch indentation, I let Emacs js-mode handle it, I don't have a preference, and re the comments, they were in there originally, I believe they contain useful information
[15:20] <danilos> benji, perhaps they should not be written as uncommented code though :)
[15:20] <danilos> benji, I'll also go through all the method/function comments and fix them as you suggest
[15:21] <benji> danilos: re. indentation; I only have a slight preference so I'm good with it staying
[15:21] <benji> re. comments: right, just a default that throws an exceptoin would be good
[15:22] <benji> danilos: re. comments: do you know if there is any reason to have the double astrisks?  I figured there is some API documentation tool (akin to javadoc) that extracts them, but I don't know that we actually use one
[15:24] <danilos> benji, yeah, there seems to be a pattern, I am unfamiliar with it myself as well
[15:29] <deryck> oh crap.  We're in rc only.
[15:30] <deryck> I had forgot we still bother with that. ;)
[15:32] <bigjools> not sure why we do it at all
[15:34] <gary_poster> jml, is there a very focussed LP team of yours that I can give the feature flag for the structural subscription stuff?  Ideally, for instance, you'd have a "LP product team" team or a "LP feature review" team
[15:34] <jml> gary_poster: ~pelicans
[15:35] <gary_poster> cool thanks jml
[15:36] <gary_poster> jml, https://launchpad.net/~pelicans does not exist
[15:36] <jml> gary_poster: it's private.
[15:36] <gary_poster> oh
[15:36] <jml> gary_poster: in which case, let's simplify to "no"
[15:36] <gary_poster> :-)
[15:37] <gary_poster> could you make a feature review team, then, jml?
[15:37] <gary_poster> or do something else like that?
[15:37] <jml> gary_poster: yes, but not right now
[15:37] <gary_poster> ideally it would be easy for you to add and remove people specifically for this purpose
[15:37] <gary_poster> ok, cool jml.  lemme know when and I'll finish up setting up the wiki page.
[15:38] <jml> gary_poster: will do.
[15:39] <gary_poster> thx
[15:48] <rvba> henninge: I've pushed 2 minor changes to my branch since you took it for review
[15:48] <henninge> rvba: np, still on it.
[15:49] <rvba> henninge: great, thx
[15:49] <henninge> rvba: what's your revno?
[15:50] <rvba> henninge: 12731
[15:50] <rvba> henninge: oops sorry: 12733
[15:50] <henninge> ah, I was starting to wonder.
[15:50] <henninge> rvba: that's the one I got. ;)
[15:51] <rvba> ok, everything is ok then
[16:02] <henninge> rvba: is there a derived series in the demo data or how do I create one?
[16:03] <rvba> henninge: yes there is https://launchpad.dev/deribuntu/deriwarty/+missingpackages
[16:04] <rvba> henninge: you have to enable the feature flag to access this page "soyuz.derived-series-ui.enabled default 1 on"
[16:04] <henninge> I did but the page is pretty boring ... ;)
[16:06] <rvba> henninge: indeed, there is no difference of the right type to show up on the new page ... one has to change the status of some of the existing differences
[16:07] <henninge> rvba: where/how do I do that?
[16:07] <rvba> henninge: hang on
[16:10] <rvba> henninge: update distroseriesdifference set difference_type=2;
[16:11] <rvba> this will change the type of the existing differences so that they show up on the new +missingpackages page
[16:11] <henninge> oh, I cannot do that in the UI?
[16:11] <henninge> ok
[16:12] <henninge> rvba: ah, now I see stuff
[16:12] <rvba> henninge: AFAIK no, not directly. These differences are computed by jobs.
[16:12] <henninge> ah, I understand
[16:13] <rvba> I probably should have included a few differences of the right type in current-dev.sql for good measure ;-)
[16:15] <henninge> I remember noodles worked on this
[16:15] <henninge> rvba: there is an UI issue.
[16:15] <henninge> also, it is confusing that the comment is empty.
[16:15] <rvba> henninge: yes, the comment slot needs some more work.
[16:16] <rvba> henninge: what is the issue?
[16:18] <henninge> http://people.canonical.com/~henninge/screenshots/review-rvba.png
[16:18] <henninge> rvba: The "blacklisted" radio buttons on the right.
[16:19] <henninge> They look completely misplaced.
[16:20] <rvba> henninge: I see ... I haven't touched these yet (they pre-existed before I started to work on this branch). But I completely agree with you.
[16:20] <rvba> s/this branch/this page/
[16:25] <henninge> rvba: did they actually look this way too, overlaping with the comment?
[16:25] <henninge> also they are aligned to .... nothing
[16:25] <henninge> oh, right-aligned, I guess
[16:25] <rvba> yes
[16:26] <henninge> strange
[16:26] <rvba> but I completely agree, this is very strange
[16:26] <henninge> rvba: to me it is strange that this passed UI review!
[16:27] <rvba> the reason might be that this is a feature that is in the works
[16:27] <henninge> rvba: Is it OK if we continue this tomorrow? I won't get through your branch before I have to EOD.
[16:27] <henninge> rvba: possible
[16:27] <rvba> will be tested on a very few number of users first
[16:27] <rvba> do you have a suggestion to fix this in a way that would be consistant with the rest of the UI?
[16:28] <henninge> I am not even clear what it is referring to
[16:28] <henninge> is it a filter?
[16:28] <rvba> no, is a status for the difference
[16:29] <rvba> you can change the status to blacklisted so you will not see it in the list ... next time you load the page
[16:29] <henninge> ah, I remember the orignial page that Michael did.
[16:29] <rvba> I guess he's the one who did the floating blacklisted slot in the first place :-)
[16:30] <rvba> henninge: note that this is less ugly when there is more data to display (https://dogfood.launchpad.net/deribuntu/dangerous/+localpackagediffs)
[16:33] <henninge> rvba: yes, that looks better.
[16:34] <henninge> rvba: but I don't see the Blacklisted thing, probably because of permissions.
[16:34] <henninge> rvba: but that's not our subject right now
[16:34] <rvba> henninge: indeed
[16:36] <henninge> rvba: I'll have to continue tomorrow morning, I am sorry. I have to leave soon. I hope that is ok.
[16:36] <rvba> henninge: sure, no problem. Just ping me tomorrow.
[16:36] <henninge> cool, thanks
[16:54] <danilos> benji, I've fixed all the problems you reported, hopefully the branch is much better now: I've only left the lint issues, though, they are in very long string construction
[16:55] <danilos> benji, (test failures due to my loading the test_ss.html from the wrong branch :/)
[16:57] <benji> danilos: cool, taking a look now
[16:59] <danilos> benji, heh, a left-over commented-out "debugger;" statement, removing that one as well
[17:02] <benji> cool
[17:12] <benji> danilos: approval plus a patch for some more-or-less lint issues: https://code.launchpad.net/~danilo/launchpad/refactor-overlay-setup/+merge/56146
[17:16] <allenap> benji: Thanks for the review :)
[17:16] <benji> my pleasure
[17:20] <danilos> benji, thanks; btw, what's your take on "concatenating strings with + is slower than array.join('')"? probably doesn't matter in this case where we've got ~60-70 strings being joined, but maybe worth considering
[17:21] <benji> danilos: good question; in modern CPythons it's roughly the same speed, I don't know about the various JS engines out there.  As you say, since we don't do it in any tight loops or anything it probably doesn't matter
[17:22] <benji> on the other hand, the code might look /slightly/ better with trailing commas instead of trailing <space><plus>, but that's pretty minor
[17:23] <danilos> benji, fwiw, I dislike multi-line vars as well, but I've seen them used so I continued the practice; I have not yet developed my personal JavaScript style and I am unsure about what is our existing one
[17:26] <benji> danilos: yep, I figured the code in question already existed and you just moved it, I wonder if pocketlint would have found it
[18:21] <deryck> we seem to have lost the "this is a duplicate bug, comment only if ..." message.
[18:21] <deryck> does anyone know, was this intended?
[18:23] <deryck> sinzui, do you perhaps know anything about this ^^?
[18:25] <sinzui> deryck: I do not know about that. I saw it a few days ago
[18:25] <deryck> sinzui, ok, no worries.  I'll ask around.
[18:25] <deryck> I'm guessing lifeless knows.  But it's still too early for him.
[18:25]  * deryck smells performance improvements at play
[18:26] <sinzui> deryck: I see it on this bug that I marked as a dupe a few hours ago: https://bugs.launchpad.net/launchpad/+bug/749419
[18:26] <_mup_> Bug #749419: Cannot undo bug status change if I lack permission to set the previous status <Launchpad itself:New> < https://launchpad.net/bugs/749419 >
[18:27] <deryck> sinzui, yeah, it's still on lpnet, but not on qastaging.  I only notice because of failing windmill tests.
[18:31] <sinzui> wtf. Someone linked Lp source code to a firefox plugin
[18:32]  * sinzui gets his axe
[18:32] <deryck> heh
[18:32] <deryck> I wondered about that, too.
[18:49] <deryck> ok, I feel like I'm going crazy.  Now I see the warnings again.
[19:03] <james_w> deryck, seen http://www.phantomjs.org/ ?
[19:06] <deryck> james_w, ah no.  I haven't.  Will look closely at that.
[19:06] <james_w> deryck, probably not equivalent to windmill/selenium, but if you wanted to build your own :-)
[19:06] <james_w> someone may already be doing that though
[19:07] <deryck> yeah, maybe so.
[19:07] <deryck> I certainly don't want to build it.
[19:07] <deryck> I'm starting to think YUI test in the context of the app server is really the best idea.
[19:08] <deryck> unless you really want end to end smoke test kind of thing.
[20:01] <bac> benji: i was able to finish adding the edit links everywhere...so there's nothing for you to do -- except review it, perhaps?
[20:01] <bac> benji: a MP has been submitted but hasn't shown up yet.
[20:02] <benji> cool, I'm working on one now and I'll do yours next
[20:04] <bac> benji: great
[20:04]  * bac afk for a bit
[20:24] <lifeless> morning
[21:03] <lifeless> statik_: ping ?
[21:07] <benji> ok bac, I'm done with https://code.launchpad.net/~bac/launchpad/add-edit-links/+merge/56247
[21:08] <bac> thanks benji
[21:43] <mtaylor> lifeless: do you know anything about the launchpad openid group extension as it relates to jenkins?
[21:48] <lifeless> mtaylor: not really, other than that we funded the openid plugin
[21:48] <mtaylor> lifeless: ok. I was trying to figure out why group information is coming through properly for me but not for other people
[21:49] <lifeless> well
[21:49] <lifeless> you need to be registered
[21:49] <lifeless> IIRC that is, we only give out group info to trusted agents
[23:36] <lifeless> jcsackett_: don't forget to qa on db-stable ;)
[23:47] <poolie> hi lifeless
[23:47] <lifeless> hi poolie
[23:48] <poolie> we can have a catch up call today if you like
[23:48] <lifeless> thursday would be better
[23:48] <lifeless> as I mentioned yesterday, I'm flat out just now
[23:50] <poolie> oh, sure