20:01:02 #startmeeting tc 20:01:03 Meeting started Tue Jun 9 20:01:02 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:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:06 The meeting name has been set to 'tc' 20:01:17 o/ 20:01:17 Live from Berlin, our agenda for today: 20:01:21 o/ 20:01:21 o/ 20:01:23 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:25 \o/ \o/ \o/ \o/ 20:01:26 o/ 20:01:30 o/ 20:01:38 o/ 20:01:40 #topic Cross-project spec final approval: Supported messaging drivers policy 20:01:45 o/ 20:01:46 #link https://review.openstack.org/#/c/174105/ 20:01:50 o/ 20:02:02 I feel like this one reached consensus state and is as rady as it will ever be 20:02:06 * flaper87 thinks that review is good to go 20:02:07 ready, even 20:02:18 * flaper87 likes rady better 20:02:20 ttx: o/ 20:02:33 If no objection I'll push final approval in-meeting 20:02:33 ttx: just finishing brekkie w/family so a little distracted :/ 20:02:43 is the end result "only the rabbit/kombu driver currently meets expectations" ? 20:02:47 fine with me, just curious 20:03:07 o/ 20:03:10 SpamapS: around? 20:03:16 * sigmavirus24 agrees with flaper87, rady is better 20:03:52 russellb: that was my impression 20:03:58 Personally I hope that this will make the people who care about certain other drivers to step up 20:04:09 ttx: it has already 20:04:14 not that it will make us drop anything 20:04:17 I've seen movement in other drivers 20:04:24 and that's why I'm happy with this spec 20:04:25 i think we can drop the old qpid one 20:04:26 :) 20:04:26 SpamapS is at a conference, he _might_ bea round 20:04:30 flaper87: including the zmq one ? 20:04:34 But I didn't see him carrying around a laptop 20:04:34 russellb: that's in the works 20:04:38 ttx: yes 20:04:38 cool 20:04:48 flaper87: ok, missed that, nice 20:04:49 iiuc, the current qpid driver would be deprecated and other drivers would need to be brought up to standard 20:04:59 wfm 20:05:05 dhellmann: yes, that's the conclusion 20:05:19 Any objection to me pushing the final +1 now ? 20:05:42 it is worth noting that it's not just solid driver code that's needed, having the user community has been pretty critical to addressing real issues in the rabbit support. So it will be interesting to see if other backends build a real user community. 20:05:54 I guess we could use a 7th TC vote on it 20:06:10 ttx: I just voted +2 20:06:14 mordred: care to convert your +1 in a +2? 20:06:16 mordred has a +1 on there 20:06:17 sdague:plus, provide the required support when issue will come up 20:06:18 makes sense to approve 20:06:19 (because they will) 20:06:23 ttx: done 20:06:31 one sec 20:06:43 Is the timeline "Liberty release" for docs updates? 20:06:44 alright, I guess that's more than enough 20:06:54 I had some nit comments but I thought they weren't blockers, hence my vote 20:07:23 annegentle: yes, I think the intent is to mark that qpid driver as deprecated this cycle 20:07:36 ok, approved 20:07:38 I guess I am a little confused why the TC is handling this... 20:07:47 * flaper87 will deprecate that driver himself 20:07:50 dhellmann: got it, thanks. I'll pass along to loquacities 20:07:54 jaypipes: we are just judging if consensus is reached 20:08:06 jaypipes: i guessed because of the broad impact it has (why it's cross-project and not just an oslo thing) 20:08:19 fundamental piece of the infrastructure 20:08:35 #topic Cross-project spec final approval: CORS Support for OpenStack 20:08:45 #link https://review.openstack.org/#/c/179866/ 20:08:47 to be fair, the original proposal was: Lets drop everything but kombu 20:08:56 which is why it ended up as a cross-project thing 20:08:56 herrh 20:08:57 well, yeah, I know that, but are we planning on doing this for databases and other stuff that is "funsdamental"? 20:09:01 hi hi! 20:09:12 This one also has pretty wide approval now, so I'd like to move and final-approve it 20:09:13 jaypipes: we're erring on the side of more communication 20:09:18 fun-damental 20:09:45 unless somone thinks we need to hold it more 20:09:52 or someone 20:09:58 lifeless was +1 on it 20:10:06 For the sake of the CORS specification, I'd be happy to do followup patches if particular points need to be tweaked. 20:10:09 so we'd have 7 +2s if he upgrades 20:10:29 we already have more than we need 20:10:40 the question is more... do we think this needs any more baking time 20:10:46 I personally do not think that it does 20:10:57 no, I think the CORS stuff looks fine to move forward 20:11:12 sdague: +1 20:11:14 I'd really been hoping krotscheck would push some tweaks 20:11:14 there will be devils in details, but honestly, that won't be sorted until there is more core 20:11:16 code 20:11:45 lifeless: is that -1? 20:11:48 lifeless: Convention travel + linting arguments prevented that. 20:11:48 I wasn't exactly sure why the proxy option wasn't viable, but don't have any real problem with the patch 20:12:19 dhellmann: I don't think its worth blocking it on. I think it would be better with my suggestions, and AIUI krotscheck isn't oppposed to them. 20:12:30 lifeless: ok, that sounds like an update patch 20:12:34 lifeless: I can push a followup tweak easily enough, as I don't really have a problem with your suggestions. They just clarify things. 20:12:46 yeh, I'd just handle that as an update patch 20:13:13 and, honestly, I'd expect that once real code is out there, a few other details will fall out 20:13:15 lifeless: if you +2 (pointing to an upcoming follow-up patch, I will final-approve it now 20:13:38 ttx: I don't know what that subordinate clause means 20:13:39 * krotscheck wanders off to write a followup. 20:13:49 ttx: do you mean wait for the subequent patcha nd +2 20:13:57 ttx: or do you mean +2 on the basis of this conversation alone? 20:14:02 lifeless: the latter 20:14:05 ok 20:14:35 done 20:14:41 Alright, let's do this 20:14:58 * krotscheck does a little specification dance. 20:15:03 done 20:15:12 One semi related question. 20:15:30 krotscheck: yes? 20:16:00 I'm doing a LOT of things right now to do javascript supporting things in Openstack, and I do _not_ want to be the only person who has that knowledge. Where can I document the things that I'm doing? 20:16:03 Like, dev guide for linting. Or how to configure cors. How caching works. That kind of stuff. 20:16:19 * krotscheck should probably just pull annegentle aside offline 20:16:52 sure 20:16:52 or loquacities the docs ptl :) 20:17:02 krotscheck: cross-project specs? 20:17:31 Alrighety, that's enough of an answer :) 20:17:40 ok moving on 20:17:42 I'm good, going to go do lifeless 's changes. 20:17:42 #topic Discuss differences between Ops and TC "tags" 20:17:44 krotscheck: the infra and qa folks have been doing some really good stuff with documenting things... might be worth looking at http://docs.openstack.org/developer/subunit2sql/README.html 20:17:57 krotscheck: in conjunctions with docs folks of course 20:18:00 #link http://lists.openstack.org/pipermail/openstack-tc/2015-June/000991.html 20:18:05 OK, so this was prompted by the recent proposals from the Ops "Tags" WG 20:18:19 When I attended the second part of the workgroup in Vancouver I was under the impression they were onto something that would work well within the framework we created 20:18:29 So I felt like it was great that they would run with the concept and own the "ops feedback" part of it 20:18:42 But looking at the recent proposals it's pretty obvious they are onto something slightly different that would not fit that well into the tag framework we have 20:18:54 Basically they want to provide structured documentation about projects around areas like packaging, production usage etc. 20:18:54 ttx: yes, entirely different :( 20:19:08 So they are more defining a grammar to express that information in YAML, rather than simple binary tags that can be attached to projects. 20:19:23 I still think it's important and valuable information for them to communicate, but I don't think we should call both "tags" or have them live under the same roof. 20:19:37 In the email referenced above I mention 3 possible solutions 20:19:40 I agree. although I do not actually want to have the discussion about the right name 20:19:46 is there anyone from the ops tags group here right now? 20:19:47 ttx: they are also setting themselves up for failure, IMHO, and a situation where the data will be almost immediately stale and worse than in the openstack.org wiki. 20:19:48 I was quite surprised, by reading ttx's email, that they're planning to score in some of those areas 20:19:55 1/ We can try to convince them to make their areas more like tags 20:20:02 Surprised in the sense that I'm curious how they are going to do it 20:20:05 but they don't see really interested in doing that 20:20:11 2/ We can overhaul *our* tags so that they look more like their areas 20:20:18 but I still think having simple tags is an easier-to-consume piece of information to attach to all the projects we have 20:20:29 (makes creating a website to navigate those so much simpler) 20:20:35 wow on "worse than in the openstack.org wiki" jaypipes :) 20:20:37 ttx: yes. exactly. a tag means something clear and concise. 20:20:43 3/ We can let them coexist (TC provides tags, Ops provide ops-data) but stop calling them the same, because that's confusing. 20:20:52 I prefer option 3, lets let them experiment and we can sync on the different approaches 20:20:55 ttx: is your followup to 1/ based on subsequent conversation, or just the initial "oh, look they have a thing and it's not our tags"? 20:20:56 I think I have a slight preference for #3 since we could totally rely on ops-data to "objectively" apply some tags 20:20:58 annegentle: meaning the wiki can very easily get stale info, like any wiki... 20:21:02 we might end up changing (or they will end up changing) 20:21:05 jaypipes: yep 20:21:18 I think we need to let both approaches run for a bit. 20:21:23 So option 3 lets that happen. 20:21:31 jeblair: from my intersaction with the group (on the ML, and direct discussions with Tom) it appears they are pretty attached to the way they want to do it 20:21:31 ttx: (you said they are not interested; are they still not interested after having been made aware of the mismatch?) 20:21:37 I think that in absence of any reps from the ops tags committee that the tc can't really decide what they should do, only what the tc should do 20:21:37 what ops want is not so much tags as more targeted analytics data (extension to bitergia/stackalytics) by the sounds of it 20:21:38 But +1 for using different terms 20:21:38 ttx: ok, thanks 20:21:46 I have a strong preference to 3 20:21:47 it'd be *really* confusing to have both called tags 20:21:51 2 doesn't really work for us 20:21:54 yeh, that's my lean is towards #3 at this point, and see where it heads 20:22:00 zaneb: that was my impression as well 20:22:08 #3 20:22:09 +1 to #3 and revisit over time as things evolve 20:22:11 and 1/ - smart folk in that group feel like it works for them; we're out of context at the moment and I think there are more important tings to focus on 20:22:15 see how it goes 20:22:18 get out of their way ;) 20:22:30 #3 20:22:33 yep. and 2 means we get further behind. 20:22:41 because at the end of the day this whole exercise was about getting information to users, and they've defined the information they want, lets see if a model for producing it and keeping it up to date emerges 20:22:44 The WG will gather on IRC next Thursday and I'd like to know what to tell them -- looks like ishouldtell them to do what they want but call it something else to avoid global confusion 20:22:45 I prefer 1/ really, but I'm more than happy to let their current strategy fail and then revisit. 20:22:45 ttx: how much confusion do you think it really raises to call both "tags"? and how likely are we to get them to change the name of their thing? 20:22:49 I'd like for this ops group to be a working group for running with the ideas for "measures for maturity" 20:23:13 dhellmann: I know every time we said "we could call both things the same" we ended up regretting it down the road 20:23:17 when it's too late to change 20:23:19 ttx: true 20:23:27 ttx: ++ 20:23:27 jaypipes: I think its entirely fine if you have the bandwidth to engage with them; but I don't think the TC movement forward should depend on aligning 20:23:28 ++ 20:23:58 jaypipes: could be worse, their grammar could be xml 20:24:06 lifeless: why you calling *me* out specifically? 20:24:21 because you're specifically saying you think they'll fail 20:24:31 well, unless someone comes up with something more catchy than "ops tags" it's going to be what sticks 20:24:35 I don't have an opinion on whether their approach will fail or not 20:24:38 as yet 20:24:42 lifeless: I have *already* engaged with them. and their answer has been "f off, we'll do it our way". 20:24:56 jaypipes: haha, so that makes 1 a no-go anyhow :) 20:24:58 sdague: "ops metrics?" 20:25:01 they could call their tags "tenants" 20:25:08 or policy 20:25:08 or maybe "projects" 20:25:16 well, i won't cmoe up wit a name, just pointing out that tags is not the best word to describe what they are up to. Also that they shouldn't feel constrained to use our format there 20:25:18 categories ? 20:25:21 rofl 20:25:21 mordred: ;) 20:25:27 zones 20:25:31 flaper87: ops monoids? 20:25:32 metadata, catalog 20:25:38 edleafe: domains 20:25:40 so many choices of things that already have uses 20:25:44 lifeless: lol 20:25:46 * jaypipes looks forward to the ops:packaged:centos:call-me-maybe:ok-with-cern-this-week "tag" 20:25:51 hopefully something similar to 'ops' can be incorporated to help distinguish the different sources 20:25:55 this bike shed is about to fall over from too much paint 20:25:58 LOL 20:25:59 jaypipes: dude. that's an AWESOME tag 20:26:07 I want it cerulean 20:26:08 russellb: heh 20:26:13 russellb: maybe we can paint the paint a different color 20:26:15 jaypipes: LOL 20:26:19 just a bare word doesn't help the reader know what they are looking at. that probably applies to 'tags' too 20:26:23 mordred: I vote black 20:26:29 noops-tag 20:26:32 flaper87: which shade? 20:26:35 ops-ribs 20:26:38 OK, I think I have what I need here 20:26:39 lifeless: YES 20:26:42 look, there's nothing wrong with structured information. but like I said in the reviews on the ops tags repo, that's what I like to call "documentation". 20:26:46 ttx: and plenty of 'helpful' suggestions 20:26:50 [if you figure out how my brain went there, you get a cider in tokyo] 20:26:52 we can move on, unless you want to further paint the yak 20:26:53 dtroyer: you make a good point 20:26:53 mordred: dark, deep, obscure and evil 20:27:01 "ops project catalog" 20:27:02 * russellb shrugs 20:27:03 * flaper87 gets his mind back on the meeting 20:27:13 #topic Add the Searchlight Project 20:27:21 +1 20:27:30 #link https://review.openstack.org/188014 20:27:38 Looks like most people like it 20:27:47 Looks more like a split than a new thing to me 20:28:05 ttx: agreed on both 20:28:09 and since it's not exactly the same team, we can definitely have a new "project team" for it 20:28:10 basically we think this improves focus on the search concept as a well defined service while also un-complicating some of the glance story. 20:28:10 yeh, the team doing it has something pretty solid already. Their initial design already had a separate end point 20:28:12 since now we can 20:28:29 no brainer, IMO. 20:28:31 it was basically pushed into glance because of old governance, but definitely best on it's own 20:28:41 Agreed, plus, the demo itself was quite isolated already 20:28:41 ++ 20:28:47 ttx: go go go go 20:29:02 * ttx checks votes 20:29:14 alright, more than enough here 20:29:19 maybe it should be SearchLight instead of Searchlight 20:29:24 (kidding..) 20:29:26 last call for objections 20:29:29 russellb: groan :) 20:29:30 russellb: don't do that 20:29:31 * sdague hits russellb with a hallibut 20:29:38 russellb: pls no 20:29:40 * dhellmann puts down the club he was swinging at russellb 20:29:47 lolol. 20:29:50 lol 20:29:55 rassellb plz 20:30:07 actually I think russellb has a point... 20:30:09 just kidding 20:30:15 Greenlight? 20:30:17 ಠ_ಠ 20:30:21 approved 20:30:27 woo! 20:30:28 :) 20:30:36 ლ(╹◡╹ლ) 20:30:40 congrats to the Searchlight team! 20:30:40 great! 20:30:42 thanks for coming to the meeting in case there was more discussion needed, team :) 20:30:43 Though I wonder what animal mascot a Searchlight can have but that's for another day 20:30:56 ttx: eye of sauron 20:30:57 ;) 20:31:00 lol! 20:31:01 one of those deep water fish 20:31:01 :-) 20:31:03 that's amazing 20:31:04 i do hope we get a patch next summit... 20:31:12 TravT: we'd better 20:31:23 * TravT still feeling unhappy that horizon didn't have one 20:31:30 searchlight spelunkers 20:31:30 an eye of sauron ? 20:31:33 rosmaita: ha! 20:31:39 lifeless: sigmavirus24 beat you to that 20:31:39 Alright, this is moving faster than I thought 20:31:44 #topic Workgroup reports 20:31:48 mordred: no, not w.r.t. horizon 20:31:55 * Project Team Guide 20:31:55 mordred: it was deliberate 20:32:02 We have a repository initial commit at https://review.openstack.org/189514 20:32:07 jeblair: what's the current make up for the core team there ? 20:32:07 i helped! 20:32:21 ttx: apparently you can +2... 20:32:29 * jeblair stalls for time 20:32:38 yeah, but if i'm te only one I guess I should not wait for another 20:32:47 ttx: I can +2 20:32:52 done 20:32:55 approved 20:33:00 ttx: oh, it's the tc 20:33:08 tc 20:33:10 yep 20:33:24 ttx: what's the approval rules expected there? normal core rules, or something more complicated? 20:33:26 let's do a simple 2 +2s though, not a majority vote :) 20:33:35 I'm fine with that 20:33:37 it's doc 20:33:50 anything contentious can come back to the meeting for a fight 20:33:51 we migt actually refine that to the group of people actually working on it 20:33:53 ++ 20:34:02 i also plan on doing a little more work before the sprint. i will add files for each of the sections based on the preliminary toc so that we can paralellize and avoid some conflicts. 20:34:02 but I'm fine with tc for starters, that might encourage others to join 20:34:09 ttx: I assumed it was like that 20:34:16 jeblair: that would be very helpful yes 20:34:24 ttx: as in, the group of folks that raised their hands 3 weeks ago 20:34:27 (or was it 4) 20:34:30 :P 20:34:39 flaper87: the list is on the etherpad 20:34:59 ttx: yup 20:35:03 #link https://etherpad.openstack.org/p/project-team-guide 20:35:04 i'll go ahead and update the gerrit acl to a new group then so we can change it easier 20:35:17 I planned to write stuff on planes this week but ended up discussing battery life with morganfainberg 20:35:44 * Communicatoins workgroup 20:35:49 annegentle: flaper87: ? 20:35:50 #link http://www.openstack.org/blog/2015/06/technical-committee-highlights-june-5-2015/ 20:35:59 That's the last report we published 20:36:00 posted! 20:36:21 tweet it y'all! 20:36:36 ttx: squandering airplane wifi 20:36:40 I wonder if enough people have been getting it (I guess we ask this question every week) 20:36:40 annegentle: flaper87: did you get any feedback ? Like from people apprecating you doing this ? 20:36:49 +i 20:36:55 ttx: the first week we did and it was good 20:36:58 ttx: not really, but we have lately been coinciding accidentally with the Weekly round up 20:37:02 but I haven't heard much lately 20:37:17 so we might try publishing Wednesdays? I dunno. 20:37:17 flaper87: where/how was this appreciation conveyed? 20:37:26 I fear it's one of those things people complain about when it's not there, but won't exactly cheer when it is 20:37:35 ttx: I sense the same 20:37:45 heh that's fine, I'm used to that :) 20:37:48 anteaya: IRC, email and twitter 20:38:06 but again 20:38:08 flaper87: any links? I missed the email appreciation apparently 20:38:22 there wasn't much and it was just the first day 20:38:50 anteaya: it might have been just IRC and twitter. I'll try to find logs and emails 20:38:52 timing note: we'd need to publish Wed. if we want a link in Friday's weekly newsletter 20:38:53 * flaper87 has a very bad memory 20:39:01 ok, anything else on the communications wg ? 20:39:07 think we can wait til next Wed. to do another post? 20:39:12 annegentle: +1 20:39:21 I think it's fine yes 20:39:24 flaper87: thank you 20:39:30 maybe a simple email to announce Searchlight's status change? 20:40:06 dhellmann: can TravT do that? I think it'd be great if he presents the project too 20:40:11 maybe can be the co-PTLs there self-congratulating 20:40:12 I like the idea of training folks who want this info to find it in one place, not scattered 20:40:23 since I believe scattered was one of the complaints 20:40:41 and then mention it in next week edition 20:40:46 flaper87, ttx: that works for me 20:40:50 flaper87: what? 20:40:59 anteaya: we can have one "official" place and let the rest of the folks share as they want 20:41:00 just trying to figure out why the gate job failed... 20:41:04 TravT: send email to list saying you got accepted 20:41:08 TravT: ^ 20:41:22 TravT: where you == SearchLight 20:41:24 :P 20:41:28 flaper87: yes, as long as they can track from the "offical" place 20:41:31 i can do that, but also would be pretty happy if it came from any of you. :) 20:41:37 anteaya: I think regularity is fine to set expectations for "where" in addition to "when" 20:41:43 oh, i think there's an oslosphinx problem right now, we may need to reapprove some changes 20:41:43 * Other workgroups 20:41:52 TravT, ttx: ^ 20:42:00 ANy other workgroup naturally emerging from chaos while I was looking the other way ? 20:42:05 annegentle: as you see fit, but I do think discoverablity was an issue 20:42:08 jeblair, TravT : I think they decided that was actually a pbr issue and lifeless was working on a new release? 20:42:17 it was and we are 20:42:24 ok. good. 20:42:33 anteaya: yeah I do agree 20:42:40 no progress on the scuba team yes ? 20:42:44 yet* 20:42:44 dhellmann also are you who we talk to about pulling the repo in? 20:42:57 we've been working on splitting it out from glance as-is in the following repo: #link https://github.com/lakshmisampath/searchlight/ 20:42:57 its just hit gate jobs 20:42:58 TravT: I can help you get set up for that, but the infra team does the real work 20:43:15 i'd like to get it back under gerrit... 20:43:19 * ttx blames that guy in the bavarian costume and his damn beer 20:43:20 TravT: drop by #openstack-relmgr-office 20:43:43 ttx: bavarians have nice hats 20:44:02 ttx: not yet.... need to schedule set time with lifeless to start work on it 20:44:13 i'm pretty sure the import process is documented .. 20:44:16 markmcclain: ack 20:44:37 russellb: it is, but I don't mind helping out 20:44:38 #topic Open discussion 20:44:40 ack yah 20:44:45 mea culpa 20:44:47 I pushed an agenda for rotating the chair of the cross-project meeting: 20:44:54 #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Chair_rotation 20:44:55 I want to get the requirements thing really moving before focusing on arch 20:45:10 TravT: http://docs.openstack.org/infra/manual/creators.html 20:45:11 We'll include volunteer PTLs in the rotation, but wanted to give a chance to TC members to take their slot before 20:45:11 This week's meeting will be chaired by Mark, anyone interested in leading next week's ? 20:45:14 since reducing debt is what thats all about 20:45:30 just edit the wiki if you are 20:45:35 russellb: thanks. 20:45:38 lifeless: ++ 20:45:49 having a few weeks advance on that rotation would be nice 20:46:29 I can't the next two weeks, sorry, guess I could then volunteer for last week of June or something 20:46:31 with all of those people to choose from, we shouldn't have to repeat being chair 20:47:25 dhellmann: right, I prefer to be ready to sub in case of last-minute issues ,rather than put myself on the rotation again 20:47:37 ttx: I think that makes sense 20:47:43 annegentle: feel free to insert your name at a later point 20:47:56 I'm taking June 30th! You can't have it! :) 20:47:59 not everyone at the same time 20:48:00 ttx: right 20:48:17 mordred: The dates on the M naming poll mentioned opening of the poll on Jun 8, so I guess we shouldn't delay that a lot more 20:48:30 I suspect you might want to finalize that before you board your next plane 20:48:37 yup 20:48:40 working on it now 20:48:50 the japanese openstack user group is helping to validate the current list 20:49:03 the japanese community did a.. pretty nice job vetting the names for us 20:49:05 because, you know, it's nice to have friendly help 20:49:06 yah 20:49:07 nice 20:49:09 they're AMAZING 20:49:12 it's like the first time the locals just take over the process 20:49:27 Ive also asked fungi for the email list so I can set up the polls 20:49:34 so as soon as I have that, I'l get the election under way 20:49:42 yep, i'm trying to wrangle those now 20:49:59 Also, *lots* of great names this time 20:50:02 yah 20:50:05 the list is pretty amazing 20:50:17 so I am not going to propose any of the non-valid names to the TC for override 20:50:28 even though there are several good ones in that list too 20:50:29 mordred: +1 20:50:35 honestly, i'm excited about using condorcet on a list like that 20:50:39 yah 20:50:52 jeblair: it kinda makes it worth it :D 20:51:05 also with an electorate the size of the entire foundation membership 20:51:39 you'll definitely need to split it a bunch of times to feed it into civs 20:51:43 mordred: you'll see there is a bit of unfun with more than 1000 voters in CIVS 20:51:52 i think they limit batches to 1k addresses 20:51:57 yeah, that 20:51:57 yes 20:52:00 meh. I can handle it 20:52:02 and then you have to just pray they won't all vote at the same time 20:52:17 so - quick question 20:52:25 first 20 minutes 20:52:35 mordred: you have 8 min 20:52:58 worst case i'll scrape addresses from the foundation member db via an ugly join query 20:53:03 "quick" 20:53:04 CIVS has an option for a public poll where you just have a link and you can vote, and it does ip address matching for uniqueness 20:53:19 this isn't really a poll likely for gaming and wants inclusivity 20:53:23 fungi: do I get to vote this time or does CIVS still have archaic domain restrictions? 20:53:34 perhaps we should just make one of those and post the link to the mailing list/twitters ? 20:53:53 mordred: that's neat; and it's pretty close to what we used to do. maybe we should think about it next time (especially if this time is difficult), but stick with emails for this go-around? 20:53:54 won't ip uniqueness be a problem for people at the same work location? 20:53:55 markmcclain: what are your domain problems? 20:53:58 markmcclain: no clue, honestly. starting to wonder if we should just host a civs instance ourselves 20:53:59 mordred: IP matching makes some corporate blocks unable to vote more than once though 20:54:05 edleafe, ttx: good point 20:54:20 use your phone to vote 20:54:24 mordred: CIVS barfed on .xyz domain during the last elections.. need .com, .net, etc 20:54:25 mordred: surveymonkey did IP+Browser cookie, which is slightly better 20:54:30 markmcclain: hah 20:54:35 mordred: civs doesn't believe some tlds created after, like, y2k, really exist 20:54:57 fungi: neither do I 20:55:04 hah 20:55:07 all those new tlds can get off my lawn 20:55:23 (as an aside, the "starting point around Nova" came up again in discussions at the OpenStack CEE day. It's like a question people actually have, not something we dreamt up) 20:55:27 k. well, well do emails this time but maybe investigate open polls next time 20:55:34 markmcclain: as long as you can vote with your arpanet address as a backup 20:55:36 ttx: ++ 20:55:45 jeblair: haha 20:55:45 ttx: ++ 20:55:50 ttx: heh yeup 20:55:54 yep even 20:56:10 Anything else, anyone ? 20:56:12 * dhellmann thinks annegentle's texas accent is getting thicker 20:56:23 whats is "starting point around Nova" ? 20:56:24 dhellmann: oh noes 20:56:27 * russellb out next week 20:56:52 johnthetubaguy: a tag describing the minimal set of projects you need to deliver a minimal compute capability 20:56:55 * annegentle says "I am from OHIO and stamps foot." 20:57:06 ttx: ah, cool, thanks 20:57:09 also known as the needle in the haystack 20:57:15 * annegentle also out next week 20:57:28 theres probably three correct answers there, but yes 20:57:42 only three? 20:57:49 johnthetubaguy: my guess is that they want an answer. Not necessarily The answer 20:57:58 * dtroyer thirds out next week 20:57:59 starting point, not end point 20:58:07 but that's discussion for next week 20:58:11 last time we talked about this, we narrowed it to two answers, so that's pretty good. 20:58:13 ttx: seems a fair request, but yeah 20:58:15 like when you start piano you start with twinkle twinkle little star 20:58:41 mary had a little lamb 20:58:42 al-righty. Let's close this 20:58:43 jeblair: actually, I think sdague and I finally understand we were talking about two different things 20:58:50 so I'm on board with sdague's definition of that now 20:58:55 mordred: still sounds like two answers :) 20:58:56 thanks, ttx 20:58:57 russellb: that works too 20:59:00 Thanks for coming! 20:59:03 he was answering that question - my competing answer is answering a diffrent question 20:59:05 and see you next week obviously 20:59:06 yeh, I need to massively refresh that document after a bunch of conversations that were had 20:59:26 sdague: you think you can do it for next week meeting ? 20:59:26 * johnthetubaguy needs to go read that... 20:59:28 sdague: thanks for driving the proposal 20:59:35 yes, I think so 20:59:37 my competing answer is "as a production end user, what is the minimal thing that's useful to run compute workloads" 20:59:40 cool. 20:59:43 sdague is answering the question from CEE day 20:59:54 "what is the smallest set of things I can deploy so i can start poking with this thing" 21:00:13 this compute thing, but yeah 21:00:15 yah 21:00:17 #endmeeting