[00:08] lifeless: Is security.py going to end up in lazr-postresql too? [00:11] no [00:12] :( [00:12] or at least, not in this arc [00:12] How're you going to manage security? [00:14] wgrant: for scriptactivity ? in the db patches themselves probably. [00:14] Ah [00:14] we have three types of patches in the new system [00:15] std (goes via slonik) [00:15] direct (applies to each node separately in a xact) [00:15] concurrent (applies to each node separately outside of a transaction) [00:22] lifeless: Right. [00:31] thus doing create role & grant on all the nodes is straight forward [00:34] Yeah, which security.py can do :) [00:34] Just needs to be made fully nodowntime, which I didn't quite get around to last week. [00:34] I eagerly await this shiny. [00:35] for now, minimal is good. [00:35] True, true. [00:35] But minimal LP is better :) [00:35] we could just ditch security.py [02:18] and success - https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-c63bba67bbc99ffb6e41ba383cd87c88 [02:18] tomorrows oops report should indeed have bazaar soft timeouts [02:18] I fear it.; [02:18] they will be soft timeouts [02:18] I still fear it. [02:19] and as you can see, w/no timeline, its pretty opaque data at the moment [02:21] 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] do you have a moment? [02:25] wallyworld_: The person limitedview thing? [02:25] wgrant: yes [02:25] What's the issue? [02:25] Hmm [02:26] Interesting. [02:26] i have a private team with a ppa. i have subscribed someone to the ppa. but theu can' [02:26] Something is broken, yeah. [02:26] t get to it [02:26] team is ~private-foobarx [02:26] i have subscribed xgy-ian to the ppa [02:27] but when i login as xgy-ian, i get Unauthorized on https://qastaging.launchpad.net/~private-foobarx/+archive/ppa [02:27] that's wrong, right? [02:27] Should be, yes. [02:27] Let me just fetch my testing account. [02:27] ok [02:27] there's 2 bugs [02:28] one is not any worse, so is technically qa-ok [02:28] but i hate marking a bug that doesn;t fix the issue as qa-ok :-( [02:28] Hmm [02:29] I think traversal may be failing. [02:29] * wgrant checks. [02:29] yes [02:29] that's my suspicion [02:29] 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] Which is checked during traversal. [02:29] when i went on leave, the 2 branches i had were wip but curtis landed them with some fixes [02:31] https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-40786f88f5a5251bc6910b6f6b1ad083 [02:31] Traversal is indeed failing. [02:31] qa-bad [02:31] Hm, it looks like Curtis fixed my branch but didn't land it. [02:32] wgrant: should i mark both bugs as qa-bad [02:32] even though one of them is just as borken as before [02:32] wallyworld_: qa-bad and bad-commit- [02:32] ok [02:32] "just as borken" == "people who are subscribed to branches owned by other private teams still can't see them"? [02:32] I need to smack people for not adding bad-commit-<> [02:32] wgrant: yes [02:33] wallyworld_: Doesn't really matter. [02:33] If they're the same rev. [02:33] i marked it as qa-ok by mistake [02:33] StevenK: how was your week off? [02:33] It was excellent. [02:33] stayed home? [02:34] Yeah, I stayed home and played games all week. [02:34] 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] wgrant: I know you are not here, but are you doing to land your config changes? [02:48] lifeless: Two are in PQM now. [02:48] One conflicts with mthaddon. [02:49] And the last conflicts with the two that are landing now, so I'll merge and submit once they've landed. [02:49] cool, thanks [02:49] I was going to do the production datedir2amqp consolidation [02:49] give spm something to do [02:49] but I'll wait for your things to percolate through [02:49] Do you want to switch (qa)staging to one-config-per-user first? [02:50] Rather than migrating prod twice? [02:50] no [02:50] we have have debt here atm with the rsync copy backup dirs [02:50] I want that solved before I go on leave [02:50] or it will be hanging over our heads through EOY [02:50] Ah, true, forgot you were running off. [02:50] one config per is nice, but refactoring vs fixing issue [02:50] Yeah. [02:51] Forgot we only had a couple of days. [02:51] says he that has already run off :P [02:51] Silence, fool. [02:53] One landed. [03:07] lifeless: just about at the point where only cocobananas is left to do. [03:17] wgrant: btw the initial lazr-postgresql code is on LP if you are interested [03:17] lifeless: So I saw. [03:18] lifeless: How will this integrate will full-update.py? We'll just use lazr-postgresql's upgrade.py? [03:19] wgrant: we'll either call upgrade.upgrade directly [03:19] wgrant: from a new buildout console_script; which will let us use the lazr config enabled connect() in the LP tree [03:19] Right. [03:20] wgrant: or we will have an extension point to call local hooks [03:20] for now, for simplicity, I'm expecting to add an upgrade (devmode) and full_upgrade(prod) buildout script. [03:32] wsyt [03:32] bah [03:32] wdyt [03:32] Sounds reasonable. [03:33] wallyworld_: Did you intend to submit the rollback twice? [03:34] 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] wallyworld_: Ah, no, PQM was just spending a while chewing on my config branches. [03:35] You can see the queue at pqm.launchpad.net. [03:35] ah ok [03:35] so do i need to correct anything? [03:35] The second one will hopefully fail. [03:35] Should be fine. [03:36] just got the email just now [03:36] and a failure for the 2nd one [03:36] Great. [03:39] wallyworld_: Check the queue, if someone submits a prod-config branch it will take 45 minutes. [03:40] StevenK: rightio. i was used to it taking a minute or two [03:40] Sure, which it does for devel branches :-) [03:40] 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] lifeless: lp:~wgrant/lp-production-configs/cleanup will be landed in 30ish minutes, or you can start working off it now. [03:45] That's only #3, but #4 is reasonably uninvasive. [04:02] I have to wonder if we should slony-I all the dev environments [04:02] You must really hate developer CPUs, then [04:03] no [04:03] Single-node slony with no slons? [04:03] two-node local cluster [04:03] To what end? [04:04] * StevenK is confused. [04:04] same reason local dev environment is postgresql, so its close to prod [04:04] sinzui didn't land my branch, but fixed the test failures and then set the bug to fix released. [04:07] wgrant: ^ Can you explain that? [04:08] Test fixes go in, bug status changes go out. Can't explain that. [04:08] But no. [04:08] No clue what's going on there :/ [04:10] 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] Probably a good plan. [04:12] Bah, conflict [04:12] * StevenK fixes first [04:58] lifeless: The configs are all yours. [04:58] thanks [06:11] anyone around up for a tiny review? [06:27] lifeless: can i help? [06:29] I ended up self reviewing :) [06:29] it was lp:~lifeless/oops-tools/own-oopses, if you wanted to do a post landing review [06:29] its horribly uninteresting though [06:31] lifeless: np. just thought i'd ask since i glanced at irc between tasks and saw your reuqest [06:31] thanks! [08:17] jtv: /winm 58 [08:17] bah [08:40] good morning [08:45] night all [09:02] Que pasa? [09:06] morning [09:07] Morning all [09:07] morning [09:13] hai, I'm from indonesia [11:33] morning party people [11:33] Can haz someone from maintaince look at why db-devel went bang on buildbot? [11:34] heh, wouldn't expect to see a .jar error on there [11:36] StevenK: maintenance is gary this week, so wait now() + 2.5 hours [11:36] Hmmm? [11:36] buildbot breakage is a $everybody event. [11:45] it is not a "drop what I am doing right now event" [11:56] rick_h_: I've been having "fun" with SqlAlchemy today :) [11:56] Its not so bad after a while :P [12:04] nigelb: heh, let me know if you need a hand with anything [12:27] 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] Given that IndexStanzaFields isn't a database-backed class, this is surprising [12:33] That's probably zope in your way, then [12:36] StevenK: no doubt, but I don't understand how it's getting there or how to fix it [12:38] Can you pastebin a traceback? [12:38] cjwatson: If you 'type()' is it a proxy or a real object? [12:38] cjwatson: probably because it's being returned from a method on a proxied object [12:39] if you give it an interface it'll work [12:39] having said that, you are running non-zopeless tests again? :) [12:41] No, this is in LaunchpadZopelessLayer [12:42] StevenK: http://paste.ubuntu.com/767819/ (above) is the traceback I have [12:43] LaunchpadZopelessLayer is not really zope-less sadly. [12:44] yeah, it's a proxy [12:44] indeed [12:44] ZopelessDatabaseLayer is what you need [12:45] for publisher stuff [12:45] I hate layers [12:45] But I need a librarian, unfortunately [12:46] 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] we need a LibrarianZopelessDatabaseLayer :) [12:47] (you see why I hate layers) [12:47] or a non-borked fakelibrarian [12:48] I think I'll shove in an interface [14:32] 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] nigelb: yea, docs are A+ imo, at least once you get past terminology === matsubara is now known as matsubara-lunch [15:20] sinzui: i have about ten vouchers -- are there any projects that really need them? [15:21] sinzui: also, do you have access to niobium? [15:22] bac: search project review for proprietary projects without a commercial subscriptions. There are some pmteam projects that need vouchers [15:22] bac: I do not have access to niobium [15:24] bac /sarasa also needs a license [15:25] We do not need to worry about ezncrypt until February [15:28] morning everyone [15:29] lifeless: it throws me when you say morning and it's actually my morning. but good morning. :-) [15:31] trust me, it throws me too :) [15:31] EBABY [15:32] jcsackett: lifeless says morning in my morning and night. [15:32] Confuses the heck out of me. [15:35] thanks sinzui [15:35] 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] abentley: that sounds entirely logical to me. i always want sort to work that way. [15:36] abentley: +1 on that [15:37] 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] abentley, but if not that, then yes, ascending probably works better for most then descending. [15:38] sorry, descending probably works better. [15:38] deryck: cool. [15:38] my head hurts trying to track ascending vs. descending for some reason. :) [15:40] 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] hmmm, I don't know. Thinking.... [15:41] * deryck is looking at how YUI tests logging [15:42] If the 'debug' config is true, a 'yui:log' event will be dispatched [15:42] can you watch that event to verify via test? [15:42] or do tests not run with debug? I don't recall [15:44] ah, that's a good idea. And easy enough to change to debug config if not. [15:45] rick_h_: Okay, I can do that. [15:46] 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] abentley, rick_h_ and debug is true by default, so that event hook should work. [15:46] I've tried installing into the eggs dir, adding to versions.cfg [15:47] rick_h_: You put the tarball in download-cache/dist, add it to setup.py, and update versions.cfg, IIRC. [15:47] 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] which I don't want to do since it's a bzr tracked file anyway [15:47] deryck: just me for prettier pdb [15:47] abentley: ah, ok. I'll try that route, thanks [15:47] rick_h_: bzr branches can be put in sourcecode/ [15:48] rick_h_: They are configured using utilities/sourcedeps.conf and updated with utilities/update-sourcecode [15:49] abentley: cool, thanks for the heads up [15:49] 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] deryck: well this is a pip install'd package [15:49] and isn't in the path from the buildout stuff it appears [15:50] 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] rick_h_, where does pip want to put it? And could you just not manually much about with PYTHONPATH exports? [15:50] deryck: so figured I'd see if there was a standard practice for this kind of personal tool thing. [15:51] 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] deryck: yea, I installed it system wife /usr/local.. dist-packages [15:51] deryck: and yea, I tried just to manually symlink it into the egg directory with no success [15:51] 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] 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] abentley: ok, just checking [15:52] rick_h_, try export PYTHONPATH=$PYTHONPATH:/path/to/other/stuff then do your make run. [15:53] 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] deryck: ok, thanks [16:16] 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] 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] abentley, I can. [16:24] deryck: thanks. [16:25] np! [16:26] abentley, nice test, btw. That's a good way to do that. glad rick_h_ suggested that. === matsubara-lunch is now known as matsubara [16:28] 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] 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] deryck: It's hard to say. What's Y.log for, if we only use the console for errors? [16:31] 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] 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] (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] deryck: This is an unusual case. On Friday, bac actually thought the link should never be missing. [16:33] right [16:33] I want us to grab oopses from failed js [16:33] deryck: And the code assumed that too, of course. [16:33] in that scenario a log of things that went odd in the page could be helpful [16:33] I'd like that too, lifeless [16:33] lifeless: me three. [16:34] 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] 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] deryck: but it would be great if Y.error was reporting an oops, and we'd fixed the problem months ago. [16:35] abentley, so I don't really mind the log, I just wonder what it buys us? [16:35] abentley, indeed! agreed there. [16:36] deryck: I guess it would make things clearer for someone debugging a structural subscription issue. [16:37] deryck: But I'm fine with killing it entirely. [16:37] abentley, fair point. I'm arguing with myself right now and trying to form a consistent opinion here. :) [16:38] deryck: there's also the option of logging it with a low priority, e.g. debug. === matsubara_ is now known as matsubara [16:39] 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] deryck: Okay. [16:40] abentley, thanks! Sorry to make more work for you. I'll note our discussion in the MP. === Ursinha is now known as Ursinha-lunch [16:50] deryck: got some time to talk about the sort issues? [16:51] adeuring, I'm about to get on a call. Can I ping you after that? [16:51] deryck: sure [16:59] adeuring: I believe you've addressed bug #894745 [16:59] <_mup_> Bug #894745: No sort on bug listing for most recently changed < https://launchpad.net/bugs/894745 > [17:00] abentley: right, thanks for the nocitce :) === salgado is now known as salgado-lunch [18:23] I'm getting OOPSes during "make sync_branches", but none of those OOPses actually seem to end up anywhere === salgado-lunch is now known as salgado [18:30] jelmer: /var/tmp/lperr/ [18:31] lifeless: other OOPSes end up there, but not the ones generated by the branch scanner [18:31] it may be firing up rabbit [18:32] 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] lifeless: I'll have a look - thanks === deryck is now known as deryck[lunch] [19:05] launchpad records timestamps for bug reports and bug last changed right? [19:05] bug reported I mean [19:29] james_w: looking at the db I see a date_last_updated === deryck[lunch] is now known as deryck [19:33] 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] deryck: erm, i seem to recall it does. IMBW [19:43] lifeless, maybe it does now. Or maybe I'm completely remembering wrong. :) [19:43] * deryck will look here in a sec [19:45] deryck: I am a little concerned at wontfix ing the sort-by-date-of-task bug [19:46] deryck: because date of task is the record of 'bug in context' [19:48] 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] a quick diversion if you will [19:49] let me grab a couple bug numbers [19:49] deryck: actually, might be simpler to switch to voice, if you have a few minutes [19:50] (ETIRED) [19:50] lifeless, I don't actually. About to jump on another call. And I've been on calls quite a bit today already. [19:50] fair enough [19:50] I'll blather on here a bit, give you as much context as I can [19:50] and you can decide after your calls ;) [19:52] ok, cool [19:53] I can't find the darn bug [19:53] so I'll describe it [19:53] when a bug has 2 tasks [19:53] and you have a search that returns both [19:53] we show both [19:53] so our collections show tasks, not bugs. [19:53] There is a bug about that [19:54] for sorts on task columns, the two rows can be widely separated. [19:54] for sorts on bug columns they will be adjacent [19:55] 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] 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] 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] I think it's a bit hard to sum up simply in UI, but maybe just "Task age" as the label. [19:57] I think the argument of 'cannot sort on it if you cannot see it' makes a great deal of sense [19:57] at least for this data [19:58] there is of course one exception - 'relevance', which is a bit hard to show as a column with any meaning [19:58] right [19:58] but if we had that, it makes more sense as a sort option that never goes away. [19:59] separately, you know what would be sexy. Having closed bugs disappear out of the list in real time [19:59] long poll subscribe to all the bugs shown on the batch. [19:59] 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] re-evaluate their inclusion on the client when they are touched [19:59] lifeless, and indeed! I'd love that. [20:00] deryck: not at all, I will do that for you [20:00] lifeless, thanks, man! And thanks for the discussion. [20:00] np! [20:00] btw today is my last day for the year [20:00] so if you have stuff you want my input on... today is the day :) [20:01] ok, I have nothing today. But I'm sure I will tomorrow or the next day. ;) [20:01] of course :) [20:02] I will probably still be around, things with long tails getting tweaked. [20:02] but I won't 'be here' here, if that scans [20:02] yup, I follow. [20:03] 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 < https://launchpad.net/bugs/896539 > [20:03] hows that for a new title [20:04] perfect! :) [20:04] I've added a note about the reopening too. Catch you later. [20:13] rick_h_, deryck: thanks [20:14] very useful attributes if exposed over the API === matsubara is now known as matsubara-afk === Ursinha-lunch is now known as Ursinha [20:53] rick_h_, are you still around, or EOD'ed? [20:53] deryck: I'm here [20:53] in/out for a few min [20:54] rick_h_, I'll get those queries now. [20:54] deryck: ty much [20:57] rick_h_, https://pastebin.canonical.com/57002/ [21:01] deryck: sorry had a typo in the id s/1007773/1007731 https://pastebin.canonical.com/57003/ [21:03] rick_h_, better? https://pastebin.canonical.com/57004/ [21:04] deryck: awesome, thanks. That looks more like what I was looking for [21:04] rick_h_, cool [21:14] hi sinzui [21:15] 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

< https://launchpad.net/bugs/480123 > [21:17] 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] sinzui: right but is relaxing those rules for distros something that bug addresses? [21:18] sinzui: so your previous 'yes' was to that question? [21:19] 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] 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] 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] bac: but too you question, distros and product must have the same behavior [21:32] sinzui, could we have a call with you anytime soon? [21:32] sinzui: whats the exploit ?? [21:32] s/??/? [21:33] 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] sinzui: if we show the full name consistently [21:33] sinzui: precise/beta1 is not the same as oneiric/beta1 [21:33] lifeless, correct [21:35] lifeless, consider the case of releasing from trunk! [21:35] 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] sinzui: indeed, and on trunk I can't imagine multiple 'beta' unqualified names being anything other than confusing [21:36] sinzui: but someone releasing from trunk could do 0.1-beta1 and we'd be ok with that AIUI [21:37] Most project do release from trunk and create series for backporting, so users creating a release want foo-5.beta [21:37] sinzui, but we would still have a constraint that milestones must be unique within a series. Does that affect your argument? [21:38] no, but the UI gets harder. [21:38] hmm,also we can't permit whatever our join character is in the milestone name [21:38] 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] otherwise the milestone 'foo-5.beta' on trunk and 'beta' on 'foo-5' might be hard to tell apart [21:39] Moving a released milestone does not change the release version [21:39] Users do move released milestones from trunk to a supported series for example [21:40] 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] 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] 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] 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] yes [21:49] The chose to escalate a bug that "sounded" like the solution to their problem [21:50] 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] Bac: the non-unique milestone bug is not about reporting, it is about normalising the milestone/release version from the series [21:52]