20:02:05 #startmeeting tc 20:02:06 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:09 The meeting name has been set to 'tc' 20:02:19 Agenda for today is at: 20:02:23 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:33 #topic Incubation request for Designate: final discussion and vote 20:02:41 #link http://lists.openstack.org/pipermail/openstack-tc/2013-June/000266.html 20:02:48 #link https://wiki.openstack.org/wiki/Designate_Incubation_Application 20:02:56 There wasn't a lot of discussion this week on the ML... 20:03:05 I don't know if that means we are all fine with voting or we should wait another week :) 20:03:28 kiall: around ? 20:03:34 ttx: hiya 20:03:45 * jd__ fine with voting 20:03:51 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 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 because like mordred said, these projects sit in places where they can either help or kill interop 20:04:43 The fact that the project relies on very few people was also noted as a bit concerning 20:04:56 Like kiall did 87% of the commits! And only 4 people did more than 1 commit. 20:05:00 * CaptTofu_ o 20:05:25 is that a risk ? do we care ? 20:05:30 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 do we care for incubation, or only for graduation ? 20:05:45 Isn't incubation about giving a chance to address those concerns? 20:05:46 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 incubation, i'm afraid, personally 20:05:51 what mikal said 20:05:52 * markmc cares for incubation 20:06:14 as in, I'd like to make specific statements about outcomes expected for graduation 20:06:21 caring for incubation remove a bit of usefulness from incubation IMHO 20:06:23 not a "no, never", but like ... "build a bit more and come back" 20:06:23 mordred: +1 20:06:33 mordred: +1 from us on that 20:06:40 jd__: how do you mean? 20:06:43 jd__: ++ 20:06:47 I think incubation is great to help grow a community to critical mass 20:07:02 markmc: +1 20:07:03 but there should be more than one just one person working on a project before incubation 20:07:08 I thnkn we saw that with heat - it was very redhat-centric, then grew more people in incubation 20:07:19 markmc: I don't know if I agree with that part necessarily :) 20:07:21 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 mordred: but several people 20:07:35 jd__: ahh... got ya thanks 20:07:47 the bus factor is a bit of a concern to me 20:07:51 mordred, heat had several leaders, not even just contributor 20:07:53 cinder was '1' for a good bit 20:07:55 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 markmc: +1, although tbh heat has only really seen a significant increase in community participation since graduating from incubation... 20:08:05 I'm with markmc, that incubation should help people get more participants 20:08:16 ttx: I'm ok for the bus factor for graduation, but for incubation… 20:08:17 jgriffith: it piggy-backed on nova's team though 20:08:43 ttx: sure, but... if it goes incubation that's the point right? 20:08:44 we certainly need more people using the project 20:08:48 ttx: see if it can stand on it's own or not 20:08:49 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 annegentle: actually I think you're with mordred :) 20:09:13 only 1 dev may also be a sign that the scope is too small and should be reconsidered 20:09:20 mordred: so far, we've been focused on getting things going for HP Cloud DNS. (Due to go GA next week) 20:09:49 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 markmc: good point. 20:10:09 sure. Both would count as "no" though :) 20:10:22 ok, fair 20:10:25 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 markmc: options for essentially a −1 and −2? 20:10:35 ttx: but one's a *nice* no :) 20:10:36 I guess no-one is really saying "no, not ever" anyway 20:10:45 markmc: exactly 20:11:14 So I think that's the main concern raised 20:11:16 Last week annegentle raised she wanted more details on future feature vision, and also a doc plan 20:11:40 ttx: most just wanted matching wiki pages to what was stated here 20:12:24 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 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 ttx: I've also heard grumbling about a lack of docs 20:12:54 that was me 20:13:00 gabrielhurley: quiet you 20:13:08 :-( 20:13:21 * annegentle thanks gabrielhurley 20:13:30 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 grumble away dood 20:13:47 ttx: think I'm agreeing with you 20:13:57 ttx: yes, feels like more traction is needed ... 20:14:15 here's my sense... kiall's a good sport but others are wanting him to do their lifting? 20:14:19 (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 haha 20:14:55 ttx: there's additional overhead in gating, CI, docs etc etc 20:14:56 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 Catch-22. 20:15:06 kiall: why? 20:15:10 that doesn't really make sense to me 20:15:13 that's lame 20:15:13 jokig aside, it takes time and I'm not sure we can handle more than 3 additions on the same cycle 20:15:21 jgriffith: +1 :) 20:15:23 russellb: so, for the most part, they are waiting for a blessed solution. 20:15:50 kiall: maybe they're not going to be the best team to have.... just sayin 20:15:51 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 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 jgriffith: maybe :) 20:16:21 kiall: getting community participation is a really slow process unfortunately.. 20:16:25 kiall: that's a reasonable point 20:16:27 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 mordred, ok, well maybe the voting distinction counts then 20:16:39 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 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 annegentle: I know that a cloud without a dns api is useless 20:17:00 we could make a statement that "we want a project like that" 20:17:06 I think in the past to get what we want feature-wise we sometimes put it under another umbrella? 20:17:13 annegentle: and I konw that right now we have two main public clouds with divergent dns apis 20:17:19 because there is not an openstack api 20:17:24 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 I think if we make a statement we should support people growing designate 20:17:29 I think that is a current failure of openstack 20:17:31 Let's not encourage another implementation 20:17:53 mordred: so we want the api but don't like a particular implementation well enough to strongly encourage and invite incubation? 20:18:05 can we just charter a working group of sorts? 20:18:08 mordred: +1 20:18:10 I'd totally vote yes for designate today 20:18:14 it's not even the implementation per se, but that the project itself stil lfeels immature by several metrics 20:18:25 I think there are problems, and I will not vote yes to graduation until they are sorted 20:18:31 but, I mean, trove doesn't even use keystoneclient 20:18:37 gabrielhurley: yeah I feel that discomfort level too 20:18:38 things have problems 20:18:49 mordred: :-) 20:18:59 mordred: there's too many things not using ksclient :) 20:19:06 so.. we could have two steps in incubation. 20:19:13 not using keystoneclient: wat 20:19:15 one is a low cost blessing 20:19:27 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 the second one starts to trigger costly resources 20:19:35 mordred: but trove has 25 active contributors.... and they're not out of incubation *yet* 20:19:40 I mean, the word incubation itself implies growing and nurturing something until it's ready 20:19:43 mordred: as far as the keystone part 20:19:46 with the first one you get blessing for a given project + time at summit 20:19:53 jgriffith: sure! 20:19:57 without impacting the rest of the project too much 20:20:01 gabrielhurley: isn't incubation about maturation exactly? 20:20:23 jd__: yes it is, but we don't incubate everyone that comes along. 20:20:37 jd__: that was my intial argument, but I suppose there should be some level of interest that's evident 20:20:54 by interest I mean active participation 20:20:58 yep 20:21:17 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 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 I wanna see what happens when there are 5 or 10 people actively working on Designate 20:21:43 jd__: or dropped later for that matter 20:21:44 jd__: in theory yes, but I've yet to see that happen 20:21:47 setting the bar too high for incubation doesn't sound right to me :( 20:22:05 gabrielhurley: I'm pretty confident in our capacity to delay graduation 20:22:05 jd__: yea, I think that's a good point 20:22:10 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 I think generally incubation really is about nurturing a project and helping find good fits 20:22:16 incubation can be > 1 cycle. 20:22:33 kiall: yes, that's what I hinted towards with the 2 stages in incubation 20:22:43 ttx: then remove (part of) that burden from the incubation status? 20:22:50 ttx: I do think we need to communicate that things can stay in incubation for a while 20:22:57 This brings up the ugliness of project versus program again IMO 20:22:59 ttx: ah, okay. re-reading with that context.. 20:23:10 I'll repeat 20:23:14 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 I thnk that's waht I Was getting at with a clear set of graduation reuqirements 20:23:25 we could have a step in the incubation when we start tapping into other groups for help 20:23:32 like, you can stay in incubation for 5 cycles for all I care until you have met those requirements 20:23:41 gabrielhurley: doesn't that suggest "like this, but not this" 20:23:44 mordred: totally 20:23:47 it's the resource allocation that's problematic at that point 20:24:16 there's got to be some bar for incubation 20:24:19 mordred: incubated projects are tapping into project resources though, so you should care 20:24:19 simonmcc: nope, "like this, could be this if this continues to grow and improve" 20:24:21 it doesn't need to be high 20:24:23 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 but >1 active contributor is not much to ask 20:24:59 yeah, I am *really* concerned about the lack of devs 20:25:00 ttx: can't we get more resources otherwise? :) 20:25:01 markmc: I think that's a fair ask, honestly 20:25:04 docs are not too much to ask either 20:25:15 annegentle: +1 20:25:15 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 cinder clearly had tonnes of contributors 20:25:34 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 even hacking has 3 active devs :) 20:25:36 while it was part of nova 20:25:53 Yeah, Cinder did have tons of help 20:26:22 so.. should we have some "promising technology" label to help those projects off the initial catch-22 ? 20:26:29 mordred: nitpicking is more attractive than DNS, tell me about it 20:26:38 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 like redhat's old "up and coming" or whatever it was called 20:26:56 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 Emerging Tech 20:27:02 ttx: too complicated 20:27:25 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 I think if it went to a vote today it would be a no 20:27:37 gabrielhurley: I can say as the tech lead, that we give Kiall complete independence 20:28:00 If DNS were a solved problem we'd all just be using Designate already 20:28:12 give it a try. 20:28:12 so I don't buy the "it doesn't need more devs" argument 20:28:14 CaptTofu_: I thnk the problem is that you're only pointing kiall at the upstream repos though 20:28:16 CaptTofu_, uh, the tech lead of what? isn't kiall PTL? 20:28:17 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 CaptTofu_: I have ;-) 20:28:20 I'm not saying it doesn't need more devs 20:28:29 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 (I say we but I don't really know who did that exactly) 20:28:35 markmc: of DNSaaS itself 20:28:39 and that this week the team could not find the time to respond to annegentle's request from last week 20:28:48 markmc: Of the HP DNS Team 20:28:51 annegentle: :) secret secret 20:28:54 jgriffith: hee 20:28:57 lol 20:29:14 mordred: tbh I don't think we can afford one-person projects within openstack, even if they are mature. 20:29:24 ttx: yeah. fair. 20:29:28 ttx: +1 20:29:30 mordred: that sounds way too brittle for our global/virtual setup 20:29:44 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 mordred: that said I'd like to help them solve the catch-22 and reach critical mass. 20:30:18 but some time is needed to work that out so that it's a sustainable project and community 20:30:20 Could we give designate a room at the next summit for a morning and see how many people show up? 20:30:28 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 mikal: +1 20:30:46 mikal: that's why I suggested a "promising tech" label and give them design summit time 20:30:49 though it's in Hong Kong, so "just showing up" is tricky. ;-) 20:30:54 mikal: +1 20:31:02 what I can't believe is one person (kiall) was willing to stand up and be the one :) 20:31:06 mikal: we (designate) hosted a talk in Portland, there was a significant turnout 20:31:12 mikal: a popularity vote based on who can fly to HK? 20:31:30 simonmcc: who is "we"? 20:31:38 when only 1 person is working on it from an upstream perspective? 20:31:41 how can it be "we" ? 20:31:43 simonmcc: not a conf talk, a design summit session 20:31:48 russellb: that was a conf talk 20:32:03 notmyname: such is life I guess... 20:32:10 ttx: k.. 20:32:18 russellb: HP's DNSaaS team, which I'm part of, I've been working on the deployment & supporting tools 20:32:47 what are the supporting tools? 20:32:53 and are they part of designate? 20:32:54 :) 20:32:57 simonmcc: internal consumption tools for HP, or for the project? 20:32:58 russellb: my stuff appears out side the designate repo mostly, but is in our gh 20:33:21 jgriffith: for the project, nearly everything is up on our GH 20:33:28 simonmcc: link? 20:33:41 perhaps folding more in could help gain more critical mass? 20:33:43 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 CaptTofu_: so, HP roles are totally irrelevant here 20:34:03 I know that. 20:34:04 jgriffith: https://github.com/moniker-dns/ & https://github.com/simonmcc/stack-kicker 20:34:12 how do you even maintain a community with only one reviewer who really knows the code? 20:34:19 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 anybody from rackspace cloud dns have a perspective on designate? /me is worried about managing divisiveness and unification 20:34:26 simonmcc: thx 20:34:38 any other way forward ? 20:34:42 * markwash shoudl have brought that up on the ml :-( 20:34:47 markwash: they are interested in designate per openstack in Portland 20:34:51 when the community starts growing, reviews, not contributors become the big problem IME 20:35:02 3. wait another week and discuss that again 20:35:19 it seems like the consensus in the channel is that we want to see more people involved 20:35:24 ttx, I don't see the need for 2. 20:35:25 in the code 20:35:35 I agree with markmc 20:35:36 ttx: I don't think a week would cut it IMO to be honest 20:35:39 it's clearly obvious the TC wants a project like this and hopes designate will grow to be it 20:35:40 mordred: yep 20:35:45 markmc: ++ 20:35:47 and what will change in a week? 20:35:48 markmc: +1 20:35:50 so, 1. for me 20:35:58 yeah, might as well vote to make it clear 20:36:03 ello 20:36:04 and then based on the outcome, can discuss next steps 20:36:06 mordred: markmc: well, kiall says people don't participate because of the missing blessing 20:36:26 ttx: I know. I mean, I'm still voting the way I'm voting - but I hear what people are saying 20:36:31 ttx, we're blessing the mission of designate 20:36:33 kiall isn't alone for moniker fyi 20:36:37 I'd say after H2 20:36:50 ttx, IMHO, we don't need to invent a new label to make that anymore clear 20:37:08 markmc: label would grant some time at design summit 20:37:16 and they could brag about it 20:37:28 that's low cost..; if that helps them... 20:37:34 ttx: I believe it could. 20:37:55 we're getting labelitis :) 20:38:10 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 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 ttx, I do :) 20:38:34 based on this scrollback 20:38:40 mordred, absolutely 20:38:50 I don't think we need to make a label for him to be able to do that 20:38:50 +1 20:39:04 I will happily tweet that if it helps :) 20:39:10 👍 20:39:15 "they like us they really really like us" 20:39:22 annegentle: haaha!! 20:39:29 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 annegentle: lol 20:39:45 they can grab a table and get going. 20:39:48 kiall: happy to tweet that :) 20:39:54 do we have any sense of a threshold kiall should shoot for before coming back? 20:40:01 API docs? 20:40:17 he said more people from HP should be getting involved in a couple weeks 20:40:31 so after that has settled in and made some impact 20:41:11 russellb: ummm... and then they all go back to what they're doing currently :) 20:41:11 I'd look for a handful of active contributors and a plausible alternate PTL 20:41:24 jgriffith: heh 20:41:28 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 ttx: No thanks 20:41:43 fine not voting 20:41:45 annegentle: I'll happily take on the API docs in the next few weeks 20:41:49 ttx: I'm fine not voting 20:41:57 ttx: fine not voting 20:42:07 can we vote on voting? 20:42:13 but a vote on record would be nice to have for records 20:42:15 mordred: raaah I was about to said that :( 20:42:19 * ttx slaps mordred with a trout 20:42:20 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 can we vote on the trout then? 20:42:36 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 annegentle: please, that would be useful 20:42:55 annegentle: also - if you could nudge people at rackspace to start working on designate ... that would probably go a long way 20:43:06 gabrielhurley: bp & config - understood 20:43:07 annegentle: because I know you have that power 20:43:09 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 notmyname: we can post an #agree for the logs. 20:43:14 ttx: ok 20:43:18 ttx: works for me 20:43:24 #agree not yet, but we like the idea very much, thank you 20:43:25 unless the position is not unanimous, that is 20:43:39 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 mordred: I'll talk to their PM 20:43:49 maybe* 20:43:51 ttx, oh, you don't mean we all do #agree 20:43:53 * markmc got confused 20:44:08 I think #agree is just noted on the log 20:44:19 #vote #agree 20:44:27 #agree #vote 20:44:32 actually it's #agreed. 20:44:46 #yes #vote is #agreed 20:44:57 #cool 20:45:02 #agreed not yet, but we like the idea very much, thank you 20:45:21 ^let me know if anyone thinks otherwise and would like a vote instead. 20:45:37 otherwise we'll move to next topic 20:45:39 #agreed 20:45:43 #+1 20:46:02 #hugs 20:46:04 #topic Open discussion: Programs 20:46:06 #trout 20:46:15 I started the discussion (based on mordred's idea) on openstack-dev at: 20:46:20 #beer 20:46:23 #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 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 nice idea 20:46:50 good idea mordred 20:46:52 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 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 ttx: ++ 20:47:02 and we can roll and adapt 20:47:13 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 ttx: I think that's a good follow on thing, yeah 20:47:32 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 I think we all already have one 20:47:44 :) 20:47:45 btw do you think we should enforce that ? I.e. include the "programs" in the Fall 2013 PTL elections round ? 20:47:59 ttx: I think that would be a good idea 20:48:04 It feels more "open" 20:48:08 mikal: +1 20:48:18 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 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 ttx: I think the current natural leads are fine 20:48:47 ttx: infra did an election already I believe, and have been running the core team like a core team 20:48:51 ttx: Id' vote for current/interim until next election cycle 20:48:54 ttx: elections done the same way PTLs are where you only vote if you have a patch in a designated repo? 20:48:55 ++ 20:49:06 where there's a natural PTL, the election is unlikely to be contested 20:49:15 which makes it a pretty cheap checkpoint process 20:49:23 markmc: true 20:49:24 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 Should we have a "release" program in the first batch ? 20:49:56 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 with relmgmt / stable maint / VMT lumped in it ? 20:50:22 ttx, release program is a bit more meta than the others, I think 20:50:42 I'm fine with excluding it from first batch 20:50:46 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 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 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 annegentle: let's brainstorm about it some over the next week 20:51:41 not convinced those horizontal efforts really need to be a "program". I'd just like them to be /somewhere/ 20:51:47 ttx: ++ 20:51:59 because those are strategic contributions we want to encourage 20:52:03 as I'll die some day 20:52:06 NO 20:52:12 unacceptable 20:52:14 you are CLEARLY not allowed to do that 20:52:20 mordred: sure. 20:52:25 #startvote should ttx be allowed to die 20:52:25 NEVER 20:52:25 Only the meeting chair may start a vote. 20:52:31 DAMMIT 20:52:32 :P 20:52:36 #vote abstain 20:52:43 ttx, release team, vuln-mgmt team, stable-maint team ... seems to work fine so far 20:52:43 markwash: lol 20:52:46 #vote godforbid 20:52:48 :-) 20:52:54 somebody had to godforbid that 20:53:12 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 as a related topic - sdague sent a note to the list this week about heat+diskimage-builder and the gate 20:53:31 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 and we'll vote on that next week after the traditional baking on -dev 20:53:43 does anyone have any objection with moving diskimage-builder into the openstack/ org before we formally approve programs and tripleo? 20:53:44 b/c I desperately want to work on horizontal concerns 20:53:47 has the idea of just generally having "programs" been covered in the ML discussion? 20:53:53 and have discussions in those kinds of contexts 20:54:08 notmyname: you mean, make everything a program ? 20:54:20