21:02:19 #startmeeting project 21:02:20 Meeting started Tue Nov 26 21:02:19 2013 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:02:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:02:24 The meeting name has been set to 'project' 21:02:25 #link http://wiki.openstack.org/Meetings/ProjectMeeting 21:02:35 #topic Icehouse-1 progress 21:02:42 o/ 21:03:03 icehouse-1 looks mostly on track from my 1-to-1s today, and not as empty as you'd think 21:03:08 We should also have a Swift 1.11.0 next week 21:03:47 * russellb resists obligatory "why is swift different" question ... 21:04:08 heat and horizon still have a lot to land 21:04:27 but otherwise everyone else is on track 21:04:34 #topic Icehouse cycle roadmapping 21:04:46 we now have release status for icehouse at: 21:04:48 ttx: any release concerns about the proposed scheduler split out? 21:04:53 #link http://status.openstack.org/release/ 21:05:12 lifeless: could you summarize your plans ? 21:05:31 We have 172 tracked blueprints (Medium priority or above) in Icehouse so far 21:05:41 I'd like to have this basic roadmap to be complete by the end of the week 21:05:47 It doesn't have to be "final" in any way. 21:05:57 It just have to be a fair reflection of what you know will be worked on and when you expect that work to hit 21:06:02 ttx: https://etherpad.openstack.org/p/icehouse-external-scheduler line 38 down for three sections; BP is coming later today 21:06:04 (this is a coordination and communication tool) 21:06:16 So please add missing blueprints to cover what you know should happen, and set an assignee and priority for them. 21:06:40 since we're doing more in depth blueprint reviews for nova, there will still be a batch in the process, and not prioritized, but we'll have them all reviewed and at least under discussion 21:06:42 lifeless: so this causes a number of issues 21:06:42 (for nova) 21:06:56 lifeless: i think we should just go off and do the technical bits that are right 21:07:07 lifeless: and come back when we have something working, and a more well defined upgrade / deprecation plan 21:07:14 russellb: ack 21:07:20 that we think are right, at least 21:07:25 lifeless: in theory a new project can't be integrated until J, supposing you fast-track incubation 21:07:42 ttx: ack 21:08:06 looking at taking a cinder-like approach ... minimizing divergence from what it's replacing 21:08:13 so marking it deprecated supposes you have the alternate project well lined up to replace it 21:08:13 so that we can get to usable ASAP 21:08:34 but I guess overall that's doable. Cinder-style 21:08:47 early, but i think it's doable :) 21:09:05 lifeless: i'll have to go deeper in that etherpad :) 21:09:47 russellb: the trick is to avoid doing it ironic-style 21:09:54 oof 21:10:02 well ironic-style is closer to neutron style 21:10:07 IMO 21:10:07 russellb: i.e. deprecating in icehouse and not replacing it in J 21:10:15 but yes, with you on that 21:10:23 won't deprecate until we know the replacement is well established 21:10:34 right 21:10:36 so, if we start with it as a nova project in a new tree we'll have the technical room to do what we need. 21:10:50 compute program project you mean? 21:10:58 *snarl* 21:11:02 :) 21:11:05 IMO, yes, compute program until it starts growing real legs to do something more 21:11:11 but it's a ways before it can get that far 21:11:18 agreed. 21:11:22 * annegentle sends lifeless some turkey and gravy 21:11:25 lifeless: you should still file for incubation asap. There are some pretty harsh requirements for incub/graduation now :) 21:11:32 ha 21:11:41 there's not even a repo yet :) 21:11:47 so, lets move on 21:11:51 I have what I need 21:11:55 cool 21:12:01 other questions on icehouse-1 / icehouse roadmap before we discuss cross-project issues ? 21:12:22 mriedem: around ? 21:12:28 ttx: yup 21:12:29 #topic Oslo sync (mriedem) 21:12:31 powervm 21:12:32 oh 21:12:39 heh 21:12:40 mriedem: not yet! i'll let you introduce the discussion 21:12:54 so i just brought up the oslo sync debate in the nova meeting last week, 21:13:01 russellb said it should come here since it's cross-project 21:13:07 since then the ML blew up a bit more but i haven't stayed up to date 21:13:20 let's not boil the ocean on this ... but basically, i was saying it wasn't a nova issue specifically 21:13:24 that's why dhellmann, bnemec, lbragstad and lifeless are here 21:13:30 and that we should engage with dhellmann, and other oslo folks 21:13:53 from what i gathered quickly from the ML was there is general consensus on improving update.py a bit? 21:14:27 russellb: right, that's what i meant to say :) 21:14:31 k 21:14:33 mriedem: that was my interpretation of that thread as well 21:14:34 so the thing I really want to see 21:14:46 is all the oslo bits that aren't evolving weekly 21:14:51 released as libraries 21:14:56 +1 21:14:59 their special incubation period is over 21:15:11 we are working on that 21:15:16 and we'd avoid a raft of overhead keeping up with hacking format changes and stuff 21:15:16 mriedem, yeah, improving update.py would help 21:15:35 dhellmann: I know - not criticising, just saying that thats what I really want to see 21:15:37 however, there are some unfortunate cross-dependencies 21:15:52 lifeless, mostly agree, but there are some we'd regret taking that approach with when we struggle with future API changes 21:15:56 dhellmann: because the other angle I'd go is aiming at making the incubator /be/ a library. 21:15:58 yes, I would prefer time spent on graduating code over gold-plating update.py 21:16:15 lifeless, but I dig your point that if the APIs haven't changed for a long time, let's just bite the bullet 21:16:27 markmc: AIUI the point of oslo is to go from 'production in one project to production in > one' 21:16:31 markmc: the incubator I mean. 21:16:43 * markwash loves the improvements we've been making before promoting to libs 21:16:47 lifeless, point of incubator is to evolve towards API stability 21:16:54 lifeless: yes, but not "as is" -- we also try to make the code actually usable 21:16:55 markmc: How do we measure that? 21:16:57 right, what markmc said 21:17:07 lifeless, you feel the truthiness in your gut 21:17:09 lifeless: gut check? 21:17:32 and i think oslo generally attracts people with a good gut for such things 21:17:38 one mornign I woke up and FELT that rootwrap was stable. 21:17:40 markmc: but if noone is evoling the thing 21:17:43 https://github.com/openstack/oslo-incubator/blob/master/MAINTAINERS 21:17:45 * dhellmann thanks russellb for complimenting his gut 21:17:49 has worked well so far i think 21:17:49 " 21:17:50 APIs in oslo-incubator are resting here temporarily until they have been 21:17:50 cleaned up sufficiently so that we can make a commitment to backwards 21:17:50 compatibility and release the API in a properly published library. 21:17:51 " 21:17:55 dhellmann: snort 21:18:03 markmc: we're stuck with manual integration rather than continual integration 21:18:33 lifeless, incompatible API churn is painful too 21:18:44 was afraid of this same discussion again, i feel like we've had it 100 times 21:18:52 lifeless, basically, I think the incubation process is evolving, we'll see libraries released more quickly now 21:19:02 the update.py pain is a good motivator for cleaning up APIs 21:19:06 lifeless, but the principle of evolving towards API stability still makes sense 21:19:09 right, I think we figured out how to do it with oslo.config and oslo.messaging 21:19:14 that's going to make the next few easier 21:19:25 I'm not disputing the principle - thats a different discussion. 21:19:46 I'm worried that we're not executing effectively, and I'd like to know how I and the community can help that happen. 21:19:46 OK, we've been havgin that discussion at least 10 times already, and I don't want to spend all this meeting on it 21:20:00 one thing that can help get libraries out more quickly 21:20:03 more people helping! 21:20:12 especially since we all know that markmc always wins the argument in the end 21:20:34 lifeless, seriously, pick a random API, turn it into a library ... see if anyone objects :) 21:20:44 Have we decided what to do with the pieces of Oslo that don't fit nicely into a library? 21:20:53 bnemec: which are those? 21:21:06 bnemec: maybe we should take that up after the meeting 21:21:10 ttx, I dunno, lifeless does alright on that front :) 21:21:23 :P 21:21:24 yes, anyone needing convincing can talk to dhellmann and markmc off-meeting, let's move on 21:21:28 I don't have any off the top of my head, but I recall from previous discussions that there were things that didn't fit nicely. 21:21:32 But +1 to after the meeting. 21:21:33 -> list 21:21:37 #topic Nova PowerVM Driver Removal (mriedem) 21:21:38 'how can we move it faster' 21:21:40 * jd__ agrees with ttx 21:21:41 You again :) 21:21:56 so i don't have much else to say about the powervm driver removal 21:22:00 So, on this one... I'm OK with a fast deprecation path if we don't screw any user in the process 21:22:06 We got some reassuring comments from the User committee that this driver may not be in use 21:22:13 ttx: russellb's idea was just move it to stackforge 21:22:14 no users have shown up, one possible future user 21:22:16 But then we had this guy: http://lists.openstack.org/pipermail/openstack/2013-November/003370.html 21:22:16 which i think we're OK with 21:22:27 that said, if he is in POC -> Prod mode, choosing the PowerVM driver at this point might not be the best option, if IBM loses interest in maintaining it 21:22:33 i am in favor of the stackforge move 21:22:50 +1 to stackforge move 21:22:51 so we might just save him by encouraging him to not go on tat road 21:22:53 ttx: russellb: yeah, i think what the one user was saying is as long as it's freely available (stackforge), he's ok with it 21:23:05 what is the point of keeping the code without any maintainers? 21:23:10 yep ... but honestly, you guys have already said you're not interested 21:23:10 mriedem: I think he said (ubuntu) but meh :) 21:23:13 so i'm not sure why anyone would 21:23:36 russellb: not interested in what? stackforge? 21:23:43 not interested in maintaining it long term 21:23:43 mriedem: you should probably engage with that specific person and make sure he moves to powervc when ready 21:23:53 so it seems like a dead end for someone to be looking to deploy in the next year 21:24:06 and let's not confuse this with powervc 21:24:12 none of this means we'd accept a powervc driver necessarily 21:24:12 ttx: yeah, that's what we plan on doing, there are some key people out to be in that discussion though this week (thanksgiving holiday) 21:24:37 russellb: right, that's understood 21:24:37 we may or may not, but it would be evaluated based on its own merits 21:24:39 ok 21:24:46 russellb, what's your thought here? delete from nova and not move to it to stackforge? 21:24:47 it keeps getting brought up, and i really want to separate it 21:24:54 we will be maintain the powervm driver internally for some time until the powervc one is 'ready'ish 21:24:58 dims: delete from nova, and then you guys (IBM) do what you want 21:24:59 mriedem: so at this point I'm fine with fast deprecation + stackforge if there is some personal advice given to that one user who has mentioned wanting to use it 21:25:00 but stackforge is an option 21:25:41 my only question about stackforge is if we can use the same gerrit and CI for running unit tests? i wasn't sure how that works. 21:25:47 yes 21:25:50 same infrastructure 21:25:54 ok, good to know 21:25:57 so actions 21:25:58 as a fallback plan basically 21:26:00 1) approve the removal 21:26:01 russellb, cool let's stick with that then "Delete from Nova, Move to Stackforge" 21:26:12 so whats the difference between powervm and powervc 21:26:15 2) mriedem respond to the openstack post giving some recommendation to the one guy 21:26:20 is one free with the hardware and one commercial ? 21:26:21 lifeless: powervc is vcenter on power 21:26:28 as a note, there is currently a hold on creating new stackforge projects because of a zuul issue 21:26:28 3) move to stackforge 21:26:34 mriedem: um, but not vcenter at all right? 21:26:36 so be aware of that when making scheduling plans 21:26:36 it's your own thing 21:26:41 russellb: +1 21:26:45 russellb: right 21:26:55 dhellmann: is that a short or long hold? 21:26:57 russellb: i agree with your action plan 21:27:08 ok thanks 21:27:09 lifeless: there's a bug they need to fix, so it depends on that 21:27:11 i think we can move on then 21:27:28 #link https://bugs.launchpad.net/openstack-ci/+bug/1242569 21:27:31 Launchpad bug 1242569 in openstack-ci "manage-projects error on new project creation" [Critical,Triaged] 21:27:43 jeblair: do we have an ETA for the fix on this one ? 21:27:55 * ttx has a icehouse-1 blueprint blokced on it) 21:28:04 ttx: mordred is working on it 21:28:09 also, totally not a zuul issue :) 21:28:15 ttx, no, yours went through because it's not a stackforge repo 21:28:17 it is a manage-projects issue 21:28:19 [infra magic] issue 21:28:20 yes. I will fix this in a few hours 21:28:23 jeblair: sorry, didn't mean to mischaracterize it 21:28:40 dhellmann: oh. nice. stops complaining 21:28:44 the fix is well identified - I just need about an hour to actually do it 21:28:58 * dhellmann would give mordred and hour if he had one 21:29:09 as soon as I'm done with these powerpoint slides... 21:29:27 hehe 21:29:28 ok, let's move on 21:29:35 russell did summarize the plan quite well 21:29:50 #topic flake8 (notmyname) 21:29:53 hi 21:29:58 notmyname: you mentioned getting pushback that forces you to ignore a check ? 21:30:08 but then you were using a phone keyboard 21:30:13 (maybe there has been process since) 21:30:18 *progress 21:30:49 so swift has a few cases where a bare except is needed. so we offered a patch to hacking to support #noqa on bare excepts 21:31:06 #link https://review.openstack.org/#/c/57334/ 21:31:15 notmyname: thats surprising. Do you run on python2.4 ? 21:31:18 it got some pushpack (https://review.openstack.org/#/c/57334/) which caused us to simply ignore the check https://review.openstack.org/#/c/56712/ 21:31:57 notmyname: i don't see pushback 21:32:09 notmyname: except for a suggestion that the commit message have an explanation 21:32:12 notmyname: neither do I 21:32:25 in fact this hasn't got approved yet just do to review backlog 21:32:26 notmyname: I realise thats a side issue, but bare except: only difference from except BaseException in that it catches string exceptions 21:32:38 notmyname: which are thorughly deprecated and dead upstream 21:32:52 like I said, seems perhaps there was movement yesterday that I hadn't seen 21:33:25 so perhaps a non issue today (not that I have more info than when I was on my phone with ttx this morning) 21:33:27 so no feedback in a few days is pushback? 21:33:31 notmyname: is there a discussion somewhere regarding the need for bare excepts? 21:33:51 notmyname: on a purely technical basis I'm fascinated :) 21:33:58 * dhellmann wonders why each hacking rule has to look for noqa independently 21:34:07 dhellmann: great question :-) 21:34:38 notmyname: (just found clay's comment on Nov 19 https://review.openstack.org/#/c/57334/ citing PEP8; reading) 21:34:42 there was other discussions in IRC earlier in the week that caused us to believe the hacking patch wouldn't land. 21:34:46 were* 21:34:50 notmyname: I think that patch is not blocked, so you should be able to remove your workaround 21:34:59 ttx: then we can move on 21:35:01 (when it lands) 21:35:08 dhellmann: each hacking rule parses the line using a few different methods - and there is not a global line parser for a line 21:35:12 I don't want to be blocked on that 21:35:40 and simply wanted to raise it here to ensure it goes (based on IRC conversations more than review comments) 21:35:47 ok, looks like this is a non-issue, next topic 21:35:58 #topic Proper tracking for non-deterministic bugs affecting gate 21:36:04 That one should be more bikeshedding 21:36:18 lifeless: want to introduce this one ? 21:36:26 oh yay 21:36:34 btw, cross project topic for the queue ... checking in on neutron vs nova-network status 21:36:39 so 40 minutes ago we were gathered here 21:36:47 and talking about how to get gate bugs attention 21:36:59 ttx: NICE time estimate, btw! 21:36:59 and the various tradeoffs between using the well known hammer of critical 21:37:08 jeblair: I'm a pro. 21:37:18 (actually 38, but 40 was a h/t to ttx) 21:37:23 anyhoo 21:37:28 critical 21:37:43 or some gate-thing-specific search (e.g. /rechecks, a canned bug search - e.g. tag, etc etc) 21:37:44 lifeless: I thought notmyname's topic would create more flames. 21:37:46 go to it 21:37:55 ttx: well if my technical question was answered, maybe:P 21:38:08 how about we start by figuring out how to decide which non-deterministic failures are really critical? 21:38:21 lets not use the word critical - overloaded. 21:38:24 markmc: I think sdague's point is that they all are 21:38:30 Lets say - things we want 24 hour fast focus on 21:38:33 markmc: as they just add up 21:38:35 markmc: so up until this point it's been the judgement of the group of us that flag it 21:38:36 and things we want ahead of other bug fixes 21:38:47 and things we want in the general mix of bugfixes 21:38:56 because those are I think the three effective categories we have 21:39:11 'drop everything', 'front of the regular queue', 'whenever' 21:39:27 and I guess the question is if we're going to continue with a small group of folks with that power (either explicitly or by cultural construct), do we trust those folks to make good judgements there 21:39:27 they sound like they should be marked as critical, yes :) 21:39:46 however, if we have say 30 non-deterministic bugs right now ... they don't all qualify under that criteria 21:39:48 lifeless: some busy projects only have two ('drop everything' and 'whenever') 21:40:01 are we also proposing that 'critical' bug fixes get priority in the gate queue? 21:40:02 because the reality is, until the race shows up a few times it doesn't pop up 21:40:06 but that's arguably a failure 21:40:20 ttx: degenerate case of front of the queue ;P 21:40:21 markmc: so here's the thing, it's not 2 giant races 21:40:30 dolphm: have to be careful with doing that kind of thing, if it's automatic it'll get abused :( 21:40:31 from collections import set as deque 21:40:31 it's actually 30 little races that all interact 21:40:37 sdague, "trust to make good judgement" does not start with "all non-deterministic bugs, no matter how rare, are automatically Critcial" IMHO :) 21:40:44 markmc: big +1 21:40:51 russellb: understood, that's why i'm asking! might affect my opinion on the larger issue 21:41:12 so perhaps, if its the set of things that is the problem 21:41:22 markmc: ok, well I've been staring at this one for a while. And the problem is we're actually getting killed by a thousand paper cuts. 21:41:25 we can talk about the criticality of making that set be below some threshold 21:41:44 however, it will take some more time to be able to easily visualize that fact 21:41:53 and if we agree about that, then we can say - whenever it's over that threshold, *all the members* count as critical until it's below the threshold. 21:41:54 which is basically my top dev priority at this point 21:41:58 sdague, making them a thousand Critical bugs won't fix it :) 21:42:16 markmc: ++ 21:42:16 markmc: what do you think will fix it? 21:42:19 lifeless: I think we could use Tag + High/Critical (as a way to prioritize amongst them) 21:42:28 how many of these things do we actually have open right now? 21:42:36 markmc: also it's 100 bugs spread over a dozen code bases. 21:42:36 i think we should focus on the goal ... making people want to work on this 21:42:38 markmc: well let me reverse it. Do you think that what myself, jog0, and clarkb have done so far has made things better or worse? 21:42:38 i.e. if all critical, it might be hard to prioritize which one should be fixed first 21:42:39 lifeless, the kind of work and awareness raising going on this week 21:42:43 markmc: thats what - 10 per code base. 21:42:47 for those that haven't seen it, i imagine these bugs would be a subset of the bugs here: http://status.openstack.org/elastic-recheck/ 21:42:52 i don't think it's 100 bugs... 21:42:53 So lets not extrapolate out to infinity on the data we have 21:42:54 right now we are tracking 9 gate bugs with e-r http://status.openstack.org/elastic-recheck/ 21:42:55 not all bugs on /rechecks/ are actually transient issues at all 21:43:07 jog0: we have 110 tracked rechecks today, if I counted right 21:43:09 what gets more people interested in helping with these things? 21:43:11 (maybe they are at the moment, but it's not always true) 21:43:16 dolphm: these aren't trusting the user provided bugs 21:43:19 lifeless: recehck vs elastic-recheck 21:43:20 jeblair: I count about 18 21:43:21 TBF it's not just 3 or 4 individuals making things better 21:43:23 lifeless: the rechecks page has a lot of garbage data 21:43:27 jeblair: ok! 21:43:34 and it's not just 3 or 4 that are going to address it 21:43:35 if they are critical, is there a good way to get help understanding and duplicating the bugs? I often cannot make heads or tails of the bug reports for things in the rechecks list 21:43:35 so elastic-recheck is our source of truth? 21:43:37 it's a scaling problem 21:43:39 this is elastic recheck 21:43:39 dhellmann: and at looks like 5 of them are ready to be removed 21:43:46 tags, priorities etc aside 21:43:48 jeblair: progress! 21:43:58 sdague, oh, far better ... totally - my input is basically that bumping a big number of bugs to Critical will hurt your progress 21:43:58 which means that a set of us have found a fingerprint, and found that it shows up more than once 21:44:07 markwash: +1 21:44:12 so that puts us at about a dozen or so on the e-r page, but if jog0 says 9 i believe him :) 21:44:45 lifeless: for this conversation, i think so. elastic-recheck is made up of bugs that have gone through human review and we know are gate-affecting 21:45:24 is there a good dashboard of the e-r bugs? 21:45:27 lifeless: /recheck is sadly full of people rechecking things against nonsense bugs. it will eventually be replaced with the e-r page 21:45:32 nm i see the URL now 21:45:33 markmc: ok, fair. :) But we are talking about a finite set here - http://status.openstack.org/elastic-recheck/ 21:45:49 russellb: that's sdague's big project for the next bit, to improve http://status.openstack.org/elastic-recheck/ and make it more dashboardy 21:45:50 sdague: cool! this is new to me 21:45:54 so problem number one is people, noted. :) 21:46:06 sdague: jog0: the elastic-recheck page is only for those that are in the yaml query file though right? 21:46:08 i think the improved dashboard will make a *much* bigger impact than changing bug priorities 21:46:18 russellb: I 100% agree 21:46:21 k :) 21:46:35 unfortunately, had these other things take the last two weeks of my time 21:46:46 so diving back in right after thanksgiving ont hat 21:46:49 russellb: here's the problem i want to solve -- we are able to fix these bugs only when we get people aware of them and working on them. i'm trying to find the best process to do that. 21:46:50 there was just a whole lot of focus on bug priority ... 21:47:13 jeblair: a good dashboard, and people regularly reporting status to the -dev list, and in meetings 21:47:14 IMO 21:47:18 jeblair: i think it might help to show people how easy it is to get a bug into the e-r query.yaml file 21:47:37 jeblair: once the bug is in the query and e-r is checking and reporting on it, you should stop seeing so many 'recheck no bug' 21:47:43 like jog0's report recently ... would love to see that regularly 21:47:44 and it's pretty easy to push patches to add queries to -er 21:47:47 here are the current issues and their status 21:47:47 russellb: I think the point is giving devs a whole other place to look when deciding what to work on might be less effective than just setting the priority so they show up at the top of the list in the usual place 21:47:50 russellb: agreed, honestly, the sequence would have been better to hit this first 21:47:51 and which ones need more attention 21:47:57 russellb: yes, that's completely the intention 21:47:57 russellb: i'm not sure we should wait for a good dashboard. i anticipate that's a while out yet, and it depends on people incorporating 'wake up and check the dashboard' into their workflow 21:48:03 dhellmann: +1 21:48:08 dhellmann: thats precisely my point 21:48:24 frankly, I think we are getting better at this, not worse. 21:48:24 folk are bad at pulling together widely disparate information sources in their inner loop of 'what to work on next' 21:48:25 a weekly email then 21:48:30 could elastic-recheck leave comments on bugs as a starting point? 21:48:43 I think it already does? 21:48:44 or more frequent when there are severe issues 21:48:44 dolphm: it already does 21:48:44 sdague, cool stuff - that page looks far more useful to people want to help with this than bug priorities 21:48:47 russellb: we plan on it 21:48:50 I like the weekly email and I like a tag ("gate"?) and I like setting the priority 21:48:51 ok all good stuff 21:48:54 the recent events have been quite well communicated imho 21:49:01 i guess i'm lucky in that i haven't experience that yet lol 21:49:02 ttx: yep 21:49:17 critical isn't quite "where I look for stuff to work on" its more like "oh crap what is ttx gonna yell at me about?" 21:49:20 markmc: thank you. 21:49:24 dolphm: yeh, honestly, keystone isn't really subject to this much by not having an rpc bus 21:49:25 markwash: +1 21:49:35 markmc: I don't understand why you (seem to) think bug priorities aren't helpful 21:49:49 markmc: but we can sidebar that if you like 21:49:52 so the recent gate issues have shown that we were just two bugs away from a massive gate wedge -- something we never want to have again 21:49:53 markwash: that's one benefit/problem of using "critical" for that. That reuses my nagging 21:50:01 i think markmc's point is to be careful not to dilute the value of bug priorities 21:50:04 nagging-as-a-service 21:50:10 marking a ton of stuff critical is counter-productive 21:50:11 so, honestly, I'm completely ok with the resolution of "go make the dashboard better first" and if it's not working talk about bug priorities later 21:50:14 and we've only been able to fix these issues by getting people on it. 21:50:20 so just want some reasonable line 21:50:21 so there are 18 such bugs 21:50:23 and then i'd be Ok with it 21:50:25 lifeless, just that marking obviously not-obviously-critical bugs as critical will be (yeah, as russellb says) counter-productive 21:50:34 sdague: i don't see how getting a better dashboard will get people to commit to fixing bugs 21:50:42 maybe 14 once fixed ones are gc'd 21:50:44 how about we use tag + high / critical depending on how urgent the fix is ? 21:50:45 ttx: lol :-) 21:50:47 i don't see how marking bugs will either on its own 21:50:56 markmc: russellb: ok, understood on dilution. 21:50:58 sdague: right now, sdague and jog0 go and bother people until someone starts working on it 21:51:01 (that's already what we do, btw) 21:51:08 there has to be a better way to communicate 21:51:15 sdague, easy to use the dashboard as data to ask bug triage teams to bump the priority of bugs 21:51:22 so the bug database is our shared understanding of defects 21:51:26 i think we'll always need people making this a higher priority on their list to look afer 21:51:27 I guess here's the question - what is the right and consistent signaling mechanism to the PTLs to get people to look at bugs 21:51:29