20:01:05 #startmeeting tc 20:01:06 Meeting started Tue Jul 2 20:01:05 2013 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:09 The meeting name has been set to 'tc' 20:01:10 o/ 20:01:10 o/ 20:01:21 Agenda for today is at: 20:01:29 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:01:40 #topic "Programs" definition and define initial set 20:01:51 thread is at: 20:01:57 #link http://lists.openstack.org/pipermail/openstack-dev/2013-June/010950.html 20:02:09 It's been a wordy and confused thread, largely my fault 20:02:16 let me summarize it 20:02:25 meh. it's a hard thing to get right without making things to nit-picky 20:02:29 My initial try at it was ripped off as a bit integratedrelease-centric 20:02:43 We have a number of ways forward that would be generally compatible with the current bylaws/charter: 20:03:00 (1) is to consider that "Programs" and "Projects" are two different types of things, with "Projects" producing at least a server/integrated IaaS piece and needing to go through incubation, while "Programs" do not 20:03:18 (2) is to consider that everything is a "Program", with the TC imposing program incubation on a case-by-case basis (those having the main goal of producing a server/integrated IaaS piece would almost always go through incubation) 20:03:37 (3) is to consider that everything is a "Program". Some programs produce an integrated/server project, and that project (not the program) would still go through incubation 20:03:56 I like 3. it seems to expres reality the best 20:04:00 Personally I like (3) because it gives us flexibility, and preserves most of the project/incubation concepts as defined in bylaws/charter while not being elitist about it 20:04:10 and expresses what we're already doing more than any of our previous things have 20:04:11 +1 20:04:27 ttx: I like non-elitist and inclusionary 20:04:39 annegentle: ++ 20:04:42 I'm fine with 3, except the idea that we'd have multiple server projects under a program 20:04:48 e.g. merging Nova and Quantum into a program 20:05:04 markmc: what's a server project again (I know it was in the ml thread but I'd like to hear more 'splanation) 20:05:07 markmc: that would make no sense, since those are different teams 20:05:15 I'm perfectly fine with a program having multiple server projects - but I think that's a fight for later if it comes up 20:05:19 annegentle, nova, glance, etc. - anything with a REST API 20:05:22 annegentle: pieces that might become "core" 20:05:26 ttx, right 20:05:36 Option three also means that a program can have more than one project, and not all are integrated by default 20:05:45 now, (1) is the most incremental option 20:05:52 mikal: yeah. like oslo or infra 20:05:57 leave server projects as they are, introduce programs for other stuff 20:06:04 markmc: solution (3) definitely leaves things open, so you should expect refinement 20:06:24 I thnk that's what I like about it - it doesn't get to legalistic and nitpicky 20:06:27 too 20:06:38 * ttx puts solution (3) text on etherpad, just a sec 20:06:55 mordred: +1 it doesn't get to legalistic and nitpicky 20:07:16 o/ 20:07:29 it also defines boundaries for programs based on the feature area rather than based on how code is organized 20:07:40 text @ https://etherpad.openstack.org/programs-draft 20:07:41 I also like 3 because the concept of "programs" as "stuff needed for us to fulfill the mission" is a self-limiting group. it doesn't grow without bounds 20:08:14 note that solution (3) means Trove and Ironic would be established as programs, since they have a project in incubation 20:08:42 * NobodyCam notes 20:08:45 What does a program get? 20:08:50 notmyname: ++ 20:08:52 just wondering "aloud" -- what if vagueness causes more confusion and a rush of applications? 20:08:55 Does that mean a long term commitment to a summit track for those programs? 20:08:59 Even if incubation fails? 20:09:20 mikal: stuff it produces//works on granks atc status and it gets to put things into the openstack/ namespace 20:09:36 like, working on a program == working on openstack, even if you aren't hacking on nova 20:09:38 I think if incubation really fails (and is not merely delayed), we would consider removing the program 20:09:48 +1 20:09:48 and yes to what ttx said 20:09:52 mikal, the TC can't really make a commitment about summit time, we don't run it 20:09:54 ttx: +1 20:09:55 Ok 20:10:01 but I think that there will be programs without incubation things 20:10:09 markmc: well, we kinda run the Design summit. 20:10:10 so, what's "our mission" ? 20:10:33 ttx, kinda, but we don't decide how many days/rooms/etc. there'll be ... without bounds anyway 20:10:37 markmc: the openstack project mission is defined and I think still valid 20:10:49 ttx, yep, just can't find it off hand 20:10:56 ttx, unless you mean the foundation's mission 20:11:00 To produce the ubiquitous OpenSource Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable. 20:11:02 https://wiki.openstack.org ? 20:11:07 cool, thanks 20:11:18 mordred: hehe... 20:11:27 mikal: we had a lot of discussion in the IncUp about what you "get" when you're integrated 20:11:32 "simple to implement" may still need work 20:11:33 mikal: that might help 20:11:39 * annegentle looks for those notes 20:11:42 mordred, indeed 20:11:43 ok 20:11:47 (FYI galstrom proxies dolphm's vote) 20:12:02 (sorry for being late) 20:12:07 galstrom: o hai dolphm 20:12:09 ;) 20:12:19 Is version 3 as described on the Etherpad acceptable for everyone ? Shall we vote ? 20:12:22 ttx: what release management does being a program qualify the program for? 20:12:36 nothing 20:12:38 ttx, are you saying we don't add any mention of programs to our charter? 20:12:44 mikal: see line 113 of https://etherpad.openstack.org/IncUp 20:12:55 annegentle: thanks 20:13:03 annegentle: release management is for integrated projects, I believe 20:13:13 markmc: hmm 20:13:13 "under the oversight of the TC" vs "not mentioned in the TC charter" ? 20:13:15 ttx: so I guess my question with this is how is it really different than what we're doing already? 20:13:21 mordred: right and if we take away "projects" what happens to release management 20:13:30 annegentle: I do not believe we are taking away projects 20:13:38 mordred: ah ok 20:14:02 jgriffith: what we're doing already is operating in a bit of vacuum. 20:14:14 jgriffith: it's not. it just captures an area where we don't have a place to do things and have been doing them by force of good will 20:14:26 ttx: mordred suppose those are very good points 20:14:33 we've been struggling to create project categories 20:14:38 to match reality 20:14:48 ttx: mordred but we seem so concerned/worried about applying definitions/buckets to anything that I don't know what we solve here really 20:14:50 if we notice no appreciable difference in our lives after this, we've done our jobs well 20:14:59 mordred: I disagree 20:15:02 it also opens up the possibility that we could better promote traction behind an incubating project by accepting the program it is living under 20:15:05 mordred: I would argue that we haven't done our jobs 20:15:19 jgriffith: not trying to add a bucket ... more trying to find a path to bless some efforts that don't have server projects associated with them 20:15:23 jgriffith: "programs" actually let us remove categories 20:15:24 well s/incubating/pre-incubating/ 20:15:44 markwash: yes. indeed 20:15:50 mordred: ttx ok 20:15:52 See "OpenStack projects" under https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee 20:16:07 mordred: ttx perhaps I'm just not seeing the bigger picture, and I agree 100% about inclusion 20:16:14 jgriffith: programs let us be goal-oriented rather than repo-oriented 20:16:29 jgriffith, the specific example here is tripleo - how does it transition from something that we all generally approve of, to something officially recognized 20:16:39 jgriffith, aside from incubating a server project 20:16:53 and without us having a conversation about every little repo it might produce 20:17:00 markmc: I guess you are right, we need to get rid of that chapter of the charter and replace it with a description of programs 20:17:11 markmc: sighh... Yeah, I get that point (sort of) 20:17:21 sort of like how infra generates new repos weekly, but doesn't need to come to the TC each time 20:17:24 ttx, I'm fine with us doing that later, just that it does need to happen 20:17:29 seems to be a halfway step to the "categories" model that we were just discussing a few weeks ago (which is another reason I like it) 20:17:39 notmyname: ++ 20:17:41 I guess the issue is I still have the unpopular notion of core versus other etc 20:17:43 how does #3 affect incubation again? 20:17:57 markwash: incubation for projects is still as before 20:18:06 personally it's hard enough to "explain" OpenStack as it is, let alone with everything but the kitchen sink thrown in 20:18:15 if a server project wants to become part of the integrated release, it needs to come to the TC and apply for incubation 20:18:16 markwash, server projects go through incubation still 20:18:33 markwash: teams that work on project X would apply to become a program and we'd answer "yes, and X goes through incubation" 20:18:46 so it's basically the same 20:19:05 I guess I'm a bit hazy about what a "server project" is. . I understand the current example, but "having a rest api" seems a bit too specific 20:19:06 or "yes and X should be part of an existing program"? 20:19:09 ttx: mordred markmc but I do see your points 20:19:11 so how does this affect, if at all, us projects in incubation? 20:19:17 markmc: seems to make sense that the programs would be incubated and then they can produce the code and repos necessary for them to fulfill their own mission 20:19:47 I'm not sure we have to resolve the incubation problem right now though 20:19:48 notmyname, I think ttx's definition is that programs get accepted, then any server projects they produce go through incubation 20:19:49 hub_cap: your effort becomes a "program" which produces trove and python-troveclient 20:19:56 hub_cap: it's very simple. everything doesn't change, except where it does 20:20:01 lol 20:20:03 hah notmyname 20:20:12 notmyname: haha 20:20:26 ttx: makes sense. and then we can remove trove-integration from the openstack github, eh? 20:20:39 let me have a try at a charter wording change 20:21:31 hub_cap: you can remove that when your integration tests are part of the normal set of them 20:21:31 this would be much more fun if we were in a room together 20:21:37 ttx drafting the charter changes 20:21:40 mordred: shhhh 20:21:43 while we all sit there and .... stare 20:21:46 no pressure ttx 20:21:52 markmc: we should totally have weekly onsite meetings 20:21:59 markmc: why are client libraries or docs (ie official deliverables of openstack) different than "server" projects? seems a distinction without a difference. either all should be incubated or all should get approval from being in a program 20:22:00 mordred, I'm all for it 20:22:08 mordred: heh, that would comsume three days of my week each time 20:22:18 s/comsume/consume/ 20:22:19 notmyname, we've only ever incubated server projects, why is that? 20:22:23 notmyname: well, client libs have a different release cycle 20:22:30 notmyname: good point. where does the unified command line fit? 20:22:35 * jgriffith votes for first meeting in Boulder Co :) 20:22:43 notmyname: because the server release cycle for client libs would be the worst idea ever 20:22:44 on a tractor jgriffith? 20:22:50 jgriffith: Hawaii is more central 20:22:56 hub_cap: indeed.... although I was thinking horseback :) 20:23:02 notmyname, the fact that they end up defining an API that cloud users interact at is a big distinction, I think 20:23:05 notmyname: I think our 'release' has always been 'the software you need to run a cloud' 20:23:07 * jgriffith likes the point made by mikal 20:23:13 mikal: ++ 20:23:16 ttx: I think I have resolved my confusion. . from the current charter it seems like we still need a section that says "integrated projects are things part of the coordinated release, and incubated projects are repos that are in the process of becoming integrated projects" 20:23:16 basically, if we are approving a community, not lines of code, then the incubation should apply to the community and procedures, not the linter's view of the python 20:23:47 notmyname: I don't think we're approving a community 20:23:50 ttx: the key feature (of incubated projects) being not whether or not a repo has a rest api, but if it needs to be part of a coordinated release 20:24:02 notmyname: I think we're approving a mission or an outcome or a direction of work 20:24:21 mordred: ok, I'll buy that 20:24:21 markwash: incubation is actually not described in the charter at all, since it's more a process 20:24:47 ttx: oh maybe I'm confusing the charter with something else then 20:24:48 markwash, see the debate on the thread about whether oslo and docs are part of the release 20:24:56 ttx: I was reading https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee 20:25:08 duh, obviously that is not the charter 20:25:08 mordred: but doesn't the idea of approving programs that "can create any code repository and produce any deliverable they deem necessary to achieve their goals" kinda make "incubation" a weird concept? 20:25:08 markwash, s/oslo/oslo libraries/ 20:25:38 mordred: especially if by contributing in a program you are considered an ATC 20:25:50 notmyname: I don't think so - I think that incubation is about including the output of one or more of those repos into the thing that we integrate and release as a cloud 20:26:18 notmyname: currently, contributing to tempest and openstakc-infra gets you ATC- both are clearly 'working on openstack' the project 20:26:20 mordred: sounds like beta features in a release 20:26:26 notmyname: but neither are part of our coordinated release 20:26:35 hah, those charter changes are not trivial 20:26:42 because releasing either one makes no sense 20:26:43 I need to spend more time on thaht 20:26:45 ttx: this surprises you? :-) 20:27:16 ttx: I'm disappointed in your ability to spit out legalese! 20:27:24 notmyname: I don't really expect a conflict, it's just that I need to make sure to catch all corner cases 20:27:37 ttx: so - can I make a suggestion? 20:27:46 Like "Project Technical Leads" that would become "Program technical leads" ? 20:27:54 ttx: with the board, we vote on the motion itself, and then the lawyer goes back after and makes the legal language work 20:27:57 ttx: "so I'll just make this small change to this threadpool code. probably doesn't have any major side effects" ;-) 20:28:13 ttx: s/threadpool code/legal document/ 20:28:24 notmyname: hehe 20:28:25 mordred: yeah, i was thinking something along those lines 20:28:26 mordred, the board? 20:28:43 markmc: yeah. when we vote on things with the foundation board, we are not voting on the exact language 20:29:00 mordred, ah, ok - go it 20:29:01 markmc: the foundation lawyer goes back and writes the appropriate legalese later 20:29:10 mordred, read that as "we ask the board to vote on this" 20:29:12 I'm fine with updating the charter based on the outcome of the vote 20:29:15 NO GOD NO 20:29:15 mordred, which I knew you didn't mean :) 20:29:27 and then if a TC member thinks I misrepresented, we can revisit 20:29:29 * mordred runs screaming and sets markmc on fire 20:29:39 ttx, sounds good 20:29:42 ++ 20:29:51 one open question to me is, do we enable incubated programs where we already have a program that has the same charter/mission? 20:30:08 The only thing I see which might be an issue is that PTLs would now mean Program Technical Lead. 20:30:35 annegentle: I think that would be a judgement call by the TC each time. I find it unlikely that we would choose to do that though 20:30:51 like, I think I'd eat my own hair if we did 20:31:00 mordred: okay similar to "we already have a dbaas" or some such 20:31:08 right 20:31:16 mordred: bleh on the hair-eating 20:31:26 ya annegentle!!!!! trove ;) 20:31:26 I mean - who knows - maybe one day we'll all be drunk and think "two dbaas projects would make our lives better" 20:31:30 I guess I really don't understand the need to say "server" on line 13 of the etherpad 20:31:54 'integrated' deliverable seems sufficient 20:32:05 markwash: that's markmc's fault. 20:32:09 I can fix 20:32:16 I agree with markwash 20:32:38 so, only 'integrated' projects in the release? 20:32:44 how do I make oslo libs 'integrated'? 20:32:46 incubation? 20:32:50 markmc: no 20:33:05 only 'integrated' projects in the 'integrated projects' release? 20:33:24 do we have any other coordinated release? 20:33:24 mordred: the case for 2 similar projects is to support a deprecated version while migrating to a new one, no? 20:33:34 so, only 'integrated' projects in the *coordinated* 6 monthly release? 20:33:38 dhellmann: sure. I just think it's a case-by-case basis and probably quite rare 20:33:43 * dhellmann nods 20:34:14 markmc: hmm 20:34:39 markmc: I think that's a different conversation 20:34:47 if a program has a library that a server depends on, does the library have to be "integrated" or incubated? 20:34:48 I'm fine with us punting the discussion about the coordinated release 20:34:51 * notmyname throws grenades 20:34:53 markmc: one that we should have, but I think it's different 20:35:05 as long as the definition of programs prevents it from having non-server release deliverables 20:35:10 sigh 20:35:22 as long as the definition of programs *doesn't* prevent them from having non-server release deliverables 20:35:33 markmc: note that the current wording doesn't close any door. You can still be incubated (or not incubated) whatever happens 20:35:47 ttx, oslo libs would be incubated? 20:35:48 anyway 20:35:59 right. and I don't think it does. I think it purely describes a process, and lets us as the TC make decisions about which things should be in that thing 20:36:39 * annegentle gets ready for a document scope discussion with the TC in the future 20:36:53 markmc: I don't see why they would. They are ripped from prevoisouly-integrated code 20:37:32 ok, I guess we're saying 'integrated' == 'server' 20:37:38 markmc: I feel like the need to be integrated comes from how tightly other OS projects as a group need to couple to a single release version 20:37:38 ttx: feel free to use trove as a example to the process update, im still a bit fuzzy on the whole process ;) 20:37:41 which does seem weird to me 20:37:59 markmc: that's due to the origins of the 'integrated' concept 20:38:07 but there can be deliverables which aren't Integrated ... even if they are integrated (little 'i' integrated) 20:38:10 which was as you remember certainly to replace "core" 20:38:29 markmc: right, another name, another fight, another day 20:38:32 ok 20:38:46 aww no fighting 20:39:10 ttx, ok, changing to big-I integrated 20:39:15 I agree that there are a lot of things that are integrated and not part of what I/our documentation calls 'Integrated' 20:39:25 imagine we built a shared messaging system that was used for cross project notifications. . perhaps all projects couple to it in a way that requires versions to be synced, so it is integrated 20:39:31 now it's really like a legal doc 20:39:31 which is confusing 20:39:35 but it is not a server, because it doesn't have a server component 20:39:46 markmc: so we can probably vote on it :) 20:39:58 any more remark on the text before we put it to vote 20:40:00 ? 20:40:08 https://etherpad.openstack.org/programs-draft <- 20:40:37 ttx: can you paste it somewhere more permanently tied to the chat logs? 20:40:38 ttx, list of defined terms at the bottom :) 20:40:47 * markmc good to vote 20:40:55 * mordred good to vote 20:41:06 markmc: trick is those are defined ELSEWHERE. 20:41:17 ttx, yeah, I'm just finding a link to stick in 20:41:32 notmyname: err... I could send it to -dev, I guess 20:42:06 ttx: eh...etherpad seems quite ephemeral 20:42:06 or paste it all over the channel 20:42:15 if that works with everyone 20:42:15 well 20:42:20 markwash: good case, works with a program to me 20:42:24 * notmyname is fine with a channel flood (don't kline yourself) 20:42:27 notmyname: my etherpads from 3 summits ago are still around :) 20:42:43 OK, quiet while I paste 20:42:47 jgriffith: rainbow text with no context or idea who edited what 20:43:08 """ 20:43:10 'OpenStack Programs' are efforts which are essential to the completion of our mission. Programs can create any code repository and produce any deliverable they deem necessary to achieve their goals. 20:43:23 Programs are placed under the oversight of the Technical Committee, and contributing to one of their code repositories grants you ATC status. 20:43:52 Current efforts or teams which want to be recognized as an 'OpenStack Program' should place a request to the Technical Committee, including a clear mission statement describing how they help the OpenStack general mission and how that effort is essential to the completion of our mission. 20:44:27 If programs have a goal that includes the production of an 'Integrated' deliverable, that specific deliverable would still need to go through an Incubation period. 20:44:54 The initial Programs are 'Nova', 'Swift', 'Cinder', 'Neutron', 'Horizon', 'Glance', 'Keystone', 'Heat', 'Ceilometer', 'Documentation', 'Infrastructure', 'QA', 'Oslo', 'Trove' and 'Ironic'. Those programs should retroactively submit a mission statement and initial lead designation, if they don't have one already. 20:45:08 The TC asks that the chair modifies the charter accordingly, including replacing the word "Projects" by "Programs" where appropriate. 20:45:11 """ 20:45:24 phew 20:45:28 ttx: thanks :-) 20:45:31 nicely pasted 20:45:40 golf clap 20:45:53 * mordred is proud of ttx 20:46:02 #startvote Accept above "Programs" definition? yes, no, abstain 20:46:03 Begin voting on: Accept above "Programs" definition? Valid vote options are yes, no, abstain. 20:46:04 Vote using '#vote OPTION'. Only your last vote counts. 20:46:19 #vote yes 20:46:20 #vote yes 20:46:23 #vote yes 20:46:26 #vote yes 20:46:29 #vote yes 20:46:30 #vote yes 20:46:30 #vote yes 20:46:44 #vote yes 20:46:52 #vote yes 20:46:54 #vote yes 20:46:54 NobodyCam: actually your vote doesn't count. 20:46:56 #vote yes 20:46:57 #vote yes 20:47:01 #vote yes 20:47:06 #vote yes 20:47:15 30 more seconds 20:47:20 lol :) 20:47:42 #vote yes 20:47:49 #endvote 20:47:50 Voted on "Accept above "Programs" definition?" Results are 20:47:51 yes (15): markmc, ttx, galstrom, annegentle, jd__, shardy, russellb, markwash, mikal, mordred, gabrielhurley, NobodyCam, jgriffith, markmcclain, notmyname 20:48:09 we'll say that NobodyCam was proxying vishy. 20:48:16 #topic Open discussion 20:48:16 lol 20:48:46 We'll be starting the discussion on Design Summit soon 20:48:51 cool. 20:48:59 like how to fill that time in the most productive manner 20:49:01 can we create a program to manage it :) 20:49:09 ttx: is the process for tripleo now to submit a motion to the TC for a week of mailing list discussion before a vote? 20:49:29 how long will programs like Ironic have to come up with the a mission statement 20:49:42 +Trove 20:49:45 NobodyCam: 30 seconds 20:49:47 NobodyCam: you will have one in 5 minutes or you will be killed 20:49:50 ieeek 20:49:51 mordred: indeed. Note that with July 4th time is running a bit short for public discussion 20:49:57 sigh 20:50:03 is anyone here likely to vote against it? 20:50:05 * mordred cires 20:50:13 yeah let's set a deadline of Aug 1st or so for programs 20:50:28 * mordred doesn't know what cires is 20:50:35 mordred: I think the discussion would be around whther Ironic should be merged with it, since the goal statement would be quite similar ? 20:50:41 special mordred tears 20:51:01 NobodyCam: yesterday ? 20:51:16 ttx: hrm. I don't think either tripleo or ironic want to merge - but, sure, worth discussing 20:51:20 Trove mission statement: to piss off mordred in some way 20:51:33 hub_cap: priceless 20:51:33 mordred: are those completely disjoint teams ? 20:51:41 ttx: largely, yes 20:51:58 yeah, I buy ironic as a separate thing 20:52:02 mordred: I'd still be interested to see that mission statement from TripleO 20:52:13 as well as Ironic's for that matter 20:52:22 to run the ubiquitous cloud on the ubiquitous cloud 20:52:23 k. 20:52:25 * markwash wonders about Glance's mission statement. . . 20:52:48 * mordred admits that he's trying to ram something in so that we dont' have to do two gerrit downtime renames over the next month 20:53:02 * mordred stops trying to do that 20:53:13 Had a question... shall programs coming from classic projects be named after the project name ("Nova") ? Or the IaaS piece name ("Compute') ? 20:53:35 ttx: let's make bryce happy and make the program named for the non-codename 20:53:42 lol 20:54:07 codenames 4 life 20:54:11 +1 to using formal names for programs 20:54:23 (fine with using formal name) 20:54:30 mordred: that would be my position too. The project is the project. The effort around that project is more tied to the goal than to the project 20:54:49 ttx: yup. and bryce and friends are usually talking about the goal rather than the codebase 20:54:51 now I'm confused. 20:54:53 ;) 20:55:00 * markwash wants to change Glance's mission and formal name :-( 20:55:03 using the OoO and iRonic example. what would that program be named 20:55:06 bryce and friends should be a tv show 20:55:32 NobodyCam: Ironic: "OpenStack Bare Metal"? - TripleO: "OpenStack on OpenStack" ? 20:55:32 markwash: you want to be the "Ministry of silly walks" program ? 20:55:48 markwash: to what? 20:56:00 mordred: boot images are too narrow 20:56:10 markwash: your name is boot images? 20:56:11 plus glance light would probably be /dev/null 20:56:22 formal name/ real name :) 20:56:27 Glance is, I think, "Image service" ? 20:56:36 markwash: OpenStack Image Registry isn't it? 20:56:42 hehe 20:56:46 * mordred asking for real 20:56:50 so I see glance changing to be more full machine images, specifying more stuff like full block device mapping, memory contents, etc 20:57:13 and then basically being an optional gatekeeper component for all of those things 20:57:25 mordred: "OpenStack Image Service" apparently 20:57:28 oh well, growing pains 20:57:33 am i late for project update meeting? i'm joining for Cinder since jgriffith is out 20:57:42 mordred: TripleO's program name might be better if it spoke to deploy/ops 20:57:45 winston-d: nope, you're early :) 20:57:52 mordred: OpenStack On OpenStack is a bit jargony. 20:57:58 jgriffith: oh, you are here. :) 20:58:09 lifeless: I look forward to you submitting a mission statement and formal name 20:58:27 by 8/1/2013 20:58:32 mordred: I shall; I asked ttx last week and he said to wait ;) 20:58:32 :-p 20:58:42 btw - I've been trying to put things formal names in the setup.cfg summary field 20:58:44 where do we submit said mission statements to? 20:58:50 lifeless: I think you can consider yourself unblocked 20:59:02 the draft of trove mission statement would just be in https://wiki.openstack.org/wiki/Trove ? 20:59:06 hub_cap: openstack-dev, with a heads-up on openstack-tc 20:59:17 mordred: we have a lookup table in the doc that I'm now going to have to file a bug against :) 20:59:26 Ah ok as in, email to the list. got it ttx 20:59:30 hub_cap: use the wiki as the permanent reference, yes 21:00:06 ok, we are closing, last round of beers 21:00:13 annegentle: I'm aslo going to try to get our automation to set the gerrit and github project description to the text in the setup.cfg summary section too 21:00:34 mordred: yes, we need a way to find out which program a given repo belongs to 21:00:42 mordred: we have http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/terminology-codenames.html and http://docs.openstack.org/grizzly/openstack-compute/admin/content/components-of-openstack.html 21:00:42 mordred: if only to automate ATC list generation 21:00:58 ok, moar next time 21:00:58 ttx: I think we can figure something out 21:01:03 #endmeeting