20:01:19 #startmeeting tc 20:01:20 Meeting started Tue Dec 15 20:01:19 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:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:24 The meeting name has been set to 'tc' 20:01:26 Hi everyone! 20:01:33 * flaper87 bows 20:01:38 Been away traveling all day, just catching up, so please bear with me if I'm not very up to date on todays reviews 20:01:44 Our agenda for today: 20:01:59 ttx: well, welcome back! 20:02:10 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:16 #topic Resolution about Image Uploads and Linux Kernels 20:02:23 #link https://review.openstack.org/#/c/256438/ 20:02:40 Looks like the proposal, whic hwas mostly consensual last week, met some resistance today 20:03:12 and/or could be split in several steps 20:03:12 it's gotten comments from folks that weren't in the meeting last week 20:03:22 I guess it's mostly around the wording not the resolution itself 20:03:38 flaper87: well... 20:03:58 jaypipes disagrees with the image upload capability, which is pretty central to mordred's proposal 20:04:19 oh, mmh, I haven't read jay's comment 20:04:26 damnit, one can never be up-to-date 20:04:29 I understand what jay means 20:04:38 * annegentle reads too 20:04:43 yes, without being able to hang the proposal on image uploads we're back to specifying what kind of POSIX-like thing is there for tempest to use. i think that's a mess. 20:04:59 *but* I think it's fine as a requirement to call your cloud a nopenstack cloud to require image upload, frankly 20:05:04 it's an interoperability question 20:05:06 Yeah I think the confusion I had around import/upload was better stated by jay as public/private and security/performance stuff 20:05:30 ttx: i think "nopenstack" is what you call it if you _don't_ allow uploads, but yeah. ;) 20:05:45 If some private clouds want to not allow image uploads, so be it, they are just not "openstack clouds, they are a private cloud built with openstack 20:05:49 lol 'nopenstack' 20:05:49 jeblair: ++ 20:05:53 ttx++ 20:06:10 ttx, right exactly, they are not openstack 20:06:20 clouds without image upload are useless 20:06:21 I think this nopenstack thing could have legs ... :) 20:06:21 people can build anything they want with the openstack code 20:06:25 But yes, what ttx said makes sense 20:06:27 which is quite ok, for an openstack private cloud 20:06:31 I'm happy to split this resolution so we can have dedicated discussions on some of these topics but, I'm of the idea an openstack cloud MUST allow for images to be uploaded 20:06:38 I'm not 20:06:38 ttx: you need to stop using that word openstack 20:06:39 this is key 20:06:45 and all of the current clouds allow this 20:06:48 it is ok, for foo private cloud 20:06:53 the "no image uploads" is a theory 20:06:56 that is upheld by nobody 20:07:00 it is not ok for openstack private cloud 20:07:02 sdague: I don't think it means what you think it means ? 20:07:05 where is jay? 20:07:16 mordred: ++ 20:07:21 * ttx can't resist Princess Bride references 20:07:22 annegentle: he's probably on a plane back from the ukraine 20:07:23 mordred: are you sure your thing about bare-metal is right? do you really mean to say every openstack cloud must provide both vms and bare metal resources running on user-uploaded images? 20:07:35 afaik Jay is in Europe this week, so probably asleep :( 20:07:39 jeblair: VMs *or* bare metal 20:07:41 it seems like this still leaves things open for defining that openstack compute clouds must do virtualization (allowing at least some specific platforms to be virtualized) and use uploaded images, while other board-defined trademarks could cover things like openstack container clouds 20:07:55 jeblair: IIRC, it's an or 20:07:56 jeblair: no, I do not mean that 20:08:01 er, yeah so virtualization or run directly on the hardware 20:08:01 jeblair: what I mean is that your cloud must allow the abiliyt to boot a user supplied kernel, and it can do that on vms or bare metal 20:08:07 jeblair: mordred: the bare metal thing is interesting, bare metal can't necessarily run arbitrary images 20:08:17 linux, yes, arbitrary no 20:08:20 it can 20:08:31 jroll, mordred: right; i think i understand the intent is that ether one is sufficient, i'm not sure that's an unambiguous reading of it though. ;) 20:08:33 it TOTALLY can 20:08:36 mordred: jaypipes sent you a reply on the ML: "Monty, just because I'm not there to argue with you in person doesn't mean you shouldn't channel your inner leakypipes and argue with yourself on the IRC channel." 20:08:44 presumably a user who knows he is using baremtal knows _how_ to use it 20:08:48 jeblair: k. we should fix tht 20:08:48 For example, I don't think any distro would cripple their "openstack cloud distribution" by not allowing image uploads by users at all 20:08:50 dougwig: hahaha 20:08:54 snort 20:09:00 ttx: ++ 20:09:01 mordred: I missed "given matching processor architecture", ignore me 20:09:05 You can disable that ability in a specific deployment, but you shouldn't expect that to be interoperable. 20:09:10 jroll: yay! 20:09:15 jroll: right, you have to vaguely know how to build an image 20:09:20 which is all that defcore is about 20:09:24 like it not being just a lolcats jpeg 20:09:24 ttx: +100 - exactly 20:09:36 I think we can all come up with corner cases where a person can try a thing and that thing can not work 20:09:38 o/ sorry I'm late 20:09:40 yep, that's fair 20:09:49 so, do we believe the only interop is in virt? 20:09:54 child had an accident yesterday, had to do forms @ preschool 20:09:55 but I think thathe general idea that a user who is reasonably competent must not be prevented from running a working image that they have built 20:09:56 is key 20:10:05 We are not removing the ability to restrict image upload. We are just saying that the interoperable set is the one that allows you to bring your own kernel 20:10:13 lifeless: hope it's "all's well that ends well" 20:10:18 ttx: yes! 20:10:26 because otherwise it just can't be interoperable. 20:10:32 annegentle: yeah, couple of scratches on eye lens, will heal fine in all probability 20:10:38 owww 20:11:02 ttx: right, because we need to think of this from the OpenStack application writer perspective 20:11:08 and I'll +2 the proposal as is for this reason. 20:11:11 annegentle: I do not personally believe there is any resaon to restrict to vms and not include bare metal 20:11:14 as I belive OpenStack is in the business of giving me machines, be they physical or virtual 20:11:21 also, to that, we can add all the discussions we've had in the last 3 (or 4) months with defcore, glance, API-WG to improve image upload to allow for clouds to use it publicly 20:11:21 sdague: but the app writers already sidestep virt 20:11:30 well, that despite the fact that most clouds do already 20:11:53 annegentle: sorry, in what context? 20:11:57 lifeless: done that myself 3 times, all healed fine 20:11:58 sdague: containers 20:12:05 annegentle: many app writers sidestep virt 20:12:08 annegentle: but not all 20:12:20 annegentle: so you are saying all openstack applications are containers? 20:12:24 there are a specific class of app writers who NEED openstack and CANNOT use containers 20:12:33 sdague: I mean, I've had to re-re-read any virt v containers discussions to understand 20:12:43 the specific thing those writers share is the need to have some amount of control over the kernel of the OIS they are running 20:12:53 whether containers "are" virtualization or not. They're not. 20:13:14 annegentle: ok, I feel like this went a little orthoginal 20:13:15 also people who are writing an openstack "app" that is a container deployment technology *need* virt. 20:13:16 mordred: and I absolutely want to have a "user first" hat on like you 20:13:28 full virt and bare metal are not needed by many people writing 12 factor apps - and that's fine 20:13:31 but we are not and never have been a good home for those people 20:13:32 sdague: ok, fair 'nough 20:13:45 we ARE an awesome place for people to run kubernetes controle planes 20:13:46 because I feel like the point is what are the guaruntees we give applications folks, so they don't have to special case every cloud 20:14:01 and if they are writing to the nova / glance API 20:14:11 and to run docker swarm control planes 20:14:15 there is no interface to deploy a container there 20:14:38 yah 20:14:40 sdague: right, so app devs can sidestep those APIs 20:14:44 yes 20:14:53 mordred: and yes, that's all cool 20:15:06 annegentle: right, and we are trying to give them guaruntees so they don't all have to ignore all our APIs all the time :) 20:15:07 OK, so does anyone besides Jay have objections to the current proposal ? 20:15:10 mordred: hence my ask you don't bury the lede :) 20:15:14 anyd many do - and that's fine for them 20:15:16 so 20:15:29 I think we need to separate product capabilities vs configured options 20:15:53 a *product* called an 'openstack cloud' - be it public, or an installer-style-thing, must IMO allow image uploads 20:16:00 lifeless: the question defcore asked was about deployed capabilities 20:16:20 lifeless: ++ 20:16:22 a private cloud based on that product being able to limit who can upload images - fine IMO 20:16:40 ttx: I'm fine with what's up there 20:16:44 yup 20:16:46 yeah, i think the point that a lot of users have "worked around" openstack's lack of consistent interoperability by adding their own normalization layer (at their own expense) isn't really an argument for giving up making that less necessary 20:16:53 jay's point seems to target not un-certifying private clouds, which makes sense to me 20:17:10 fungi: ++ 20:17:11 there's a huge legal gap between (product capability and trademark definition) and (deployed stuff) 20:17:14 I don't have objections with what's up for review, tbh. 20:17:16 lifeless: but it can't be called "an openstack cloud", it may be called "a cloud deployed from an openstack distribution", I guess 20:17:27 or it can be called a cloud 20:17:31 I don't have objections with what's there either 20:17:33 ttx: we don't certify private clouds today, we certify the product used to install them 20:17:33 without the word openstack near it 20:17:40 ttx: AIUI it anyhow 20:17:42 lifeless: then all is fine 20:18:00 (if your understanding is correct) 20:18:17 but if we want an ecosystem of off the shelf software (open or commercial) that interacts with OpenStack clouds 20:18:30 we need to set that SDK expectation correctly, otherwise it's all tears 20:18:31 sdague: then those products need to be given appropriate acls on the cloud 20:18:35 maybe mordred could sparkle some magic dust on the proposal to make it less worrisome for private cloud vendors 20:18:53 so - I can try doing that 20:18:57 sdague: thats no different to needing a certain size quota, or particular image flavours 20:19:00 sdague: is it? 20:19:01 ttx: why is it worrysome? 20:19:02 but I'm not sure that anything in here talks about that at all 20:19:02 while keeping the guts of it, which is interoperability of things we call "openstack clouds" 20:19:08 right 20:19:15 if it's a private cloud, will anyone know it's being called an openstack cloud? tree in a forest and all. it's private. :) 20:19:17 this is talking about clouds 20:19:31 not about cloud constructoin kits 20:19:38 if someone wants to claim that a running cloud is an OpenStack cloud, it needs to meet criteria 20:19:42 or else it's not behaving well 20:19:45 make it more clear, i guess, that the proposal is specific to public clouds and openstack software distributions seeking interoperability certification 20:19:48 dougwig: it will be the first time someone in IT gets Veritas for OpenStack 20:19:52 tries to plug it in 20:20:04 sdague: I think /some/ private cloud vendors are worried that they won't be able to use the openstack trademark because their product is used to deploy clouds that do not allow user image uploads 20:20:04 and Foobar cloud they were sold doesn't have any of the interfaces for it 20:20:14 ttx: which ones? 20:20:14 sdague: oh, you just gave me flashbacks and nightmares in one word. 20:20:17 ttx: like, who is doing that? 20:20:28 mordred: jay's employer, maybe 20:20:31 ttx: because I'm getting tired of theoretical people with theoretical problems 20:20:45 ttx: I believe fuel installs clouds that can upload images 20:20:51 sdague: so yes, that matters - but as long as the product the company bought /can/ do it, is it an issue? 20:21:00 sure, and I think the concern is not warranted 20:21:06 ttx: if their product doesn't allow it at all, then it's not openstack. If it allows uploads to be turned off, well, that's the deployer's choice 20:21:11 as long as their distribution allows you to build a cloud that allows image uploads, the fact that it also allows you to build ones which don't shouldn't be cause for concern 20:21:14 edleafe: ++ 20:21:15 edleafe: ++ 20:21:22 mordred: ++ on the theoritical people with theoretical problems issue 20:21:27 edleafe: except when its a public cloud... ? 20:21:37 lifeless: when it's a public cloud it MUST allow image uploads 20:21:38 maybe adding a short sentence that says what edleafe just said would alleviate their concern 20:21:55 because then the user of the public cloud is not a private user who had a relationship with the deployment choices, nor should they be 20:22:03 but then , again, I'm fine with approving this as-is, I think it's clear enough 20:22:16 sure, though it does seem like in such an environment there should be a checkbox of "ensure compatibility with OpenStack" 20:22:20 ttx: I'm fine adding one - or doing a follow up that says such a thing 20:22:31 lifeless: if a public cloud turns off uploads, then they are not openstack. 20:22:34 My understanding being that all the other TC members are fine with it 20:22:52 sdague: yah - because we're talking hopefully people who _want_ to verify that peope who write things "for openstack" can run those things on their cloud 20:23:05 sdague: so those people would not be able to assert such a thing if the cloud in question did not allow image uploads 20:23:10 sdague: yeah and that'll enable that ecosystem too 20:23:19 tbh, the discussion is getting confusing at this point. Let's just say that clouds that want to me stamped as OpenStack must allow image uploads, regarless they are public or private. We don't need to care about the mechanics of how/why/when a private cloud would require such certification/stamp 20:23:32 flaper87: +100 20:23:37 yep 20:23:49 you can ALWAYS use the software to do any number of other crazy things 20:23:57 mordred: without Jay around, i don't think we can make a lot more progress continuing the discussion in-meeting. I propose we move to the review -- I'll approve it whenever it passes the majority vote 20:23:58 right 20:23:58 I mean, the combinations are limitless 20:24:00 edleafe: right. *we* are agreed. But we're writing prose folk will try to lawyer-at-us. 20:24:11 edleafe: so I'd like there to be no things that can be taken out of context. 20:24:15 and I propose we move on 20:24:19 flaper87: agreed. You can add the ability to turn it off, but it has to be an *option*. 20:24:20 ttx: ++ 20:24:21 wfm 20:24:26 unless someone wants to discuss another very specific point 20:24:27 I'm happy to comment on the review and reply to Jay's comments with the summary or even my own 20:24:30 the review conversation has been very useful so far 20:24:34 edleafe: right 20:24:41 I'll be replying on the review after the meeting 20:24:43 a bit late, but then that was posted late too 20:24:49 I also haven't read jay's comments yet - so I'll poke those too 20:24:54 OK, moving on 20:24:59 #topic Spin off stable team as separate team 20:25:03 thanks mordred 20:25:06 #link https://review.openstack.org/255159 20:25:13 So this is the final stage of spinning-out the stable maintenance team into its own project team 20:25:22 We had elections over the last weeks and the team has an initial PTL, mriedem 20:25:40 I'll approve this now, since it has more than enough votes 20:25:43 mriedem congrats, wherever you are 20:26:07 #topic Redefine Release Management team mission 20:26:14 #link https://review.openstack.org/255379 20:26:26 So... back in the day the "Release Cycle Management" team was a frankenteam of things I happened to lead 20:26:33 i.e. release management, stable branch maintenance and vulnerability management 20:26:41 Now that the last two are separated (one under Security, the other under its own team) it's time to reword the mission 20:26:54 still short of a couple of votes 20:27:20 alright, we are in 20:27:50 FWIW I'll follow the team at least during the mitaka cycle to see it's off wit ha good start 20:28:13 #topic Rewording Freezer mission 20:28:23 #link https://review.openstack.org/254239 20:28:30 Non-trivial team mission changes need to be formally approved by the TC 20:28:38 This one sounds pretty simple 20:28:49 mostly shortening it, not changing it 20:28:57 ttx: I could just revise their patch, think they'll mind? 20:29:17 annegentle: I don't think Fausto would mind if yo udo 20:29:28 I think he's a bit on/off these days 20:29:29 annegentle: I'd appreciate an edit pass over my suggestion ;) 20:29:42 annegentle: go for it 20:29:46 dtroyer: yep! Ok, on it 20:30:11 the TC puts its famous iron fist on the table and overwrite the PTL proposed change 20:30:23 +s 20:30:25 dtroyer: I'll also start it with To verb 20:30:43 let's come back to that once Anne is done 20:30:51 #topic Cross-project spec rubberstamp: Chronicles of a DLM 20:31:01 thingee: you there ? 20:31:17 #link https://review.openstack.org/#/c/209661/ 20:31:17 ttx: hi 20:31:25 thingee: care to quickly introduce this one ? 20:31:46 sure 20:31:48 looks pretty consensual to me 20:32:09 missing a few +2s before we can rubberstamp it 20:32:11 at the summit we came to consensus we wanted to use tooz but have a refernece implementation for gate testing 20:32:41 since then devstack supports bring up zookeeper as a first pass on a ref implementation 20:32:55 (annegentle: let me know when done) 20:32:58 there are also other drivers coming into tooz for distributed lock management 20:33:00 etcd https://review.openstack.org/#/c/246879/ 20:33:04 done diggity ttx 20:33:08 consul https://review.openstack.org/#/c/245362/ 20:33:11 yay ^ 20:33:16 I think the future looks bright 20:33:34 w0000h00000! Gotta love the options 20:33:48 we are following a similar model to MQ's where there has to be two maintainers I believe behind a driver. 20:33:54 thingee: we're still planning on deprecating the less featureful toox drivers, yeah? 20:33:57 thingee: ++ 20:34:10 flaper87: I have to say, I mostly hate options here 20:34:12 (like redis) 20:34:16 thingee: like, the ones that 'work' but don't actually work 20:34:18 like redis 20:34:35 mordred: call me maybe.... 20:34:44 because it just means segmenting our operator community into islands of knowledge that can't help each other 20:34:45 sdague: I also hate the options, but I think the current set of curated options are not the worst thing that has ever happened to us 20:34:47 sdague: it depends. If we're talking about the whole DLM discussion, then yes. I love the fact that tooz now has support for other consensus services 20:34:51 mordred: that's a good question. I need to follow up with julien on that 20:34:53 sdague: I like having one non-Java option. I agree that options are not necessarily a good thing 20:35:00 sdague: they seemed segmented already 20:35:19 sdague: if the operator community were willing to converge, we could do so really very easily 20:35:22 sdague: I also agree, unfortunately majority wanted options. I think the ref implementation is going to be what kvm is today in openstack nova 20:35:24 there was at least one vocal never-consul and one vocal never-zk 20:35:28 I would have settled with two (the best option and the non-Java option) 20:35:30 ttx: ++ 20:35:33 sdague: oo good point, but it's a natural progression 20:35:58 sdague: also we had good operator presence and this is what they wanted. 20:36:05 more hammers, more nails, more finesse as we go 20:36:05 options 20:36:05 thingee: so be it 20:36:07 still one vote short 20:36:16 FWIW, we tried to not have options at the summit and the result after talking to OPs and based on the knowledge we had back then, we thought tooz + options was the probably the best thing in this case 20:36:37 we also thought that qpid was a good idea 20:36:40 * flaper87 remembers entering the room with his "I want just one solution" hat on 20:36:44 sdague: who did ? 20:36:46 flaper87: yeah even though I was moderating I was definitely leaning towards no options. 20:37:07 lots of people, options were important. Erlang is yucky. 20:37:24 sdague: for the record, I've never thought qpid was a good idea 20:37:25 and, it turns out that superstition based on language, is silly 20:37:44 the important thing is software has been out there and used under load for a long time 20:37:47 * flaper87 still doesn't think rabbitmq is the best technology to use there BUT that's a whole different discussion 20:37:57 anyway, fwiw, in this case, we also listened to OPs 20:37:59 but, I'll let it go now 20:38:03 flaper87: for the record, I've never thought rabbitmq was a good idea 20:38:12 sdague, ttx lets bring back the burrow mq 20:38:15 * flaper87 hugs mordred 20:38:30 hmm, missing one vote... jeblair, russellb, lifeless ? 20:38:52 thingee: about that, I'm wondering if we should not burrow cue 20:39:04 since it looks a bit dead 20:39:25 * thingee takes note 20:39:34 ttx: I need to do a final close read but its very likely to get my +1 20:39:56 oh well, let's go back to anne in the mean time 20:40:16 #topic Rewording Freezer mission (again) 20:40:22 #link https://review.openstack.org/254239 20:41:21 should we require fausto's +1 on it ? 20:41:30 flaper87: or do you vouch for his support of it ? 20:41:32 ttx: I'd prefer to wait for his +1 20:41:34 ok 20:41:42 Let's pile up our +2s still 20:42:09 I can follow-up with him 20:42:43 ok, please add your +2 to this one and i'll approve it as soon as Fausto +1s it 20:42:56 #topic Cross-project spec rubberstamp: Chronicles of a DLM 20:43:00 back on track 20:43:04 it has 7+ votes now 20:43:07 i'll rubberstamp it 20:43:28 done 20:43:31 #topic Cross-project spec rubberstamp: Add clouds.yaml support specification 20:43:37 #link https://review.openstack.org/#/c/236712 20:43:49 last-minute -1 posted 20:44:09 last minute! 20:44:13 harumph :) 20:44:16 * ttx looks sideways to Anne 20:44:24 that was yesterday morning! 20:44:27 well, this has been posted 2 monts ago 20:44:31 heh 20:44:36 yeah I'm late to the party 20:44:40 looooooooool 20:44:58 It was until then a disturbing contest of approvals 20:45:16 annegentle: what's your main objection? 20:45:20 I just see the one comment 20:45:43 sdague: since going through that project ID exercise I realized just how many new projects we have 20:45:46 thingee: should we put it back to drawing board to address Anne's concern before going back to rubberstamp stage ? 20:45:50 that may or may not already have a client plan 20:46:19 annegentle: ok, so it seems sensible to give them guidance here, right? 20:46:31 thingee: would it help if I posted all the names of the clients in that sort of state? 20:46:45 ttx: whoops sorry back scroll was stuck 20:46:52 that happens 20:47:02 annegentle: I can totally add some guidance for new projects 20:47:33 mordred: thingee at the core of my question is this: are there different work items for say a handful of projects that are pretty new? 20:48:01 annegentle: it depends on if they cargo culted python-novaclient or not 20:48:06 (that's a common way to start a client) 20:48:09 yah 20:48:25 annegentle: but if you could point me towards a few new projects, I can look and write up a thing on what newer projects should do 20:48:28 ok, let's put it back on the drawing board for at least one week then, sounds like a valuable thing to have 20:48:39 annegentle: for context, it took about 45 minutes for me to port python-magnumclient :) 20:48:41 mordred: 20:48:50 heh sorry, I'll get you a list 20:48:56 annegentle: thanks! happy to have it 20:49:10 one of my tasks for this cycle is making the patches for as many client projects as I can 20:49:17 * mordred exects to rage code over chirstmas 20:49:23 s/exects/expects/ 20:50:06 mordred: will the thing you will write be part of the spec or separate ? Should we just postpone approval on this review ? 20:50:30 * flaper87 thinks mordred will rewrite openstack in rust 20:50:36 ttx: let's give it one week so that I can make sure 20:50:41 ok 20:50:43 mordred: you don't seem to have a lot of projects input - do you have consensus around this? 20:50:43 #topic Cross-project spec rubberstamp: Backwards compat for libraries and clients 20:50:47 ttx: it's possible the list from anne could illuminate something missing 20:50:48 * flaper87 knows mordred thinks flaper87 will do that someday 20:50:52 So this was added by thingee way after I sent the agenda, so don't worry if you missed it 20:50:58 mordred: it's there, 9 projects or so 20:51:03 I'm fine postponing it if we need more time to look at it. If it has 7 votes though we can fasttrack the rubberstamping 20:51:10 annegentle: aewsome. thanks! 20:51:23 ttx: sorry! 20:51:34 #link https://review.openstack.org/#/c/226157 20:51:35 yeah we can wait...I'll get better at posting things faster ;) 20:51:47 we are 5 rubberstamp votes short 20:52:14 and if you've not read it before, will be har dto swallow in the next 9 minutes 20:52:44 so maybe let's plan to rubberstamp it next week and give everyone time to read the final version ? 20:53:07 lifeless: nice work there 20:53:14 I'll upload a version today including the thing about having a tag for this 20:53:19 no changes to the meat of it though 20:53:34 annegentle: thanks! 20:53:51 ttx: thanks 20:53:56 lifeless: so could you comment about how the oslo.middleware issue we just hit fouled here? 20:54:00 #action ttx to put "Backwards compat for libraries and clients" and "Add clouds.yaml support specification" back on the agenda next week. TC members to read and vote by then 20:54:29 just as we have a set of guidelines, and we had a fail, and it would be good to see where they intersected 20:54:31 sdague: the namespace one ? 20:54:35 lifeless: yep 20:54:48 sdague: we did an API break while the API was still in use in deprecated form 20:54:53 sdague: and we had no testing to catch it 20:55:10 so L33 20:55:14 sdague: the spec addresses both of those points: deprecate, stop using, stop *supporting*, then delete. 20:55:15 it was semver signaled 20:55:32 however, we aren't allowed to semver break any existing supported branches 20:55:45 so maybe just make that point a little clearer 20:55:57 as it's mostly in the parens substatement 20:56:09 sdague: ack, can do. 20:56:23 but, yeh, seems solid 20:56:31 sdague: I'll break it into two points. 20:56:36 lifeless: great 20:57:07 #topic Open discussion 20:57:20 from what I see here, I think it's good, I can't project forward every detail off of it, but this seems like the a solid stab in the right direction 20:57:29 I can't help noticing the N naming poll is still not started 20:57:34 sdague: ++ 20:57:38 * ttx tries not to look at mordred 20:57:48 oh. BLAST 20:57:52 this afternoon 20:57:53 ttx he's not a medusa 20:57:55 * mordred sucks 20:58:09 * mordred waves his snake-hair at sdague and makes his eyes shine yellow 20:58:27 Anything else, anyone ? 20:58:34 fyi, I'll not be here next week, starting christmas break this weekend 20:58:34 sdague: what shiny yellow eyes you have 20:58:53 About dead projects, I think we should remove kite, too 20:59:12 ttx: how are we monitoring those? 20:59:12 or at least remove it from projects.yaml, it can stay as a git repo if someone wants to take it over 20:59:12