20:02:17 <ttx> #startmeeting tc
20:02:18 <openstack> Meeting started Tue Jul 16 20:02:17 2013 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:22 <openstack> The meeting name has been set to 'tc'
20:02:25 <mordred> russellb: do you have to cut your hands off first to do that?
20:02:29 <ttx> wkelly: proxies for mikal
20:02:35 <ttx> Agenda for today is at:
20:02:39 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:54 <ttx> #topic New program application: TripleO
20:02:59 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-July/011605.html
20:03:07 <ttx> I'd like to separate the discussion in two steps:
20:03:16 <ttx> (1) Scope, mission statement, how "essential" the effort is to OpenStack
20:03:24 <ttx> (2) Team/effort/community maturity
20:03:31 <ttx> let's discuss the program scope first.
20:03:48 <ttx> Personally I think facilitating deployment at scale (and reusing OpenStack while doing so) is an essential effort
20:03:56 <ttx> And I think the current program mission statement captures that well.
20:04:00 <russellb> +1
20:04:13 <markmc> definitely
20:04:30 <mordred> " by being simple to implement" is from the OpenStack mission statement :)
20:04:38 <markmc> this fills a big gap in the project
20:05:01 <ttx> ok, that part sounds like a no-brainer then
20:05:14 <ttx> next step, team/effort/community maturity
20:05:16 <mordred> nod. it's also something we'll need to be able to do larger multi-node gating and stuff
20:05:30 <ttx> I'm not totally convinced (yet) that this effort has reached enough maturity to be accepted as a program today
20:05:42 <ttx> that said it might just be due to my ignorance of the current status and usability of the TripleO stuff...
20:05:57 <ttx> What I've seen so far are clear goal definitions and a team formed mostly around Robert's team within HP
20:06:06 <hub_cap> we use it right _now_ to deploy our instances in testing
20:06:09 <mordred> well, we're actually running a rack-sized tripleo install currently
20:06:18 <hub_cap> i find its quite mature in that process
20:06:22 <ttx> And I'd like to set /some/ maturity bar (for the team, for the community that formed around it, for the deliverables it produces) before we turn teams and efforts into programs
20:06:22 <mordred> and elements of it are being used currently by other projects
20:06:34 <ttx> basically I don't want every informal team we have to think that the only way they can "exist" is by being an official program.
20:06:37 <stevebaker> there has been some valuable collaboration with the heat project
20:06:38 <hub_cap> ill be using it for heat integration too fwiw
20:07:19 <mordred> so, there's two sets of outputs the tripleo team is working on - tripleo specific code projects, and patches to other openstack projects
20:07:30 <markmc> I see the community as being pretty mature at this point - good core group of folks, some more folks looking like they're on the path to core, a nice "long tail" of contributors
20:07:31 <mordred> the patches are not something that really need any sort of anything from us
20:08:02 <jd__> o/
20:08:02 <mordred> the code projects are things that are picking up usage in places other than just tripleo-specific things
20:08:28 <devananda> there's also considerable overlap with the ironic folks
20:08:33 <ttx> mordred: you know their progress better than I do, do you think "usable by havana" (as promised by lifeless) is likely ?
20:08:40 <mordred> ttx: 100%
20:08:48 <devananda> as, right now, the two practical uses of baremetal/ironic are: private trusted deployments, or tripleo
20:08:48 <mordred> ttx: it's actually usuable today
20:08:53 <stevebaker> we're considering adopting os-*-config code projects for heat's in-instance tools
20:08:53 <mordred> there's just more steps you have to follow
20:09:11 <mordred> stevebaker: cool! I hadn't caught that yet
20:09:18 <devananda> stevebaker: awesome!
20:10:01 <mordred> ttx: and when I say usable today, I mean being used in a customer facing deployment :)
20:10:19 <ttx> annegentle_: you raised doc concerns on the original thread, I think that factors into maturity as well... Did you get the answers you wanted ?
20:10:20 <mordred> ttx: pleia2 has also been working on starting to get it integrated with CI
20:10:41 <ttx> mordred: ok, sounds more than enough for my "maturity" bar
20:10:53 <annegentle_> ttx: so I am still concerned about doc efforts -- contained in their team, great, but how do they get the word out to openstack consumers?
20:11:14 <ttx> anyone else has concerns they'd like to voice about tripleO's application ?
20:11:24 <annegentle_> ttx: it's my own concern about how much can docs take on, while doing release docs, what is the Docs program responsible for? All the programs?
20:11:34 <ttx> annegentle_: I found them pretty active at various conferences fwiw
20:11:39 <markwash> I'm a tiny bit concerned that there is a slight conflict in the dual mandate for tripleo
20:11:56 <markwash> mandate #1: make production deployment much better
20:11:58 <ttx> annegentle_: that's a good question. Did you write up your mission statement ? :)
20:12:03 <devananda> markwash: can you clarify?
20:12:06 <jd__> has the potential overlap with ironic been covered/answered?
20:12:07 <markwash> mandate #2: use openstack wherever possible
20:12:14 <annegentle_> ttx: working on, but getting stuck on "all the things"
20:12:15 <mordred> annegentle_: I'll put "getting some doc people" on the todo list
20:12:30 <markmc> jd__, ironic would be its own program
20:12:45 <devananda> jd__: tripleo expressly uses ironic (baremetal). it doesn't overlap any more than it overlaps any other openstack program (heat, nova, glance, ...)
20:12:46 <markmc> jd__, has use cases other than tripleo
20:12:50 <ttx> annegentle_: markmc, jd__: it already is its own program.
20:12:56 <annegentle_> I think their expected deliverables should include docs.
20:13:14 <devananda> i agree that tripleo deliverable should include docs :)
20:13:16 <ttx> annegentle_: interesting point.
20:13:29 <mordred> markwash: #2 is in part a framing for the how of #1 shuld get accomplished. lifeless actually didn't want to call it out explicitly because he thought it went without saying
20:13:32 <devananda> but perhaps i mean someting else by that?
20:13:45 <lifeless> hi
20:13:51 <lifeless> oh, I thought this was an hour later. doh.
20:13:57 <ttx> lifeless: welcome. Talking about you.
20:13:58 * mordred pokes lifeless in the face
20:14:10 <annegentle_> I guess I would like to understand more about who consumes tripleo now, and who will in the future?
20:14:14 * markmcclain joins late
20:14:15 <jd__> devananda: ah "triple epxressly uses ironic" was the answer I wanted, thanks :)
20:14:36 <lifeless> jd__: well it doesn't yet, but it will as ironic matures. It expressly uses nova-bm today.
20:14:44 <jd__> lifeless: fair enough
20:14:47 <markwash> mordred: is it ever possible that openstack is not the best tool for deploying openstack? could there be a fundamental conflict between the assumptions made by deployers vs by customers?
20:14:48 <ttx> lifeless: how about adding docs to your 'expected deliverables' list ?
20:15:10 <annegentle_> lifeless: are you Clint who answered my question?
20:15:14 <lifeless> ttx: I can, but can you think of a program that shouldn't document things?
20:15:19 <ttx> annegentle_: he is Robert Collins.
20:15:20 <lifeless> annegentle_: I am Robert Collins
20:15:20 <mordred> markwash: I absolutely think that other people should 100% be able to do openstack deployments withouth using openstack to do so
20:15:25 <annegentle_> ah ok
20:15:32 <ttx> Clint is SpamapS.
20:15:35 <mordred> markwash: and I certainly don't want this effort to make that effort not possible
20:15:37 <annegentle_> thanks
20:15:51 <markwash> mordred: I guess my issue is, technically, I think "Openstack on Ironic" is a great architecture, but "Openstack on Openstack" maybe isn't so great
20:16:00 <devananda> annegentle_: i would say the consumer of tripleo are those who want to deploy an openstack cloud. not the end users of said cloud.
20:16:06 <lifeless> annegentle_: so right now we have a product in HP that /wants/ to consume it [and should have an edition by the end of the year]. RedHat are developing something built on it. RackSpace want to consume it.
20:16:16 <mordred> markwash: well, it's not just ironic - heat is a major part of the puzzle too
20:16:22 <devananda> markwash: except that, to deploy openstack requires /all/ the bits (image, network, orchestration, etc) -- not just baremetal/ironic
20:16:23 <lifeless> markwash: as mordred says
20:16:24 <mordred> markwash: and then it turns out glance and quantum are essential
20:16:31 <devananda> :)
20:16:35 <annegentle_> so would heat and ironic go in this program? Is there a nesting question?
20:16:42 <mordred> markwash: and we have roadmaps around places where cinder is going to be needed
20:16:44 <lifeless> markwash: consider what a deployment needs: hardware, networking, service orchestration.
20:16:47 * markwash just got incepted
20:16:55 <mordred> markwash: haha
20:17:01 <lifeless> markwash: these are all things that OpenStack is actively developing management APIs for
20:17:04 <markmc> annegentle_, separate programs - tripleo depends on heat, ironic, nova, ceilometer, ...
20:17:08 <ttx> annegentle_: no. Heat and Ironic would be consumed by TripleO, like Nova.
20:17:14 <mordred> annegentle_: I don't think so - I think heat and ironic both have lifecycles quite happily outside of deploying openstack
20:17:23 <lifeless> markwash: why would an org want to have expertise on using those APIs and then not leverage that for deploying them, since they solve the same problems
20:17:57 <markwash> lifeless: I might be out of scope here, but what I'm trying to say is that they're kinda different problems
20:18:11 <markwash> as a deployer, I pay for it, and I want a lot of placement control
20:18:25 <markwash> as a customer, I don't expect to have placement control, and the folks on the otherside don't want to let me have it
20:18:45 <notmyname> makes sense that tripleo, heat, and ironic all have different scopes (otherwise why have them), but should they be different deliverables part of the same program?
20:18:53 <lifeless> markwash: so thats interesting. We have consumers of clouds [being super generic because it turns up in many places] that care about placement intensely.
20:19:09 <lifeless> markwash: specifically anti-affinity for HA, and proximity-affinity for performance.
20:19:14 <ttx> notmyname: their teams are slightly disjoint, so probably not ?
20:19:31 <markwash> lifeless: that makes sense
20:19:32 <lifeless> notmyname: they are quite different problem domains
20:19:38 * devananda deletes his post so as not to be redundant with what lifeless just said
20:20:06 <ttx> notmyname: if it's the same team working on it, your question would be relevant though.
20:20:08 <mordred> lifeless: dont' forget legal-domain affinity
20:20:16 <lifeless> mordred: godgodgodgodgodno
20:20:20 <markwash> its probably just my preference to "just assign the placement" manually if I'm the deployer, rather than translating my basic layout into a complex affinity dsl, that the system just tries to translate back to my layout
20:20:42 <lifeless> markwash: so, ignore deployments for a second
20:20:51 <notmyname> ttx: well, I'd argue that relevance has to do with scope, not persons :-) but I've got my answer from ... everyone
20:20:55 <lifeless> markwash: just look at bare metal workloads. Hadoop, DB clusters etc.
20:21:09 <lifeless> markwash: I think you can see that the folk doing those workloads will have the same care that you do about placement.
20:21:21 <lifeless> markwash: so we (nova/ironic) need to solve the same problems.
20:21:23 <ttx> notmyname: it's both. Scope and the team working on it.
20:21:43 <lifeless> markwash: adding deployment into it doesn't (AFAICT) add any scope to their needs
20:21:46 <ttx> because in the end what you want is an efficient team working well together to achieve a common goal
20:21:51 <markwash> lifeless: I think I'd just be a tiny bit happier if we pulled the "using openstack wherever possible" from the mission, in favor of that being implicit / changeable if the facts on the ground change
20:21:59 <devananda> markwash: also, heat/nova/ironic won't prevent you from assigning the placement manually. just uses a different language for expressing it than, say, your standard CM
20:22:22 <ttx> markwash: actually I like that opiniated part in the statement.
20:22:22 <lifeless> markwash: I have no objection to doing that, because there is such strong community focus around openstack components collaborating.
20:22:44 <lifeless> markwash: mordred felt it was an important thing to highlight how tripleo is different to e.g. crowbar
20:23:37 <ttx> "openstack on openstack" is really what this team has been working on. Stripping it from the mission statement sounds weird.
20:24:04 <devananda> markwash: if we pull "using openstack wherever possible", the statement becomes far too generic and could refer to existing (politically charged) tools. like crowbar. or commercial tools...
20:24:08 <ttx> I prefer that they come back to TC to change that mission statement if the facts on the ground end up chaging.
20:24:19 <ttx> changing*
20:24:36 <markmc> sounds sensible to me
20:24:37 <markwash> ttx: that makes sense too
20:24:42 <lifeless> +1
20:24:44 <markmc> "tripleo without the o"
20:24:46 <ttx> (rather than use a weak statement that doesn't describe what they do)
20:25:02 <markwash> how about make the opinion stronger in the statement then?
20:25:11 <ttx> ok, ready to vote when everyone else is
20:25:17 <ttx> markwash: how so ?
20:25:28 <markwash> nevermind
20:25:35 * markmc ready
20:26:07 <ttx> just yell now if you need more discussion/answers before the vote
20:26:14 * stevebaker proxies for shardy
20:26:41 <ttx> stevebaker: ack
20:26:45 <ttx> #startvote Accept TripleO as an official OpenStack program? yes, no, abstain
20:26:46 <openstack> Begin voting on: Accept TripleO as an official OpenStack program? Valid vote options are yes, no, abstain.
20:26:47 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:26:53 <russellb> #vote yes
20:26:57 <markmc> #vote yes
20:26:58 <wkelly> #vote yes
20:27:01 <dolphm> #vote yes
20:27:04 <mordred> #vote yes
20:27:06 <stevebaker> #vote yes
20:27:06 <ttx> #vote yes
20:27:07 <markmcclain> #vote yes
20:27:08 <jd__> #vote yes
20:27:25 <jgriffith> #vote yest
20:27:26 <openstack> jgriffith: yest is not a valid option. Valid options are yes, no, abstain.
20:27:29 <jgriffith> #vote yes
20:27:31 <ttx> 30 more seconds...
20:27:32 <markwash> #vote yeast
20:27:33 <openstack> markwash: yeast is not a valid option. Valid options are yes, no, abstain.
20:27:35 <annegentle_> #vote yes
20:27:46 <jgriffith> markwash: ha!!  even better than mine!
20:27:50 <mordred> I think yeast should be a valid option
20:27:53 <markwash> #vote abstain
20:28:00 <notmyname> #vote abstain
20:28:05 <lifeless> markwash: long as it's been fermented
20:28:08 <lifeless> bah
20:28:09 <lifeless> mordred: ^
20:28:18 <ttx> #endvote
20:28:19 <openstack> Voted on "Accept TripleO as an official OpenStack program?" Results are
20:28:20 <openstack> yes (11): markmc, stevebaker, ttx, jd__, russellb, jgriffith, mordred, wkelly, annegentle_, dolphm, markmcclain
20:28:21 <openstack> abstain (2): notmyname, markwash
20:28:42 <ttx> cool.
20:28:46 <ttx> #topic Open discussion
20:29:03 <lifeless> should there be some minimum things all programs do
20:29:05 <lifeless> e.g. deliver docs.
20:29:06 <ttx> I'd like to raise two topics in this section, and more if you have some too
20:29:20 <ttx> first, a preliminary discussion on devstack application as a program
20:29:21 <annegentle_> lifeless: depends on the audience.
20:29:30 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-July/011896.html
20:29:34 <annegentle_> lifeless: if you expect deployers to stand up Tripleo then yes
20:29:43 <ttx> The fact that devstack should be "official" and under the oversight of the TC is pretty much a no-brainer
20:29:49 <lifeless> annegentle_: I can't think of a program that doesn't need docs so far
20:29:51 <annegentle_> lifeless: but. I don't think the Documentation Program can take on the docs for all. the. programs.
20:29:57 <ttx> since it was "official" (as a "gating" project) under the old projects taxonomy
20:30:02 <annegentle_> lifeless: right so far we have audiences for everything
20:30:07 <jgriffith> ttx: +1
20:30:10 <mordred> ttx: +1
20:30:13 <markwash> +1
20:30:17 <ttx> The question raised on the ML is... does it need its own program or should it be considered part of QA and/or Infrastructure
20:30:28 <annegentle_> ttx: right, for devstack it's a nesting question also
20:30:31 <ttx> On one hand I think the scope is pretty narrow and definitely overlaps with both QA and Infra goals
20:30:32 <lifeless> project or program
20:30:47 <ttx> On the other, a program is organized around a single team, and devstack's team is pretty separate from the general QA or Infra teams
20:30:59 <ttx> So if neither team wants it, and the devstack crew doesn't feel like they belong there, maybe a separate program is what makes the most sense
20:31:03 <mordred> I also think that devstack is focused on dev envs
20:31:08 <markmc> right, for me - they're very separate teams and only accidentally overlapping scope
20:31:09 <mordred> as someone said, it's not 'teststack'
20:31:13 <mordred> even if we're using it that way right now
20:31:31 <russellb> we say that, but it is teststack...
20:31:37 <markmc> there could be a time when our deployment for gate testing isn't devstack
20:31:40 <jgriffith> Like I mentioned I think the interests/goals of devstack are broader than just Q/A infra etc, thus my thought for it being independent
20:31:45 <vishy> o/
20:31:46 <markmc> but devstack would still be essential to developers
20:31:51 <russellb> but if the teams are separate, and QA and Infra are saying "it's not ours", then no need to push it there
20:31:52 <mordred> markmc: ++
20:32:08 <jgriffith> russellb: a lot of folks do *all* of their development in a devstack env
20:32:15 <mordred> I think infra and qa like to be involved with it - but to be fair I like to be involved in many things...
20:32:16 <russellb> sure.
20:32:22 <jgriffith> russellb: thus more than "test-stack"
20:32:25 <jgriffith> IMO
20:32:29 <russellb> i'm not saying it's not more
20:32:41 <jgriffith> russellb: ok, point taken
20:32:42 <ttx> yeah, I had this view that it didn't "warrant a program" but if you think of the people involved and the history of devstack, it actually makes sense as a separate program imho
20:32:45 <russellb> i'm just saying it turns out that making a super easy dev env also happens to make a super easy test env
20:32:47 <russellb> and it's clearly used for both
20:32:48 <markwash> +1 to ttx's notion on the ML about following the existing team structure / cohesion
20:33:14 <annegentle_> devstack is pretty essential for dev/test/doc but it's not the only implementation of such a tool. So it feels like a bake-off to me, a blessed tool, and should we enable more ways of solving a particular problem within a "program"...
20:33:23 <annegentle_> so I'd say, make a Dev Tool Program
20:33:24 <ttx> the overhead in having MOAR PROGRAMS is the extra election to organize for its PTL
20:33:34 <markwash> #vote dtroyer
20:33:36 <ttx> so it's an acceptable overhead
20:33:39 <annegentle_> ttx: and the track at the summit, and the docs, and... and ... and...
20:33:41 <sdague> the team things is where stuff is odd. devstack is basically still me and dean reviewing. the contributors are pretty varied.
20:33:45 <markmcclain> I thought we added programs to allow us to nest projects
20:34:17 <jgriffith> sdague: interesting point....
20:34:26 <markwash> or #vote sdague. . not trying to be divisive!
20:34:44 <jgriffith> sdague: in your view is there enough "consistent" teamp participation to be a stand-alone program?
20:34:45 <sdague> no way, I already have way to many things on my plate, #vote dtroyer :)
20:34:51 <ttx> annegentle_: well, if I were you I wouldn't sign up to document all the things :) Integrated projects might be enough.
20:35:10 <annegentle_> ttx: yea. NO. Not.
20:35:33 <sdague> jgriffith: I guess the team criteria is new to me here. I thought we were doing logical boxes
20:35:54 <sdague> which is why dtroyer_zz and I agreed grenade (which is also basically he and I) is a QA thing
20:35:59 <gabrielhurley> empty boxes are only good for hiding. ;-)
20:36:04 <ttx> So we won't be looking into devstack application today because it hasn't baked enough on the ML, but we can probably already tell them that a separate application does make sense.
20:36:27 <russellb> meh
20:36:29 <mordred> I think it's certainly an app that makes sense and a discussion worth having
20:36:30 <sdague> though the contributors on grenade are really just dtroyer_zz, me, and adalbas, which is actually more overlapping with tempest
20:36:34 <lifeless> so I'm not entirely sure the team thing makes sense
20:36:37 <lifeless> consider nova and novaclient
20:36:46 <jgriffith> sdague: more of a curiousity question than anything else...
20:36:50 <jgriffith> sdague: thanks
20:36:53 <lifeless> where I recall there being 'hey were are all the reviewers'discussions w.r.t. novaclient
20:37:02 <lifeless> maybe in principle they are all shared...
20:37:27 <ttx> The other topic I wanted to raise is whether vulnerability handling, common release management and/or stable branch management should be program(s)
20:37:45 <ttx> Personally I consider those to be pretty essential to our mission, and quite mature at this point
20:37:59 <ttx> It just feels a bit heavy-handed to request 3 new programs to cover for them
20:38:02 <markmc> "product management" ? :)
20:38:07 <mordred> I just assume that they're all ttx
20:38:09 <ttx> But they are different teams with different goals, so that might just be what makes the most sense
20:38:11 <mordred> and that ttx will take care of them
20:38:13 <annegentle_> release management
20:38:15 <lifeless> isn't there a team doing vun stuff already
20:38:19 <lifeless> more than just ttx ?
20:38:24 <mordred> yes. I'm being flippant
20:38:27 <markmc> annegentle_, some people see trunk as a "release"
20:38:32 <jgriffith> team yes, program no
20:38:33 <lifeless> markmc: +1
20:38:43 <markmc> annegentle_, and object to the term "release" ... hence my "product" vs "release"
20:38:50 <annegentle_> markmc: oic
20:38:50 <ttx> the fact that I'm heading two of those doesn't mean the rest of the teams are shared
20:39:17 <markmcclain> they are 3 different teams, but still seems like they can be under one program
20:39:42 <ttx> I don't really like that idea. How would you select the PTL if there is no single team ?
20:39:48 <mordred> yeah. it does seem like they are arms of release management
20:39:52 <mordred> oslo has multiple teams
20:40:03 <mordred> and markmc is the ptl of the whole thing
20:40:13 <ttx> mordred: hmm, good point
20:40:14 <notmyname> ttx: because if they are all in the same scope, they are all working to the same goal
20:40:45 <sdague> yeh, I think oslo is a good model for that. In reality we've got a similar thing on QA, our two git repos have overlapping core groups, but also non overlapping +2 folks
20:40:48 <ttx> mind you, I'm not trying to be the first to hold TWO PTL positions, quite the opposite :)
20:41:05 <russellb> sdague: sounds like devstack overlaps too :)
20:41:05 <markmc> ttx, e.g. you could totally direct the efforts of release management, vulnerability management, stable branch ... without necessarily being heavily active on all of them
20:41:08 * mordred thinks ttx is making a power grab... quick, someone write a new constitution
20:41:23 <markwash> ttx: ever notice how vish and waldon were never in the same room at the same time?
20:41:36 <mordred> markwash: wait, they're different people?
20:41:37 <ttx> markwash: yeah.
20:41:59 <sdague> russellb: hey, you don't want to use where I've got +2 as overlap criteria, that gets messy quickly :)
20:42:14 <mordred> markmc: in fact, It hink that all three of them are about curating the releases, just different elements of them that need curating
20:42:17 <ttx> ok, will propose ONE program, looks like a good trade-off.
20:42:26 <mordred> patches to existing releases, making releases, managing security for releases
20:42:26 <annegentle_> I think scale will press the need for one PTL but multiple teams
20:42:46 <dolphm> ttx: be sure to name it 'ttx'
20:42:52 <russellb> sdague: it sounds like 100% overlap in that case... that's different.
20:43:09 <vishy> markwash: ssshhh
20:43:10 <ttx> dolphm: good point, I wonder what name to give it now
20:43:26 <sdague> russellb: hmm....
20:43:44 <ttx> markwash: the model that vish hired to "impersonate" waldon at conferences wasn't so great. He fooled nobody.
20:44:14 <markwash> good ol' bearded man #3. . I miss him
20:44:40 <markwash> ttx: it feels like "release management" could be interpreted broadly enough to encompass the other two
20:44:56 <ttx> markwash: yes. Or "series management"
20:45:04 * vishy applies for asylum in nicaragua
20:45:24 <ttx> but everyone has been calling it release management forever now so probably it's there to stick
20:45:29 <notmyname> a generic "project management" would encompass it. the elected PTL would be the "release manager"
20:46:11 <ttx> notmyname: well, tbh it's a bit linked to our development cycles. The three activities are.
20:46:17 <lifeless> product management perhaps ?
20:46:39 <markwash> does anyone want to take up the issue of s/PTL/PL/ again, sometime?
20:46:54 <ttx> "project" or "product" is a bit wide. Cycle/series/release makes it more... tied to the series concept
20:47:02 <ttx> markwash: god no
20:47:23 * markwash yields
20:47:25 <notmyname> ttx: s/project/<whatever>/ same concept, IMO
20:47:40 <ttx> nobody knows it stands for Program tech Lead now
20:47:47 <markwash> haha
20:48:06 <notmyname> it's a 6 month thing. "program temporary lead"
20:48:13 <markwash> haha
20:48:14 <ttx> notmyname: +1
20:48:14 <dolphm> lol
20:48:28 <jgriffith> notmyname: ha!!
20:48:33 <ttx> sounds like a good openstack quiz question. WTF does PTL mean
20:48:41 <ttx> depends on when you ask
20:49:01 * jgriffith is updating his "intro to openstack" presentation
20:49:13 * ttx could use a "WTF is a PTL" T-shirt
20:49:16 <markwash> praise the lord
20:49:16 <mordred> political task lackey
20:49:23 <mordred> nope. markwash wins
20:49:24 <notmyname> mordred: ++
20:49:39 <jgriffith> +1 t-shirts!!!!
20:49:46 <dolphm> s/temporary/transient/
20:50:19 <ttx> ok, anything else on your mind ?
20:50:30 <russellb> plenty, but not that we need to discuss
20:50:30 <ttx> anyone up for chairing next week meeting, or should we skip it ?
20:50:39 <notmyname> #vote skip
20:50:42 <ttx> i'll be at OSCOn with... a few other people in this room
20:50:51 <ttx> #vote skip
20:50:57 <russellb> #vote abstain
20:51:02 <mordred> who in the room is _NOT_ going to be at OSCON
20:51:08 <russellb> o/
20:51:11 <sdague> o/
20:51:11 <annegentle_> skip
20:51:11 <stevebaker> o/
20:51:12 * markmc raises his hand
20:51:16 <jd__> o/
20:51:18 * markmcclain is a maybe
20:51:18 <jd__> +skip
20:51:21 <markmc> happy to skip next week
20:51:25 * annegentle_ not at OSCON
20:51:27 <mordred> aw. darn. I like you people
20:51:29 <dansmith> o/ (sadly)
20:51:38 <ttx> ok, +skip it is
20:51:50 <markmc> so, yeah - no TC quorum at OSCON :)
20:51:56 <markwash> portland has asked me not to return
20:52:05 <mordred> hahaha
20:52:14 <vishy> o/
20:52:24 <hub_cap> mordred: lies
20:52:29 <jgriffith> o/
20:52:32 <ttx> Please keep your program descriptions coming.
20:52:43 * hub_cap submitted Trove eariler today
20:52:52 <vishy> The waldon impersonator isn't available either
20:52:53 <annegentle_> I do want input/feedback!
20:53:02 <annegentle_> when I get my program mission done
20:53:07 <mordred> vishy: dammit
20:53:35 <ttx> hub_cap: yep, tahnks for that !
20:53:42 <ttx> thanks even
20:53:49 <annegentle_> do all projects submit as programs?
20:53:50 <hub_cap> i prefer tahnks
20:55:29 * annegentle_ is confused
20:55:54 <ttx> annegentle_: see the wiki. I heard it's a good doc source :)
20:56:19 <ttx> https://wiki.openstack.org/wiki/Programs
20:56:20 <annegentle_> ttx: bah
20:56:35 <ttx> need to update that to add tripleO now
20:56:45 <notmyname> ttx: can you remind me the difference in the -ongoing and the -next milestones?
20:57:16 <annegentle_> ttx: so every one on the bullets has to submit prog. descriptions, got it
20:57:20 <ttx> notmyname: -ongoing is for tasks that are never really finished but you still want to track
20:57:36 <ttx> like "database optimization"
20:57:44 <notmyname> ttx: therefore bugs will never get targeted at -ongoing?
20:57:56 <ttx> notmyname: probably not
20:58:17 <ttx> -next is just a way to tag stuff
20:58:20 <gabrielhurley> If somebody opened a bug for "database optimization" I would close it as too vague
20:58:30 <notmyname> sure. -next makes sense
20:58:37 <markwash> "Database is *too* optimized"
20:58:50 <ttx> notmyname: blame markwash for -ongoing
20:58:57 <ttx> ok, wrapping up
20:59:00 <notmyname> gabrielhurley: can we target "make it better"?
20:59:07 <ttx> #endmeeting