20:01:05 <ttx> #startmeeting tc
20:01:06 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:09 <openstack> The meeting name has been set to 'tc'
20:01:10 <markmcclain> o/
20:01:10 <russellb> o/
20:01:21 <ttx> Agenda for today is at:
20:01:29 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:01:40 <ttx> #topic "Programs" definition and define initial set
20:01:51 <ttx> thread is at:
20:01:57 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-June/010950.html
20:02:09 <ttx> It's been a wordy and confused thread, largely my fault
20:02:16 <ttx> let me summarize it
20:02:25 <mordred> meh. it's a hard thing to get right without making things to nit-picky
20:02:29 <ttx> My initial try at it was ripped off as a bit integratedrelease-centric
20:02:43 <ttx> We have a number of ways forward that would be generally compatible with the current bylaws/charter:
20:03:00 <ttx> (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 <ttx> (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 <ttx> (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 <mordred> I like 3. it seems to expres reality the best
20:04:00 <ttx> 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 <mordred> and expresses what we're already doing more than any of our previous things have
20:04:11 <jd__> +1
20:04:27 <annegentle> ttx: I like non-elitist and inclusionary
20:04:39 <mordred> annegentle: ++
20:04:42 <markmc> I'm fine with 3, except the idea that we'd have multiple server projects under a program
20:04:48 <markmc> e.g. merging Nova and Quantum into a program
20:05:04 <annegentle> 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 <ttx> markmc: that would make no sense, since those are different teams
20:05:15 <mordred> 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 <markmc> annegentle, nova, glance, etc. - anything with a REST API
20:05:22 <ttx> annegentle: pieces that might become "core"
20:05:26 <markmc> ttx, right
20:05:36 <mikal> Option three also means that a program can have more than one project, and not all are integrated by default
20:05:45 <markmc> now, (1) is the most incremental option
20:05:52 <mordred> mikal: yeah. like oslo or infra
20:05:57 <markmc> leave server projects as they are, introduce programs for other stuff
20:06:04 <ttx> markmc: solution (3) definitely leaves things open, so you should expect refinement
20:06:24 <mordred> I thnk that's what I like about it - it doesn't get to legalistic and nitpicky
20:06:27 <mordred> too
20:06:38 * ttx puts solution (3) text on etherpad, just a sec
20:06:55 <NobodyCam> mordred: +1 it doesn't get to legalistic and nitpicky
20:07:16 <jgriffith> o/
20:07:29 <dhellmann> it also defines boundaries for programs based on the feature area rather than based on how code is organized
20:07:40 <ttx> text @ https://etherpad.openstack.org/programs-draft
20:07:41 <notmyname> 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 <ttx> 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 <mikal> What does a program get?
20:08:50 <mordred> notmyname: ++
20:08:52 <annegentle> just wondering "aloud" -- what if vagueness causes more confusion and a rush of applications?
20:08:55 <mikal> Does that mean a long term commitment to a summit track for those programs?
20:08:59 <mikal> Even if incubation fails?
20:09:20 <mordred> mikal: stuff it produces//works on granks atc status and it gets to put things into the openstack/ namespace
20:09:36 <mordred> like, working on a program == working on openstack, even if you aren't hacking on nova
20:09:38 <ttx> I think if incubation really fails (and is not merely delayed), we would consider removing the program
20:09:48 <dhellmann> +1
20:09:48 <mordred> and yes to what ttx said
20:09:52 <markmc> mikal, the TC can't really make a commitment about summit time, we don't run it
20:09:54 <jgriffith> ttx: +1
20:09:55 <mikal> Ok
20:10:01 <mordred> but I think that there will be programs without incubation things
20:10:09 <ttx> markmc: well, we kinda run the Design summit.
20:10:10 <markmc> so, what's "our mission" ?
20:10:33 <markmc> ttx, kinda, but we don't decide how many days/rooms/etc. there'll be ... without bounds anyway
20:10:37 <ttx> markmc: the openstack project mission is defined and I think still valid
20:10:49 <markmc> ttx, yep, just can't find it off hand
20:10:56 <markmc> ttx, unless you mean the foundation's mission
20:11:00 <mordred> 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 <ttx> https://wiki.openstack.org ?
20:11:07 <markmc> cool, thanks
20:11:18 <jgriffith> mordred: hehe...
20:11:27 <annegentle> mikal: we had a lot of discussion in the IncUp about what you "get" when you're integrated
20:11:32 <mordred> "simple to implement" may still need work
20:11:33 <annegentle> mikal: that might help
20:11:39 * annegentle looks for those notes
20:11:42 <markmc> mordred, indeed
20:11:43 <mikal> ok
20:11:47 <ttx> (FYI galstrom proxies dolphm's vote)
20:12:02 <galstrom> (sorry for being late)
20:12:07 <mordred> galstrom: o hai dolphm
20:12:09 <mordred> ;)
20:12:19 <ttx> Is version 3 as described on the Etherpad acceptable for everyone ? Shall we vote ?
20:12:22 <annegentle> ttx: what release management does being a program qualify the program for?
20:12:36 <mordred> nothing
20:12:38 <markmc> ttx, are you saying we don't add any mention of programs to our charter?
20:12:44 <annegentle> mikal: see line 113 of https://etherpad.openstack.org/IncUp
20:12:55 <mikal> annegentle: thanks
20:13:03 <mordred> annegentle: release management is for integrated projects, I believe
20:13:13 <ttx> markmc: hmm
20:13:13 <markmc> "under the oversight of the TC" vs "not mentioned in the TC charter" ?
20:13:15 <jgriffith> ttx: so I guess my question with this is how is it really different than what we're doing already?
20:13:21 <annegentle> mordred: right and if we take away "projects" what happens to release management
20:13:30 <mordred> annegentle: I do not believe we are taking away projects
20:13:38 <annegentle> mordred: ah ok
20:14:02 <ttx> jgriffith: what we're doing already is operating in a bit of vacuum.
20:14:14 <mordred> 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 <jgriffith> ttx: mordred suppose those are very good points
20:14:33 <ttx> we've been struggling to create project categories
20:14:38 <ttx> to match reality
20:14:48 <jgriffith> 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 <mordred> if we notice no appreciable difference in our lives after this, we've done our jobs well
20:14:59 <jgriffith> mordred: I disagree
20:15:02 <markwash> 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 <jgriffith> mordred: I would argue that we haven't done our jobs
20:15:19 <mordred> 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 <ttx> jgriffith: "programs" actually let us remove categories
20:15:24 <markwash> well s/incubating/pre-incubating/
20:15:44 <mordred> markwash: yes. indeed
20:15:50 <jgriffith> mordred: ttx ok
20:15:52 <ttx> See "OpenStack projects" under https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee
20:16:07 <jgriffith> mordred: ttx perhaps I'm just not seeing the bigger picture, and I agree 100% about inclusion
20:16:14 <ttx> jgriffith: programs let us be goal-oriented rather than repo-oriented
20:16:29 <markmc> 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 <markmc> jgriffith, aside from incubating a server project
20:16:53 <mordred> and without us having a conversation about every little repo it might produce
20:17:00 <ttx> 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 <jgriffith> markmc: sighh... Yeah, I get that point (sort of)
20:17:21 <mordred> sort of like how infra generates new repos weekly, but doesn't need to come to the TC each time
20:17:24 <markmc> ttx, I'm fine with us doing that later, just that it does need to happen
20:17:29 <notmyname> 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 <mordred> notmyname: ++
20:17:41 <jgriffith> I guess the issue is I still have the unpopular notion of core versus other etc
20:17:43 <markwash> how does #3 affect incubation again?
20:17:57 <mordred> markwash: incubation for projects is still as before
20:18:06 <jgriffith> personally it's hard enough to "explain" OpenStack as it is, let alone with everything but the kitchen sink thrown in
20:18:15 <mordred> 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 <markmc> markwash, server projects go through incubation still
20:18:33 <ttx> 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 <ttx> so it's basically the same
20:19:05 <markwash> 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 <dhellmann> or "yes and X should be part of an existing program"?
20:19:09 <jgriffith> ttx: mordred markmc but I do see your points
20:19:11 <hub_cap> so how does this affect, if at all, us projects in incubation?
20:19:17 <notmyname> 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 <markwash> I'm not sure we have to resolve the incubation problem right now though
20:19:48 <markmc> notmyname, I think ttx's definition is that programs get accepted, then any server projects they produce go through incubation
20:19:49 <ttx> hub_cap: your effort becomes a "program" which produces trove and python-troveclient
20:19:56 <notmyname> hub_cap: it's very simple. everything doesn't change, except where it does
20:20:01 <markwash> lol
20:20:03 <hub_cap> hah notmyname
20:20:12 <mordred> notmyname: haha
20:20:26 <hub_cap> ttx: makes sense. and then we can remove trove-integration from the openstack github, eh?
20:20:39 <ttx> let me have a try at a charter wording change
20:21:31 <mordred> hub_cap: you can remove that when your integration tests are part of the normal set of them
20:21:31 <markmc> this would be much more fun if we were in a room together
20:21:37 <markmc> ttx drafting the charter changes
20:21:40 <hub_cap> mordred: shhhh
20:21:43 <markmc> while we all sit there and .... stare
20:21:46 <markmc> no pressure ttx
20:21:52 <mordred> markmc: we should totally have weekly onsite meetings
20:21:59 <notmyname> 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 <markmc> mordred, I'm all for it
20:22:08 <mikal> mordred: heh, that would comsume three days of my week each time
20:22:18 <mikal> s/comsume/consume/
20:22:19 <markmc> notmyname, we've only ever incubated server projects, why is that?
20:22:23 <mordred> notmyname: well, client libs have a different release cycle
20:22:30 <dhellmann> notmyname: good point. where does the unified command line fit?
20:22:35 * jgriffith votes for first meeting in Boulder Co :)
20:22:43 <mordred> notmyname: because the server release cycle for client libs would be the worst idea ever
20:22:44 <hub_cap> on a tractor jgriffith?
20:22:50 <mikal> jgriffith: Hawaii is more central
20:22:56 <jgriffith> hub_cap: indeed.... although I was thinking horseback :)
20:23:02 <markmc> notmyname, the fact that they end up defining an API that cloud users interact at is a big distinction, I think
20:23:05 <mordred> 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 <mordred> mikal: ++
20:23:16 <markwash> 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 <notmyname> 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 <mordred> notmyname: I don't think we're approving a community
20:23:50 <markwash> 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 <mordred> notmyname: I think we're approving a mission or an outcome or a direction of work
20:24:21 <notmyname> mordred: ok, I'll buy that
20:24:21 <ttx> markwash: incubation is actually not described in the charter at all, since it's more a process
20:24:47 <markwash> ttx: oh maybe I'm confusing the charter with something else then
20:24:48 <markmc> markwash, see the debate on the thread about whether oslo and docs are part of the release
20:24:56 <markwash> ttx: I was reading https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee
20:25:08 <markwash> duh, obviously that is not the charter
20:25:08 <notmyname> 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 <markmc> markwash, s/oslo/oslo libraries/
20:25:38 <notmyname> mordred: especially if by contributing in a program you are considered an ATC
20:25:50 <mordred> 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 <mordred> notmyname: currently, contributing to tempest and openstakc-infra gets you ATC- both are clearly 'working on openstack' the project
20:26:20 <notmyname> mordred: sounds like beta features in a release
20:26:26 <mordred> notmyname: but neither are part of our coordinated release
20:26:35 <ttx> hah, those charter changes are not trivial
20:26:42 <mordred> because releasing either one makes no sense
20:26:43 <ttx> I need to spend more time on thaht
20:26:45 <notmyname> ttx: this surprises you? :-)
20:27:16 <mordred> ttx: I'm disappointed in your ability to spit out legalese!
20:27:24 <ttx> 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 <mordred> ttx: so - can I make a suggestion?
20:27:46 <ttx> Like "Project Technical Leads" that would become "Program technical leads" ?
20:27:54 <mordred> 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 <notmyname> ttx: "so I'll just make this small change to this threadpool code. probably doesn't have any major side effects" ;-)
20:28:13 <notmyname> ttx: s/threadpool code/legal document/
20:28:24 <mordred> notmyname: hehe
20:28:25 <ttx> mordred: yeah, i was thinking something along those lines
20:28:26 <markmc> mordred, the board?
20:28:43 <mordred> markmc: yeah. when we vote on things with the foundation board, we are not voting on the exact language
20:29:00 <markmc> mordred, ah, ok - go it
20:29:01 <mordred> markmc: the foundation lawyer goes back and writes the appropriate legalese later
20:29:10 <markmc> mordred, read that as "we ask the board to vote on this"
20:29:12 <ttx> I'm fine with updating the charter based on the outcome of the vote
20:29:15 <mordred> NO GOD NO
20:29:15 <markmc> mordred, which I knew you didn't mean :)
20:29:27 <ttx> 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 <markmc> ttx, sounds good
20:29:42 <mordred> ++
20:29:51 <annegentle> 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 <ttx> The only thing I see which might be an issue is that PTLs would now mean Program Technical Lead.
20:30:35 <mordred> 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 <mordred> like, I think I'd eat my own hair if we did
20:31:00 <annegentle> mordred: okay similar to "we already have a dbaas" or some such
20:31:08 <mordred> right
20:31:16 <annegentle> mordred: bleh on the hair-eating
20:31:26 <hub_cap> ya annegentle!!!!! trove ;)
20:31:26 <mordred> 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 <markwash> I guess I really don't understand the need to say "server" on line 13 of the etherpad
20:31:54 <markwash> 'integrated' deliverable seems sufficient
20:32:05 <ttx> markwash: that's markmc's fault.
20:32:09 <ttx> I can fix
20:32:16 <mordred> I agree with markwash
20:32:38 <markmc> so, only 'integrated' projects in the release?
20:32:44 <markmc> how do I make oslo libs 'integrated'?
20:32:46 <markmc> incubation?
20:32:50 <ttx> markmc: no
20:33:05 <ttx> only 'integrated' projects in the 'integrated projects' release?
20:33:24 <markmc> do we have any other coordinated release?
20:33:24 <dhellmann> mordred: the case for 2 similar projects is to support a deprecated version while migrating to a new one, no?
20:33:34 <markmc> so, only 'integrated' projects in the *coordinated* 6 monthly release?
20:33:38 <mordred> dhellmann: sure. I just think it's a case-by-case basis and probably quite rare
20:33:43 * dhellmann nods
20:34:14 <ttx> markmc: hmm
20:34:39 <mordred> markmc: I think that's a different conversation
20:34:47 <notmyname> if a program has a library that a server depends on, does the library have to be "integrated" or incubated?
20:34:48 <markmc> I'm fine with us punting the discussion about the coordinated release
20:34:51 * notmyname throws grenades
20:34:53 <mordred> markmc: one that we should have, but I think it's different
20:35:05 <markmc> as long as the definition of programs prevents it from having non-server release deliverables
20:35:10 <markmc> sigh
20:35:22 <markmc> as long as the definition of programs *doesn't* prevent them from having non-server release deliverables
20:35:33 <ttx> markmc: note that the current wording doesn't close any door. You can still be incubated (or not incubated) whatever happens
20:35:47 <markmc> ttx, oslo libs would be incubated?
20:35:48 <ttx> anyway
20:35:59 <mordred> 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 <ttx> markmc: I don't see why they would. They are ripped from prevoisouly-integrated code
20:37:32 <markmc> ok, I guess we're saying 'integrated' == 'server'
20:37:38 <markwash> 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 <hub_cap> 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 <markmc> which does seem weird to me
20:37:59 <ttx> markmc: that's due to the origins of the 'integrated' concept
20:38:07 <markmc> but there can be deliverables which aren't Integrated ... even if they are integrated (little 'i' integrated)
20:38:10 <ttx> which was as you remember certainly to replace "core"
20:38:29 <ttx> markmc: right, another name, another fight, another day
20:38:32 <markmc> ok
20:38:46 <annegentle> aww no fighting
20:39:10 <markmc> ttx, ok, changing to big-I integrated
20:39:15 <ttx> 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 <markwash> 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 <markmc> now it's really like a legal doc
20:39:31 <ttx> which is confusing
20:39:35 <markwash> but it is not a server, because it doesn't have a server component
20:39:46 <ttx> markmc: so we can probably vote on it :)
20:39:58 <ttx> any more remark on the text before we put it to vote
20:40:00 <ttx> ?
20:40:08 <ttx> https://etherpad.openstack.org/programs-draft <-
20:40:37 <notmyname> ttx: can you paste it somewhere more permanently tied to the chat logs?
20:40:38 <markmc> 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 <ttx> markmc: trick is those are defined ELSEWHERE.
20:41:17 <markmc> ttx, yeah, I'm just finding a link to stick in
20:41:32 <ttx> notmyname: err... I could send it to -dev, I guess
20:42:06 <notmyname> ttx: eh...etherpad seems quite ephemeral
20:42:06 <ttx> or paste it all over the channel
20:42:15 <ttx> if that works with everyone
20:42:15 <markwash> well
20:42:20 <annegentle> 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 <jgriffith> notmyname: my etherpads from 3 summits ago are still around :)
20:42:43 <ttx> OK, quiet while I paste
20:42:47 <notmyname> jgriffith: rainbow text with no context or idea who edited what
20:43:08 <ttx> """
20:43:10 <ttx> '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 <ttx> 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 <ttx> 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 <ttx> 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 <ttx> 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 <ttx> The TC asks that the chair modifies the charter accordingly, including replacing the word "Projects" by "Programs" where appropriate.
20:45:11 <ttx> """
20:45:24 <ttx> phew
20:45:28 <notmyname> ttx: thanks :-)
20:45:31 <gabrielhurley> nicely pasted
20:45:40 <jgriffith> golf clap
20:45:53 * mordred is proud of ttx
20:46:02 <ttx> #startvote Accept above "Programs" definition? yes, no, abstain
20:46:03 <openstack> Begin voting on: Accept above "Programs" definition? Valid vote options are yes, no, abstain.
20:46:04 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:46:19 <ttx> #vote yes
20:46:20 <annegentle> #vote yes
20:46:23 <jd__> #vote yes
20:46:26 <NobodyCam> #vote yes
20:46:29 <markmc> #vote yes
20:46:30 <gabrielhurley> #vote yes
20:46:30 <mikal> #vote yes
20:46:44 <markwash> #vote yes
20:46:52 <galstrom> #vote yes
20:46:54 <shardy> #vote yes
20:46:54 <ttx> NobodyCam: actually your vote doesn't count.
20:46:56 <mordred> #vote yes
20:46:57 <notmyname> #vote yes
20:47:01 <markmcclain> #vote yes
20:47:06 <jgriffith> #vote yes
20:47:15 <ttx> 30 more seconds
20:47:20 <NobodyCam> lol :)
20:47:42 <russellb> #vote yes
20:47:49 <ttx> #endvote
20:47:50 <openstack> Voted on "Accept above "Programs" definition?" Results are
20:47:51 <openstack> yes (15): markmc, ttx, galstrom, annegentle, jd__, shardy, russellb, markwash, mikal, mordred, gabrielhurley, NobodyCam, jgriffith, markmcclain, notmyname
20:48:09 <ttx> we'll say that NobodyCam was proxying vishy.
20:48:16 <ttx> #topic Open discussion
20:48:16 <gabrielhurley> lol
20:48:46 <ttx> We'll be starting the discussion on Design Summit soon
20:48:51 <mordred> cool.
20:48:59 <ttx> like how to fill that time in the most productive manner
20:49:01 <markmcclain> can we create a program to manage it :)
20:49:09 <mordred> 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 <NobodyCam> how long will programs like Ironic have to come up with the a mission statement
20:49:42 <hub_cap> +Trove
20:49:45 <jgriffith> NobodyCam: 30 seconds
20:49:47 <mordred> NobodyCam: you will have one in 5 minutes or you will be killed
20:49:50 <NobodyCam> ieeek
20:49:51 <ttx> mordred: indeed. Note that with July 4th time is running a bit short for public discussion
20:49:57 <mordred> sigh
20:50:03 <mordred> is anyone here likely to vote against it?
20:50:05 * mordred cires
20:50:13 <annegentle> 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 <ttx> 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 <annegentle> special mordred tears
20:51:01 <ttx> NobodyCam: yesterday ?
20:51:16 <mordred> ttx: hrm. I don't think either tripleo or ironic want to merge - but, sure, worth discussing
20:51:20 <hub_cap> Trove mission statement: to piss off mordred in some way
20:51:33 <jgriffith> hub_cap: priceless
20:51:33 <ttx> mordred: are those completely disjoint teams ?
20:51:41 <mordred> ttx: largely, yes
20:51:58 <markmc> yeah, I buy ironic as a separate thing
20:52:02 <ttx> mordred: I'd still be interested to see that mission statement from TripleO
20:52:13 <ttx> as well as Ironic's for that matter
20:52:22 <jgriffith> to run the ubiquitous cloud on the ubiquitous cloud
20:52:23 <mordred> 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 <ttx> 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 <mordred> ttx: let's make bryce happy and make the program named for the non-codename
20:53:42 <hub_cap> lol
20:54:07 <russellb> codenames 4 life
20:54:11 <markmcclain> +1 to using formal names for programs
20:54:23 <russellb> (fine with using formal name)
20:54:30 <ttx> 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 <mordred> ttx: yup. and bryce and friends are usually talking about the goal rather than the codebase
20:54:51 <ttx> now I'm confused.
20:54:53 <ttx> ;)
20:55:00 * markwash wants to change Glance's mission and formal name :-(
20:55:03 <NobodyCam> using the OoO and iRonic example. what would that program be named
20:55:06 <mordred> bryce and friends should be a tv show
20:55:32 <mordred> NobodyCam: Ironic: "OpenStack Bare Metal"? - TripleO: "OpenStack on OpenStack" ?
20:55:32 <ttx> markwash: you want to be the "Ministry of silly walks" program ?
20:55:48 <mordred> markwash: to what?
20:56:00 <markwash> mordred: boot images are too narrow
20:56:10 <mordred> markwash: your name is boot images?
20:56:11 <markwash> plus glance light would probably be /dev/null
20:56:22 <annegentle> formal name/ real name :)
20:56:27 <ttx> Glance is, I think, "Image service" ?
20:56:36 <mordred> markwash: OpenStack Image Registry isn't it?
20:56:42 <ttx> hehe
20:56:46 * mordred asking for real
20:56:50 <markwash> 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 <markwash> and then basically being an optional gatekeeper component for all of those things
20:57:25 <ttx> mordred: "OpenStack Image Service" apparently
20:57:28 <markwash> oh well, growing pains
20:57:33 <winston-d> am i late for project update meeting? i'm joining for Cinder since jgriffith is out
20:57:42 <lifeless> mordred: TripleO's program name might be better if it spoke to deploy/ops
20:57:45 <jgriffith> winston-d: nope, you're early :)
20:57:52 <lifeless> mordred: OpenStack On OpenStack is a bit jargony.
20:57:58 <winston-d> jgriffith: oh, you are here. :)
20:58:09 <mordred> lifeless: I look forward to you submitting a mission statement and formal name
20:58:27 <NobodyCam> by 8/1/2013
20:58:32 <lifeless> mordred: I shall; I asked ttx last week and he said to wait ;)
20:58:32 <NobodyCam> :-p
20:58:42 <mordred> btw - I've been trying to put things formal names in the setup.cfg summary field
20:58:44 <hub_cap> where do we submit said mission statements to?
20:58:50 <ttx> lifeless: I think you can consider yourself unblocked
20:59:02 <hub_cap> the draft of trove mission statement would just be in https://wiki.openstack.org/wiki/Trove ?
20:59:06 <ttx> hub_cap: openstack-dev, with a heads-up on openstack-tc
20:59:17 <annegentle> mordred: we have a lookup table in the doc that I'm now going to have to file a bug against :)
20:59:26 <hub_cap> Ah ok as in, email to the list. got it ttx
20:59:30 <ttx> hub_cap: use the wiki as the permanent reference, yes
21:00:06 <ttx> ok, we are closing, last round of beers
21:00:13 <mordred> 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 <ttx> mordred: yes, we need a way to find out which program a given repo belongs to
21:00:42 <annegentle> 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 <ttx> mordred: if only to automate ATC list generation
21:00:58 <ttx> ok, moar next time
21:00:58 <mordred> ttx: I think we can figure something out
21:01:03 <ttx> #endmeeting