21:01:25 #startmeeting crossproject 21:01:26 Meeting started Tue Mar 15 21:01:25 2016 UTC and is due to finish in 60 minutes. The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:29 The meeting name has been set to 'crossproject' 21:01:31 thingee: am still not on the list 21:01:55 * thingee adds nikhil now :( 21:01:58 hello 21:02:02 missed ya'll 21:02:03 hiya 21:02:05 thingee: thx 21:02:05 o/ 21:02:11 o/ 21:02:14 agenda today https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda 21:02:21 pretty full so lets get to it! 21:02:22 o/ 21:02:52 #topic Compute node HA (a.k.a. automatic evacuation of instances 21:03:00 .o/ 21:03:04 o/ 21:03:04 o/ 21:03:05 #link http://specs.openstack.org/openstack/openstack-user-stories/user-stories/proposed/ha_vm.html 21:03:10 aspiers: hi! 21:03:13 hey :) 21:03:25 o/ 21:03:37 conscious that my slot doesn't have too much time 21:03:39 o/ 21:03:51 \o/ 21:03:54 Thanks thingee ! 21:03:59 thingee: shall I kick things off? 21:04:02 \_/o/+ 21:04:08 aspiers: yes 21:04:08 o/ 21:04:09 ok 21:04:15 hi everyone :) I'm new to cross-project meetings so please bear with me :) 21:04:24 since Tokyo I've been moderating weekly meetings of the #openstack-ha IRC community 21:04:36 we've been collaborating on various approaches to implementing automatic "evacuation" of VM instances 21:04:36 #link https://review.openstack.org/#/c/257809/ cross-project spec 21:04:54 "evacuation" is in quotes, because so far we've really been dealing with resurrection of dead VMs, via nova's evacuate API 21:05:14 however in the future, proactive evacuation of live VMs based on (say) alarms from ceilometer is certainly a possibility too 21:05:32 alarms from Aodh* 21:05:39 right 21:05:41 :) 21:05:43 we've been trying to promote awareness of the various approaches out there 21:06:05 with the ultimate goal of facilitating convergence on a single implementation, if possible 21:06:23 you can find a summary of all known existing approaches (to resurrection) here: 21:06:32 #link https://etherpad.openstack.org/p/automatic-evacuation 21:06:48 first question from my side is: how cross-project is this, really? which projects do we expect to be affected? 21:06:58 aspiers: do you mind telling us here and identifying in the spec the projects this involves? 21:07:00 yes 21:07:02 heh 21:07:12 sure 21:07:30 IMHO the answer is "probably less than 10 projects": 21:07:35 1. obviously nova is involved :) 21:07:36 heh 21:07:58 2. ceilometer 21:08:01 3. aodh 21:08:11 4. senlin is clearly aiming to be involved 21:08:35 5. mistral - Intel have been working on a PoC where mistral orchestrates evacuation (ddeja who is here with us :) 21:08:53 6. heat has been aired in the spec linked above as a possible alternative to mistral, not sure how realistic that is 21:09:06 7. congress: I expect this to be needed in the future, to accommodate different recovery policies 21:09:12 may the subset be defined by "any project involving quota management" + what triggers and what effectively does the ressurection ? 21:09:15 and maybe 8. cinder? 21:09:34 what about manila? 21:09:51 I suspect someone wants this for ironic eventually, based on ideas I've seen, but this would just use nova live-migrate or something, right? 21:09:53 rockyg: I hadn't thought about manila yet :) 21:10:07 oh yeah of course: also ironic and Triple-O 21:10:10 (so ironic, as a virt driver, would just work) 21:10:13 i'm curious if there are some criteria for determining if our project is affected? (something akin to what samueldmq said) 21:10:14 (once it has migrate) 21:10:15 there's the whole question of fencing of compute nodes 21:10:23 gordc, cdent ^ 21:10:28 25. watcher? 21:10:30 elmiko: not yet 21:10:39 yes quite possibly watcher too :) 21:10:45 thingee: just reading spec now (missed some of earlier chatter) 21:10:51 jroll: I think it's very likely this would use public apis in Nova, so ironic should "just work"(tm) 21:11:01 alaski: cool, that's what I hoped 21:11:15 if congress is in charge of deciding what triggers workflows, then other projects don't necessarily have to be aware that data collected from them is being used in this way 21:11:17 yeah, nova already has the APIs for this as far as i know 21:11:22 aspiers: have you look at the events ceilometer captures currently? 21:11:30 aspiers: agreed 21:11:33 I don't see what Nova needs 21:11:41 gordc: not nearly as much as I should 21:11:56 aspiers: elmiko: interesting, I'd expect that we had defined keywords to help identifying involved projects 21:11:57 bauzas: currently the nova evacuation process is not robust enough (I'm told) 21:12:00 fwiw, there is an ibm product that already does something like this, event-driven automatic evacuation, i could get names of people involved in that, they might also be invovled in this, 21:12:06 but they had some nova api extensions i believe 21:12:18 like rate limiting the migrations off the compute node 21:12:23 rather than just a huge batch 21:12:32 mriedem: yes that is one of the problems which needs tackling 21:12:38 samueldmq: yea, i'm very curious as i could a hypervisor dropout affecting sahara in a negative way 21:12:46 scalable scheduling 21:12:47 *i could see 21:13:04 aspiers: i think quite a few of this is already captured in Ceilometer via messages sent from services or the polling done 21:13:22 elmiko: ++ 21:13:23 aspiers: +1, the current prototype i’ve seen for Masakari specifies nova hosts for evacuation versus using the scheduler 21:13:34 nova host* 21:13:36 you can tell when a host or instance is up or down and provisioning failures i believe are already sent as events by nova 21:13:39 aspiers: well, evacuate for instance HA means that you resurrect your instance, and then impacting the users 21:13:59 so, for the sake of time, what's the goal for this meeting? "should we pursue this" or? 21:14:06 there are lots of architectural considerations 21:14:07 jroll: ++ 21:14:12 and jroll is right, we can't discuss them now 21:14:12 I personally see it as instance recovery vs. availability 21:14:20 jroll: ++ 21:14:36 bauzas: also, you can't evacuate unless the compute is donw 21:14:37 *down 21:14:49 in the short time we have, I just want to understand how this relates to the cross-project team (if it's called a team, I'm not sure) 21:14:51 methinks anyway 21:15:04 aspiers: i'm not sure it does 21:15:06 yup, I was just explaining the problem about using evacuate for HA 21:15:11 for those interested, comment on spec i guess? i have a feeling most of this is already covered across various projects 21:15:16 aspiers: the spec was proposed in the repo 21:15:17 :) 21:15:17 aspiers: if you have API needs in nova, then propose those as specs for nova 21:15:25 thingee: yeah, not by me ;-) 21:15:39 ok, so I think we're saying, sure do this and use existing apis? 21:15:54 thingee: that is what it sounds like 21:15:55 and it shouldn't have been proposed spec as sdague mentioned earlier 21:15:56 thingee: and if there are gaps in the API, propose project-specific specs to fill those gaps 21:16:00 <_gryf> mriedem, I think all the api are in place, if we talking about nova 21:16:03 mriedem: +1 21:16:06 mriedem: +1 21:16:23 yup, I agree too 21:16:26 mriedem: ++ 21:16:28 ok will leave a comment to have this spec abandoned 21:16:40 well 21:16:41 #topic super scheduling 21:16:44 aspiers: hunt down jwcroppe if you haven't already 21:16:50 ok, thanks 21:16:52 fhermeni: hi! 21:16:56 hi there 21:16:57 it'd be great to have a single bp to use cross-projects (in the topic of changes) 21:16:58 #link https://review.openstack.org/#/c/210549/ spec 21:17:19 (first OS meeting, be cool) 21:17:33 got a lot of first timers today :) 21:18:14 fhermeni, we're generally a friendly bunch 21:18:22 we’ll see 21:18:36 lol 21:18:43 so we have no josh harlow, so I want to understand where are we going with this spec. I guess a little intro and what you need from the general cross-project team 21:19:04 ok. Indeed, josh is afk (6am local time) 21:19:19 so there is 2 objectives 21:19:46 1) expose a single entry for every scheduling aspect to allow to exhibit a higher perspective on scheduling expectations 21:20:07 2) abstract the scheduler a bit to decouple from existing implementation 21:20:23 in that sense, you support the spec, you are suitable 21:20:52 I haven't read the spec yet 21:20:55 (but I will) 21:21:02 so we designed the spec for being extensible, with a very few orthogonal concepts 21:21:09 does it at least acknowledge that the problem it's trying to solve is really hard? 21:21:22 yes of course 21:21:37 (I am writing VM placement algorithm since 10 years, I know it is hard ;)) 21:21:38 okay 21:22:04 the exception cases are likely to be where it gets tangled up 21:22:07 so we drafted a spec and wanted to have feedback from the involved communities 21:22:27 fhermeni: I couldn't tell from the spec if you were proposing having a scheduler that makes decisions using all the state/context/data/resources of many different services, or if you were proposing an abstraction that all (local) schedulers would implement. 21:22:50 fhermeni: so we had kind of this discussion in the past during previous summits 21:22:57 every summit 21:23:00 lol 21:23:05 fhermeni: that's why something popped up called Gantt 21:23:07 I don't think we can call it a summit without a scheduler session 21:23:18 it is an abstraction. The backend may or may not fullfil all the expectation (the extensibility concern) 21:23:40 with the clear intent of splitting out the nova scheduler to be a separate project that others could consume 21:23:40 lifeless: it is not a surprise to me 21:24:04 it was a dead-end for technical reasons at least, but also valid design concerns 21:24:10 this sounds a bit like a blog post I wrote last year http://blog.adamspiers.org/2015/05/17/cloud-rearrangement/ 21:24:20 bauzas: gnatt isn't active anymore is it? 21:24:28 gordc: nope, defunct 21:24:35 kk. good to know 21:24:49 as an academic, I observe there is about 50 VM placement algorithm that are proposed yearly. No one can propse or test a validation with OS because of the thigh coupling with Nova 21:25:09 mostly because we weren't having those stable interfaces we were needing to have 21:25:10 decoupling might help 21:25:24 fhermeni: is your scheduler completely original or does it leverage nova's scheduler? 21:25:34 fhermeni: see, the real problem of that is 2 words : tech debt 21:25:52 bauzas: that is one of the point that require nova output 21:26:01 bauzas: does the language wrap nova features 21:26:25 so in the interest of time here, I agree with sdague and cdent that probably engagement should happen with nova here? I'm not really sure why this needs a cross-project spec. 21:26:25 bauzas: and ofc I cannot reply objectively because I am out of nova and an OS newbie 21:26:31 we keep saying vm placement, but this is about general resource placement, correct? 21:26:48 thingee: ++ 21:26:51 thingee: just to be clear sdague and I have different ideas on how that engagement should happen 21:26:55 jroll, ++ 21:26:59 thingee: ++, I think if something like this gets pulled into nova, then it may require some cross-project work, but it needs to begin with nova 21:27:13 cdent: and I agree with sdake 21:27:18 damn 21:27:21 sdague 21:27:21 cdent: sorry 21:27:29 hoisted on your own tab key bauzas ! 21:27:33 :) 21:27:42 to do correct global placement is far larger than just nova 21:27:53 bswartz, ++ 21:28:03 you need information about storage, networking, compute, and information that exists nowhere in openstack today 21:28:06 Congress would play a part 21:28:26 I am ok discussing with nova ofc. The language is quite simple so I am not affraid about its suitability but it is quite different from the pending spec I read about the proposed generic api for nova 21:28:27 bswartz, you copied my keyboard! 21:28:30 thingee: I think it could be useful to add 'keywords' in a spec, that'd identify what projects are affected 21:28:38 this will need to know about the placement of services too in such a case? 21:28:45 bswartz: that's exactly why we need stable interfaces and a correct model for describing resources 21:28:49 samueldmq: sure 21:29:06 thingee: so it will be easier to identify proposals that only relate (mostly) to a single project 21:29:13 both were not the case in nova a couple of months before, and that's gradually improving 21:29:19 bauzas, which is why this is crossproject. More resources than just vms and compute nodes 21:29:37 thingee: I will propose a change to the spec template 21:29:38 yeah I'm only arguing that while nova involvement is essential, this is in no-way nova-specific 21:29:42 fhermeni: so I would say figure out what happened with gnatt, see if there is a need to revive that. I'm not really hearing much people here having an interest with global placement scheduler though 21:29:54 rockyg: so, see, I had this convo a lot of times before, and had no clear commitment on resource placement for others than vms 21:30:05 thingee: you don’t, don’t worry we have 21:30:09 * jroll is curious how many people here know the details of the nova scheduler rework 21:30:12 thingee: watcher is an example 21:30:20 and the plans for the future 21:30:31 people want x-project affinity for placing instances, but I haven't seen a clear interest for placing something else but instances 21:30:33 thingee: I think we're all interested, but we've been burned by past failures and fear getting burned again 21:30:35 jroll: take jaypipes out for lunch 21:30:44 mriedem: oh, I know the plans, but curious about others :) 21:30:57 jroll: i don't 21:31:02 e.g. "is there a need to revive gaant" 21:31:12 I'm aware but not in deep 21:31:19 it's too much to describe here, but I think it's good background reading for this topic 21:31:25 * jroll finds email 21:31:50 #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html 21:31:54 So, there are all sorts of issues in multiregion clouds that include other resources besides vm 21:31:56 folks may want to read that for some context 21:32:00 jroll++ 21:32:41 The ops community wants placement related to networking capabilities 21:32:57 rockyg: I'm certainly sure, I just said I haven't seen user stories yet 21:32:58 indeed. For testbed for example, it is a prime feature 21:33:03 And HPC want placement wrt data storage 21:33:05 so anyway, I agree that the super scheduler folks should chat more with the nova scheduler folks 21:33:19 rockyg: that's affinity for vms 21:33:21 and figure out how this fits in, if at all 21:33:23 HPC as well indeed. network and cache affinity 21:33:25 yea, i've seen some user asking question about data and compute affinity with respect to hadoop 21:33:43 bauzas, but global rather than local 21:33:45 elmiko: indeed. VM close to the storage for data intensive workload 21:33:52 cdent: can we get some folks interested in engaging with this spec? I think you and sdague are the only from nova that have responded to the spec 21:33:59 fhermeni: right, and asking for more options in sahara to control the affinity 21:34:00 could we stop making confusion between x-project affinity for placing vms, vs. placing things like volumes ? 21:34:16 thingee: I made a very clear statement too 21:34:28 I think it is pretty clear that bauzas should be actively contributing to the discussion on the spec 21:34:44 especially to clarify some of the thing he just clarified here 21:34:47 cdent, ++ 21:35:00 I don't see the need for that being a x-project spec honestly 21:35:03 I'd love to see a session on this at the design summit 21:35:07 at least now 21:35:08 there's a vast amount of assumptions that people make about the use cases and nobody seems to really agree 21:35:20 ok, anyone disagree with bauzas? 21:35:22 bauzas: ++ this needs to start in nova and expand 21:35:35 going 21:35:35 the nova work is making rooms for other resources like network and volumes 21:35:36 ... 21:35:39 going 21:35:44 fdafda 21:35:46 ok to me 21:35:57 gone! 21:35:59 cdent has opinions it seems? 21:36:12 jroll: I do, but not really on where the talk happens 21:36:13 #agreed fhermeni and harlow to work with nova-scheduler folks to further this along to later propose cross-project 21:36:34 cdent: right on 21:36:34 fhermeni: thanks 21:36:44 with pleasure 21:36:48 #topic rolling upgrades 21:36:50 kencjohnston: hi 21:36:52 fhermeni: http://eavesdrop.openstack.org/#Nova_Scheduler_Team_Meeting 21:36:52 howdy 21:36:55 #link https://review.openstack.org/#/c/290977/1 spec 21:37:02 third first timer... 21:37:18 nice =) 21:37:42 This spec was copied from a Product Work Group developed User Story 21:38:14 with the intent of providing common problem description and use cases for upgrade improvements 21:38:29 we didn't get rolling schema upgrades into keystone last release. 21:38:34 realizing that work is underway in many projects on this front 21:39:01 so I think dansmith and sdague bring up a good point that this should reflect current use cases that are already in flight and in progress. 21:39:05 we should start there 21:39:26 thingee yeah happy to do so and I wlll incorporate their feedback 21:39:41 this is similar to that ops spec. 21:39:49 however, this spec needs ownership of someone technical that can surface the problem, and agreed concepts of a solution as well as existing shared libraries like oslo.versionobjects 21:39:50 but more narrow in scope. 21:40:48 to be clear, the product working group is trying to engage more with the community in the use cases they receive from things like the user survey. 21:40:55 thingee +1 21:41:24 but this was received the wrong way I think. mostly because it was looked as a wish list since some of the stuff is not the current direction today. 21:41:45 we already have a tag for this? https://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html 21:41:47 However, I do think it would be good if the product working group was able to find someone who wants to own these repos from the technical side 21:41:52 gordc: yeah i was going to point that out 21:41:55 thingee Correct, and that is on me. I misunderstood some important direction thingee provided me on that front. 21:42:01 are we trying to find owners for each project? 21:42:20 if a project doesn't have the rolling upgrades tag, work with each project on what it takes to add rolling upgrade support 21:42:22 gordc: no, and I need to document this better from cross-project perspective... 21:42:38 is this a guideline spec? 21:43:00 or technical guideline spec? (first one being generic guideline) 21:43:05 so cross-project specs I feel like should be general problem, general solutions and linking to existing libraries if they exist. 21:43:19 or a use these existing tools and stop adding tech debt to my prj spec? 21:43:24 individual projects can do their own spec if they need to hash out particular details that involve their individual services. 21:43:35 so all three then 21:43:39 seems like most CP specs specify an end goal and recommended solutions 21:43:49 the end goal here is clear - the tag 21:43:56 but we need these general ideas and solutions surfaced up somewhere, instead of what mriedem suggested of having to figure things out and dig for this information. 21:43:58 what is a cross-project spec? 21:44:05 the recommended solutions is less clear, as we can't just copy/paste code 21:44:10 what does define something as a cp spec? 21:44:29 yes, then we'd remove the Proposed solution Heading from the spec IMHO 21:44:30 samueldmq: I think it's something that involves more than one project. 21:44:38 but rather should have things that get you there - if you use RPC, you should version that properly. you should do expand/contract style migrations. etc. 21:44:41 personally, I really don't want us to have a spec to cover all of upgrades 21:44:55 if we need a spec to distill best practices for versioned RPC, then we can do that 21:44:56 I just saw the previous 2 specs and the comment from Dan on this one and was confused 21:45:07 (for example) 21:45:09 dansmith: ++ 21:45:10 dansmith: + 21:45:16 dansmith: sure, if you want to call it that, that's fine with me 21:45:23 there's a number of things (e.g. RPC) that projects do that make upgrades hard 21:45:24 dansmith: that's not different from the logging spec best practice 21:45:26 or eventlet 21:45:34 thingee: I got that question after reading cdent's comment in patchset 2 at https://review.openstack.org/#/c/257809/ 21:45:36 yeah, "upgrades" seems like a blanket idea, which can mean many different facets of design to different projects 21:45:41 we could clarify what things those are, and how a project might solve them 21:45:48 like log guidelines i guess? http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html 21:45:52 (whether that's one spec or many, I'm not opinionated) 21:45:52 jroll: right, versioned rpc applies to a lot of projects.. versionedobjects will be picked up by fewer of those, and some will use neither 21:46:04 mriedem: exactly what I was mentioning above :) thanks 21:46:05 yep 21:46:06 thingee: ah you beat me to logging :) 21:46:20 dansmith: there's other solutions too, like "don't change the rpc wire protocol" - crazy but it totally would work 21:46:27 :P 21:46:39 dansmith: I think a best practice is good. 21:46:50 jroll: right, which is why I kinda hesitate to do any of this, but I think of all the topics, versioned RPC best practices is probably the widest applicability 21:46:58 jroll: that's what we use :) 21:47:11 I do question if a spec is needed for best practices, or if this should be more like a (project guide?) docs thing 21:47:22 Also the upgrade tag is not the final resolution here, but the indicator that it was reached 21:47:22 or a blog, or a wiki 21:47:23 etching the protocol in stone without possibility of future revision encourages unsavory sorts of data serialization with nasty security vulnerability surface area though 21:47:33 jroll: ++ 21:47:33 fungi: I was about 10% serious :) 21:47:35 jroll: yeah, I've tended to put this kind of stuff in blogs 21:47:37 heh 21:47:41 jroll: as mriedem pointed out earlier, this isn't different from best practice of logging or eventlet which we cover today in our repo 21:47:51 jroll: I'd rather leave specs and TC-blessed things for required stuff 21:48:02 thingee: okay, that's fair precedent 21:48:22 I don't have a strong opinion, I guess. writing things down is what's important to me 21:48:24 Well I feel that many developers pick cp spec and just assume it to be source of truth 21:48:44 * thingee thinks if there is disagreement of what should go in this repo, he should propose what should go in this repo in the project team guide 21:48:46 dansmith: ^ 21:48:48 I feel we need to decouple the technical details and emphasize more on best practices 21:48:51 i feel like a lot of the disagreements over cross-project specifications have to do with meaning people are reading into the term "specification" 21:48:52 nikhil: right, I'd hate for someone to read a spec, think it doesn't work for them, and decide not to pursue upgrades because that's the required solution 21:48:54 nikhil, if not source of truth, director to the various project sources of truth 21:48:54 and then we can hash it out there. 21:49:23 dansmith: I mean we have precedent of best practices, but we don't have to keep doing that. 21:49:31 fungi: that's a good question 21:50:04 but I think rolling upgrades is a common problem people are trying to solve 21:50:05 thingee: yeah, I'm not super familiar with the PTG, so I can't really say, but sounds reasonable 21:50:05 fungi, ++ 21:50:09 thingee: I like CP specs, but it would be pretty good survey white paper sort of thing that has pointers to best articles or something of such sorts 21:50:23 i don't think it's necessarily a bad thing we realised everything so far is probably overreaching. we're just confirming they are not required for everyone 21:50:30 dansmith: what's ptg here? :P 21:50:32 nova added specifications, then neutron, then others followed suit. then someone thought we should maybe have something like specs to coordinate stuff across multiple projects, but still called that a "specification" 21:50:42 dansmith: oh pwg? 21:50:44 heh 21:50:52 thingee: project team guide you mentioned above? 21:50:57 fungi: yes, either meaning of specification or cross-project :) 21:51:10 dansmith: oh gotcha 21:51:11 thingee: I think I misread, 21:51:19 you meant use the PTG to describe what CP specs are for? 21:51:31 Can't remember which project, but they have RFEs for non developers to describe their needs 21:51:34 dansmith: yes, because there are disagreements here it seems. 21:51:45 rockyg: ack and I agree to what you said 21:51:47 rockyg: neutron and ironic 21:52:21 sean dague isn't present, I know he had disagreements here. 21:52:23 And this doc is pretty much an RFE. 21:52:44 what does RFE stand for ? 21:52:50 rfe is also known broadly in free software as a "wishlist item" 21:52:51 request for enhancement 21:52:53 Request for Enahancement 21:53:02 thanks 21:53:19 as in "here's something we'd like to see happen, but we don't know how it should be done or who will actually do it" 21:53:20 and I agree it makes sense to have them 21:53:31 if we're going to get requirements from non-dev people 21:53:36 and once the RFE is fleshed out with the stuff we've talked about, either individual project specs or cross project specs or both can be generated by devs 21:53:48 #action thingee to define cross-project specs in project team guide 21:53:51 fungi: right, usually only happens if money is exchanged somewhere :) 21:53:58 rockyg: ++ 21:54:05 kind of a bummer that we have to go back to this, but I don't want us to keep getting blocked here. 21:54:09 thingee: nice! should our spec template include something as well? 21:54:24 rockyg +1 21:54:25 fungi I do want to clarify there is commitment from representatives of companies int he PWG to work on this (this being upgrades) 21:54:39 I think part of the problem is that as a volunteer org we need devs to be able to work on it 21:54:43 kencjohnston: +1 21:55:18 #topic stale specs 21:55:27 I think we have devs, but not senior devs. We need the cores and drivers to architect the right directions to go with this 21:55:27 bknudson: agreed, starting on getting RFEs and writting specs down 21:55:28 so nobody is arguing that we should or should not document best practices for projects that want to do upgrades, rather where it should be 21:55:30 #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/089115.html 21:55:31 bknudson: I believe there are devs working on it today and we can continue to ask them to work on this 21:55:37 kencjohnston: carolbarrett: awesome. though it's generally helpful to have the people who will be working on it write up their proposal for how they'd do it so there's more to review 21:55:52 I've listed some stale specs here. 21:55:56 lifeless has a bit :) 21:56:27 jroll: I'm just going to define what the cross-project specs should be for. We can start there. 21:56:34 thingee: cool 21:56:38 thingee: i would abandon them and let them reopen if someone actually cares about it 21:56:47 thingee: I do :( 21:56:59 so this involves the TC to abandon them. I don't have powers. 21:57:06 but I wanted people to be aware 21:57:10 backwards compat is ongoing 21:57:11 and revive whatever you care about 21:57:11 thingee: ah i see. :( 21:57:12 gordc: ++ 21:57:12 I need to update it 21:57:22 lifeless: ok! 21:57:23