| wgrant | lifeless: Is security.py going to end up in lazr-postresql too? | 00:08 |
|---|---|---|
| lifeless | no | 00:11 |
| wgrant | :( | 00:12 |
| lifeless | or at least, not in this arc | 00:12 |
| wgrant | How're you going to manage security? | 00:12 |
| 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:14 |
| 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:15 |
| wgrant | lifeless: Right. | 00:22 |
| lifeless | thus doing create role & grant on all the nodes is straight forward | 00:31 |
| 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:34 |
| 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 | 00:35 |
| 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:18 |
| lifeless | and as you can see, w/no timeline, its pretty opaque data at the moment | 02:19 |
| 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:21 |
| wgrant | wallyworld_: The person limitedview thing? | 02:25 |
| wallyworld_ | wgrant: yes | 02:25 |
| wgrant | What's the issue? | 02:25 |
| wgrant | Hmm | 02:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| * 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:35 | |
| lifeless | wgrant: I know you are not here, but are you doing to land your config changes? | 02:47 |
| wgrant | lifeless: Two are in PQM now. | 02:48 |
| wgrant | One conflicts with mthaddon. | 02:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| wgrant | One landed. | 02:53 |
| spm | lifeless: just about at the point where only cocobananas is left to do. | 03:07 |
| lifeless | wgrant: btw the initial lazr-postgresql code is on LP if you are interested | 03:17 |
| wgrant | lifeless: So I saw. | 03:17 |
| wgrant | lifeless: How will this integrate will full-update.py? We'll just use lazr-postgresql's upgrade.py? | 03:18 |
| 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:19 |
| 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:20 |
| lifeless | wsyt | 03:32 |
| lifeless | bah | 03:32 |
| lifeless | wdyt | 03:32 |
| wgrant | Sounds reasonable. | 03:32 |
| wgrant | wallyworld_: Did you intend to submit the rollback twice? | 03:33 |
| 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:34 |
| 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:35 |
| wallyworld_ | just got the email just now | 03:36 |
| wallyworld_ | and a failure for the 2nd one | 03:36 |
| wgrant | Great. | 03:36 |
| StevenK | wallyworld_: Check the queue, if someone submits a prod-config branch it will take 45 minutes. | 03:39 |
| 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:40 |
| 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. | 03:45 |
| 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:02 |
| 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:03 |
| * 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:04 |
| StevenK | wgrant: ^ Can you explain that? | 04:07 |
| 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:08 |
| 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:10 |
| StevenK | Bah, conflict | 04:12 |
| * StevenK fixes first | 04:12 | |
| wgrant | lifeless: The configs are all yours. | 04:58 |
| lifeless | thanks | 04:58 |
| lifeless | anyone around up for a tiny review? | 06:11 |
| wallyworld_ | lifeless: can i help? | 06:27 |
| 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:29 |
| wallyworld_ | lifeless: np. just thought i'd ask since i glanced at irc between tasks and saw your reuqest | 06:31 |
| lifeless | thanks! | 06:31 |
| lifeless | jtv: /winm 58 | 08:17 |
| lifeless | bah | 08:17 |
| adeuring | good morning | 08:40 |
| lifeless | night all | 08:45 |
| mrevell | Que pasa? | 09:02 |
| bigjools | morning | 09:06 |
| danhg | Morning all | 09:07 |
| jtv | morning | 09:07 |
| Guest52098 | hai, I'm from indonesia | 09:13 |
| rick_h_ | morning party people | 11:33 |
| StevenK | Can haz someone from maintaince look at why db-devel went bang on buildbot? | 11:33 |
| rick_h_ | heh, wouldn't expect to see a .jar error on there | 11:34 |
| 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:36 |
| bigjools | it is not a "drop what I am doing right now event" | 11:45 |
| nigelb | rick_h_: I've been having "fun" with SqlAlchemy today :) | 11:56 |
| nigelb | Its not so bad after a while :P | 11:56 |
| rick_h_ | nigelb: heh, let me know if you need a hand with anything | 12:04 |
| 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:27 |
| cjwatson | Given that IndexStanzaFields isn't a database-backed class, this is surprising | 12:28 |
| StevenK | That's probably zope in your way, then | 12:33 |
| cjwatson | StevenK: no doubt, but I don't understand how it's getting there or how to fix it | 12:36 |
| 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:38 |
| bigjools | if you give it an interface it'll work | 12:39 |
| bigjools | having said that, you are running non-zopeless tests again? :) | 12:39 |
| cjwatson | No, this is in LaunchpadZopelessLayer | 12:41 |
| cjwatson | StevenK: http://paste.ubuntu.com/767819/ (above) is the traceback I have | 12:42 |
| StevenK | LaunchpadZopelessLayer is not really zope-less sadly. | 12:43 |
| cjwatson | yeah, it's a proxy | 12:44 |
| bigjools | indeed | 12:44 |
| bigjools | ZopelessDatabaseLayer is what you need | 12:44 |
| bigjools | for publisher stuff | 12:45 |
| bigjools | I hate layers | 12:45 |
| cjwatson | But I need a librarian, unfortunately | 12:45 |
| 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:46 |
| bigjools | we need a LibrarianZopelessDatabaseLayer :) | 12:47 |
| bigjools | (you see why I hate layers) | 12:47 |
| cjwatson | or a non-borked fakelibrarian | 12:47 |
| cjwatson | I think I'll shove in an interface | 12:48 |
| 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:32 |
| rick_h_ | nigelb: yea, docs are A+ imo, at least once you get past terminology | 14:33 |
| === matsubara is now known as matsubara-lunch | ||
| bac | sinzui: i have about ten vouchers -- are there any projects that really need them? | 15:20 |
| bac | sinzui: also, do you have access to niobium? | 15:21 |
| 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:22 |
| sinzui | bac /sarasa also needs a license | 15:24 |
| sinzui | We do not need to worry about ezncrypt until February | 15:25 |
| lifeless | morning everyone | 15:28 |
| jcsackett | lifeless: it throws me when you say morning and it's actually my morning. but good morning. :-) | 15:29 |
| lifeless | trust me, it throws me too :) | 15:31 |
| lifeless | EBABY | 15:31 |
| nigelb | jcsackett: lifeless says morning in my morning and night. | 15:32 |
| nigelb | Confuses the heck out of me. | 15:32 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:40 |
| deryck | hmmm, I don't know. Thinking.... | 15:41 |
| * deryck is looking at how YUI tests logging | 15:41 | |
| 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:42 |
| deryck | ah, that's a good idea. And easy enough to change to debug config if not. | 15:44 |
| abentley | rick_h_: Okay, I can do that. | 15:45 |
| 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:46 |
| 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:47 |
| abentley | rick_h_: They are configured using utilities/sourcedeps.conf and updated with utilities/update-sourcecode | 15:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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 | 15:53 |
| 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:16 |
| 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:23 |
| abentley | deryck: thanks. | 16:24 |
| deryck | np! | 16:25 |
| deryck | abentley, nice test, btw. That's a good way to do that. glad rick_h_ suggested that. | 16:26 |
| === matsubara-lunch is now known as matsubara | ||
| 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:28 |
| 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:29 |
| abentley | deryck: It's hard to say. What's Y.log for, if we only use the console for errors? | 16:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| abentley | deryck: I guess it would make things clearer for someone debugging a structural subscription issue. | 16:36 |
| 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:37 |
| abentley | deryck: there's also the option of logging it with a low priority, e.g. debug. | 16:38 |
| === matsubara_ is now known as matsubara | ||
| 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:39 |
| deryck | abentley, thanks! Sorry to make more work for you. I'll note our discussion in the MP. | 16:40 |
| === Ursinha is now known as Ursinha-lunch | ||
| adeuring | deryck: got some time to talk about the sort issues? | 16:50 |
| deryck | adeuring, I'm about to get on a call. Can I ping you after that? | 16:51 |
| adeuring | deryck: sure | 16:51 |
| 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 > | 16:59 |
| adeuring | abentley: right, thanks for the nocitce :) | 17:00 |
| === salgado is now known as salgado-lunch | ||
| jelmer | I'm getting OOPSes during "make sync_branches", but none of those OOPses actually seem to end up anywhere | 18:23 |
| === salgado-lunch is now known as salgado | ||
| lifeless | jelmer: /var/tmp/lperr/ | 18:30 |
| 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:31 |
| 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:32 |
| jelmer | lifeless: I'll have a look - thanks | 18:33 |
| === deryck is now known as deryck[lunch] | ||
| james_w | launchpad records timestamps for bug reports and bug last changed right? | 19:05 |
| james_w | bug reported I mean | 19:05 |
| rick_h_ | james_w: looking at the db I see a date_last_updated | 19:29 |
| === deryck[lunch] is now known as deryck | ||
| 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:33 |
| lifeless | deryck: erm, i seem to recall it does. IMBW | 19:42 |
| deryck | lifeless, maybe it does now. Or maybe I'm completely remembering wrong. :) | 19:43 |
| * deryck will look here in a sec | 19:43 | |
| lifeless | deryck: I am a little concerned at wontfix ing the sort-by-date-of-task bug | 19:45 |
| lifeless | deryck: because date of task is the record of 'bug in context' | 19:46 |
| 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:48 |
| 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:49 |
| 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:50 |
| deryck | ok, cool | 19:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:57 |
| 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:58 |
| 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. | 19:59 |
| 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:00 |
| deryck | ok, I have nothing today. But I'm sure I will tomorrow or the next day. ;) | 20:01 |
| lifeless | of course :) | 20:01 |
| 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:02 |
| 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:03 |
| deryck | perfect! :) | 20:04 |
| lifeless | I've added a note about the reopening too. Catch you later. | 20:04 |
| james_w | rick_h_, deryck: thanks | 20:13 |
| james_w | very useful attributes if exposed over the API | 20:14 |
| === matsubara is now known as matsubara-afk | ||
| === Ursinha-lunch is now known as Ursinha | ||
| 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:53 |
| deryck | rick_h_, I'll get those queries now. | 20:54 |
| rick_h_ | deryck: ty much | 20:54 |
| deryck | rick_h_, https://pastebin.canonical.com/57002/ | 20:57 |
| rick_h_ | deryck: sorry had a typo in the id s/1007773/1007731 https://pastebin.canonical.com/57003/ | 21:01 |
| deryck | rick_h_, better? https://pastebin.canonical.com/57004/ | 21:03 |
| rick_h_ | deryck: awesome, thanks. That looks more like what I was looking for | 21:04 |
| deryck | rick_h_, cool | 21:04 |
| bac | hi sinzui | 21:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:22 |
| sinzui | bac: but too you question, distros and product must have the same behavior | 21:23 |
| gary_poster | sinzui, could we have a call with you anytime soon? | 21:32 |
| lifeless | sinzui: whats the exploit ?? | 21:32 |
| lifeless | s/??/? | 21:32 |
| 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:33 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:44 |
| 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:49 |
| 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:50 |
| 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:52 |
| 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:54 |
| bac | sinzui: curtis do you have time to for a call with gary and me nowish? | 21:58 |
| sinzui | As I said before, no, I am meeting with my team | 21:59 |
| bac | sinzui: sorry, i missed your reply. maybe early tomorrow? | 21:59 |
| === matsubara-afk is now known as matsubara | ||
| 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:00 |
| sinzui | perfect | 22:01 |
| bac | thanks. | 22:01 |
| 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:07 |
| === salgado is now known as salgado-afk | ||
| 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:14 |
| lifeless | cjwatson: marked it invalid for you | 22:19 |
| lifeless | (there is no actual defect..) | 22:19 |
| cjwatson | fair enough | 22:19 |
| StevenK | sinzui, wallyworld_, jcsackett: http://pastebin.ubuntu.com/768422/ | 22:33 |
| === matsubara is now known as matsubara-afk | ||
| lifeless | incoming | 22:40 |
| mwhudson | jelmer: hey, does the "Always load foreign plugins" change mean we can switch to putting lp:bzr-git in sourcecode? | 23:01 |
| lifeless | mwhudson: where is it now ? | 23:02 |
| wgrant | cjwatson: I don't think so, but possibly... | 23:19 |
| 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:20 |
| === maxb_ is now known as maxb | ||
| 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:47 |
| jelmer | mwhudson: ah, right. that's no longer necessary | 23:48 |
| wgrant | wallyworld_: buildbot is about to fail, with account_status inaccessible. | 23:58 |
| 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 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!