20:03:30 #startmeeting tc 20:03:31 Meeting started Tue Jul 28 20:03:30 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:34 The meeting name has been set to 'tc' 20:03:35 edleafe: aww :( 20:03:38 markmcclain: doh! 20:03:48 * flaper87 is back 20:03:48 Our agenda for today: 20:03:52 flaper87: maybe he'll peek in at some point 20:03:57 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:04:06 #topic Add Stackforge Namespace Retirement resolution 20:04:10 #link https://review.openstack.org/192016 20:04:15 I think we are getting nearer with the latest version of this resolution 20:04:23 No more objections from my side... anyone else ? 20:04:40 if not, review could use MOAR votes 20:04:54 ++votes 20:05:16 +R 20:05:29 2 more and we can pass it in-meeting 20:05:44 ok, so moving on? seems like votes can tally when they tally 20:05:58 * devananda lurks 20:06:09 btw, the pecan folks have decided to leave regardless of this (related to CLA issues and our platform support) 20:06:13 sure 20:06:14 it's a friendly parting 20:06:32 but we are at 7 so I guess we can approve it now 20:06:40 I guess that's a question, does everything in openstack need CLA check box? 20:06:49 sdague: pecan actually does not 20:06:52 have it now 20:06:59 jeblair: right, we never required it on stackforge 20:07:06 but it's pretty impossible to convey that to a contributor 20:07:08 approved 20:07:16 #topic Introduce the "deliverables" concept 20:07:20 jeblair: I was more thinking after the namespace is gone 20:07:24 jeblair: is it possible to activate a gerrit account without signing the cla? 20:07:24 #link https://review.openstack.org/202583 20:07:31 sdague: ack dhellmann: yes 20:07:35 I refreshed this one yesterday based on the current repository status 20:07:37 jeblair: cool! 20:07:41 jeblair: ok, cool, I never tried :-) 20:07:42 And added the related tooling changes so that it passes tests 20:07:50 So it should be ready for adoption, before it gets into further merge conflicts 20:07:59 (Note that I'll update the other changes that will get wedged by this change merging) 20:08:14 so that would be great to mertge it now before it gets out of date again, if you agree with it 20:08:23 ++ 20:08:27 * flaper87 has no objections 20:08:28 ttx: so... that seems like a giant list to be kept accurate by TC, I think my only concern is I'd like to figure out a way that we're not handling 4 updates to projects.yaml every meeting 20:09:00 more updates to projects.yaml happen off-meeting 20:09:01 I think we really only need to approve additions or removals to the list, right? 20:09:04 I'd like to make project based updates to project.yaml be single-+2A 20:09:23 lifeless: they are "one week, no objection" 20:09:24 like, what's there is fine, but I'm mostly not going to vote on random changes on project.yaml in the future 20:09:27 'neutron added a repo' isn't something we conceptually vote on 20:09:28 sdague: yeah 20:09:36 lifeless: we have to be careful, because adding repos == adding voters, and we want to make sure we're doing that appropriately 20:09:37 lifeless: you don't 20:09:38 ttx: k 20:09:55 20:09:56 Once a project has joined OpenStack, it may create additional source code repositories as needed at the discretion of its Project Team Lead (PTL) without prior approval from the TC as long as the additional source code repositories fall within the scope of the approved project mission statement. 20:10:01 lifeless: ^ http://governance.openstack.org/reference/new-projects-requirements.html 20:10:03 didn't we agree on letting some of this addition mature for a week and approve without meeting if no objections were raised ? 20:10:10 sdague: I actually handle most projects.yaml changes after letting them mature for a week unless there are objections 20:10:11 jeblair: yes, exactly 20:10:34 (as long as the PTL approves it) 20:10:35 ttx: so... can you tag all those procedural ones with ProceduralChange or something 20:10:41 jeblair: what I mean is that the land-the-metadata-change-mechanics shouldn't require multiple votes from the TC 20:10:42 so that I can filter it out of my reviews 20:10:52 sdague: tag them ? 20:10:55 jeblair: and it sounds like we've already established that 20:10:59 add a thing to the commit message 20:10:59 ttx: commit-tag 20:11:19 sdague: sure, I could do that 20:11:25 well, 202583 is worth voting on, right? we're introducing a concept? 20:11:26 ttx: cool 20:11:35 jeblair: yes 20:11:37 jeblair: yes 20:11:59 jeblair: yes, of course 20:12:01 but now there is a ton of data in there, so I wanted to make sure keeping that data fresh is more expedited in the future 20:12:06 ttx, sdague: how about a topic so it doesn't require a patchset update? 20:12:19 jeblair: that works too 20:12:21 anything I can build a gerrit filter for, I'm happy 20:12:22 jeblair: ++ 20:12:35 jeblair: something like project-update 20:12:43 mechanism unimport to me beyond that 20:12:47 or not-a-vote 20:13:09 #action ttx to pick a topic name to tag all things that don't require a formal TC vote 20:13:16 ttx: thanks 20:13:25 (a.k.a. "project list updates") 20:13:48 sdague: we already had those, there was just no way to quickly tell them apart 20:13:59 that will help with building the meeting agenda too. 20:14:04 sdague: devstack tags - how about 'internal/external' or someting ? 20:14:14 lifeless: next topic 20:14:27 ttx: yes :) 20:14:30 Since we generate a giant merge conflict with that one anyway, I propose we fast-track the alphabetical reorder 20:14:33 #link https://review.openstack.org/#/c/206460/ 20:14:44 it's a no-vote change 20:14:56 +1 20:14:58 will approve now unless someone screams BAD IDEA 20:15:00 * flaper87 voted anyway 20:15:03 doit 20:15:14 good idea. i'm pretty much just going to trust that's right. 20:15:19 ttx: it would be good to add tooling to enforce it stats alphabetic later 20:15:35 andreas did some of that for infra files 20:15:36 sdague, ttx: there's some tooling in project-config you can borrow 20:15:38 sdague: good idea 20:15:44 jeblair: yep ++ 20:16:07 #action ttx to rebase all current patches on top of his giant change 20:16:35 there might be off-governance tooling that will be caught unaware of the projects.yaml format change. Let me know if you spot any 20:16:57 there are a couple of scripts in release-tools, but I can fix those tomorrow 20:16:59 fungi: the election roll tooling will likely need an update 20:17:13 ok, next topic 20:17:14 #topic Add devstack tags 20:17:18 #link https://review.openstack.org/203785 20:17:19 thanks ttx 20:17:22 sdague: care to introduce this/these ? 20:17:53 sure, so basically it seemed useful to actually annotate what projects have facilities to come up in devstack 20:18:03 be it in the devstack tree, or via our published plugin interface 20:18:17 the whole conversation started on the mailing list earlier this month 20:18:42 I like the integration:thing-its-integrating-with 20:18:54 I think the tag(s) are pretty self explanatory, naming is a thing 20:19:13 sdague: there is the open question of the value of having seperate tags for mainline and plugin 20:19:17 yeh, integration: seems fine 20:19:36 would it be enough to just have devstack:plugin-name ? 20:19:48 instead of distinguishing between upstream/downstream 20:20:07 based on the rationale ("Knowing which components are easily brought up in [devstack] environment") I'm not sure it needs the distinction 20:20:12 flaper87: how would you tag keystone in that way? 20:20:14 so the one-tag variant is something like: "integration:devstack" says "this thing works with devstack", and if you want to know how, you can check the docs... 20:20:30 sdague: plugin-name would be whatever you use to enable it in devstack 20:20:31 I quite like that 20:20:39 do people actually ask about *how* ? 20:20:44 jeblair: I fear that it puts pressure on devstack people to get things mainline, while we push the other way around 20:20:51 flaper87: so, for nova, you don't have a single thing like that 20:21:05 ttx: oh, but "integration:devstack" applies to plugins too 20:21:09 as-in, do we negatively affect people if we don't document the plugin/included status ? 20:21:10 sdague: could we have one? AFAIK (please correct me) most projects do 20:21:14 s/we/it/ 20:21:16 honestly, specifying it's a plugin 20:21:23 is kind of useful to people 20:21:31 jeblair: right 20:21:35 but, that's from a devstack support perspective 20:21:52 and I also imagined who acks the patch is different in the 2 cases 20:22:09 because project cores should be able to ack the fact that they have a bit now 20:22:30 I kinda think we should now have a repo to keep track of devstack plugins + urls (or something like that) 20:22:43 well 20:22:43 how about one tag that means there is any form of integration, and another tag that says the integration is not built into devstack itself? 20:22:49 but that's basically what this tag is for 20:22:50 lifeless: the negative effect being what though? 20:22:52 I could go either way 20:22:57 * flaper87 just thought this through a bit better 20:23:09 maybe devstack could lookup the repo based on the name and pull it in automagically. But thats a devstack dev question. 20:23:13 annegentle: well - like sdague said 20:23:38 lifeless: it just about already does that 20:23:56 ttx: I've got to head out for a presentation... if a real time vote pops up today... dhellmann can proxy for me 20:24:07 markmcclain: ack 20:24:16 * dhellmann gets out a second keyboard 20:25:06 right, personally, I'd feel more comfortable if it was 2 tags because of the support question. Because the amount of devstack plugins exceeds the number of things in the devstack tree, and would like to prevent tears prematurely when people ask me why their opendaylight doesn't work in devstack (for instance) 20:25:25 "There's no crying in baseball!" 20:25:33 right sdague I see what you mean. 20:25:34 If we get the plugins discoverable from devstack, I don't think the extra information saying "as a plugin" is worth it 20:25:48 but they aren't todau 20:25:53 I see this as sort of parallel to the release tags, where we have a "managed" tag and several "model" tags 20:25:56 so lets refactor if/when it is 20:25:56 right, but that then means that devstack needs to maintain an authoritative registry 20:26:09 which, sort of goes against the whole big tent thing 20:26:18 sdague: well no - it could infer from the name 20:26:20 I was actually trying to push this out to the edges 20:26:23 lifeless: some times 20:26:23 sdague: if it doesn't (or won't in the near future) then I agree that "as a plugin" is valuable piece of info 20:26:26 and which is part of what this tag tries to address 20:26:28 so if there's an "integration:devstack" tag to indicate support at all, and then a "devstack:external-plugin" tag to indicate that the code doesn't live in devstack, I think we'd express everything 20:26:34 i'm just thinking back to the "tags replacing docs" thing, and documenting the specific mechanism you use to devstack something seems to have crossed the line from "new user browsing the software site" to "deployer actually trying to run commands" 20:26:41 I think it's a valuable info now 20:26:47 it might not be needed anymore in the future 20:26:54 jeblair: maybe 20:27:02 jeblair: yeah 20:27:04 *a lot* of people bring up devstack to test things 20:27:21 it's actually the first experience a lot of users have with openstack 20:27:32 jeblair: maybe "there is a way to run in devstack" is enough as far as tags are concerned 20:28:03 ttx and then when they ask "and that way is... " 20:28:06 where do they go? 20:28:20 does devstack integration indicate any test integration? 20:28:30 sdague: if they don't find it mainline, they look for a plugin? 20:28:39 ttx: and how do they look for that? 20:28:40 the thing is that even when the 'as-plugin' info, they won't know exactly 20:28:47 ttx: I'm not sure new users would know about plugins as a thing 20:28:47 annegentle: hopefully? most of the projects with plugins should run devstack tests on them 20:28:48 because there are plugins outside repos anyway 20:28:54 sdague: devstack:as-plugin doesn't exactly point to a repo either 20:28:55 I mean, devstack plugins in their own repos 20:29:03 ttx: yes it does, it's the repo that's tagged 20:29:07 jeblair: ok 20:29:11 sdague: if I was looking, frankly I would look at the devstack docs, so I wonder if there should just be a registry there 20:29:35 sdague: is it ? 20:29:38 ttx: yes 20:29:41 dhellmann: sdague: you could also look at the tag list and say, "Oh, I should work on devstack integration" 20:29:46 sorry if that wasn't clear 20:29:53 I'm not sure it's any more of a burden to keep the docs up to date than the governance list 20:29:53 * ttx reads deeper 20:29:54 sdague: how would that tag work for https://github.com/openstack/devstack-plugin-zmq ? 20:30:00 * flaper87 confused now 20:30:00 I'm so knee deep in this, I forget what people don't know 20:30:15 annegentle: yeah, that's why I think it's useful to have an integration:devstack tag 20:30:39 like openstack/trove => integration:devstack-plugin 20:30:44 sdague: we just approved a patch that moved tags from repos to deliverables 20:31:08 sdague: ok, I thought they might live in a specific repo, but if they are always bundled with the code... that works 20:31:23 how would that tag work for https://github.com/openstack/devstack-plugin-zmq ? 20:31:24 ttx: they can also live off in other repos 20:31:27 sdague: is that always true? I thought the oslo.messaging stuff ended up in its own repository? 20:31:29 so is each neutron aas plugined separately? 20:31:38 flaper87: right, that 20:31:39 lifeless: yes, they will be 20:31:49 sdague: then the tag applies to the devstack plugin ? or the code that has devstack integration ? 20:31:51 so this tag is going to be repo then, not deliverable 20:31:53 oslo.messaging has several drivers and plugins for each 20:32:00 these plugins live outside the repo 20:32:08 lifeless: there are no such things anymore 20:32:08 and there's also an in-repo plugin, IIRC 20:32:12 ttx: and yet 20:32:38 so, for stuff that lives outside the repo, I don't know. I was thinking about this in terms of "I want to use designate, does it come up"? 20:32:59 lifeless: hence my question, I think the "has devstack integration" tag should apply to the thing that has devstack integration, which may be multiple repos 20:33:14 not to the thing that contains devstack plugin code 20:33:16 I understand that we need a registry of where those plugins are, but I'm starting to doubt that the governance project list is that registry. 20:33:34 I'd say, lets just say it has support for devstack for now and forget about the plugin bit until we find a good solution for that 20:33:41 I like integration:devstack for the deliverable, and then more details in the deliverable docs or the devstack docs (or both) 20:33:44 flaper87: ++ 20:33:50 flaper87: ++ 20:33:50 sounds like a good first step anyway 20:33:55 ttx: but neutron having devstack integration doesn't mean that all the aas's are enabled 20:33:58 for instance 20:34:11 so I guess I'm wondering if thats going to mislead 20:34:15 ok, I'm fine just tagging the devstack in tree bits 20:34:23 lifeless: right, figuring out how to express that is more than a tag 20:34:23 that's a step 1 20:34:27 lifeless: they should, otherwise publishing them as a single "thing" may be confusing anyway 20:34:35 sdague: no, I think we want a tag that says "has some devstack integration" and does not distinguish here 20:34:43 dhellmann: ++ 20:34:46 ok, well I don't want that 20:34:55 because of support issues 20:34:57 ttx: should doesn't make it actually happen though 20:35:13 so its seeming to me that either we need to bring back per repo tags 20:35:30 lifeless: we could say the tag doesn't apply if only part of the deliverable gets devstack-integrated 20:35:32 sdague: can that not be solved by documentation within devstack itself? 20:35:32 or find some other way of communicating what (I think) sdague wants to communicate 20:35:47 sdague: i.e., list what is in tree, and describe how to find the out-of-tree stuff 20:36:20 without making an exhaustive list ("look for a directory named foo" or "look at the contributor docs for the project") 20:36:27 dhellmann: that then implies that it is the role of the devstack team to categorize the universe, vs. the project registry to be a place for information about that to be stored 20:36:44 sdague: no, you only have to list the things you support in your tree, which you could do automatically 20:36:51 sdague: just tell people what's in-tree 20:36:55 hrm, that means maybe we should remove the vulnerability:managed tag from, e.g., the neutron deliverable. it was applied to the openstack/neutron repo previously but not the other repos which just got glommed on today 20:36:59 sdague: is it possible to write an oracle that takes git tree in and returns 'has devstack plugin:TRUE|FALSE' ? 20:37:04 yeah, i also don't think that only tagging things in devstack is a good idea -- it could increase pressure (and of all the things we have discussed, that's the thing that could be _most_ served by a devstack-maintained list) 20:37:04 each project should do its best to let others know where to find the devstack plugin 20:37:05 and then give general guidance for how to find the other stuff by directing them to ask the project team 20:37:29 if I need a plugin for X, I'd probably look in devstack -> project repo -> wherever the project repo tells me to go 20:37:32 fungi: maybe the -*aas should be split if they are so different 20:37:35 sort of sad i missed the implication of the deliverables discussion now 20:37:37 lifeless: I could probably 20:37:45 that's something that the 'is-plugin' bit doesn't fix anyway 20:37:57 lifeless: to a 95% accuracy at least 20:37:58 sdague: so I'm wondering if something could take teh repo list in, scan all the repos, and provide data back to governance (or wherever) automatically 20:38:06 sure 20:38:07 fungi: technically they were once in openstack/neutron and got split though 20:38:08 well, thinking in terms of "tag only applies to a deliverable if all repos within the deliverable are covered" suggestion 20:38:21 lifeless: there are plugins outside repos that wouldn't be listed 20:38:21 ttx, fungi: i think the model is good; we probably need to reconcile whether we fix this by supporting more repos or saying that "neutron" isn't supported because it's so complex 20:38:26 unless they use submodules 20:38:32 but similar concerns as qa will have with devstack support i think 20:38:37 or some sort of agreed listing model 20:38:44 jeblair: yeah that's the concern, complexity drowning 20:38:47 right, qa will not support vpnaas 20:38:52 flaper87: would they be able to move to being in repos? 20:38:55 but does support neutron 20:39:02 if that is not an expressible thing 20:39:06 that's kind of problematic 20:39:18 lifeless: in some cases, maybe. In other cases, it's unlike (vendor specific plugins) 20:39:20 sdague: it is if we split neutron-*aas from the neutron deliverable 20:39:33 I guess I also missed this issue on the deliverable side 20:39:34 sdague: since it looks like it's a different "thing" 20:39:35 i think our side-track is getting side-tracked 20:39:53 yep 20:39:54 jeblair: lol 20:40:00 jeblair: sure, but I think this is part of the confusion about what kind of information shows up here 20:40:03 OK, I suggest we give it some thought and comment on the review 20:40:04 ok, I think this need more work/discussion 20:40:08 agreed 20:40:10 I'll comment on the review with my thoughts 20:40:14 lets move on 20:40:16 flaper87: vendor specific plugin wouldn't be in vendor specific codebase? 20:40:21 because things like upgrade modes get impacted as well 20:40:23 no point is running for 10 more minutes in circles 20:40:27 * zaneb was bout to comment but will take it to the review 20:40:28 well, applicability of previously per-repo tags is coming into question, so seems on-topic to the devstack tag discussion 20:40:48 but agreed probably better in review 20:40:58 #topic Add and apply guidelines for project and service names 20:41:00 yeh, we can collect there, figure out what questions to ask for next week 20:41:06 #link https://review.openstack.org/201160 20:41:07 lifeless: yes but they are still plugins that I might want to use and therefore I'd like to find easily. An automated tool would ignore those plugins. For example: https://github.com/openstack/devstack-plugin-zmq 20:41:08 #link https://review.openstack.org/201670 20:41:13 annegentle: where are we now with this one ? 20:41:14 * flaper87 stays on topic 20:41:25 I'll have to rebase after the alphabetization 20:41:39 but I updated today with the key management v key manager update 20:41:58 docs team is informed. 20:42:04 that's about it 20:42:13 flaper87: that looks like it would be discovered actually 20:42:31 annegentle: I'm still a little worried that the zaqar description is too terse, but we can iterate on that separately 20:42:40 lifeless: ah ok, lets talk about it offline (or in 2 days :P) 20:42:50 flaper87:kk 20:42:50 annegentle: specifically, differentiating zaqar and cue 20:42:51 dhellmann: yeah I get it. 20:42:58 dhellmann: yeah, I was worried about that as well but I didn't comment because that would require changing cue as well 20:43:03 and probably other projects 20:43:04 dhellmann: ayup 20:43:06 unfortunately, I don't have a constructive suggestion right now :-/ 20:43:20 I was thinking to propose a follow up patch with a better descriptio 20:43:22 description 20:43:27 flaper87: do the rules generally work except for messaging queues? 20:43:29 one for each project so we can track the change 20:43:36 flaper87: sure 20:44:16 any other naming concerns? 20:44:23 annegentle: If we all imagine there's 'Service' at the end, I believe it does. Otherwise, it's a bit terse for every project. 20:44:24 'Governance' 20:44:38 my main worry right now is that Message and Message broker will cause confusion 20:44:38 just because http://governance.openstack.org/ 20:44:40 sdague: yeah that one is pretty bad 20:44:45 flaper87: yeah the idea is to add service everywhere. 20:44:49 sdague: yeah 20:44:53 which, you know, is in no way related 20:45:14 sdague: maybe we can get the congress team to review the minor projects.yaml changes? 20:45:21 yeah, actually, i'm pretty sure the TC is reposnsible for implementing governance as a service 20:45:24 Delta faucets, Delta airlines 20:45:48 annegentle: note that you needed 2 words to differentiate those companies :-) 20:45:49 Gaas 20:45:52 :) 20:46:59 so.. let's accumulate reviews and patchset on that one ? 20:47:08 ttx: yep, I'll rebase and keep asking people to take a look 20:47:17 #topic Add a release model for all projects 20:47:22 #link https://review.openstack.org/201724 20:47:26 We are still gathering information on this one 20:47:31 dhellmann: Starting to wonder if smaller incremental patches would not lead to faster improvements there 20:47:39 not sure we have anything TC to discuss about it 20:47:47 ttx: yeah, I'll split that up next week 20:47:51 cool 20:47:55 #topic Diversity script improvements 20:48:01 We have two improvements around the diversity script 20:48:03 #link https://review.openstack.org/204372 20:48:05 #link https://review.openstack.org/204770 20:48:08 I propose to approve those "code" reviews once they get two rollcall+1 votes 20:48:19 since they are not governance either 20:48:30 ++ 20:48:41 and not spend meeting time on them 20:48:55 #topic Workgroup reports 20:48:59 * Project team guide 20:49:04 So we have almost everything we need to publish in 20:49:09 Only missing the open development chapter 20:49:10 I swear I'll get my part done 20:49:17 I'll do it on my flight tomorrow 20:49:23 and plublish it 20:49:31 flaper87: sounds good -- post what you have 20:49:32 * flaper87 is so ashamed 20:49:38 jeblair: will you be working on the publication jobs ? Maybe you have already and I missed them 20:49:45 ttx: i will 20:49:52 jeblair: thx! 20:49:54 * Next-tags 20:49:55 ttx: i'm currently hiding behind flaper87. ;) 20:50:00 Team will gradually post new tags over the coming weeks. 20:50:05 The devstack tags proposed by sdague are an early manifestation of that 20:50:09 * flaper87 starts jumping 20:50:12 sdague is just faster than us slackers 20:50:24 * Communications 20:50:30 annegentle, flaper87: maybe we should include this TC in the next blog post ? 20:50:36 yeah 20:50:43 i.e. the conclusion of the stackforge thing 20:50:48 and do a single post 20:50:53 the stackforge thing is important 20:50:54 sure, next week ok? 20:51:10 well, next week we might have more to post :) 20:51:27 flaper87: the stackforge thing might be worth a separate post entirely 20:51:29 release early, release often! 20:51:40 yeah, I'm thinking stackforge is a separate post, not a highlights one 20:51:46 dhellmann: not sure 20:51:54 I can think of questions about it that someone could answer for the post 20:51:56 annegentle: the change is a technical one, not a governance one 20:52:03 we can make a longer post this time that gives enough information about stackforge 20:52:19 I'm not sure we need to make a separate post... we just rename repos 20:52:35 * dhellmann shrugs 20:52:41 How will I be notified of the move? What's the timeline for renames? What if no one is maintainer, what happens? 20:52:44 i don't want people to start making up their own idea of what "moving under openstack namespace" means 20:53:05 (I have a no-one-is-maintainer repo in there) 20:53:17 I tried explaining this to people. They are confused about it 20:53:23 annegentle: i expect the infra team to come up with a plan that addresses that 20:53:37 jeblair: I think that a blog post should be part of that comm plan 20:53:39 I tried explaining this to people. They are confused about it 20:53:43 annegentle: ++ 20:53:48 ugh 20:53:54 edleafe: heh 20:54:03 annegentle: I guess as long as the post clearly says it's just a repo rename, it's not "moving all of Stackforge into OpenStack" that's good 20:54:07 typing in two windows == bad 20:54:13 ttx: ++ 20:54:26 I have enough big-tent haters sending me things 20:54:32 ttx: orly? 20:54:35 we have a nice shiny yaml file to point to as the list of official projects 20:54:54 lifeless: it's more of a "hit me at conference about how much the whole idea sucks" kind of thing 20:54:57 I really don't understand big-tent haters 20:55:17 ttx: totes 20:55:20 so, do you think we need a highlights post this week or is next ok? 20:55:29 zaneb: it's mostly that they don't get it, but misinformed people / press will make headlines out of small things 20:55:51 yeah, I know 20:56:07 but how hard can it be to just ignore the parts you don't care about? 20:56:13 it's a less informed version of the same pov that wanted a starter kit. If openstack is 100 projects, people feel intimidated about where to start 20:56:29 hopefully compute starter kit helps offset that 20:56:34 yep, fear of getting lost 20:56:40 zaneb: some felt that incubation meant better quality 20:56:52 zaneb: and we know that wasn't always true 20:57:01 edleafe: + 20:57:03