20:02:24 #startmeeting tc 20:02:25 Meeting started Tue Nov 26 20:02:24 2013 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:29 The meeting name has been set to 'tc' 20:02:35 Agenda is at: 20:02:41 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:52 #topic Recognize indirect contributions to our code base 20:03:06 We got a formal request asking us to support a Sponsored-By: commit message header 20:03:11 #link http://lists.openstack.org/pipermail/openstack-tc/2013-November/000389.html 20:03:20 My reading of the -dev discussion would be that commit messages are not to be turned into a NASCAR car 20:03:27 +1 20:03:32 And complex affiliations / sponsoring can be tracked into analytics repositories if that's something people really care about 20:03:37 o/ 20:03:41 #link http://lists.openstack.org/pipermail/openstack-dev/2013-November/018571.html 20:03:46 also that thread on dev ^ 20:03:54 jeblair: ah, bad link, thx 20:04:00 well, also people can consider using different email addresses for work affiliated for different companies 20:04:12 me too 20:04:14 we have a system 20:04:14 o/ 20:04:15 and have the analytics tools handle single person, multiple addresses, multiple affiliations 20:04:15 use emails. 20:04:19 done 20:04:24 does anyone want to argue *for* Sponsored-by at this point ? 20:04:30 ttx, markmc: i agree with what you have said, and don't feel that this is ripe for tc action 20:04:31 yep, emails seems like a good recommendation 20:04:49 agree- it ials would work with all of the current stats counting things 20:04:51 also, Co-authored-by: my-alt-email@foobar.com where your work is sponsored by multiple companies 20:04:56 and would not break russel's things 20:05:06 * nijaba can argue if you want ;) 20:05:27 no need to spend more time on this if no member feels like defending it 20:05:41 seems like we feel that using email addresses solves this 20:05:43 nijaba, would have been better to reply on-list :) 20:06:08 nijaba, we're just re-stating consensus from the list here 20:06:16 markmc: sure, but I think I made my point in the original proposal. Then wanted to let the debate take place 20:06:24 markmc: i like the co-authored-by strategy 20:06:46 + its an easy way to double your line count! 20:06:48 ok, I guess we can move on to next topic 20:06:55 unless someone screams now 20:07:25 #topic Add David Chadwick as exceptional ATC (Keystone) 20:07:30 #link https://review.openstack.org/#/c/57500/ 20:07:34 makes sense to me 20:07:37 +1 ("I'm actually surprised that he isn't a contributor already") 20:07:41 +1 20:07:52 +1 20:08:00 Will APRV this one as soon as it reaches the bar (probably already has) 20:08:11 * ttx checks 20:08:36 except Monty -1ed it :) 20:08:43 for alphabetizing 20:08:45 has 5 20:08:45 he's that guy 20:08:54 there's always that guy 20:08:55 jeblair: did you make the +1/+2 change already ? 20:09:06 ttx: yes 20:09:12 ok, that explains stuff 20:09:30 ttx: that's why we're all +/-1 now 20:09:32 only ttx has +2/+A? and tc has +1/-1? 20:09:35 anyway, will approve once it reaches the approval bar 20:09:38 russellb: yes 20:09:40 k 20:09:51 lsell: around? 20:09:53 also, i agree it should be alphabetized, but since we agreed that ttx can self-approve trivial changes, i figure we can fix later. 20:09:59 yes 20:10:14 skipping to ceilo / telemetry since Lauren is around 20:10:16 #topic Change Ceilometer from Metering/Monitoring to Telemetry 20:10:21 jeblair: I can change my vote with that - that's a good solution 20:10:24 #link https://review.openstack.org/#/c/56402/ 20:10:38 Last week I delayed the decision so that we can get input from the OpenStack marketing folks on this "official name" 20:10:49 I think there is confusion between the program name (which is originally picked by the team itself) and the official OpenStack name (which is more of a marketing / BoD thing) 20:10:56 * vishy wants his +2 back 20:10:56 We reuse the official names in the program names 20:11:13 I guess we could consider that programs are named by their teams and when one of their projects become incubated they engage with the marketing folks to come up with a name for it 20:11:25 and if that makes sense, may rename the program to match the official name (may not always make sense) 20:11:44 In this case, this is the program being renamed 20:12:03 But also the name we'd suggest as official OpenStack name for Ceilometer 20:12:13 so there's program names, project code names, and project official openstack names, yes? 20:12:22 yes 20:12:36 russellb: imagine multiple projects under the Compute program 20:12:39 yep 20:12:44 just making sure i have it straight 20:12:45 you have Nova and SuperNova 20:12:54 * mordred wants supernova 20:13:01 Nova's "openstack name " is "OpenStack Compute" like the program 20:13:06 and here we're proposing a program name change (and probably recommending an official project name change too, but technically separate) 20:13:12 right. 20:13:12 program is "Compute" 20:13:21 SuperNova could be "OpenStack Black Hole" 20:13:43 at which point you may consider renmaing the program to "Computes and Black Holes" if that makes better sense than "Nova" 20:13:48 err. "Compute". 20:14:19 does that make sense for everyone ? 20:14:25 good here! 20:14:32 it's a little contorted, but I get what you mean :) 20:14:52 ttx: yes. and ideally, we want the program and product names aligned. thus, lsell is here :) 20:15:05 jeblair: exactly! 20:15:09 sounds good to me too. i just want to make sure we stay aligned where possible as we choose the terms for public comms 20:15:17 also she could suggest better names ! 20:15:27 lsell, so how does Telemetry sound? :) 20:15:31 lsell: so does "OpenStack Telemetry" sound good? I personally think it sounds awesome 20:15:52 I like that it's accurate, catchy, one-word 20:16:19 I'm a little concerned that a broader audience might not immediately understand the meaning, but we'd like to give it a try and I can circle back with you guys in a few months if we feel like it's not getting traction 20:16:34 yeah 20:16:40 so yes...let's try it 20:16:46 * markmc has a pretty decent vocabulary but had to look it up 20:16:52 it struct me as odd at first FWIW 20:16:57 see my -1 original vote, heh 20:17:02 * mordred just realized we have lsell, markmc, nijaba and himself here - does that mean we're having a joint TC/Board meeting? 20:17:03 it's not as if we didn't move from "OpenStack Networking" to "OpenStack Network service" and back a few times 20:17:14 ok, i'm glad i'm not the only one who had to look it up :) 20:17:19 i was familiar with it, but i guess i read different books. :) 20:17:36 it's quite accurate, but there is some cost to being overly clever, i think 20:17:36 jeblair: i like missiles and space too 20:17:45 but i'm still ok with it.. 20:17:50 And AI supre tanks 20:17:54 jbryce: right! :) 20:18:03 jbryce: we could shoot missiles for next Foundation team activity. 20:18:16 * jeblair plays with the space toys on his desk 20:18:20 it's hard to make something that relates to billing sound exotic, but I think Telemetry just might do it 20:18:38 heh 20:18:38 i think that clear over clever is usually better too, but in this case the clear option was getting to be a little unwieldy too 20:18:40 ha 20:18:40 sparkycollier, OpenStack ShowMeTheMoney 20:18:41 i think it will require additional explanation on our side, where metering and/or monitoring is pretty straight forward 20:18:43 yes, "Monitoring" was both inaccurate and boring 20:18:51 moneyball 20:19:05 * nijaba thinks that mordred has some fun ideas :) 20:19:25 anyway, let's use that as program name and initial openstack name and see how it goes 20:19:34 nijaba: :) 20:19:47 will they also change the IRC channel from -metering? 20:19:59 annegentle: would make sense... 20:20:17 sounds good. and moving forward we'd love to engage with the PTL and team as soon as a project is incubated to nail down the naming and make sure everyone is on board 20:20:28 Will APRV https://review.openstack.org/#/c/56402/ tomorrow morning if it still has the overwhelming majority in favor 20:20:43 lsell: sounds great 20:20:54 this one decided to change scope and mess up the name :-p 20:21:01 which brings us to... 20:21:06 #topic Incubation / Graduation / NewProgram requirements drafts 20:21:28 (we could actually add that engagement to the graduation requirements) 20:21:34 #link http://lists.openstack.org/pipermail/openstack-tc/2013-November/000415.html 20:21:51 So the idea here is for us to have a clearer set of guidelines to apply for incubation / new program requests and end-of-cycle graduation review 20:22:10 So far we've been applying a number of unwritten rules, and I think writing them out would help setting expectations right for candidate projects 20:22:10 (and they are guidelines; not set in stone) 20:22:20 yes. I think that's very important 20:22:30 we are, ultimately, humans who can make decisions 20:23:10 I would like to turn those etherpads into a resolution and push for discussion to -dev 20:23:14 that's good to hear confirmed, because i was accused of being a robot recently 20:23:23 ttx: i think we're about at that point... 20:23:30 ttx, just added some legal bits - apache license, library licensing, contributors signed the CLA, no trademark violations 20:23:38 so if you have strong ideas that are not reflected yet, please add to that before eod 20:23:45 markmc: I appreciate that, thanks 20:23:46 one thing that might bear discussion is the relative stringency of the transition to incubation vs graduation 20:23:46 also important that the guidelines will evolve 20:23:53 yeh, I was pretty happy with what was in the etherpads yesterday, went through them in depth then 20:23:54 russellb is a robot?! Who knew 20:24:05 What was the etherpad discussion about the two deployments bit? 20:24:45 the proposed guidelines for being incubated are quite high -- requiring stackforge, devstack tests, etc. after seeing the discussion around them, i'm coming to agree that that is a good idea. 20:24:46 I actually don't like the requiring production deployments thing ... i think it's in conflict to wanting to be able to review and influence the architecture if necessary 20:24:47 ttx: just out of curiosity, was there a reason not to put them in one pad with headings? I feel in a lot of ways the flow from one level to the next is an important part of the story 20:25:13 russellb: but it was a requirement for graduation, not incubation 20:25:27 sdague: I thought they would end up in 3 separate documents in the repo 20:25:39 sdague: do you think it makes more sense in a single document ? 20:25:50 ttx: it feels better to me as a single document 20:25:50 "rules-we-apply-for-stuff" ? 20:25:53 i think a single doc makes sense 20:25:56 russellb: i agree, i think it's almost an anti-requirement (but i don't think we can do that either). however, it's struck-out, so i take that as a good sign. 20:25:59 sdague: ttx: I like the single doc as well 20:26:09 project lifecycle? 20:26:13 or something. 20:26:16 russellb: well... 20:26:18 jeblair: but why is it an anti requirement? 20:26:25 the issue is that new program is not a step in that lifecycle 20:26:26 Why are we gradutating things people aren't using? 20:26:28 do we have any time limits already in our governance docs? Such as you don't incubate > integrate until a release passes? 20:26:52 mikal: some things might not get used until they are in a release 20:26:54 ttx: true ... programs_and_projects.txt ? 20:26:57 still seems tightly related 20:26:59 depending on the space in which it exists 20:27:07 mikal: well, that would have bounced cinder from graduating 20:27:18 just added "project must have an elected PTL" to incubation requirements 20:27:19 mordred: couldn't we have dealt with that by making an exception at the time? 20:27:22 and I think cinder is a model for the right way to get through the process 20:27:23 maybe two documents. project lifecycle and program lifecycle 20:27:30 markmc: +1 20:27:35 mikal: well, how about we say "we'd like to see production deployments" 20:27:38 markmc: elected from its technical contributors? 20:27:42 I want to block projects which don't have active users. 20:27:45 because newprogram can happen before or after incubation request, basically 20:28:08 If they can't find at least a couple of deployments during incubation, there is a big problem 20:28:09 russellb, point 20:28:27 How do we know it meets actual user needs? 20:28:30 mikal: i would not hold it against operators to avoid deploying incubated projects 20:28:34 How do we know the design is right? 20:28:34 mikal: incubation is risky 20:28:40 Why are we working on this thing no one wants? 20:28:49 right. especially the more stable openstack itself gets 20:28:53 mikal: and if we're not willing to say it's part of openstack, we shouldn't expect other people to behave otherwise. 20:29:02 jeblair: +1 20:29:05 I mean, there might be a point where people are only wiling to deploy our integrated projects 20:29:05 that's my feeling 20:29:09 mikal: yeah, I removed the production deployment requirements when I saw there was no consensus around it. Doesn't mean you can't apply it in your own decision grid 20:29:19 mikal: so what if it's a should instead of a must, and make it judgement call during vote 20:29:25 ttx: I think its stronger than that 20:29:34 ttx: I will vote against the proposed requirements as they stand 20:29:46 ttx: I'm willing to tweak the language 20:29:52 mikal: on that single point, or are there others? 20:29:58 ttx: But I honestly feel we should have a test that says "people will use this" 20:30:18 sdague: I think this one point is a pretty big deal 20:30:39 We have at least two virt drivers in nova at the moment that we don't know if _anyone_ uses 20:30:45 mikal: which ones? 20:30:47 I want to stop that happening at the project level as well 20:30:52 mikal: no, that's fine, it wasn't an accusation, just a question 20:30:56 * mordred not trolling, trying to get context 20:31:05 mordred: virt drivers? powervm and docker are the ones I am thinking of 20:31:07 yeh, I only know one :) 20:31:11 mikal: the document will never represent the whole set of rules we'll apply, it just strives to document a number of rules that we all agreed on 20:31:13 mikal: k. thanks 20:31:16 mikal: you'll vote against a necessary-but-not-sufficient ruleset because it doesn't contain a rule which there isn't consensus on ? :) 20:31:32 mikal, more context ... do you think we've not held projects to this standard so far and it's hurt us? examples? 20:31:34 lifeless: +1 20:31:39 mikal: openstack is not just public cloud software. i think we should try to only add useful programs, but i also think there's room for being flexible here, and understanding that this isn't just for hpcloud and rax. 20:31:40 mikal: not sure if anyone uses lxc either 20:31:54 markmc: no, I think we've done a good job at the project level until now 20:31:55 lifeless: you expressed it better than I did :) 20:31:59 markmc: I just want to solidify that in the future 20:32:07 So, rephrase it 20:32:19 We could require that users have expressed a desire to deploy. 20:32:25 mikal, I'm not sure I feel we've held projects to the bar you describe so far 20:32:31 mikal: "project should have users" ? 20:32:33 "meets a clear user need" ? 20:32:43 "project should be usable" ? 20:32:53 usable is probably not enough 20:32:59 "Project should have planned deployments"/ 20:32:59 ? 20:33:06 vishy: I know people use lxc 20:33:16 mordred: good god, that would be horrible 20:33:21 planned deployments way, way overstates it IMHO 20:33:24 it's easy to wave hands around and say that you plan to deploy it ... 20:33:46 project should be usable in production at scale in line with other openstack projects? 20:33:55 do the Heat team have any insights even now to "planned deployments" of Heat? 20:34:13 markmc: yes, Rackspace have publicly stated they intend to deploy 20:34:19 markmc: I'd say HP has as well via tripleo 20:34:20 yeh, I was going to say, trove was kind of an exception, looking at Heat and Ceilo 20:34:39 horizon wouldn't have made the cut for a long, long time. but adding it was a GOOD idea. 20:34:53 yup 20:34:57 same for heat, i think 20:34:57 and now there are deployments 20:35:00 mikal, ok, knew RAX was involved, hadn't heard about planned deployment 20:35:02 and ceilo .. 20:35:15 mikal, but did that come before it was accepted into incubation? (no) 20:35:21 can we change the language to *should* - and then make it part of the judgement? 20:35:21 mikal, before graduation? 20:35:25 RAX have a beta deploy 20:35:28 you can ask for access 20:35:34 its just not GA yet 20:35:40 lifeless, coolness, thanks 20:35:55 honestly, I think the raised bar on QA requirements will mean anything that gets near this bar, is going to be in a much better place for people to deploy 20:36:06 so the question is 20:36:10 to me anyhow :) 20:36:11 sdague: similar for docs 20:36:17 sdague: and that's something *much* easier for us to measure 20:36:24 sdague: since it's under our control, where as deployments are not 20:36:26 is incubation the path to integration, or the path to broad acceptance 20:36:26 russellb: right, exactly. 20:36:34 I think it clearly should be the former, not the latter. 20:36:44 But 20:36:49 I think there will be some of the latter occuring 20:36:51 lifeless: it is often argued by applicants that it is a pre-requisite for the latter 20:37:03 lifeless: as in "no one will use my thing until its incubated" 20:37:16 lifeless: so we should incubate it and then say "so, does anyone use your thing?" 20:37:23 mikal: and I accept that argument to a degree. Especially for things that we'd otherwise break willynilly. 20:37:27 lifeless: cause if we're working on things people don't want, we should kill those things 20:37:27 mikal: like hypervisor drivers. 20:37:45 thats very frustrating to some projects, they want to get some users before incubation, to get feedback and devs 20:37:45 drivers are a separate thing from projects ... 20:37:52 mikal: I agree with killing unwanted projects. 20:37:58 but then are told "we wont run you until your incubated" 20:37:59 russellb: it was an allegory :) 20:38:14 mikal: how about you use the ML thread to come up with a vibrant call to take actual usage in account when considering graduation ? I'm pretty sure that won't be the only suggestion we'll receive out there. 20:38:17 Designate was in and somewhat still is in that trap 20:38:29 MarkAtwood: sure, so incubation is the time to prove your market. Not integration. 20:38:38 I thought designate was in the trap of single vendor 20:38:39 MarkAtwood: designate's problem was nobody else working on it 20:38:45 MarkAtwood: I don't like groups coming to us for resources, they should bring them. 20:38:54 and you sohuldn't need to be able to production deploy it to join in to build the thing 20:38:56 ttx: sure, is there an existing thread for these proposals? 20:39:03 ttx: or are you about to send one? 20:39:11 mikal: I plan to start one based on the curret etherpads. Probably tomorrow 20:39:16 current* 20:39:21 ttx: sure, I will reply when it goes out 20:39:25 annegentle: I don't think that's teh designate issue 20:39:36 russellb, i personally got told by several large private cloud operators that the wouldnt start using or contributing to designate until other people did... it was... frustrating 20:39:38 designate wants to apply again btw, i encouraged them to wait until we have these docs finished 20:39:42 I think that's something that will benefit from carefully-worded argument, rather than IRC discussion 20:39:43 ttx, take a look over https://etherpad.openstack.org/p/incubation-and-integration-requirements as you're doing that 20:39:44 mordred: yeah that oversimplifies it 20:39:46 annegentle: the designate issue is that the other companies kept waiting for us to 'bless' designate before starting projects to throw out their current dns aas 20:39:53 ttx, I tried to dig up past threads, docs, etc. and summarize 20:39:54 MarkAtwood: then that's their broken approach, not ours 20:39:56 Look, I'm no trying to be a dick here... I just feel very strongly we should have users for our projects, especially before we devalue our brand by associating things people don't want with it. 20:40:02 with several of them having declared they would, but none of them having done it yet 20:40:06 ttx, not sure if we've gotten everything in your etherpads yet 20:40:18 mikal: ack, I get that too 20:40:24 markmc: ncie 20:40:27 nice even 20:40:36 russellb 20:40:37 just as an extra data point, by the time heat and ceilometer were fully integrated, we had dozens of catalogued deployments for each from the user committees data 20:40:48 40+ for heat and 70+ for ceilometer 20:40:51 markmc: i can wait until you turned that into the etherpad before starting up -dev discussion 20:40:52 jbryce: nice! 20:40:57 mordred: then they're probably putting their interests first and not OpenStack's? That's at the heart of my line of questioning. 20:41:02 russellb: agreee that its there broken process not openstacks, but just be aware its a very common breakage 20:41:12 jbryce: it's possible that those are numbers we might want to be able to see when doing graduation review 20:41:13 MarkAtwood: common, as in 1 case? 20:41:17 jbryce: I did not know that 20:41:22 ttx, nah, don't wait for me - I posted that etherpad here and on the list a couple of weeks ago 20:41:29 annegentle: perhaps, but the problem is that 'they' in your sentence and 'they' in designates devs are different groups 20:41:37 common as i see it many places, not just openstack world 20:41:50 mordred: yeah...we can share the aggregate at any time whenever you're having those reviews 20:41:55 jbryce, was that at the end of the Havana cycle, or the start? 20:41:55 people waiting for the crowd to move so they dont have to be in front 20:41:56 annegentle: of course they are - we're tyring to teach them - sometimes we have to leverage them into contributing to openstack 20:42:00 and sometimes they are companies who are already part of openstack but have alternate things that predate openstack 20:42:09 jbryce, Heat graduated at the start 20:42:11 so they're caught in chicken-and-egg problems 20:42:22 Also we still haven't seen much of a "food fight" in terms of competing solutions, does that scenario change any of our criteria? 20:42:24 markmc: everyone graduates before the start, actually 20:42:41 mordred: yep, agreed 20:42:44 annegentle: good point 20:42:45 ttx, right - just trying to get to whether that survey came before or after graduation 20:42:49 i.e. it's been 8 months that everyone knew it would be in Icehouse 20:42:54 annegentle: probably the incubation criteria 20:43:00 ttx, i.e. did graduation trigger deployments, or did we have deployments before 20:43:12 markmc: I'm pretty sure adoption ramped up after graduation, before integration :) 20:43:13 we also have 7 trove and 8 ironic users catalogued currently 20:43:14 markmc: yah. interesting question 20:43:16 this suggests another concern 20:43:19 if we push back too hard 20:43:25 do we make projects create their own brand 20:43:28 jbryce: dude. you have 8 ironic users catalogued? 20:43:28 in order to get users 20:43:30 markmc: those were numbers shortly pre-havana release 20:43:36 mordred, heh :) 20:43:43 so they they are less likely to really integrate? 20:43:47 ok, let's push this to the ML thread that will start soon, or for open discussion at the end of meeting if there is time there 20:43:51 jbryce: that's both awesome and terrifying 20:43:55 ttx: ++ 20:43:55 annegentle: something like ... in the case that there are competing implementations, there is consensus that this implementation is the way forward for OpenStack ... or something 20:44:00 ttx: +1 20:44:03 I have a few quick other things to cover 20:44:10 #topic Other governance changes in progress 20:44:13 russellb: or can we handle two at once? 20:44:18 jbryce, ironic doesn't (or didn't at the time of the survey) work at all, really :) 20:44:18 Mission statement for Compute program: https://review.openstack.org/57981 20:44:25 I'll approve this one once it gets YES from the majority of voters 20:44:30 * russellb just trying to catch up on program paperwork 20:44:33 I think a version with "including but not limited to" would be ok for everyone 20:44:33 annegentle, russellb there's also, comapnies that don't want to ditch their private thing, but _will_ once there is an official openstack thing 20:44:47 Make election times less ambiguous: https://review.openstack.org/#/c/57396/ 20:44:47 cough, HP, cough. 20:44:55 I'll approve this one now as a factual/cleanup one, unless someone objects 20:45:00 i +1d because i never think 'including' means 'including AND limited to'. 20:45:09 markmc: the survey's always open. the ironic and trove numbers are current not pre-havana 20:45:13 but either wfm 20:45:13 jeblair: same here, but then I'm French 20:45:21 jbryce, ah 20:45:27 * russellb is fine either way too ... but generally prefers more well defined scope over open ended 20:46:15 jbryce: I'm assuming that you meant "8 catalogued nova-baremetal deployments" ? 20:46:18 #topic Open discussion 20:46:20 jbryce: yeh, it would be nice to time bucket it so we could see evolution over time 20:46:29 i had one last thing: 20:46:34 lifeless suggested we should rule on the critical state for non-deterministic bugs 20:46:43 I replied on the TC list saying it's probably better handled a ML / wiki level unless there is a fight about it 20:46:52 do you generally agree to keep it on ML/wiki rather than imposed by TC at this point ? 20:46:53 so I'm torn 20:46:54 anyone fighting it? 20:47:01 on the one hand yes - light weight TC is better 20:47:03 sdague: we can, just the easiest view for me is a real-time report 20:47:16 yah. dolphm didn't like the use of critical 20:47:16 on the other hand, this seems to be a bit of a bikeshedding thing already 20:47:22 russellb: not sure how I feel on it yet TBH 20:47:22 ttx, lifeless: maybe we can bring it up at the project meeting next, and if there is disagreement, come back to tc? 20:47:26 the main reason I flagged it now on the tc list 20:47:29 is the week lead time 20:47:34 jeblair: yes, probably a good bet 20:47:42 if consensus happens by next week, then take it off the agenda. 20:47:44 russellb: if the triage is accurate fine, but still wayyy too many incorrectly diagnosed 20:47:53 there is no project meeting now is there? I thought it was canceleld 20:47:54 yeh, I like it being brought to the project meeting first 20:47:57 and while I agree with lifeless on the intent, I think dolphm also has a good point about that - perhaps that's a UI feature we can fix in storyboard... 20:48:05 lifeless: cacelled ? NEVER 20:48:33 mordred: folk will never agree on the definition of critical I fear. 20:48:33 jgriffith: er, i think the qa team has a really good track record on triaging gate-blocking bugs 20:48:44 mordred: yeh, maybe. fwiw, on projects that I have bug access I push all the race bugs to critical when I triage them 20:48:46 jgriffith: to be clear, we're not at all suggesting any random person be able to do it. 20:48:47 mordred: better to get out of the game entirely and just say 'this is the order we care about' 20:48:53 I don't really mind which way it's tracked. I just want to make sure however we track it, people react to it 20:48:56 jeblair: fair 20:49:11 "Critical" is a way to make it appear on my radar, which makes sure I pester people about it 20:49:24 The suggestion is two part: a) QA should have triage rights everywhere. b) gate affecting bugs should be top of the queue of work. 20:49:29 * jgriffith is fine then... he can always change it :) 20:49:38 I agree with a and b 20:49:41 The bikeshed seems to be about how b is represented. 20:49:48 yep 20:49:52 details about shed color bleh 20:49:55 I am going to let it stew for a day or so before replying to whatever is said 20:50:07 since I've been around this many many times before 20:50:09 :) 20:50:15 honestly, there are non QA core folks that should have this right too, as they do lots of awesome here, like clarkb and jog0 20:50:23 let's mention it at the project meeting after this one 20:50:24 and also, not all "gate affecting" bugs are created equal ... 20:50:33 perhaps have an 'uber-triage' group that people can be in ? 20:50:34 it failed a few times may really not be the most valuable thing to work on today 20:50:41 so if we are defining a subset, vs. open tracker, we might want to define a new group of folks that are responsible enough to have this priv 20:50:43 I'm just concerned about proliferation of TC edicts where none is actually necessary 20:50:45 lifeless, I think it's more about building a culture of jumping on these issues 20:50:50 sdague: jinx 20:50:53 markmc: +1 20:50:54 lifeless, setting bugs to critical isn't going to help it much 20:50:57 "gate-keepers" :) 20:51:00 which i think is already getting better 20:51:01 most teams are open 20:51:06 lifeless, what jog0 did this week is much more effective 20:51:15 ttx: I'm not sure we need an edict here - I think a lot of times even just the tc talking about it can be useful for coordination 20:51:22 markmc: I agree 20:51:23 yes, I think that task could benefit from some branding 20:51:26 when all bugs are critical, what does critical mean 20:51:28 we need a jog0 for every project that is looking after stuff and making lots of noise when necessary 20:51:29 just sayin 20:51:31 and I think we are moving the culture, which is great 20:51:32 markmc: I agree to an extent. Part of changing culture is making the desired thing super easy. 20:51:48 markmc: 'bug is critical' is very easy for any contributor to see without needing a special search. 20:51:50 russellb: we should put out a tc edict that every project provide infra/qa with a jog0 20:51:55 russellb: :) 20:51:57 +1 20:52:00 markmc: 'bug is high but tagged and you should search for those first' -> nowhere near as easy 20:52:01 a gate czar! 20:52:01 nice :) 20:52:03 like the VMT is pursuing people to get things patched, the GateCrashSquad is after non-deterministic bugs and chase people down to make them care 20:52:03 although I do agree anything holding up gates is critical 20:52:23 lifeless: interesting to note that the VMT doesn't need to set bugs to critical to get them prioritized 20:52:37 although security bugs are arguably all critical too 20:52:44 honestly - even just a "gate affecting" tag would allow people find gate affecting bugs 20:52:50 mordred: +1 20:52:54 mordred: but not raise visibility 20:52:56 that would be the best solution IMO 20:52:58 because that's the main thing - 'how do I find a list of BLAH" 20:52:59 VMT? 20:53:05 mordred: no, i don't think that's the main thing 20:53:08 lifeless: vulnerability management team 20:53:10 mordred: it's not quite the main thing 20:53:11 ventro medial.. 20:53:12 mordred: yes, but I think you actually need to have a team chsaing people to make them all care, critical/tagged or not 20:53:27 so the VMT is a specific team, and they have one search they do right ? 20:53:27 mordred: i think the main thing is that there is a group of people who are good at identifying bugs that are stopping development work on the project 20:53:27 isnt' that what the PTL's should be doing? 20:53:35 mordred: we need to make sure their work is visible 20:53:37 lifeless: vulnerability management team 20:53:40 if we're going to build a dedicated gate tackling team, then having a tag is sufficient 20:53:50 jeblair: how is that different from what I said? 20:53:54 It's not clear to me that that is what we were going to do 20:54:15 mordred: tagging a bug does not make it visible, except to people looking for it, and there are not very many people looking for it 20:54:18 lifeless: I think we already have the team, it just needs branding and to build awareness 20:54:24 ttx: who is the team? 20:54:31 ttx: I don't think we have a team 20:54:45 making these issues more visible - why not improve on http://status.openstack.org/rechecks/ ? 20:54:45 I also don't think we have the team 20:54:46 ttx: we do? Cool... links or it doesn't exist :P 20:54:52 i think we need these bugs marked as critical, and active participation from project ptls, specifically because we don't have that team. 20:54:56 we have a few people that dropped the things they should have been doing to tackle it this time 20:55:01 jeblair: those people who worked on the recent gate break report look pretty well-organized to me 20:55:15 ttx: most of those people need to go back onto other stuff 20:55:16 ttx: no, sdague is right, they have other jobs 20:55:30 markmc: again, if there is a group of folk tracking that specifically, its fine. But if we want to harvest the broad set of 'find a bug and work on it' - that fails to surface the information to the folk that I want to harvest 20:55:37 * russellb views it as a function of the QA team, honestly ... to at least organize around the current issues 20:55:45 and then yell at the right people to get their attention as necessary 20:55:47 jeblair: ok, fair enough. I'mjust unsure that will work. Whatever the way you mark those bugs 20:56:00 ttx: so I think from a triage perspective, to flag something as critical, we might be able to cover it 20:56:11 but to drive those fixes, that needs to come back from the project teams 20:56:13 jeblair: in my experience, marking bugs critical is no substitute for chasing people down. tha's what I do all the time 20:56:24 which is why flagging as critical is an important signaling mechanism 20:56:50 flagging things as critical lets you piggyback on ME to raise awareness in PTLs 20:56:54 and making it culturally acceptable for people outside of a project team to do that for gate bugs is really the thing I'd like to make sure we're cool with 20:57:06 ttx: that's why my suggestion is specifically that when the qa team marking something as critical, the project/ptl/dev-community should be notified, and we should expect someone to be assigned to it. 20:57:11 what rate of occurrence would a bug need for it to jump to Critical ? 20:57:11 ttx: do you have a problem with that ? :) 20:57:47 markmc: i'd like to know that too 20:57:49 lifeless: only works until I get bored about it 20:57:54 because not every failure is automatically a top priority IMO 20:57:58 it's just not that simple 20:57:59 markmc: honestly, any race in the gate I think is critical. It's non deterministic behavior that's able to be created in a relatively low concurent environment 20:58:16 what about the 800 other bugs already reported, that are more clearly defined than the gate failure bug? 20:58:24 interesting as we'll have that discussion in the next meeting ! 20:58:26 sdague, we're saying it's critical because it's holding up development - there are degrees of "blocking development" 20:58:27 they're both things we know that are broken 20:58:31 T-2 20:58:41 was there anything else somebody wanted to mention before we jump into the next meeting ? 20:59:02 markmc: it's not critical because it's holding up development, it's critical because it's a race in openstack 20:59:03 sdague, "once every 10 years" is not Critical, "happens 50% of the time" is Critical ... so there's a boundary 20:59:22 sdague, it could be a race in unit tests, doesn't affect deployments 20:59:45 markmc: fair, though we've not flagged any of those 20:59:52 would like it defined 20:59:54 only devstack-gate 21:00:08 because if i get a bunch of critical bugs for something that failed twice and nobody knows why, i'm just going to get seriously annoyed 21:00:10 ... 21:00:12 well >50% of the time in unit tests *is* Critical 21:00:13 well, it will be at least a month before we've got enough stats to give yuo hard numbers 21:00:22 ok, we'll continue this ons in 40 min 21:00:27 #endmeeting