20:01:37 #startmeeting tc 20:01:38 Meeting started Tue Sep 8 20:01:37 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:42 The meeting name has been set to 'tc' 20:01:46 * rockyg is shaking jaypipes' hand 20:01:52 Agenda for this Technical committee meeting lives at: 20:01:57 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:07 #topic Adding Monasca to OpenStack 20:02:12 #link https://review.openstack.org/213183 20:02:19 Two weeks ago we decided to table Monasca application for two weeks 20:02:27 In order for them to implement a few logistics change to further align with the OpenStack Way 20:02:36 But also to give some TC members more time to investigate how closely Monasca worked with Ceilometer and/or API overlap issues 20:02:49 "some TC members"? :) 20:02:56 >=1 20:02:58 At this stage I'd say that while they were not exactly "one of us" in the past, they are now organized to be one of us in the future, and certainly feel responsive and motivated to do so 20:02:59 * mordred looks at jaypipes 20:03:02 heh 20:03:03 o/ 20:03:12 That leaves jaypipes's objections 20:03:20 jaypipes: http://blog.leafe.com/establishing-apis/ 20:03:24 * dimsum__ sneaks in 20:03:25 ttx: I agree that they are now organized to be one of us. 20:03:25 one is the question of compatible API between competing implementation of the same functionality, which arguably was never articulated before 20:03:49 o/ 20:04:02 two is fairness in comparison of how Fuel / GBP were treated, asking for the same kind of delay to assess cooperation 20:04:10 ttx: it was indeed brought up in the GBP big tent proposal, which I brought up in my latest comment. 20:04:31 So I guess we should discuss both points 20:04:59 I tend to agree with jaypipes 20:05:00 do we want compatible APIs for competing implementation of the same functionality ? 20:05:11 for one - I think I do not care about the API overlap if the two are not claiming the same key in the new keystone catalog 20:05:28 I read the logs from the first irc meeting, and noticed early on a discussion of an in-person whiteboarding session being scheduled, which seemed ironic 20:05:29 mordred: good point 20:05:44 but I also agree with mordred in that I don't think API overlap is an issue 20:05:53 if monasca has a pile of ceilometer's API but is also different in some ways BUT calls itself by a different catalog key - Im fine with it 20:05:56 mordred:++ 20:06:04 mordred: the key being claimed by monasca in the projects.yaml patch is "telemetry" 20:06:06 mordred: I agree with that, unless they are both trying to claim the same service catalog entry, same API seems weird 20:06:18 the problem with GBP wasn't the API, it was that they had not been able to work with the other teams working on networking, and that's a much lower-level feature than monitoring 20:06:26 jaypipes: is that the key they intend to have in the new world order of catalog with standards? 20:06:28 do we have the Object Storage API implemented with ceph already? 20:06:29 dhellmann: so you would also ask for more time before reconsidering the application ? 20:06:37 ttx: yes, to see how the community thing works out 20:07:00 Personally I'm on the fence. I think waiting for mitaka is fine 20:07:00 dhellmann: there was also a number of points raised by me and mestery around the GBP API essentially supplanting the OpenStack Network API. 20:07:02 dhellmann:++ 20:07:21 because if that is the case, I would like to say "no" to similar but also different things claiming the same catalog id - that seems like road to insane 20:07:32 i've left a lot of comments on why monasca isn't the same api as ceilometer 20:07:34 * flaper87 is catching up on the topic since he didn't attend the meeting where this was first discussed 20:07:38 mordred: not sure. I suggested changing it to "monitoring" per rhochmuth's response to me about "what makes monasca different from ceilometer" 20:07:48 mordred: it would be crazy-making to have dupes in the catalog 20:07:50 so mostly speaking based on generic cases, tbh 20:07:52 also, i've commented on the community and the number of organizations involved 20:07:59 jaypipes: right, if the rest of the community was not behind neutron, then I would support a competitor, but because there is support for neutron and it's a foundation piece I think the argument for duplication of feature set (not API, feature set) is a harder sell 20:08:03 jaypipes: I agree that the service catalog entry should be changed 20:08:03 jaypipes: in the GBP case there was the question of diluting a pretty fundamental project, which had questionable value for our users 20:08:12 i already think we are part of the openstack community 20:08:17 rhochmuth: so, in short- you think monasca and ceilomter API are same or different? 20:08:21 I also think that we should probably discuss monasca separate from GBP 20:08:24 they are different 20:08:27 jaypipes: whereas in the monitoring game, multiple solutions are less likely to cause loss of value for our users 20:08:29 mordred, annegentle : yes, we can't allow dupes in the catalog, that would defeat the purpose of all of the consistency work being done there 20:08:36 and the reasons have been documented 20:08:37 rhochmuth: great. are you planning on wanting the same keystone catalog id? 20:08:48 ttx dhellmann: sure, fair points both. I just thought there was enough similarity here for a pause before fast-tracking. 20:08:55 jaypipes: ++ 20:08:56 monasca is more than about monitoring of openstack resources 20:09:03 rhochmuth: the concern is L1194 here - https://review.openstack.org/#/c/213183/1/reference/projects.yaml,cm 20:09:16 rhochmuth: so you would not register in the keystone catalog as "telemetry" - but as "monitoring"? 20:09:17 it is also highly performance and in production today at scale 20:09:17 rhochmuth: I take that as a No to mordred's question 20:09:21 jaypipes: I'm fine with a pause, I see no reason for fast-tracking. But we need to address the question of compatible APIs or not 20:09:29 i would register as monitoring 20:09:37 * flaper87 phew 20:09:39 rhochmuth: awesome. I'm sold 20:09:40 rhochmuth: ok, so you need to change L1194 then 20:09:44 rhochmuth: yes, that's what I figured, thus my comment on the projects.yaml file... 20:09:44 originally when i wrote the submission i said monitoring 20:09:44 rhochmuth: I tink we need to ^^ that 20:09:47 mordred: ditto 20:09:50 and changed to telemetry 20:09:58 do be honest i don't know the difference 20:10:01 rhochmuth: sorry for the whiplash -let's change it back 20:10:12 sure, i would chnage back 20:10:17 rhochmuth: thus my concern about overlapping APIs with the OpenStack Telemetry API ;) 20:10:20 rhochmuth: the thing is is related to a spec up by anne and sdague to get a consistent set of standards into the keystone catalog 20:10:24 rhochmuth: we don't want 2 projects using the same terminology there, because that's one of the key fields users have to tell projects apart 20:10:30 i tend to use monitoring and telemetry interchangeably 20:10:34 rhochmuth: where we want to make sure we know what people are registering in the catalog as 20:10:34 ok, so it seems we have a clear answer on the compatible APIs question 20:10:37 rhochmuth: yeah don't do that :) 20:10:41 ttx: :) 20:10:46 ok, will switch to monitoring 20:10:48 annegentle: ++ 20:10:49 rhochmuth: thank ou 20:10:50 the question of timing remains 20:10:59 ok, so if this gets sorted, are there other pressing concerns? 20:11:15 rhochmuth: in this case, it means that someone saying keystone.session.get_session_endpoint('telemetry') gets a ceilomter endpoint and ...('monitoring') gets monasca 20:11:23 ttx: the answer is "we are okay with different apis for similar services as long as they have different names" ? 20:11:26 sounds good to me 20:11:27 I would like resolution on the multiple languages support and details of that scope before voting on monasca to be honest 20:11:33 I seem to remember from the logs that there were some concerns about some Java code... Am I mixing up things? 20:11:34 jeblair: seems to be 20:11:39 we actually want both ceilometer and monasca 20:11:40 sdague: well, I'd like to see the team actually be able to use the IRC meeting space, instead of immediately jumping to in-person and screen-sharing systems again (as was brought up in their first irc meeting) 20:11:44 I'm not super comfortable with "we're Java now but we'll be Python on " 20:11:58 sdague: my final comment was this, which AFAIK, remains unaddressed: "Finally, another condition we asked the Fuel project to meet was alignment of the continuous integration systems used in Fuel development with those of the upstream infra CI. Does the Monasca community have a plan/roadmap for aligning with the upstream CI systems, particularly for the remaining Java parts of the Monasca project? We asked Fuel to put t 20:11:58 his plan together. To not ask Monasca to do the same seems inconsistent to me." 20:12:02 rhochmuth: yes, I appreciate your comments clarifying that ceilometer is a source of input for monasca 20:12:02 annegentle: ah-ha, so I'm not crazy. I did read that on the logs 20:12:04 :D 20:12:22 in the first irc meeting, we held it completely in irc 20:12:37 we had a performance issue that needed to follow-up 20:12:47 we discussed with all in irc how to do that 20:12:49 jaypipes: totally. but I believe monasca has been doing 100% of its CI in upstream CI, so I think that bit is already done, no? 20:12:55 dhellmann: ok, I consider that a fair point 20:12:59 rhochmuth: yes, but one of the topics brought up was how to address an issue by having a separate meeting either in person or with screensharing, right? 20:13:00 many of us or local to the denver region 20:13:06 jaypipes: (I agree it's inconsistent, I just don't think it's the case) 20:13:07 mordred: our upstream CI supports testing Java components? 20:13:11 jaypipes: yes 20:13:16 so we did a face to face and had cisco tele conference in 20:13:18 ah, well awesome then. 20:13:21 mordred, jaypipes, rhochmuth: it looks like there are both java and python unit tests, but i don't see integration tests, and of course the java tests hit the internet for deps. 20:13:35 "15:11:53 if it is just deklan and me, we could to a physical meeting, but if others want to be invovled, can do desktop sharing" from http://eavesdrop.openstack.org/meetings/monasca/2015/monasca.2015-09-02-15.00.log.html 20:13:37 jeblair: ty for that info, appreciated. 20:13:41 jeblair: right, but so does diskimage-builder, for instance 20:13:42 jeblair, jaypipes: yah - there are places we need to flesh out the awesome for sure 20:13:48 so we are completely in irc, unless we need to use teleconferencing 20:13:50 rhochmuth: and are docs sphinx/rst/wadl (tobeswaggersoon)? 20:13:53 sdague: we need to flesh out the awesome there too 20:13:53 does Monasca use rabbitmq ? 20:13:54 which in this cases was required 20:13:54 so not hitting the internet is not just a sin of this project 20:14:03 monasca doe not use rabbitmq 20:14:03 * flaper87 should dig into this 20:14:04 sdague: we need tons more awesome :) 20:14:06 so we've yet to have a java project volunteer to invest in fixing that 20:14:11 SO the remaining question is... do we consider that they are already "one of us" or could use more time to align, no need to hurry 20:14:18 sdague: yes, but dib folks are actively engaged in fixing that 20:14:22 rhochmuth: any messaging technology? 20:14:32 we use kafka 20:14:47 jeblair: perhaps a member of the Monasca contributor team might provide that necessary help on the Java project front. 20:14:57 jaypipes: ++ 20:15:00 jaypipes: i think that would be swell 20:15:00 rabbitmq can not sustaing the perofmrance we need, it is not durable, it does not handle ha well 20:15:06 rhochmuth: gotcha 20:15:27 * mordred has heard that there are humans who would like to discuss making an oslo.messaging backend for kafka 20:15:27 rhochmuth: not judging, just looking for some info :D 20:15:28 jaypipes: yeh, that would be the right place for that to come from, it sort of feeds into the lang support discussion 20:15:44 should we do a quick show of hands to solve that remaining question ? 20:15:58 ++ 20:15:59 mordred: yeah, there've been discussions since Atlanta 20:16:00 ++ 20:16:02 right, I've heard tons of rumble about kafka, so having something regularly poking that in upstream CI would be really interesting 20:16:02 mordred: no one has step up for that yet 20:16:10 mordred: https://review.openstack.org/#/c/189006/ 20:16:21 gordc: well then! 20:16:28 ttx: you mean the question on CI alignment? 20:16:40 ttx: or soemthing else? sorry, got lost here a bit. 20:16:40 ttx: go 20:16:42 ttx: yes, I'm not sure which question you are asking about 20:16:47 I'm not sure what I'm showing my hands on 20:16:59 * mordred waves hands just on general principle 20:16:59 SO the remaining question is... do we consider that they are already "one of us" or could use more time to align, no need to hurry 20:17:11 should we do a quick show of hands to solve that remaining question ? 20:17:13 more time seems helpfu 20:17:17 gordc: oh, I had missed that 20:17:18 helpful even 20:17:23 ttx: well, I thought the hurry was whether or not they get any space in tokyo 20:17:34 ttx: I am comfortable with their level of one of us 20:17:38 yeah let's not hurry due to a summit 20:17:42 i don't need space tor tokyo 20:17:43 ttx: gotcha. well, I think it would be more consistent if we asked for a bit of a "prove yourselves" period, as we did with Fuel. 20:17:45 flaper87: it's been on and off. that said, i'm interested as well. 20:17:48 well, space was allocated last week, so it's too late to get "regular" space now 20:17:51 we are one of you 20:17:56 ttx: 2 months, maybe. 20:17:56 will gladyl take spacei if available, but that isn't an issue to me 20:18:06 I'm not sure what I'd be asking them to do or how I'd judge it 20:18:12 what is the action that i'm supposed to work on for 2 months? 20:18:19 would someone clarify this now? 20:18:23 rhochmuth: ++ 20:18:31 6 serious companies are working on this 20:18:35 rhochmuth: could you last 2 months with only video meetings? 20:18:36 in is deployed in production 20:18:40 I mean only RIC 20:18:41 IRC 20:18:50 rhochmuth: I was looking for 8 unserious companies. 20:18:55 there was no problems with last weeks irc 20:18:56 rhochmuth: CI assignments, docs assignments? 20:19:00 i actually enjoyed that 20:19:07 has some advantages 20:19:12 like log files 20:19:15 logging ++ 20:19:19 i think the meeting was productive 20:19:26 ok, let me start a quick show of hands poll for the TC members 20:19:37 #startvote Can Monasca be considered "one of us" now or should it be given a couple months, waiting for Mitaka to further align to OpenStack ways? now, mitaka, dunno 20:19:37 Begin voting on: Can Monasca be considered "one of us" now or should it be given a couple months, waiting for Mitaka to further align to OpenStack ways? Valid vote options are now, mitaka, dunno. 20:19:38 Vote using '#vote OPTION'. Only your last vote counts. 20:19:49 #vote now 20:19:52 #vote mitaka 20:19:58 #vote dunno 20:19:58 #vote mitaka 20:19:58 #vote now 20:20:08 #vote mitaka 20:20:08 rhochmuth: you haven't addressed my question about this part of the conversation: http://paste.openstack.org/show/450730/ 20:20:14 #vote mitaka 20:20:17 #vote mitaka 20:20:18 #vote mitaka 20:20:21 #vote now 20:21:01 #endvote 20:21:02 Voted on "Can Monasca be considered "one of us" now or should it be given a couple months, waiting for Mitaka to further align to OpenStack ways?" Results are 20:21:03 mitaka (5): annegentle, jaypipes, dhellmann, flaper87, markmcclain 20:21:04 now (3): mordred, lifeless, sdague 20:21:05 dunno (1): ttx 20:21:20 Looks like people are more comfortable tabling this for a couple months 20:21:21 i think it would be good to see some engagement on the CI front -- both in supporting java infrastructure and some integration testing 20:21:44 jeblair we are moving away from java 20:21:53 then that part isn't so important :) 20:21:55 and monasca is already in the ci/cd systems 20:21:58 perhaps we might invite rhochmuth and ddieterly to the TC meeting on Monday in Tokyo and hold an in-person vote for Monasca? 20:21:59 we run unit tests 20:22:01 ... 20:22:17 what are we waiting for 20:22:27 not sure what is actionable on my part 20:22:29 unit tests are good, but I'm not seeing any integration test jobs 20:22:34 rhochmuth: but there are no integration tests, right? 20:22:42 rhochmuth: I think getting some devstack integration tests owuld be nice - especeially if you've got kafka stuff - that would actually likely be helpful for the oslo.messaging kafka folks to build on 20:22:43 rhochmuth: right, integration tests seem kind of important 20:22:49 maybe those who voted "mitaka" in the poll could detail what they would like to see in the coming months 20:22:50 rhochmuth: time. trust. patience. 20:22:50 we have an entire suite of tempest tests in a separate repo that we would merge 20:22:50 probably something with a keystone service catalog entry ought to have an integration test 20:23:09 jaypipes: well said 20:23:13 I'd personally like to see more interactions with the rest of the community, perhaps better CI (integration tests) 20:23:22 full stack testing in some regard at least 20:23:42 Personally I'd like to see if the OpenStack ways work for you -- it's one thing to be forced to use IRC, it's another to come to appreciate what it brings you 20:23:46 jeblair: ++ 20:23:51 rhochmuth: have a link to those tests or that repo? 20:23:54 ttx agreed 20:24:00 it's perfectly fine to discover that it doesn't work for you 20:24:01 I think nothing bad will happen in the next couple of months, if anything it's just some extra time to migrate more of the code to python, integrate with other parts of the ocmmunity and CI 20:24:13 so, I believe waiting is just for the better 20:24:34 other than that, I don't have anything against welcoming monasca in the big tent 20:25:12 right and I since there's not an immediate pressing working a bit wider with CI, meetings makes sense before adding into tent 20:25:29 so it looks like it won't gather the required votes today anyway 20:25:46 and this should be tabled until Mitaka starts, when we'll reconsider Fuel as well 20:26:25 anyone else wanting to detail what they expect from Monasca between now and then ? 20:26:40 so - it might be good for one person to write up a $something that summarizes the above thoughts for rhochmuth ? 20:26:47 rhochmuth: do you feel like you have a handle on what's expected of your team? 20:26:56 no, i do not know what you want 20:27:03 more irc meetings??? 20:27:25 more community 20:27:30 rhochmuth: I think jaypipes made the point of patience 20:27:34 I think my concerns were included in those summaries: more meetings using tools the community can all use & integration test jobs 20:27:40 do all the project that you've accepted have 6 companies working on it 20:27:42 ++ 20:27:48 * an integration test (likely based on devstack and tempest, using plugins) 20:27:58 rhochmuth: nope, that doesn't have anything to do with this vote result. 20:28:06 rhochmuth: I'd like to feel that you're one of us. Not that you're forced to adopt our ways to pass a bar 20:28:08 jeblair: ++ 20:28:14 so 20:28:19 rhochmuth: the criteria we use to evaluate a project are listed at http://governance.openstack.org/reference/new-projects-requirements.html 20:28:23 we don't have integration tests as a requirement in the governance 20:28:36 do all other projects have integration tests 20:28:40 lifeless: The project has core reviewers and adopts a test-driven gate in the OpenStack infrastructure for changes 20:28:42 have we uncovered another thing we should be requiring? 20:28:46 anyway we have a suite of integration tests in a repo 20:28:46 lifeless: it's true, however, this project, at the point it is in its development, should have one. 20:28:49 dhellmann: yes, which it has 20:29:15 lifeless: if it were a less mature project, i would not ask it to develop one first 20:29:16 jeblair: so we wouldn't have asked for it if they'd become one-of-us earlier ?. I am confused. 20:29:28 rhochmuth: right, but most projects run those on every commit 20:29:33 https://github.com/hpcloud-mon/monasca-tempest 20:29:46 definitely all the projects we consider mature 20:29:47 why is it so hard to ask for just time to pass so that we can see the new community processes/meetings/collaboration is not just all for show? 20:30:07 rhochmuth: are those in gerrit, too? 20:30:21 no, we have not merged them with gerrit 20:30:22 jaypipes: well I think that letting time pass was agreed 20:30:29 jaypipes: yeah, that's my bigger concern 20:30:31 jaypipes: I am really glad you have that position 20:30:35 I think the question is on other more concrete things 20:30:35 rhochmuth: are there other parts of monasca not in gerrit? 20:30:43 jaypipes: you also mentioned trust earlier as well 20:30:45 lifeless: i think for a project to get to this level of maturity and not have an uptream integration test shows that it was not developed as an openstack project. this is something specific to this project that needs to be remedied. 20:30:46 i have to concur, it seems odd for a "one of us" project to prefer to start developing their tests in a github repo 20:30:49 which did get brought up, the point of critical bits not in gerrit is good 20:30:52 jaypipes: dunno (?) 20:30:54 all the source is in gerrit 20:31:08 OK, we really need to write a more explicit response here 20:31:10 * flaper87 connection is lagging like crazy and he's not even on a plane 20:31:13 there are a bunch of repos for Ansible and side project not part of the core submission 20:31:23 any volunteer to draft that over the coming week ? 20:31:28 rhochmuth: why aren't those part of the project? 20:31:30 I'm happy to collect it and report back to the review 20:31:42 I'll work with flaper87 20:31:42 * flaper87 read ttx's mind 20:31:43 flaper87: ty. 20:31:50 dhellmann: danke! 20:31:51 jaypipes: np 20:32:12 a tester developed the monasca tempest test and was unfamilier with next steps 20:32:15 and a late ++ to jeblair's comment 20:32:18 flaper87: awesome. Etherpad and -tc list should do 20:32:41 rhochmuth: ok. that does need to be addressed, though. 20:32:48 the ansible is not part of gerrit, becuase it isn't really considered core 20:32:58 we need to move on 20:33:27 #action flaper87 to draft a clearer response with TC expectations 20:33:43 #agreed Monasca application tabled until start of Mitaka cycle 20:34:12 #topic Add team:danger-not-diverse tag 20:34:16 #link https://review.openstack.org/218725 20:34:20 thanks flaper87 20:34:27 jogo proposed a tag to describe project teams that are "dangerously" not diverse. 20:34:35 annegentle: np :) 20:34:39 I think that's a great data point to communicate out -- projects that rely on a single company or where only two companies are contributing are fragile 20:34:46 I had a late "danger is judgemental" comment :) 20:35:01 annegentle: I think judgemental is fine here 20:35:10 yeah, i think it's fine too 20:35:12 because this is really not a state we want any project to be in 20:35:19 consumers of the project should know that before they choose to invest in deliverables produced by that team 20:35:37 There are fragile (or already dead) projects in the big tent today 20:35:44 a simple non-diverse would work too, but I agree the extra bit implied by danger is ok here 20:35:44 personally I probably would have dropped the 2 orgs at 95% bit 20:35:45 sdague: danger to whom? Might be a sign that the project should break up anyway? fragile might be better 20:35:49 I think it's fine to say "danger" but I'm less comfortable assuming that lack of diversity is associated with a lack of desire for diversity, as is implied by line 14 20:35:58 annegentle: dangerous to adopters 20:35:58 (of draft 4) 20:36:05 * jaypipes curious what benefit this explicit negative tag has versus just the absense of the diverse-affiliation tag 20:36:16 fragile-not-diverse ? 20:36:17 sdague: ok 20:36:24 jaypipes: it identifies the other end of the spectrum 20:36:35 jaypipes: you may not have a divcerse affiliation, but still not be fragile 20:36:38 jaypipes: it's the red zone just before you run out of gas 20:36:42 I think it's a valid measure 20:36:50 dhellmann: i strongly endorse your objection. 20:36:56 dhellmann: by that token, should we add tags for "doesn't-assert-deprecation-policy"? 20:37:14 jaypipes: well, that more binary 20:37:15 jaypipes: no, because that's a boolean. diversity is a float 20:37:26 dhellmann: ++ 20:37:36 jaypipes: if you have a different set of labels to get 3 states here, those are welcomed 20:37:44 but this is a tristate, not a dual-state 20:37:50 dhellmann: I agree 100.0000028283 percent. 20:37:59 jaypipes: and yes, i also wonder the same thing -- i thought when we added the 'diverse' tag that was sufficient. 20:38:10 I thought tags were supposed to be boolean? 20:38:12 sdague: what are the three states? 20:38:16 seriously, I think it's great that MagnetoDB gets the tag. It's pretty dead now that Mirantis seems to have pulled from it 20:38:25 angdraug: they were supposed to be, yes. 20:38:30 and if we had the tag before every consumer could have seen it coming 20:38:30 diverse-affiliation, none, diversity-danger 20:38:33 angdraug: either you have the tag, or you don't. 20:39:21 it is not possible for 1 project to have both tags, it is possible for a project to have neither tag 20:39:31 why then should diversity be any special? either the project is diverse, or it's not, why add a third state of "kinda diverse but kinda not enough"? 20:39:34 so they are 2 binary tags, that together represent a tristate 20:39:35 sdague: i'm not sure "low, medium, high" diversity helps me decide that something is well supported as much as "almost none, some" diversity. 20:39:43 this isn't quite like the ops "tags" stuff, where you have a value part like "packaged:76%" or something, but this is less than ideal, IMHO... more confusing than anything. 20:40:06 those tags answer different questions. 20:40:18 One says the project is produced by a diverse community 20:40:25 $The other says the projecvt is at risk 20:40:28 honestly, I think this is hugely important to be explicit about the fact that we have a set of really healthy projects that clearly can handle one or more big players falling out 20:40:45 ttx: what's the value of the first one if not to mitigate the risk represented by the second one? 20:40:48 sdague: me too, i consider that the diversity tag. 20:40:50 and on the other end a set of projects which are very clearly at the whim of a single orgs budge cycle 20:40:51 Every project that the tag is applied to is in danger of not being there tomorrow 20:41:01 ttx: I disagree. One says the project is diverse or a project is not diverse. The other doesn't say something positive at all. 20:41:26 I think it's a trinary state which our tags don't show 20:41:26 sdague: i guess i don't see the middle road as being not in danger. i think anything without the current diversity tag is in danger. 20:41:38 ttx: couldn't you say the same thing about any project without the diverse-affiliation tag? 20:41:40 the diversity tag has a much different threshold 20:42:03 i think any project without the diversity tag is unhealthy. i certainly thought that when infra lost it. 20:42:04 jaypipes: I think they are not indanger. They are not produced by a diverse community, but they shuold survive a given company pulling out 20:42:04 jeblair: ++ 20:42:05 jeblair: infra is not going to collapse if a single org has a priority shift. cue will 20:42:14 as a for instance 20:42:19 that's a really concrete one 20:42:28 sdague: i'm worried about it. 20:42:31 jeblair: unhealthy doesn't mean in immediate danger of dying. 20:42:45 which is what I mean by answering two different questions 20:42:50 jeblair: ++ 20:42:58 perhaps if the tag was named non-negatively 20:42:59 sdague: ++ 20:43:04 still points to "danger" and "fragile" as not really describing this 20:43:05 Fuel is in no immediate danger of dying even though it's definitely a Mirantis monoculture 20:43:08 so that the meaning could be captured - but not with the negative voice? 20:43:25 jeblair: I agree that it's a concern, but it won't literally cease to exist if one of the orgs changes priorities in their annual budget review 20:43:26 ttx: i think i'm starting to see where you and sdague are coming from. i think this may be a matter of audience. 20:43:42 angdraug: Fuel can die is a single person decides it. That is what I call "danger"; 20:43:46 mordred: ++ 20:43:54 angdraug: I think what folks are saying is that Fuel *is* in danger of dying if Mirantis goes belly up, simply because it is not a diverse affiliation. 20:43:56 we have a set of projects that will completely cease to exist if an exec at one org decides to move people around 20:43:59 as a user, or even general observer of the project, i think my primary concern is whether a project is healthy (diverse) or not 20:44:14 jaypipes: yah. and we'd like for that not to be the case, beause fuel is pretty cool - as is cue 20:44:24 sdague, ttx: i agree there is a further degree that you have articulated here, but what audience is that of use to? 20:44:30 while I understand the points behind flags being booleans, I also see how, in this specific case, it's useful to have it describing something else other than yes/no 20:44:35 jaypipes: so I tihnk what I'd like to communicate is "opportunity for other people to make a difference by getting involved" 20:44:37 jeblair: operators deciding to deploy a component 20:44:38 angdraug: MagnetoDB is in the bug tent, has the tag, was removed from Mirantis priorities apparently and is now a zombie project 20:44:41 sdague, ttx: users should already have panicked based on not having diverse 20:44:43 and thus taking on support 20:44:56 this is actually a question that gets asked 20:44:58 given the amount of activity around Fuel and number of people using it, it's very likely that all that will be picked up by current users of Fuel even if Mirantis pulls out of it 20:45:04 sdague: right, i guess i think that's the diverse tag. 20:45:06 mordred: well, branding a project with a negative "diverse-affiliation-danger" tag is unlikely to inventivize a project. negative incentives rarely work in the way that positive ones do, IME. 20:45:08 mordred: that's exactly what I "not so diverse but could be" state would mean to me 20:45:15 and I think we should have a way to express that 20:45:17 jeblair: I still think the projects the tag applies to are in more... immediate danger. 20:45:20 jaypipes: right. that's why I'm syaing we should hav ea better name 20:45:21 jaypipes: or whatnot 20:45:24 sdague: are there really people willing to deploy something "somewhat non-diverse but not dangerously so"? 20:45:36