20:02:05 <ttx> #startmeeting tc
20:02:06 <openstack> Meeting started Tue Jun 25 20:02:05 2013 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:09 <openstack> The meeting name has been set to 'tc'
20:02:19 <ttx> Agenda for today is at:
20:02:23 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:33 <ttx> #topic Incubation request for Designate: final discussion and vote
20:02:41 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2013-June/000266.html
20:02:48 <ttx> #link https://wiki.openstack.org/wiki/Designate_Incubation_Application
20:02:56 <ttx> There wasn't a lot of discussion this week on the ML...
20:03:05 <ttx> I don't know if that means we are all fine with voting or we should wait another week :)
20:03:28 <ttx> kiall: around ?
20:03:34 <kiall> ttx: hiya
20:03:45 * jd__ fine with voting
20:03:51 <ttx> The main concern raised last week was, I think, general adoption.
20:03:54 * mordred hasn't received any bribe money from kiall yet
20:04:09 <ttx> On one hand it's a chicken-and-egg problem... but on the other you want to see potential alignment before blessing a candidate
20:04:18 <ttx> because like mordred said, these projects sit in places where they can either help or kill interop
20:04:43 <ttx> The fact that the project relies on very few people was also noted as a bit concerning
20:04:56 <ttx> Like kiall did 87% of the commits! And only 4 people did more than 1 commit.
20:05:00 * CaptTofu_ o
20:05:25 <ttx> is that a risk ? do we care ?
20:05:30 <russellb> i think it is
20:05:31 * markmc cares
20:05:32 * gabrielhurley cares
20:05:35 * mordred cares
20:05:39 * shardy cares
20:05:40 <ttx> do we care for incubation, or only for graduation ?
20:05:45 <mikal> Isn't incubation about giving a chance to address those concerns?
20:05:46 <kiall> ttx: yea, I agree there are merits to both a yes / no .. Obviously we think a yes vote will significantly help with adoption..
20:05:47 * mordred would say for graduation
20:05:47 <russellb> incubation, i'm afraid, personally
20:05:51 <mordred> what mikal said
20:05:52 * markmc cares for incubation
20:06:14 <mordred> as in, I'd like to make specific statements about outcomes expected for graduation
20:06:21 <jd__> caring for incubation remove a bit of usefulness from incubation IMHO
20:06:23 <russellb> not a "no, never", but like ... "build a bit more and come back"
20:06:23 <jgriffith> mordred: +1
20:06:33 <kiall> mordred: +1 from us on that
20:06:40 <jgriffith> jd__: how do you mean?
20:06:43 <mordred> jd__: ++
20:06:47 <markmc> I think incubation is great to help grow a community to critical mass
20:07:02 <jgriffith> markmc: +1
20:07:03 <markmc> but there should be more than one just one person working on a project before incubation
20:07:08 <mordred> I thnkn we saw that with heat - it was very redhat-centric, then grew more people in incubation
20:07:19 <jgriffith> markmc: I don't know if I agree with that part necessarily :)
20:07:21 <jd__> jgriffith: if you care of such things for incubation, you're setting the bar almost the same for incubation and graduation, at least on that point which is a downside for me
20:07:31 <russellb> mordred: but several people
20:07:35 <jgriffith> jd__: ahh... got ya thanks
20:07:47 <ttx> the bus factor is a bit of a concern to me
20:07:51 <markmc> mordred, heat had several leaders, not even just contributor
20:07:53 <jgriffith> cinder was '1' for a good bit
20:07:55 <kiall> Yea, I've heard from more than a few people that incubation is a requirement to starting to make use of the project.
20:07:59 <shardy> markmc: +1, although tbh heat has only really seen a significant increase in community participation since graduating from incubation...
20:08:05 <annegentle> I'm with markmc, that incubation should help people get more participants
20:08:16 <jd__> ttx: I'm ok for the bus factor for graduation, but for incubation…
20:08:17 <ttx> jgriffith: it piggy-backed on nova's team though
20:08:43 <jgriffith> ttx: sure, but...  if it goes incubation that's the point right?
20:08:44 <CaptTofu_> we certainly need more people using the project
20:08:48 <jgriffith> ttx: see if it can stand on it's own or not
20:08:49 <mordred> kiall: there's multiple people working on designate at HP - why aren't we seeing a wider pool of commits from folks who aren't you?
20:08:57 <ttx> annegentle: actually I think you're with mordred :)
20:09:13 <russellb> only 1 dev may also be a sign that the scope is too small and should be reconsidered
20:09:20 <kiall> mordred: so far, we've been focused on getting things going for HP Cloud DNS. (Due to go GA next week)
20:09:49 <markmc> ttx, oh, yes - on voting, can we have a voting category that distinguishes between "no, not ever" and "no, but we'd like to see you next cycle"
20:10:08 <russellb> markmc: good point.
20:10:09 <ttx> sure. Both would count as "no" though :)
20:10:22 <markmc> ok, fair
20:10:25 <kiall> I've focused on Moniker itself, while others have figured out how to make it a production ready service. Once we get our GA out of the way, I expect you'll see more commits from HP people
20:10:25 <markmcclain> markmc: options for essentially a −1 and −2?
20:10:35 <jgriffith> ttx: but one's a *nice* no :)
20:10:36 <markmc> I guess no-one is really saying "no, not ever" anyway
20:10:45 <ttx> markmc: exactly
20:11:14 <ttx> So I think that's the main concern raised
20:11:16 <ttx> Last week annegentle raised she wanted more details on future feature vision, and also a doc plan
20:11:40 <annegentle> ttx: most just wanted matching wiki pages to what was stated here
20:12:24 <kiall> annegentle: so, we haven't managed to find the time this week to update the wiki pages. But, is is on our todo lists.
20:12:28 <annegentle> kiall: and a doc plan can be just stating in the wiki page what docs are high priority/necessary (API docs, deployer docs)
20:12:29 <markwash> ttx: I've also heard grumbling about a lack of docs
20:12:54 <gabrielhurley> that was me
20:13:00 <markwash> gabrielhurley: quiet you
20:13:08 <gabrielhurley> :-(
20:13:21 * annegentle thanks gabrielhurley
20:13:30 <ttx> I'm starting to think this could mature a bit without starting to tap into incubation resources like release management alignment yet
20:13:33 <annegentle> grumble away dood
20:13:47 <jgriffith> ttx: think I'm agreeing with you
20:13:57 <russellb> ttx: yes, feels like more traction is needed ...
20:14:15 <annegentle> here's my sense... kiall's a good sport but others are wanting him to do their lifting?
20:14:19 <ttx> (part of that thinking is my own laziness in adding more than two projects per cycle, though, so feel free to ignore me)
20:14:31 <jd__> haha
20:14:55 <jgriffith> ttx: there's additional overhead in gating, CI, docs etc etc
20:14:56 <kiall> so, one of the things we're really looking to get from incubation is tracation, I've had conversions with a good few people who are interested in helping, but won't until it's incubated.
20:14:59 <kiall> Catch-22.
20:15:06 <russellb> kiall: why?
20:15:10 <russellb> that doesn't really make sense to me
20:15:13 <jgriffith> that's lame
20:15:13 <ttx> jokig aside, it takes time and I'm not sure we can handle more than 3 additions on the same cycle
20:15:21 <russellb> jgriffith: +1 :)
20:15:23 <kiall> russellb: so, for the most part, they are waiting for a blessed solution.
20:15:50 <jgriffith> kiall: maybe they're not going to be the best team to have.... just sayin
20:15:51 <kiall> And are not willing to commit time+resources to something they might have to replace in 6months when something else comes in.
20:15:52 <mordred> and I think by blessed, they're looking for openstack to say it wants one of these at all - I've heard that as well
20:16:20 <kiall> jgriffith: maybe :)
20:16:21 <shardy> kiall: getting community participation is a really slow process unfortunately..
20:16:25 <jgriffith> kiall: that's a reasonable point
20:16:27 <annegentle> mordred: so you have a compelling want for this feature, how would you say you get it? Incubation only? Or put it under something already "blessed"
20:16:35 <markmc> mordred, ok, well maybe the voting distinction counts then
20:16:39 <ttx> hmm, so the problem is that incubation is about maturity and our capacity to welcome and integrate more projects... but externally it's seen as a blessing necessary to grow a community
20:16:58 <markmc> mordred, i.e. the TC saying "yes, we want one of those, but not ready to incubate designate" vs "no, we don't want one of these"
20:17:00 <mordred> annegentle: I know that a cloud without a dns api is useless
20:17:00 <ttx> we could make a statement that "we want a project like that"
20:17:06 <annegentle> I think in the past to get what we want feature-wise we sometimes put it under another umbrella?
20:17:13 <mordred> annegentle: and I konw that right now we have two main public clouds with divergent dns apis
20:17:19 <mordred> because there is not an openstack api
20:17:24 <markwash> borrowing from the next discussion, I feel like I want to bless the mission of designate as a way of driving traction, without really blessing the project (for the reasons others have noted)
20:17:24 <mikal> I think if we make a statement we should support people growing designate
20:17:29 <mordred> I think that is a current failure of openstack
20:17:31 <mikal> Let's not encourage another implementation
20:17:53 <annegentle> mordred: so we want the api but don't like a particular implementation well enough to strongly encourage and invite incubation?
20:18:05 <markmcclain> can we just charter a working group of sorts?
20:18:08 <jd__> mordred: +1
20:18:10 <mordred> I'd totally vote yes for designate today
20:18:14 <gabrielhurley> it's not even the implementation per se, but that the project itself stil lfeels immature by several metrics
20:18:25 <mordred> I think there are problems, and I will not vote yes to graduation until they are sorted
20:18:31 <mordred> but, I mean, trove doesn't even use keystoneclient
20:18:37 <annegentle> gabrielhurley: yeah I feel that discomfort level too
20:18:38 <mordred> things have problems
20:18:49 <markwash> mordred: :-)
20:18:59 <jd__> mordred: there's too many things not using ksclient :)
20:19:06 <ttx> so.. we could have two steps in incubation.
20:19:13 <russellb> not using keystoneclient: wat
20:19:15 <ttx> one is a low cost blessing
20:19:27 <gabrielhurley> to be frank, I think the community drive for "we want a project like that" has been lowering the bar for incubation over the past three cycles. not that we've been bitten by it yet, but we're accepting less mature projects every time to try and keep up with what people want from their cloud.
20:19:27 <ttx> the second one starts to trigger costly resources
20:19:35 <jgriffith> mordred: but trove has 25 active contributors.... and they're not out of incubation *yet*
20:19:40 <mordred> I mean, the word incubation itself implies growing and nurturing something until it's ready
20:19:43 <jgriffith> mordred: as far as the keystone part
20:19:46 <ttx> with the first one you get blessing for a given project + time at summit
20:19:53 <mordred> jgriffith: sure!
20:19:57 <ttx> without impacting the rest of the project too much
20:20:01 <jd__> gabrielhurley: isn't incubation about maturation exactly?
20:20:23 <gabrielhurley> jd__: yes it is, but we don't incubate everyone that comes along.
20:20:37 <jgriffith> jd__: that was my intial argument, but I suppose there should be some level of interest that's evident
20:20:54 <jgriffith> by interest I mean active participation
20:20:58 <gabrielhurley> yep
20:21:17 <gabrielhurley> If kiall says that in another couple weeks there should be a big uptick in participation at HP then I'd like to wait and see that
20:21:27 <jd__> the things to keep on mind is that incubation doesn't mean graduation for the next cycle; we could have incubated things for several cycles
20:21:31 <gabrielhurley> I wanna see what happens when there are 5 or 10 people actively working on Designate
20:21:43 <jgriffith> jd__: or dropped later for that matter
20:21:44 <gabrielhurley> jd__: in theory yes, but I've yet to see that happen
20:21:47 <jd__> setting the bar too high for incubation doesn't sound right to me :(
20:22:05 <jd__> gabrielhurley: I'm pretty confident in our capacity to delay graduation
20:22:05 <kiall> jd__: yea, I think that's a good point
20:22:10 <ttx> jd__: but incubation has some cost, it's not just a label. We have to grow them into a real project and that takes qa/ci/relmgt work
20:22:10 <annegentle> I think generally incubation really is about nurturing a project and helping find good fits
20:22:16 <kiall> incubation can be > 1 cycle.
20:22:33 <ttx> kiall: yes, that's what I hinted towards with the 2 stages in incubation
20:22:43 <jd__> ttx: then remove (part of) that burden from the incubation status?
20:22:50 <annegentle> ttx: I do think we need to communicate that things can stay in incubation for a while
20:22:57 <jgriffith> This brings up the ugliness of project versus program again IMO
20:22:59 <kiall> ttx: ah, okay. re-reading with that context..
20:23:10 <ttx> I'll repeat
20:23:14 <gabrielhurley> I would certainly vote for "we want a service *like* this" to signal the community to go get involved, but at the moment I'm hestitant to vote for incubation
20:23:17 <mordred> I thnk that's waht I Was getting at with a clear set of graduation reuqirements
20:23:25 <ttx> we could have a step in the incubation when we start tapping into other groups for help
20:23:32 <mordred> like, you can stay in incubation for 5 cycles for all I care until you have met those requirements
20:23:41 <simonmcc> gabrielhurley: doesn't that suggest "like this, but not this"
20:23:44 <jd__> mordred: totally
20:23:47 <gabrielhurley> it's the resource allocation that's problematic at that point
20:24:16 <markmc> there's got to be some bar for incubation
20:24:19 <ttx> mordred: incubated projects are tapping into project resources though, so you should care
20:24:19 <gabrielhurley> simonmcc: nope, "like this, could be this if this continues to grow and improve"
20:24:21 <markmc> it doesn't need to be high
20:24:23 <jd__> incubation could be a minimal of mv stackforge/project openstack/ and try to release on time and we'll judge you on that
20:24:34 <markmc> but >1 active contributor is not much to ask
20:24:59 <gabrielhurley> yeah, I am *really* concerned about the lack of devs
20:25:00 <jd__> ttx: can't we get more resources otherwise? :)
20:25:01 <mordred> markmc: I think that's a fair ask, honestly
20:25:04 <annegentle> docs are not too much to ask either
20:25:15 <markmcclain> annegentle: +1
20:25:15 <gabrielhurley> I don't think we've *ever* accepted a project with that few (except Cinder which was split from Nova as a special case)
20:25:33 <markmc> cinder clearly had tonnes of contributors
20:25:34 <ttx> if the project needs to be incubated to grow to 2 active devs, then there is a critical mass problem at the end of the day anyway
20:25:36 <mordred> even hacking has 3 active devs :)
20:25:36 <markmc> while it was part of nova
20:25:53 <jgriffith> Yeah, Cinder did have tons of help
20:26:22 <ttx> so.. should we have some "promising technology" label to help those projects off the initial catch-22 ?
20:26:29 <jd__> mordred: nitpicking is more attractive than DNS, tell me about it
20:26:38 <CaptTofu_> a lot of it is that the project "Just Works"
20:26:42 * ttx is reluctant to bastardize incubation by making it two-step)
20:26:50 <jgriffith> like redhat's old "up and coming" or whatever it was called
20:26:56 <gabrielhurley> I hate to say it, but there's also a huge political aspect to every project in OpenStack... we mostly work for companies with huge budgets... if nobody's willing to devote a dev or two to a project then that's worrisome to me. Usually the multi-billion dollar corporations are happy to have controlling influence over a new project.
20:26:57 <ttx> Emerging Tech
20:27:02 <jd__> ttx: too complicated
20:27:25 <mordred> CaptTofu_: also makes a good point - kiall wrote a lot of designate a while ago and as I understand it, it's been working for its users, so there hasn't been a lot of pressing dev need
20:27:34 <jgriffith> I think if it went to a vote today it would be a no
20:27:37 <CaptTofu_> gabrielhurley: I can say as the tech lead, that we give Kiall complete independence
20:28:00 <gabrielhurley> If DNS were a solved problem we'd all just be using Designate already
20:28:12 <CaptTofu_> give it a try.
20:28:12 <gabrielhurley> so I don't buy the "it doesn't need more devs" argument
20:28:14 <mordred> CaptTofu_: I thnk the problem is that you're only pointing kiall at the upstream repos though
20:28:16 <markmc> CaptTofu_, uh, the tech lead of what? isn't kiall PTL?
20:28:17 <annegentle> I still can't help but think, if dns already lived under nova, then we would treat it like we did cinder with recruiting jgriffith
20:28:20 <gabrielhurley> CaptTofu_: I have ;-)
20:28:20 <CaptTofu_> I'm not saying it doesn't need more devs
20:28:29 <ttx> I'd like us to find a way to help them grow, but I'd like them to be a community before they are considered part of openstack
20:28:32 <annegentle> (I say we but I don't really know who did that exactly)
20:28:35 <CaptTofu_> markmc: of DNSaaS itself
20:28:39 <mordred> and that this week the team could not find the time to respond to annegentle's request from last week
20:28:48 <kiall> markmc: Of the HP DNS Team
20:28:51 <jgriffith> annegentle: :)  secret secret
20:28:54 <annegentle> jgriffith: hee
20:28:57 <gabrielhurley> lol
20:29:14 <ttx> mordred: tbh I don't think we can afford one-person projects within openstack, even if they are mature.
20:29:24 <mordred> ttx: yeah. fair.
20:29:28 <jgriffith> ttx: +1
20:29:30 <ttx> mordred: that sounds way too brittle for our global/virtual setup
20:29:44 <russellb> that's why i was saying it could just be a scope issue, if it's actually mature (though i'm not sure it is)
20:30:13 <ttx> mordred: that said I'd like to help them solve the catch-22 and reach critical mass.
20:30:18 <russellb> but some time is needed to work that out so that it's a sustainable project and community
20:30:20 <mikal> Could we give designate a room at the next summit for a morning and see how many people show up?
20:30:28 <gabrielhurley> there's tons of places Designate can be improved: API enhancements, DOCS!, Internationalization, etc. Even if the underlying DNSaaS code was perfect it could still use 3 or 4 more people who understand the code deeply and are willing to devote time to it.
20:30:35 <gabrielhurley> mikal: +1
20:30:46 <ttx> mikal: that's why I suggested a "promising tech" label and give them design summit time
20:30:49 <gabrielhurley> though it's in Hong Kong, so "just showing up" is tricky. ;-)
20:30:54 <markmcclain> mikal: +1
20:31:02 <annegentle> what I can't believe is one person (kiall) was willing to stand up and be the one :)
20:31:06 <simonmcc> mikal: we (designate) hosted a talk in Portland, there was a significant turnout
20:31:12 <notmyname> mikal: a popularity vote based on who can fly to HK?
20:31:30 <russellb> simonmcc: who is "we"?
20:31:38 <russellb> when only 1 person is working on it from an upstream perspective?
20:31:41 <russellb> how can it be "we" ?
20:31:43 <mikal> simonmcc: not a conf talk, a design summit session
20:31:48 <ttx> russellb: that was a conf talk
20:32:03 <mikal> notmyname: such is life I guess...
20:32:10 <russellb> ttx: k..
20:32:18 <simonmcc> russellb: HP's DNSaaS team, which I'm part of, I've been working on the deployment & supporting tools
20:32:47 <russellb> what are the supporting tools?
20:32:53 <russellb> and are they part of designate?
20:32:54 <russellb> :)
20:32:57 <jgriffith> simonmcc: internal consumption tools for HP, or for the project?
20:32:58 <simonmcc> russellb: my stuff appears out side the designate repo mostly, but is in our gh
20:33:21 <simonmcc> jgriffith: for the project, nearly everything is up on our GH
20:33:28 <jgriffith> simonmcc: link?
20:33:41 <russellb> perhaps folding more in could help gain more critical mass?
20:33:43 <CaptTofu_> my role is tech lead (the guy who goes to meetings so Kiall and Simon can code) and Database guy who worked on the db cluster setup that I'm glad to contribute however much back.
20:33:57 <russellb> CaptTofu_: so, HP roles are totally irrelevant here
20:34:03 <CaptTofu_> I know that.
20:34:04 <simonmcc> jgriffith: https://github.com/moniker-dns/ & https://github.com/simonmcc/stack-kicker
20:34:12 <shardy> how do you even maintain a community with only one reviewer who really knows the code?
20:34:19 <ttx> so options at this point include: 1. vote yes/no and see how many people view incubation as an early or a late process, 2. create a separate label for helping promising projects off the initial community step
20:34:24 <markwash> anybody from rackspace cloud dns have a perspective on designate? /me is worried about managing divisiveness and unification
20:34:26 <jgriffith> simonmcc: thx
20:34:38 <ttx> any other way forward ?
20:34:42 * markwash shoudl have brought that up on the ml :-(
20:34:47 <CaptTofu_> markwash: they are interested in designate per openstack in Portland
20:34:51 <shardy> when the community starts growing, reviews, not contributors become the big problem IME
20:35:02 <ttx> 3. wait another week and discuss that again
20:35:19 <mordred> it seems like the consensus in the channel is that we want to see more people involved
20:35:24 <markmc> ttx, I don't see the need for 2.
20:35:25 <mordred> in the code
20:35:35 <mordred> I agree with markmc
20:35:36 <jgriffith> ttx: I don't think a week would cut it IMO to be honest
20:35:39 <markmc> it's clearly obvious the TC wants a project like this and hopes designate will grow to be it
20:35:40 <russellb> mordred: yep
20:35:45 <mordred> markmc: ++
20:35:47 <markmc> and what will change in a week?
20:35:48 <markwash> markmc: +1
20:35:50 <markmc> so, 1. for me
20:35:58 <russellb> yeah, might as well vote to make it clear
20:36:03 <ekarlso> ello
20:36:04 <russellb> and then based on the outcome, can discuss next steps
20:36:06 <ttx> mordred: markmc: well, kiall says people don't participate because of the missing blessing
20:36:26 <mordred> ttx: I know. I mean, I'm still voting the way I'm voting - but I hear what people are saying
20:36:31 <markmc> ttx, we're blessing the mission of designate
20:36:33 <ekarlso> kiall isn't alone for moniker fyi
20:36:37 <jgriffith> I'd say after H2
20:36:50 <markmc> ttx, IMHO, we don't need to invent a new label to make that anymore clear
20:37:08 <ttx> markmc: label would grant some time at design summit
20:37:16 <ttx> and they could brag about it
20:37:28 <ttx> that's low cost..; if that helps them...
20:37:34 <kiall> ttx: I believe it could.
20:37:55 <markmc> we're getting labelitis :)
20:38:10 <annegentle> as the TC are we supposed to evaluate on technical merits more?
20:38:14 * ttx is a catgorization freak, you should know that by now
20:38:28 <mordred> I think it would be well withing rights for kiall  to say to people "the TC liked us, but needs us to have more contributors"
20:38:28 <markmc> ttx, I do :)
20:38:34 <mordred> based on this scrollback
20:38:40 <markmc> mordred, absolutely
20:38:50 <mordred> I don't think we need to make a label for him to be able to do that
20:38:50 <russellb> +1
20:39:04 <mordred> I will happily tweet that if it helps :)
20:39:10 <jd__> 👍
20:39:15 <annegentle> "they like us they really really like us"
20:39:22 <jgriffith> annegentle: haaha!!
20:39:29 <ttx> mordred: fair enough. And there is no point in giving design summit time if there is no more than 1-2 people involved
20:39:30 <kiall> annegentle: lol
20:39:45 <ttx> they can grab a table and get going.
20:39:48 <annegentle> kiall: happy to tweet that :)
20:39:54 <mordred> do we have any sense of a threshold kiall should shoot for before coming back?
20:40:01 <annegentle> API docs?
20:40:17 <russellb> he said more people from HP should be getting involved in a couple weeks
20:40:31 <russellb> so after that has settled in and made some impact
20:41:11 <jgriffith> russellb: ummm... and then they all go back to what they're doing currently :)
20:41:11 <markmc> I'd look for a handful of active contributors and a plausible alternate PTL
20:41:24 <russellb> jgriffith: heh
20:41:28 <ttx> does anyone still want to vote, or does "not yet, but we like the idea very much, thank you" work for everyone ?
20:41:36 <jgriffith> ttx: No thanks
20:41:43 <mordred> fine not voting
20:41:45 <simonmcc> annegentle: I'll happily take on the API docs in the next few weeks
20:41:49 <annegentle> ttx: I'm fine not voting
20:41:57 <markmcclain> ttx: fine not voting
20:42:07 <mordred> can we vote on voting?
20:42:13 <notmyname> but a vote on record would be nice to have for records
20:42:15 <jd__> mordred: raaah I was about to said that :(
20:42:19 * ttx slaps mordred with a trout
20:42:20 <annegentle> simonmcc: excellent. I had been asking at Rackspace for them to donate their API docs months ago, I can ask more if you'd want them as a starting point?
20:42:36 <jd__> can we vote on the trout then?
20:42:36 <gabrielhurley> simonmcc: API docs and much more in terms of documenting sane/best-practice configurations for the various backends. Pros/cons would be lovely.
20:42:51 <simonmcc> annegentle: please, that would be useful
20:42:55 <mordred> annegentle: also - if you could nudge people at rackspace to start working on designate ... that would probably go a long way
20:43:06 <simonmcc> gabrielhurley: bp & config - understood
20:43:07 <mordred> annegentle: because I know you have that power
20:43:09 <notmyname> I think we should vote on incubation (yes/no) and add a "signing statement" to the resulting no
20:43:10 * markmc fine with not voting too
20:43:10 <ttx> notmyname: we can post an #agree for the logs.
20:43:14 <notmyname> ttx: ok
20:43:18 <notmyname> ttx: works for me
20:43:24 <markmc> #agree not yet, but we like the idea very much, thank you
20:43:25 <ttx> unless the position is not unanimous, that is
20:43:39 <mordred> I have heard no dissent to this course of action
20:43:44 * ttx repeats as many #agree is limited to mod
20:43:45 <CaptTofu_> mordred: I'll talk to their PM
20:43:49 <ttx> maybe*
20:43:51 <markmc> ttx, oh, you don't mean we all do #agree
20:43:53 * markmc got confused
20:44:08 <ttx> I think #agree is just noted on the log
20:44:19 <russellb> #vote #agree
20:44:27 <markmc> #agree #vote
20:44:32 <ttx> actually it's #agreed.
20:44:46 <markmc> #yes #vote is #agreed
20:44:57 <markwash> #cool
20:45:02 <ttx> #agreed not yet, but we like the idea very much, thank you
20:45:21 <ttx> ^let me know if anyone thinks otherwise and would like a vote instead.
20:45:37 <ttx> otherwise we'll move to next topic
20:45:39 <gabrielhurley> #agreed
20:45:43 <russellb> #+1
20:46:02 <markmc> #hugs
20:46:04 <ttx> #topic Open discussion: Programs
20:46:06 <jd__> #trout
20:46:15 <ttx> I started the discussion (based on mordred's idea) on openstack-dev at:
20:46:20 <jgriffith> #beer
20:46:23 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-June/010821.html
20:46:30 * markmc likes the focus on programs' mission statements
20:46:33 <ttx> I think the base idea is a bit of a no-brainer, there are just a few details to flesh out before we roll
20:46:33 <markmc> nice idea
20:46:50 <annegentle> good idea mordred
20:46:52 <ttx> At this point I'm ready to draft a motion that describes what a program is, explains how to add one and officializes the first batch of them (Oslo, Infrastructure, Docs, QA)
20:46:55 <mordred> ttx: excellent email, excellent write up, and I thnk it's not too new - it's just a codifidation of sort of what we've been doing anyway
20:47:02 <mordred> ttx: ++
20:47:02 <ttx> and we can roll and adapt
20:47:13 <ttx> There is a bit of a grey area about where release management / stable branch management / vulnerability management could fit but I guess we can clear that out after the first batch.
20:47:29 <mordred> ttx: I think that's a good follow on thing, yeah
20:47:32 <ttx> In practice that first batch won't change anything for those teams... except maybe having to designate some PTL/Lead/Ambassador/Coordinator.
20:47:41 <mordred> I think we all already have one
20:47:44 <mordred> :)
20:47:45 <ttx> btw do you think we should enforce that ? I.e. include the "programs" in the Fall 2013 PTL elections round ?
20:47:59 <mikal> ttx: I think that would be a good idea
20:48:04 <mikal> It feels more "open"
20:48:08 <ttx> mikal: +1
20:48:18 <ttx> Should we run formal elections to designate the current lead ? or let the programs communicate their "natural" lead without necessarily formally organizing elections, in the same way we do initial PTLs sometimes?
20:48:24 <markmc> ttx, whether programs can release official stuff to users separately from "the integrated release", or whether the release should bring together everything is I think what I'm talking about in the thread
20:48:40 <mikal> ttx: I think the current natural leads are fine
20:48:47 <mordred> ttx: infra did an election already I believe, and have been running the core team like a core team
20:48:51 <jgriffith> ttx: Id' vote for current/interim until next election cycle
20:48:54 <annegentle> ttx: elections done the same way PTLs are where you only vote if you have a patch in a designated repo?
20:48:55 <mordred> ++
20:49:06 <markmc> where there's a natural PTL, the election is unlikely to be contested
20:49:15 <markmc> which makes it a pretty cheap checkpoint process
20:49:23 <mikal> markmc: true
20:49:24 <ttx> markmc: yeah, I think that's something we can handle as we go (what's the "product" and how that plays with programs
20:49:52 <ttx> Should we have a "release" program in the first batch ?
20:49:56 <mordred> honestly - I think a lot of this is going to be a roll-with-the-punches and not get too hidebound for the first while
20:50:09 <ttx> with relmgmt / stable maint / VMT lumped in it ?
20:50:22 <markmc> ttx, release program is a bit more meta than the others, I think
20:50:42 <ttx> I'm fine with excluding it from first batch
20:50:46 <mordred> yeah. I'm lukewarm on that - I'm not opposed, but it also seems maybe like everything-is-a-nail with this nice hammer
20:50:52 <markmc> there's a healthy stable-maint team, any reason to lump it into something else?
20:51:17 * markwash had to look up "hidebound"
20:51:24 <annegentle> ttx: mordred: I'm up for trying and re-envisioning as we go, but I worry about communicating clearly the scope for released docs...
20:51:39 <mordred> annegentle: let's brainstorm about it some over the next week
20:51:41 <ttx> not convinced those horizontal efforts really need to be a "program". I'd just like them to be /somewhere/
20:51:47 <mordred> ttx: ++
20:51:59 <ttx> because those are strategic contributions we want to encourage
20:52:03 <ttx> as I'll die some day
20:52:06 <mordred> NO
20:52:12 <russellb> unacceptable
20:52:14 <mordred> you are CLEARLY not allowed to do that
20:52:20 <annegentle> mordred: sure.
20:52:25 <mordred> #startvote should ttx be allowed to die
20:52:25 <jgriffith> NEVER
20:52:25 <openstack> Only the meeting chair may start a vote.
20:52:31 <mordred> DAMMIT
20:52:32 <ttx> :P
20:52:36 <markwash> #vote abstain
20:52:43 <markmc> ttx, release team, vuln-mgmt team, stable-maint team ... seems to work fine so far
20:52:43 <ttx> markwash: lol
20:52:46 <annegentle> #vote godforbid
20:52:48 <markwash> :-)
20:52:54 <annegentle> somebody had to godforbid that
20:53:12 <ttx> ok, so I'll draft seomthing so that the basic idea of a program is described, and the first batch as mentioned above
20:53:18 <mordred> as a related topic - sdague sent a note to the list this week about heat+diskimage-builder and the gate
20:53:31 <markwash> I have to admit, beyond the "this just makes sense" level, I'm really fascinated by programs specifically for the horizontal effort use case
20:53:33 <ttx> and we'll vote on that next week after the traditional baking on -dev
20:53:43 <mordred> does anyone have any objection with moving diskimage-builder into the openstack/ org before we formally approve programs and tripleo?
20:53:44 <markwash> b/c I desperately want to work on horizontal concerns
20:53:47 <notmyname> has the idea of just generally having "programs" been covered in the ML discussion?
20:53:53 <markwash> and have discussions in those kinds of contexts
20:54:08 <ttx> notmyname: you mean, make everything a program ?
20:54:20 <mordred> notmyname: ttx has been suggesting some iterations around that
20:54:22 <markmc> mordred, will diskimage-builder be a release deliverable? when? havana? or ... ?
20:54:27 <notmyname> ttx: ya
20:54:38 <markmc> mordred, where ttx was getting to in the thread was that openstack/ would be for release deliverables
20:54:45 <ttx> notmyname: yes, kind of. one difference is that programs don't really need incubation though.
20:54:59 <mordred> markmc: unclear. I thnk the immediate concern is that it's wanting ot be used in the gate
20:55:09 <markmc> mordred, yeah, I buy that totally
20:55:11 <ttx> notmyname: since their potential in ruining the life of other projects is so much smaller
20:55:18 <mordred> markmc: we were discussing in -infra earlier the opposite - that we'd sort of like to kill openstack-dev/ and just put everything in openstack/
20:55:29 <notmyname> ttx: hmm..ok. I'll ponder this
20:55:42 <ttx> notmyname: the thread will live for another week, anyway
20:55:44 <markmc> mordred, ah, well ... that's the opposite of what ttx was saying
20:55:50 <mordred> markmc: yup.
20:56:06 <mordred> so rigt now, things that are used in the gate but are not deliverables are in openstack-infra/ or openstack-dev/
20:56:08 <ttx> markmc: i can pass on the opportunity to have github orgs mirror our taxonomy though
20:56:09 <markmc> mordred, I'd like to flesh out the release deliverables discussion, what tripleo's mission in terms of release deliverables would be etc.
20:56:12 <ttx> it's such a mess already
20:56:31 <mordred> markmc: so you would like to hold off on heat using it in the gate until we have that sorted?
20:56:38 <markmc> mordred, no
20:56:42 <markmc> meh, I'm easy
20:56:44 <markwash> does anyone else feel like "horizontals" is a critical use case to get right, though?
20:56:48 <markmc> I was more proxying ttx's point
20:56:54 <markmc> but he's a big boy
20:57:00 <mordred> markmc: he IS a big boy
20:57:29 <ttx> markwash: yes, but no reason to hold on the first programs while we nail it
20:57:29 <mordred> I'm going to take that as a tacit "nobody but ttx, jeblair and mordred really care which thing goes in which github org"
20:57:41 <markwash> ttx: accepted
20:58:06 <mordred> and if ttx and jeblair can agree on which hole to put it in, it's probably right, yeah?
20:58:09 <markmc> mordred, well ... that wouldn't be a license to move *everything* over from stackforge either :)
20:58:18 <markmc> yeah, that
20:58:20 <mordred> markmc: note I did include ttx in there
20:58:23 <markmc> yep
20:58:42 * mordred cowers in terror of ttx and his taxonomies
20:58:43 <ttx> #action ttx to draft a motion for basic programs definition and initial batch
20:59:00 <ttx> I am vulcan. I live and die logicly
20:59:02 <jeblair> o/
20:59:04 <markmc> mordred, taxing taxonomies
20:59:31 <ttx> ok, one minute left to add a last trout reference
20:59:36 <ttx> before we close
20:59:46 <mikal> Truot
20:59:49 <mordred> wow
20:59:53 <markwash> lol
20:59:53 <mordred> well done mikal
20:59:56 <mikal> :P
20:59:59 <markmc> strong work
21:00:00 <ttx> everyone should tweet their love of designate but not just yet.
21:00:19 <ttx> #endmeeting