[00:08] <wgrant> lifeless: Is security.py going to end up in lazr-postresql too?
[00:11] <lifeless> no
[00:12] <wgrant> :(
[00:12] <lifeless> or at least, not in this arc
[00:12] <wgrant> How're you going to manage security?
[00:14] <lifeless> wgrant: for scriptactivity ? in the db patches themselves probably.
[00:14] <wgrant> Ah
[00:14] <lifeless> we have three types of patches in the new system
[00:15] <lifeless> std (goes via slonik)
[00:15] <lifeless> direct (applies to each node separately in a xact)
[00:15] <lifeless> concurrent (applies to each node separately outside of a transaction)
[00:22] <wgrant> lifeless: Right.
[00:31] <lifeless> thus doing create role & grant on all the nodes is straight forward
[00:34] <wgrant> Yeah, which security.py can do :)
[00:34] <wgrant> Just needs to be made fully nodowntime, which I didn't quite get around to last week.
[00:34] <lifeless> I eagerly await this shiny.
[00:35] <lifeless> for now, minimal is good.
[00:35] <wgrant> True, true.
[00:35] <wgrant> But minimal LP is better :)
[00:35] <lifeless> we could just ditch security.py
[02:18] <lifeless> and success - https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-c63bba67bbc99ffb6e41ba383cd87c88
[02:18] <lifeless> tomorrows oops report should indeed have bazaar soft timeouts
[02:18] <wgrant> I fear it.;
[02:18] <lifeless> they will be soft timeouts
[02:18] <wgrant> I still fear it.
[02:19] <lifeless> and as you can see, w/no timeline, its pretty opaque data at the moment
[02:21] <wallyworld_> wgrant: i think there's a bad rev on qas but i'd like a 2nd opinion to ensure i've set things up correctly
[02:21] <wallyworld_> do you have a moment?
[02:25] <wgrant> wallyworld_: The person limitedview thing?
[02:25] <wallyworld_> wgrant: yes
[02:25] <wgrant> What's the issue?
[02:25] <wgrant> Hmm
[02:26] <wgrant> Interesting.
[02:26] <wallyworld_> i have a private team with a ppa. i have subscribed someone to the ppa. but theu can'
[02:26] <wgrant> Something is broken, yeah.
[02:26] <wallyworld_> t get to it
[02:26] <wallyworld_> team is ~private-foobarx
[02:26] <wallyworld_> i have subscribed xgy-ian to the ppa
[02:27] <wallyworld_> but when i login as xgy-ian, i get Unauthorized on https://qastaging.launchpad.net/~private-foobarx/+archive/ppa
[02:27] <wallyworld_> that's wrong, right?
[02:27] <wgrant> Should be, yes.
[02:27] <wgrant> Let me just fetch my testing account.
[02:27] <wallyworld_> ok
[02:27] <wallyworld_> there's 2 bugs
[02:28] <wallyworld_> one is not any worse, so is technically qa-ok
[02:28] <wallyworld_> but i hate marking a bug that doesn;t fix the issue as qa-ok :-(
[02:28] <wgrant> Hmm
[02:29] <wgrant> I think traversal may be failing.
[02:29]  * wgrant checks.
[02:29] <wallyworld_> yes
[02:29] <wallyworld_> that's my suspicion
[02:29] <wgrant> eg. if you go to https://qastaging.launchpad.net/api/devel/~private-foobarx?ws.accept=application/json you get an Unauthorized for account_status
[02:29] <wgrant> Which is checked during traversal.
[02:29] <wallyworld_> when i went on leave, the 2 branches i had were wip but curtis landed them with some fixes
[02:31] <wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-40786f88f5a5251bc6910b6f6b1ad083
[02:31] <wgrant> Traversal is indeed failing.
[02:31] <wgrant> qa-bad
[02:31] <StevenK> Hm, it looks like Curtis fixed my branch but didn't land it.
[02:32] <wallyworld_> wgrant: should i mark both bugs as qa-bad
[02:32] <wallyworld_> even though one of them is just as borken as before
[02:32] <StevenK> wallyworld_: qa-bad and bad-commit-<rev>
[02:32] <wallyworld_> ok
[02:32] <wgrant> "just as borken" == "people who are subscribed to branches owned by other private teams still can't see them"?
[02:32] <StevenK> I need to smack people for not adding bad-commit-<>
[02:32] <wallyworld_> wgrant: yes
[02:33] <wgrant> wallyworld_: Doesn't really matter.
[02:33] <wgrant> If they're the same rev.
[02:33] <wallyworld_> i marked it as qa-ok by mistake
[02:33] <wallyworld_> StevenK: how was your week off?
[02:33] <StevenK> It was excellent.
[02:33] <wallyworld_> stayed home?
[02:34] <StevenK> Yeah, I stayed home and played games all week.
[02:34] <wallyworld_> excellent. i went to the beach. limited internet so very relaxing :-)
[02:35]  * wallyworld_ goes to rollback the bad rev
[02:35]  * StevenK goes for lunch, with a plan to look carefully at the ec2 failure mail from this branch.
[02:47] <lifeless> wgrant: I know you are not here, but are you doing to land your config changes?
[02:48] <wgrant> lifeless: Two are in PQM now.
[02:48] <wgrant> One conflicts with mthaddon.
[02:49] <wgrant> And the last conflicts with the two that are landing now, so I'll merge and submit once they've landed.
[02:49] <lifeless> cool, thanks
[02:49] <lifeless> I was going to do the production datedir2amqp consolidation
[02:49] <lifeless> give spm something to do
[02:49] <lifeless> but I'll wait for your things to percolate through
[02:49] <wgrant> Do you want to switch (qa)staging to one-config-per-user first?
[02:50] <wgrant> Rather than migrating prod twice?
[02:50] <lifeless> no
[02:50] <lifeless> we have have debt here atm with the rsync copy backup dirs
[02:50] <lifeless> I want that solved before I go on leave
[02:50] <lifeless> or it will be hanging over our heads through EOY
[02:50] <wgrant> Ah, true, forgot you were running off.
[02:50] <lifeless> one config per is nice, but refactoring vs fixing issue
[02:50] <wgrant> Yeah.
[02:51] <wgrant> Forgot we only had a couple of days.
[02:51] <lifeless> says he that has already run off :P
[02:51] <wgrant> Silence, fool.
[02:53] <wgrant> One landed.
[03:07] <spm> lifeless: just about at the point where only cocobananas is left to do.
[03:17] <lifeless> wgrant: btw the initial lazr-postgresql code is on LP if you are interested
[03:17] <wgrant> lifeless: So I saw.
[03:18] <wgrant> lifeless: How will this integrate will full-update.py? We'll just use lazr-postgresql's upgrade.py?
[03:19] <lifeless> wgrant: we'll either call upgrade.upgrade directly
[03:19] <lifeless> wgrant: from a new buildout console_script; which will let us use the lazr config enabled connect() in the LP tree
[03:19] <wgrant> Right.
[03:20] <lifeless> wgrant: or we will have an extension point to call local hooks
[03:20] <lifeless> for now, for simplicity, I'm expecting to add an upgrade (devmode) and full_upgrade(prod) buildout script.
[03:32] <lifeless> wsyt
[03:32] <lifeless> bah
[03:32] <lifeless> wdyt
[03:32] <wgrant> Sounds reasonable.
[03:33] <wgrant> wallyworld_: Did you intend to submit the rollback twice?
[03:34] <wallyworld_> wgrant: no. i hadn't gotten any merge email so thought it didn't go through as happens when bb is broken and it just disappears into the ether
[03:35] <wgrant> wallyworld_: Ah, no, PQM was just spending a while chewing on my config branches.
[03:35] <wgrant> You can see the queue at pqm.launchpad.net.
[03:35] <wallyworld_> ah ok
[03:35] <wallyworld_> so do i need to correct anything?
[03:35] <wgrant> The second one will hopefully fail.
[03:35] <wgrant> Should be fine.
[03:36] <wallyworld_> just got the email just now
[03:36] <wallyworld_> and a failure for the 2nd one
[03:36] <wgrant> Great.
[03:39] <StevenK> wallyworld_: Check the queue, if someone submits a prod-config branch it will take 45 minutes.
[03:40] <wallyworld_> StevenK: rightio. i was used to it taking a minute or two
[03:40] <StevenK> Sure, which it does for devel branches :-)
[03:40] <wgrant> I optimised (db-)devel landings from 45 minutes to 45 seconds. But configs are harder and rarer, so I didn't fix them.
[03:45] <wgrant> lifeless: lp:~wgrant/lp-production-configs/cleanup will be landed in 30ish minutes, or you can start working off it now.
[03:45] <wgrant> That's only #3, but #4 is reasonably uninvasive.
[04:02] <lifeless> I have to wonder if we should slony-I all the dev environments
[04:02] <StevenK> You must really hate developer CPUs, then
[04:03] <lifeless> no
[04:03] <wgrant> Single-node slony with no slons?
[04:03] <lifeless> two-node local cluster
[04:03] <StevenK> To what end?
[04:04]  * StevenK is confused.
[04:04] <lifeless> same reason local dev environment is postgresql, so its close to prod
[04:04] <StevenK> sinzui didn't land my branch, but fixed the test failures and then set the bug to fix released.
[04:07] <StevenK> wgrant: ^ Can you explain that?
[04:08] <wgrant> Test fixes go in, bug status changes go out. Can't explain that.
[04:08] <wgrant> But no.
[04:08] <wgrant> No clue what's going on there :/
[04:10] <StevenK> From what I can see, the bug isn't fixed, so I'm tempted to set it back and toss my branch at ec2.
[04:10] <wgrant> Probably a good plan.
[04:12] <StevenK> Bah, conflict
[04:12]  * StevenK fixes first
[04:58] <wgrant> lifeless: The configs are all yours.
[04:58] <lifeless> thanks
[06:11] <lifeless> anyone around up for a tiny review?
[06:27] <wallyworld_> lifeless: can i help?
[06:29] <lifeless> I ended up self reviewing :)
[06:29] <lifeless> it was lp:~lifeless/oops-tools/own-oopses, if you wanted to do a post landing review
[06:29] <lifeless> its horribly uninteresting though
[06:31] <wallyworld_> lifeless: np. just thought i'd ask since i glanced at irc between tasks and saw your reuqest
[06:31] <lifeless> thanks!
[08:17] <lifeless> jtv: /winm 58
[08:17] <lifeless> bah
[08:40] <adeuring> good morning
[08:45] <lifeless> night all
[09:02] <mrevell> Que pasa?
[09:06] <bigjools> morning
[09:07] <danhg> Morning all
[09:07] <jtv> morning
[09:13] <Guest52098> hai, I'm from indonesia
[11:33] <rick_h_> morning party people
[11:33] <StevenK> Can haz someone from maintaince look at why db-devel went bang on buildbot?
[11:34] <rick_h_> heh, wouldn't expect to see a .jar error on there
[11:36] <bigjools> StevenK: maintenance is gary this week, so wait now() + 2.5 hours
[11:36] <wgrant> Hmmm?
[11:36] <wgrant> buildbot breakage is a $everybody event.
[11:45] <bigjools> it is not a "drop what I am doing right now event"
[11:56] <nigelb> rick_h_: I've been having "fun" with SqlAlchemy today :)
[11:56] <nigelb> Its not so bad after a while :P
[12:04] <rick_h_> nigelb: heh, let me know if you need a hand with anything
[12:27] <cjwatson> I've done (among other things) http://paste.ubuntu.com/767818/; can anyone explain why I get this ForbiddenAttribute exception? http://paste.ubuntu.com/767819/
[12:28] <cjwatson> Given that IndexStanzaFields isn't a database-backed class, this is surprising
[12:33] <StevenK> That's probably zope in your way, then
[12:36] <cjwatson> StevenK: no doubt, but I don't understand how it's getting there or how to fix it
[12:38] <StevenK> Can you pastebin a traceback?
[12:38] <StevenK> cjwatson: If you 'type()' is it a proxy or a real object?
[12:38] <bigjools> cjwatson: probably because it's being returned from a method on a proxied object
[12:39] <bigjools> if you give it an interface it'll work
[12:39] <bigjools> having said that, you are running non-zopeless tests again? :)
[12:41] <cjwatson> No, this is in LaunchpadZopelessLayer
[12:42] <cjwatson> StevenK: http://paste.ubuntu.com/767819/ (above) is the traceback I have
[12:43] <StevenK> LaunchpadZopelessLayer is not really zope-less sadly.
[12:44] <cjwatson> yeah, it's a proxy
[12:44] <bigjools> indeed
[12:44] <bigjools> ZopelessDatabaseLayer is what you need
[12:45] <bigjools> for publisher stuff
[12:45] <bigjools> I hate layers
[12:45] <cjwatson> But I need a librarian, unfortunately
[12:46] <cjwatson> In any case the actual site of the problem is not in a test so I need to deal with the proxy thing regardless
[12:47] <bigjools> we need a LibrarianZopelessDatabaseLayer :)
[12:47] <bigjools> (you see why I hate layers)
[12:47] <cjwatson> or a non-borked fakelibrarian
[12:48] <cjwatson> I think I'll shove in an interface
[14:32] <nigelb> rick_h_: Its mostly been okay so far. I took some time to get used to handling relationships. I have the manual open for the most part (which is excellent btw), so that's helping :)
[14:33] <rick_h_> nigelb: yea, docs are A+ imo, at least once you get past terminology
[15:20] <bac> sinzui:  i have about ten vouchers -- are there any projects that really need them?
[15:21] <bac> sinzui:  also, do you have access to niobium?
[15:22] <sinzui> bac: search project review for proprietary projects without a commercial subscriptions. There are some pmteam projects that need vouchers
[15:22] <sinzui> bac: I do not have access to niobium
[15:24] <sinzui> bac /sarasa also needs a license
[15:25] <sinzui> We do not need to worry about ezncrypt until February
[15:28] <lifeless> morning everyone
[15:29] <jcsackett> lifeless: it throws me when you say morning and it's actually my morning. but good morning. :-)
[15:31] <lifeless> trust me, it throws me too :)
[15:31] <lifeless> EBABY
[15:32] <nigelb> jcsackett: lifeless says morning in my morning and night.
[15:32] <nigelb> Confuses the heck out of me.
[15:35] <bac> thanks sinzui
[15:35] <abentley> deryck: It really throws me that we default to ascending order when clicking the losenges. If we default to descending order, we'll see most-important-first, recently-updated-first, most-bug-heat-first.  Can and should we change this?
[15:36] <jcsackett> abentley: that sounds entirely logical to me. i always want sort to work that way.
[15:36] <rick_h_> abentley: +1 on that
[15:37] <deryck> abentley, I think we should make it losenge-specific actually.  title makes more sense ascending, for example. I think each on should have it's own starting default...
[15:37] <deryck> abentley, but if not that, then yes, ascending probably works better for most then descending.
[15:38] <deryck> sorry, descending probably works better.
[15:38] <abentley> deryck: cool.
[15:38] <deryck> my head hurts trying to track ascending vs. descending for some reason. :)
[15:40] <abentley> deryck: Does YUI provide a way to test that something is logged?  I'm changing a Y.error to a Y.log, but it only seems right to test the log.
[15:41] <deryck> hmmm, I don't know.  Thinking....
[15:41]  * deryck is looking at how YUI tests logging
[15:42] <rick_h_> If the 'debug' config is true, a 'yui:log' event will be dispatched
[15:42] <rick_h_> can you watch that event to verify via test?
[15:42] <rick_h_> or do tests not run with debug? I don't recall
[15:44] <deryck> ah, that's a good idea.  And easy enough to change to debug config if not.
[15:45] <abentley> rick_h_: Okay, I can do that.
[15:46] <rick_h_> my turn, abentley deryck if I wanted to install a package for dev purposes (ipdb in this case) what's the *right* way to get it available?
[15:46] <deryck> abentley, rick_h_ and debug is true by default, so that event hook should work.
[15:46] <rick_h_> I've tried installing into the eggs dir, adding to versions.cfg
[15:47] <abentley> rick_h_: You put the tarball in download-cache/dist, add it to setup.py, and update versions.cfg, IIRC.
[15:47] <deryck> rick_h_, this is only something you want to use yourself?  or trying to add it for all lp devs to have access?
[15:47] <rick_h_> which I don't want to do since it's a bzr tracked file anyway
[15:47] <rick_h_> deryck: just me for prettier pdb
[15:47] <rick_h_> abentley: ah, ok. I'll try that route, thanks
[15:47] <abentley> rick_h_: bzr branches can be put in sourcecode/
[15:48] <abentley> rick_h_: They are configured using utilities/sourcedeps.conf and updated with utilities/update-sourcecode
[15:49] <rick_h_> abentley: cool, thanks for the heads up
[15:49] <deryck> rick_h_, can you not install it normally via apt-get and use it as you wish?  I didn't think we did any sort of virtualenv stuff that prevent importing from system python.
[15:49] <rick_h_> deryck: well this is a pip install'd package
[15:49] <rick_h_> and isn't in the path from the buildout stuff it appears
[15:50] <rick_h_> deryck: so I was trying to cheat it in, but it's still not picking it up and not sure if I'm doing it wrong or buildout/make is being overly helpful
[15:50] <deryck> rick_h_, where does pip want to put it?  And could you just not manually much about with PYTHONPATH exports?
[15:50] <rick_h_> deryck: so figured I'd see if there was a standard practice for this kind of personal tool thing.
[15:51] <deryck> rick_h_, there is, what abentley said.  but you'll have to be more careful to not commit that. So just thinking how to do it without going through lp.
[15:51] <rick_h_> deryck: yea, I installed it system wife /usr/local.. dist-packages
[15:51] <rick_h_> deryck: and yea, I tried just to manually symlink it into the egg directory with no success
[15:51] <rick_h_> deryck: definitely, don't want to muck with the official files, but figured I need to start with getting it to work, and then work on backing it out of bzr tracking
[15:51] <abentley> rick_h_: well, we don't really have a practise for stuff we're not intending for other devs to use.  Aside from the standard ways of administering your system.
[15:52] <rick_h_> abentley: ok, just checking
[15:52] <deryck> rick_h_, try export PYTHONPATH=$PYTHONPATH:/path/to/other/stuff then do your make run.
[15:53] <deryck> rick_h_, I'm not a pip user, though, which I know may be blasphemy to some. ;) So maybe others here have better ideas for how they manage their system with pip and running launchpad.
[15:53] <rick_h_> deryck: ok, thanks
[16:16] <lifeless> gary_poster: thanks for updating the lxc page; btw feel free to edit the main page as you go - probably easier than merging concurrent changes later
[16:23] <abentley> deryck or bac: There's no OCR, could one of you review https://code.launchpad.net/~abentley/launchpad/distro-structural-subscription/+merge/85356 ?
[16:23] <deryck> abentley, I can.
[16:24] <abentley> deryck: thanks.
[16:25] <deryck> np!
[16:26] <deryck> abentley, nice test, btw. That's a good way to do that.  glad rick_h_ suggested that.
[16:28] <deryck> abentley, in terms of code, I have no complaints.  Looks good!  I do wonder why we even need the logging, if we don't need the error.  I guess it doesn't hurt, though….
[16:29] <deryck> abentley, but why dirty up the console for would could be a normal operation?  i.e. why not just do nothing and move on?
[16:30] <abentley> deryck: It's hard to say.  What's Y.log for, if we only use the console for errors?
[16:31] <deryck> abentley, it's usually a debugging tool, right?  so it implies, we're logging something unexpected or unusual. in this case, we'll log on every juju page, which maybe is unneeded.
[16:32] <deryck> log for unusual or debugging corner cases, error for when we want the page to blow up because the tool is being used wrong.
[16:32] <deryck> (and I more asking here, than that I think this is wrong to do.  I'm not sure myself and wanted to discuss it.)
[16:32] <abentley> deryck: This is an unusual case.  On Friday, bac actually thought the link should never be missing.
[16:33] <deryck> right
[16:33] <lifeless> I want us to grab oopses from failed js
[16:33] <abentley> deryck: And the code assumed that too, of course.
[16:33] <lifeless> in that scenario a log of things that went odd in the page could be helpful
[16:33] <deryck> I'd like that too, lifeless
[16:33] <abentley> lifeless: me three.
[16:34] <deryck> lifeless, in that case Y.error makes sense, I think.  This is a case were we changed to Y.log since it's not an exceptional situation.
[16:34] <deryck> abentley, right.  and sense we can have cases where the link isn't present, I wonder if we shouldn't do nothing and move on.  That's our normal approach… sniff for something in the dom, nothing there?, them do nothing…..
[16:34] <abentley> deryck: but it would be great if Y.error was reporting an oops, and we'd fixed the problem months ago.
[16:35] <deryck> abentley, so I don't really mind the log, I just wonder what it buys us?
[16:35] <deryck> abentley, indeed!  agreed there.
[16:36] <abentley> deryck: I guess it would make things clearer for someone debugging a structural subscription issue.
[16:37] <abentley> deryck: But I'm fine with killing it entirely.
[16:37] <deryck> abentley, fair point.  I'm arguing with myself right now and trying to form a consistent opinion here. :)
[16:38] <abentley> deryck: there's also the option of logging it with a low priority, e.g. debug.
[16:39] <deryck> abentley, let's do it lower priority, so we can turn it on if we need, but we're not logging on every request for these pages.  I like that.  That work for you?
[16:39] <abentley> deryck: Okay.
[16:40] <deryck> abentley, thanks!  Sorry to make more work for you.  I'll note our discussion in the MP.
[16:50] <adeuring> deryck: got some time to talk about the sort issues?
[16:51] <deryck> adeuring, I'm about to get on a call.  Can I ping you after that?
[16:51] <adeuring> deryck: sure
[16:59] <abentley> adeuring: I believe you've addressed bug #894745
[16:59] <_mup_> Bug #894745: No sort on bug listing for most recently changed <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894745 >
[17:00] <adeuring> abentley: right, thanks for the nocitce :)
[18:23] <jelmer> I'm getting OOPSes during "make sync_branches", but none of those OOPses actually seem to end up anywhere
[18:30] <lifeless> jelmer: /var/tmp/lperr/
[18:31] <jelmer> lifeless: other OOPSes end up there, but not the ones generated by the branch scanner
[18:31] <lifeless> it may be firing up rabbit
[18:32] <lifeless> if so, follow my notes to setup a local exchange, and you can suck them out using amqp2datedir (either the main one or the oops-tools one, if you have oops-tools setup as well
[18:33] <jelmer> lifeless: I'll have a look - thanks
[19:05] <james_w> launchpad records timestamps for bug reports and bug last changed right?
[19:05] <james_w> bug reported I mean
[19:29] <rick_h_> james_w: looking at the db I see a date_last_updated
[19:33] <deryck> james_w, yeah, we do.  but bug last changed doesn't include comments.  so you have to do the more recent of date_last_updated and date_last_message.
[19:42] <lifeless> deryck: erm, i seem to recall it does. IMBW
[19:43] <deryck> lifeless, maybe it does now.  Or maybe I'm completely remembering wrong. :)
[19:43]  * deryck will look here in a sec
[19:45] <lifeless> deryck: I am a little concerned at wontfix ing the sort-by-date-of-task bug
[19:46] <lifeless> deryck: because date of task is the record of 'bug in context'
[19:48] <deryck> lifeless, ok.  we'll need to either break our basic design premise and stick a sort option on the bar that can never be removed, or add some display info that represents "bug in context age" (or some such)
[19:49] <lifeless> a quick diversion if you will
[19:49] <lifeless> let me grab a couple bug numbers
[19:49] <lifeless> deryck: actually, might be simpler to switch to voice, if you have a few minutes
[19:50] <lifeless> (ETIRED)
[19:50] <deryck> lifeless, I don't actually.  About to jump on another call.  And I've been on calls quite a bit today already.
[19:50] <lifeless> fair enough
[19:50] <lifeless> I'll blather on here a bit, give you as much context as I can
[19:50] <lifeless> and you can decide after your calls ;)
[19:52] <deryck> ok, cool
[19:53] <lifeless> I can't find the darn bug
[19:53] <lifeless> so I'll describe it
[19:53] <lifeless> when a bug has 2 tasks
[19:53] <lifeless> and you have a search that returns both
[19:53] <lifeless> we show both
[19:53] <lifeless> so our collections show tasks, not bugs.
[19:53] <lifeless> There is a bug about that
[19:54] <lifeless> for sorts on task columns, the two rows can be widely separated.
[19:54] <lifeless> for sorts on bug columns they will be adjacent
[19:55] <lifeless> related to this is our heuristic logic for when-to-show-context (e.g. we show 'project' when searching bugs in a project group, or on a users person +bugs page
[19:55] <lifeless> so -> seems to me that showing task-created as an optional column should be easy and preserve the design premise (which is pretty nice!)
[19:57] <deryck> yeah, I guess I have no issues with task-created as an extra piece of visible info.  It's creating it as a sort option in isolation that I don't support.
[19:57] <deryck> I think it's a bit hard to sum up simply in UI, but maybe just "Task age" as the label.
[19:57] <lifeless> I think the argument of 'cannot sort on it if you cannot see it' makes a great deal of sense
[19:57] <lifeless> at least for this data
[19:58] <lifeless> there is of course one exception - 'relevance', which is a bit hard to show as a column with any meaning
[19:58] <deryck> right
[19:58] <deryck> but if we had that, it makes more sense as a sort option that never goes away.
[19:59] <lifeless> separately, you know what would be sexy. Having closed bugs disappear out of the list in real time
[19:59] <lifeless> long poll subscribe to all the bugs shown on the batch.
[19:59] <deryck> lifeless, do you mind re-opening that bug and repurposing it to say "add display info and sort option for bug task age"?  if not, I can grab it later.
[19:59] <lifeless> re-evaluate their inclusion on the client when they are touched
[19:59] <deryck> lifeless, and indeed!  I'd love that.
[20:00] <lifeless> deryck: not at all, I will do that for you
[20:00] <deryck> lifeless, thanks, man!  And thanks for the discussion.
[20:00] <lifeless> np!
[20:00] <lifeless> btw today is my last day for the year
[20:00] <lifeless> so if you have stuff you want my input on... today is the day :)
[20:01] <deryck> ok, I have nothing today.  But I'm sure I will tomorrow or the next day. ;)
[20:01] <lifeless> of course :)
[20:02] <lifeless> I will probably still be around, things with long tails getting tweaked.
[20:02] <lifeless> but I won't 'be here' here, if that scans
[20:02] <deryck> yup, I follow.
[20:03] <lifeless> https://bugs.launchpad.net/launchpad/+bug/896539
[20:03] <_mup_> Bug #896539: bug task creation date is not selectable for display and thus can no longer be sorted by <bug-columns> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/896539 >
[20:03] <lifeless> hows that for a new title
[20:04] <deryck> perfect! :)
[20:04] <lifeless> I've added a note about the reopening too. Catch you later.
[20:13] <james_w> rick_h_, deryck: thanks
[20:14] <james_w> very useful attributes if exposed over the API
[20:53] <deryck> rick_h_, are you still around, or EOD'ed?
[20:53] <rick_h_> deryck: I'm here
[20:53] <rick_h_> in/out for a few min
[20:54] <deryck> rick_h_, I'll get those queries now.
[20:54] <rick_h_> deryck: ty much
[20:57] <deryck> rick_h_, https://pastebin.canonical.com/57002/
[21:01] <rick_h_> deryck: sorry had a typo in the id s/1007773/1007731 https://pastebin.canonical.com/57003/
[21:03] <deryck> rick_h_, better?  https://pastebin.canonical.com/57004/
[21:04] <rick_h_> deryck: awesome, thanks. That looks more like what I was looking for
[21:04] <deryck> rick_h_, cool
[21:14] <bac> hi sinzui
[21:15] <bac> sinzui: gary and i were talking about bug 480123 and whether the relaxing of the db constraint regarding milestone uniqueness should apply to distros too.  thoughts?
[21:15] <_mup_> Bug #480123: Milestone names/version should be unique to series <escalated> <linaro> <lp-registry> <Launchpad itself:In Progress by bac> < https://launchpad.net/bugs/480123 >
[21:17] <sinzui> bac, yes. the rules for distros are the same for projects...there can be only one release version in the history to prevent confusion and security vulnerabilities
[21:18] <bac> sinzui: right but is relaxing those rules for distros something that bug addresses?
[21:18] <bac> sinzui: so your previous 'yes' was to that question?
[21:19] <sinzui> bac I do not think that is what the bug is about. We are not in the business of making it easy to exploit a release.
[21:20] <sinzui> I think the issue is about making it possible to create an aggregate report of milestones in a project group's sub projects
[21:22] <sinzui> We do not need to change the constraints if we introduce a group_version that might make pg milestones faster and accurate since there will not no guessing.
[21:23] <sinzui> bac: but too you question, distros and product must have the same behavior
[21:32] <gary_poster> sinzui, could we have a call with you anytime soon?
[21:32] <lifeless> sinzui: whats the exploit ??
[21:32] <lifeless> s/??/?
[21:33] <sinzui> lifeless, If there is a defect in one of two version of the same name, how can I be certain I have the fixed version
[21:33] <lifeless> sinzui: if we show the full name consistently
[21:33] <lifeless> sinzui: precise/beta1 is not the same as oneiric/beta1
[21:33] <sinzui> lifeless, correct
[21:35] <sinzui> lifeless, consider the case of releasing from trunk!
[21:35] <lifeless> sinzui: so is the issue 'if we make milestone names only unique for a series, we have to audit the UI to be sure we always show the series' ?
[21:36] <lifeless> sinzui: indeed, and on trunk I can't imagine multiple 'beta' unqualified names being anything other than confusing
[21:36] <lifeless> sinzui: but someone releasing from trunk could do 0.1-beta1 and we'd be ok with that AIUI
[21:37] <sinzui> Most project do release from trunk and create series for backporting, so users creating a release want foo-5.beta
[21:37] <gary_poster> sinzui, but we would still have a constraint that milestones must be unique within a series.  Does that affect your argument?
[21:38] <sinzui> no, but the UI gets harder.
[21:38] <lifeless> hmm,also we can't permit whatever our join character is in the milestone name
[21:38] <sinzui> consider that I can move milestones between series and we support the feature because projects need a mechanism to reorganise themselves when hey grow, or advance
[21:39] <lifeless> otherwise the milestone 'foo-5.beta' on trunk and 'beta' on 'foo-5' might be hard to tell apart
[21:39] <sinzui> Moving a released milestone does not change the release version
[21:39] <sinzui> Users do move released milestones from trunk to a supported series for example
[21:40] <sinzui> I believe the current proposal support project that use leading series and milestones, which is not the norm. Most work on trunk/master, and use series for supported version
[21:41] <sinzui> Since the underlying issue is about a project group report, I think we need to be certain we are really solving that issue, and if we solve the timeouts too, instead of exacerbating the,, great
[21:44] <sinzui> gary_poster, bac, lifeless: project group milestones are the most prone to timeout because the listing grows too long. A good solution will reduce timeouts be making it easier to know which milestones compose the virtual project group milestone
[21:49] <bac> sinzui: it sounds like you are suggesting a different solution than the one originally discussed in the bug.  a new way to model linaro's grouping using something different from a milestone.  is that right?
[21:49] <sinzui> yes
[21:49] <sinzui> The chose to escalate a bug that "sounded" like the solution to their problem
[21:50] <sinzui> When I looked at the issue and the performance concerns, I seriously considered dropping support for project group milestones...which make matters worse for them
[21:52] <sinzui> Bac: the non-unique milestone bug is not about reporting, it is about normalising the milestone/release version from the series
[21:52] <bac> sinzui: but it does allow their report to be generated...
[21:54] <sinzui> yes. but at the cost that you must move the guard of duplicate releases from the early act of milestone creation to the late act of creating a release. An early mistake is easy to fix, a late mistake is not.
[21:58] <bac> sinzui: curtis do you have time to for a call with gary and me nowish?
[21:59] <sinzui> As I said before, no, I am meeting with my team
[21:59] <bac> sinzui: sorry, i missed your reply.  maybe early tomorrow?
[22:00] <sinzui> sure. I am free in the morning and isn the late afternoon
[22:00] <bac> sinzui: ok, great.  we're sprinting and cannot start until 9 am.  10am good for you?
[22:01] <sinzui> perfect
[22:01] <bac> thanks.
[22:07] <cjwatson> wgrant: Hmm.  Was bug 669404 perhaps fixed by your fix for bug 680889?
[22:07] <_mup_> Bug #669404: support linux-any and similar expansions in Packages-arch-specific <lp-soyuz> <soyuz-build> <soyuz-core> <Launchpad itself:Triaged> < https://launchpad.net/bugs/669404 >
[22:07] <_mup_> Bug #680889: Needs to handle "all linux-any" like "linux-any" <lp-soyuz> <qa-ok> <soyuz-build> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/680889 >
[22:14] <cjwatson> Could somebody with appropriate privileges mark bug 51763 as Won't Fix?  I left a comment explaining why.
[22:14] <_mup_> Bug #51763: Add effective tests for archive-cruft-check-ng.py <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/51763 >
[22:19] <lifeless> cjwatson: marked it invalid for you
[22:19] <lifeless> (there is no actual defect..)
[22:19] <cjwatson> fair enough
[22:33] <StevenK> sinzui, wallyworld_, jcsackett: http://pastebin.ubuntu.com/768422/
[22:40] <lifeless> incoming
[23:01] <mwhudson> jelmer: hey, does the "Always load foreign plugins" change mean we can switch to putting lp:bzr-git in sourcecode?
[23:02] <lifeless> mwhudson: where is it now ?
[23:19] <wgrant> cjwatson: I don't think so, but possibly...
[23:20] <wgrant> cjwatson: Doesn't look like it. P-a-s interpretation is pretty separate.
[23:20] <wgrant> It's in the same file, but it's handled very different.
[23:20] <wgrant> differently
[23:47] <jelmer> mwhudson: it's already in sourcecode, isn't it?
[23:47] <mwhudson> jelmer: we have some hack to support deregistering don't we?
[23:48] <jelmer> mwhudson: ah, right. that's no longer necessary
[23:58] <wgrant> wallyworld_: buildbot is about to fail, with account_status inaccessible.
[23:59] <wallyworld_> wgrant: ok. i'll deal with it. curtis landed the branch last night so i'll try and figure out why it got past ec2