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