Cloud Native Computing Foundation Serverless Working Group, 9 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CNCF Serverless WG 2020-07-09

Description

CNCF Serverless WG 2020-07-09

A

A

A

B

Boy don't know.

A

And take John good morning, hey hyung! Is that how you pronounce it are you there.

A

A

C

C

Hey yeah, this is Hongqi.

A

Hello, so what's good.

C

A

Myself, yeah, which company are you with if you want to.

C

A

With a company always I'll call okay got it. Thank you. Hey guys, hey.

D

Roomie how's it going to be 19 in might know that teachers, schools, I.

A

Think everybody's tired these days, hey Tommy, you and Daniel.

A

Hello, hello: is this your first time in I, don't remember for sure I've.

E

Sat in on the SDK part of the meeting before but okay.

A

That's what company are you with just if you want to be associated with the company sure I'm with Google? Okay, I can spell that. Thank you all right morning, Nick Owen, let's see who else we have here ray? Are you there? Yes,.

D

A

And miss ginger howdy howdy.

F

F

A

A

Hello Eric good morning.

A

A

A

Hey Lance how's it going good. How are you go pretty good.

A

I, don't know, as you notice it Lance, but slinky opened up a PR for the rules for approving new maintained errs for the SDK stuff, we're not going to prove that today. I just want to make sure you saw it, though he could take a look at it. Yeah.

G

I did see it and I started to look at it before this meeting, but thought I should really yep.

A

Okay, cool and Klaus hello, hello,.

A

I just give another couple minutes I, don't think maybe very long call today, although we don't have anything on the s CK agendas. So if anybody has anything, please go ahead and add it otherwise, probably going to skip that call. Today,.

A

Hello, Brian, hello, Doug.

H

Good morning, I guess, but.

A

Close yeah, almost hey, Mark how's it going.

A

I'm gonna say it, you know it sounds like ever since you moved to the new house, you've been chippy er. You.

C

Know being able to not have to commute wonderful time, yeah.

A

A

A

You start at 3 after you.

I

All right, that's.

A

Gonna get started it's three after oh, you got one more person, uh hi Hamid. Are you there, hello.

H

Yes, here excellent.

A

Welcome all right: let's get started here, community time, okay, anything from the community that people like to bring up. That's not on the agenda, all right, I'm, not hearing anybody SDK calls. We have one scheduled after this week. I'm sorry after this call nothing on the agenda as of right now. So if you have anything, please add to the agenda doc, otherwise, we'll be very short call.

A

um One thing we probably should talk about, though, is we originally scheduled that to happen every week is for a while there we had a whole flurry of activity going on and lots of things to talk about, I. Think if I remember correctly, the last two or three weeks really haven't had a whole lot to talk about and I'm kind of wondering whether we should switch back to every other week.

A

We don't need to discuss that right here, but think about that, and maybe, as the only topic for the SDK call later on, let's see Timur is not there. Anybody from the SDK I was right from the workflow I. Don't see anybody, so another thing, I, don't think is anything update there other than I will say that every now and then he pings me to tell me some good news about some other company getting involved and wanting to collaborate with them.

A

So it doesn't seem like there is more and more attention popping up around the work flow spec. So if you've had any interest in the past, you may want to pop that back on your radar to take a look at it because it does seem like it's getting more traction which is kind of cool and okay. So before we jump to the pr's, is there anything on the agenda? People need to add that I forgot to add all right.

A

In that case, let's jump right into it, bring day to Def Jam welcome you just join so I'll. Let you talk to this one.

I

Yeah sure so this was something that I call member who raised an issue for because the json schema definition was not entirely aligned with the specification document, so in the spec it basically allows the data construct to be any Chason object, whereas the our original schema just had objects and strings. So all I did was add all the other sort of potential Jason types that could be present.

I

A

Cool any questions for Jim any concerns.

A

A

Done, thank you. Everybody approved, ok, typo, I think Remy. This one might be yours, I, remember correctly, yeah, it's mine. Ok! Let me scroll down to the non type of things. Just refresh everybody's memory, about the big change.

D

Yeah I think there was just a mistake in the spec yeah on the type of return because of you seats a map and it was weakened as an array. So I just think that.

A

Nobody yep more of a sin, tactical error, type of thing, so, ok, any questions or comments.

I

Good question: sorry: yeah. That example is no right. Isn't it.

H

It the it used to be a map. Oh wait, opal.

A

Just to be an array yeah.

H

Basically, it's a map.

D

Just like you have the name like it's an invalid syntax. Previously it was a nindroid syntax, as example, yeah.

A

I think when I brought that up my original intent in my mind, was a map I. Just for some reason, wrote everything I was in a right. I have no idea why I think it's just a brain part, all right, any other questions or comments any to approving alright done. Thank you.

A

Everybody next sear, this one is this is grant grant is not on the call and neither is Kristoff so okay, um I'll try to summarize this one as best I can, let's see so grant, was bothered that the specification talks about two different types of modes, structured and binary, and then he noticed that in the HTTP spec we then talked about batched and he was looking at that as another mode. So he was bothered that there seemed to be an inconsistency where were totally talk about two valid modes, but then we introduced a third one.

A

Someplace else excuse me, so we thought we really should add some text in here that says, oh by the way transports can define other modes. Well. Christoph pointed out that there's that batch isn't really another mode, it's just a different flavor of structured. So what he added recently and I, we helped with the wording yesterday on this, is to make it clear: that's the transports themselves may modify technically either. One of these message structures right, maybe add some sort of wrapper as necessary for the transport or in the batch case.

A

It can actually add more than one events into the message itself it. So it's a different flavor of sort of massaging of the events themselves for a particular transport so, but either way you still have the basic structure of it's either binary, basically, just the raw data versus it's a structured mode where the caught event attributes themselves appear inside the message body, as opposed to like HTTP, headers and stuff like that. Okay. So hopefully, this text in here makes it clear that transports can define theirs, which they do today in HTTP.

A

So it's technically a ton of a changing, a breaking change, an aspect or anything. It just adds clarification that this can't happen by adding this me right here. Okay, any questions about that gem, your answer.

I

I'm so just question: you know when these transports add these extra representations to be compliant. Do I have to implement all of those as a transport provider.

I

That's that's the only so, for instance, when you we add, you know the request to add batching or streaming. Is it then a requirement? All trans, all HTTP transport implementations, support those other modes, or do they become optional, that that was the only it's not really related to this spec, but it's related to all these sort of quirky transport things that have been popping up recently. Yeah.

A

It's a good question and I believe if that's what I want to double check, I believe that the specification will say when it's required I just want to see. If that's true, because I'm pretty sure batching is not required, but I just want to see.

A

So in trying to see fact, he says whether must support it.

I

And I guess that also then plays into your discovery stuff, because now all these different modes need to be advertised through that discovery mechanism as well yeah.

A

So I'm not seeing it jump out at me, but let's do we take that one offline, because I think that might be a good clarification in general for some specification someplace. Maybe it's the main spec to make it clear that this that it is optional I mean the fact that it's welded that's made for the spiking of the finite, but it's not clear whether you have to support it. So you know you mind if we take that offline and do it as a separate issue. No.

I

Absolutely do you want me to why we put it as an issue, just increase.

A

In the yeah that we want wonderful, you can open that up. It remind us to go back and double check that, because I believe the intention was something like Bosch is not required, but I have this vague recollection that we do require them to support the in general, binary and structure that you know the simple version of those I do.

I

A

Yeah: okay, okay,.

A

Okay yeah. Thank you. Doug hold on I'll, make a comment here.

A

Okay, thank you. Oh sorry, Brian I missed that. Okay, either way, he'll get noticed and all updated. Daniel your hands up.

E

Yeah so I'm I think Grant opened this, partly because of my confusion as I was doing some really. The implementation, um so I think I think my confusion was still that there was there's this.

E

There's this question of okay. So if we're going to call it different forms of structured mode, that that's great, then can we make that consistent across, so the protocol binding spec still called it a mode still treats it or listed as a separate mode.

E

You know separate from structured and and call it a mode, yeah and and so forth, and so and so there's still this idea that and you know, and even there's a separate section, three point: three bash content, more mode, that's in parallel with structured and binary, and so, if can can we be maybe be a little bit more consistent as to kind of what the what the the taxonomy of these things is across the different specs.

A

Yeah, no I, that's an excellent point: cuz you're right! If it's not a separate, if it's not a third mode, then we should use a different term for it. Yes and.

E

I, look at my clarify some of the questions about what's required and you might just because breezing the same terminology: okay,.

A

It came to me a favor. Can you add a comment to this PR to that effect? That way grant knows he has a little more editing to do sure. Let me see what what number is is 660.

A

Link to it in the zoom chat for yeah, there.

E

A

Hopefully, that's a very minor change, but he's, but we should probably make it as part of the same PR. Okay, any other questions on this one I mean aside from that. Hopefully some tactical change. Do people agree with the general direction. This is going and alright and are okay with it.

A

Okay, not here any objections, then, but just see if we get grant to make those final edits and then review it again next week. Okay, anything else before we move on perfect all right. Thank you. Everybody!

A

Okay, this one I think this one's mine. Let's see if I were what I did here, okay, so this one I was mainly clean up. Basically, I decided to move the governance stock, which was all by its the SDK governance stock, which is in a directory all by itself into our community directory to live it with all the other governance related documentation. For example, our main main governance stock is in here now as well. So I put this one in there and just call the SDK governance.

A

Certainly I didn't do any textual changes in here, I just renamed the the PR and maintainer guidelines, because these are actually for the SDKs, so just rename those to quit SDK in front of it to make it really clear. It's about those and then the main readme I, just added more information to actually point to these documentation to these new documents that are in there does it. Obviously, change any of the specs just moving things around in the repo more than anything else, any questions or concerns about those.

A

To approving all right, thank you.

A

All right, okay, next one is mine as well, so this one I mentioned last week as a as a warning I might be opening up.

A

So last week I talked about how there really wasn't a good mechanism to make it so that when a client queries the discovery spec a second time to know whether the metadata about a particular service, if it's been changed, is a brand new service or it's replacing an existing service and they just tweaked some of the metadata, because there really wasn't any field and here identified as having to be immutable across these queries and I was originally thinking.

A

Well, maybe we should make the name immutable, but then I was with somebody pointed out that maybe that's not so great either, because what if there's a typo in there or for whatever reason they need to change that, but it is still technically the exact same service. So that's when I defaulted after thinking about it and said: okay, let's just introduce an ID, that's globally unique and it's a UUID and it's basically just uniquely identifies the service. The value must not.

A

Change has to be a UUID per our CV 4122, relatively simple thing, conceptually the only real question I think for the group is: do we want to add this as a field? There that's immutable to allow people to do this identification for when things change.

A

Any comments, questions I, think everything else in here is just modifying the samples and stuff like that. Oh I did change this other places. I was using curly braces around variables and I missed one here, so that was it you're once a song yeah.

B

So the name is also still unique thing. That's I think it's the requirements.

A

That is, oh, yes, I'm. Sorry, you're right, you must be unique, but not it doesn't say to us be immutable. That's the key part tonight. Okay,.

B

So I'm just wondering because I think in kubernetes we have similar concept, that you have a name and your ID for objects, and it means a different thing slightly. So, even if you recreate something with the same name, it will then have a different UI Jesus that intended to be something similar here. My.

A

Intention right, this was yes. If, if somebody does something like they, they first have a service called foo, and then they change its name. So it's now called bar and then someone else comes along and creates another service called foo, even though it shares the same name as the original service. It is a complete different one because it will have a different UUID, so I think in conceptually I think it is similar to cover Nettie's, but I definitely did not model that after kubernetes.

B

But yeah, of course you see those concepts yeah. It's.

A

Just slightly different right, because in companies you actually can't rename an object, yeah, that's true, which is actually really annoying, but that's their topic.

A

Well, I have both right, but I have a unique ID and an ID, but you can.

B

Delete it and create it again and yeah, and it's that's the same name, although it might be something different, yeah.

A

I know we're gonna rathole in this, but sure why not? It drives me nuts, because you can actually get into a weird state where things are referenced by other things, by fine just names, sometimes things you can get a bad reference to a new object that you didn't mean to actually reference. It gets really really ugly, sometimes, but anyway, back to this one, hey are there questions comments by anybody. I have.

C

A question: didn't we talk about this at some point of having it in the spec and then we gotta move.

A

C

I mean it might be worthwhile going back in history and just see whether there had been one because we we had, we added a whole bunch of these, and then we went back to more minimalist. Are you talking about the discovery spec or the C II spec? Oh.

C

Good point: yeah I I was talking more about the disease back sorry.

A

Yeah, that may be true, I came here for sure, but I don't recall one in the discovery. Spec.

C

I'll go back in history, okay,.

A

Obviously, if, for some reason we decide, this is a bad idea, but if assuming we prove it today, you can always rip it, but I got it again later.

A

As long as it's not as I said, the use case I'm going after is to make sure that if the metadata changes I want to know as a server which metadata I'm allowed to change versus not- and this as of right now makes it so that you can change anything except for ID and then as a client I want to be able to know how do you could be how to uniquely identify an object to know whether it's a new thing versus just updated metadata, and if you want to solve that a different way, I'm.

A

Okay, with that I just I, just couldn't leave it the way to do it.

A

Okay, any other questions comments, any objection to approving or any reason we should hold off and keep people more time to think about it. I actually.

B

Would like to think about it a bit more okay,.

A

That's fine, no hurry! Okay, in that case, any other discussions. Otherwise, we'll move on.

A

Okay- in that case, this one now, this one was just open today, so we can't approve it, but I just want to talk to people's attention. Slinky open this up. We were missing some documentation in the SDK governance. Talk about how new maintainer z' get added. You know what kind of voting process there is how the nominated stuff like that. So this is his first initial pass at it. Obviously, this matters most to the SDK folks, so at least those people please review when you get a chance, but obviously anybody in their wider group.

A

If you're interested go ahead and review it, it seems fairly straightforward. We want to tweak some of the wording just because English is not his first language. Aside from that, it seems like it's fairly consistent with what I see in most communities anyway. Take a look at that when you get a chance. You also add a little section here about how to update this document itself. I think that was missing as well and I think the rules he defined here are consistent with how he updated the the main governance doc itself.

A

Anyway, any comments on that: okay review, that when you get a chance and I believe gem, we're not ready to talk about protobuf. Yet are we nope, yep, I, think so? Okay and I believe Francisco still wants to hold off on these two okay, so I think two weeks ago, or so we talked about possibly reviewing where we were relative to the implementations of the discovery. Spec I'll raise my head.

A

First I have started: that's how I identified some of these issues that I've been opening up, I'm, not ready to share it or discuss it, or do any interrupts testing with it yet, but I have at least started the process.

A

Anybody else want to raise your hand to give an education is whether they're starting on that any feedback they have.

D

On my site, I did an implementation in Java Street.

D

D

It was kind of working Russian.

D

I could probably do it like not today.

D

From the next okay.

A

Yeah, if we have time demo, be really kind of cool to see something in action like like, like you in the last week, I didn't get a chance to actually work on mine, so I'm hoping maybe this weekend to be able to work on it and then yeah me. We can, you know, show each of our clients talking to each other's servers or something like that. That'd be kind of cool all right. Any other topics I mean any other discussion around the Interop or implementation side of things here.

A

Anybody else want to raise their hand in terms of thinking about working on it.

A

Okay, in that case, we're technically at the end of the agenda. Are there any other topics? People would like to bring up.

A

All right, in that case, we'll fire final roll call and then we'll step over to the SDK call. As short as that may be so Doug are you there.

A

Doug, you look cute okay. What about Lucas hello.

D

A

And then well, hi, hello and Vinay woopsy. Spelled you wrong I'm here now you there! Yes, that's that good, okay I got you Doug! Thank you. Did I miss anybody else for the roll call all right, in that case non SDK folks, you are free to leave. Thank you for joining and we'll start the SDK call in just about a minute herself. Thank you. Everybody. Oh.

E

A

What was the topic? I said we should talk about oh yeah meeting times. Oh we're getting an agenda excellent. Thank you. Folks.

A

Lance was this year's.

G

The proposal to vote yeah.

A

G

A

So I make sure hey, but the right name in front of it. Okay, oh wait till 26 after the hour that we'll get started didn't there and just for fun for waiting.

H

Not that it matters.

A

All right 26, why don't go and get started? Lance you're up first, so.

G

There was a proposal to rename the SDK from cloud of incest DK to just pure cloud events and kind of following some of the guidelines that slinky did put together. For you know, voting on other issues within an SDK I thought this might be a good issue to vote on, because it's been, you know there are disagreements about it. So if anyone has an opinion on this, I would appreciate an up or down vote.

G

That's it yeah.

A

Laurie's my Hampton I've got a question for you. um Do into other SDKs have a similar concept to like a module where they have the same kind of naming question in front of them.

G

Are you asking me that yeah.

A

You or anybody else, I'm, just curious I'm, just wonder whether it's a whether it's a JavaScript specific issue or whether all SDKs are gonna, render the same problem. Well,.

G

I mean I, guess you know um for each one of the SDKs, they all have their own unique names. I.

G

Think the specific concern here is that that you know there have already been a couple of releases, and you know this will just break existing usage, but you know there are there ways around I suppose by omitting you know, deprecation notices and stuff like that, when you do an installation of the SDK.

G

A

That's okay, it's so they guess. My other question is something that you'd mentioned. Obviously breaking backwards back breaking existing people are using. It is obviously a question is what is the consistent or what is the pattern that you see in the JavaScript community around stuff like this? Do they normally a pen, SDK type things to their modules, or do they usually not do that kind of stuff I? Don't.

G

I, don't think that that would be very common, really I mean typically a module name should just say what it is and, and in grant's point is that this isn't really an sdk.

G

You know, I can I can kind of see it both ways, especially if we start to do things like add the discovery stuff to it. Sort of in creeps a little further along that continuum towards something larger than just a little module. I.

D

Mean if I may, it happened also like when NPM just basically released their organization principle. So with the add something usually what people are doing is like they move to organization, and then they were doing like a cut mud to automatically update euro imports and change your codebase. So we could maybe provide a cut not to do that, but basically go through all the import and update them automatically.

G

I'm sorry, I didn't I didn't quite follow that.

D

Like basically, it happened with the organization, so sometimes it happens like that. You have a codemod I, don't know if you ever used that one that allows you to define like to basically introspect the JavaScript and typescript and like modify it with introspection to magically update all the imports into Australia.

D

So some people provide that and then in one common line you just take the whole naming right.

G

D

I'm I cannot agree with Gregg and to get my opinion so I press one.

D

A

Glance, I notice that you voted no on. It is your biggest concern, just the the idea of breaking existing people. Yeah.

G

Pretty much okay, you know, and I and I recognize that it's not a huge community of users at this point, but there are people using it. So yeah.

A

Okay, anybody else want to chime in or vote.

A

Okay, was there a specific action? Lancer looking for here was just to raise it to people's attention, so they should vote if they ki if they have an opinion, the latter, okay, okay, cool. Thank you all right. Thank you for bringing up a annoying question, but something it's not unexpected. All right, Daniel.

E

Yeah, this came from a discussion and brief discussion on the slack, um so it looks like for a bunch of languages, maybe most languages we're releasing libraries to our package managers under our kind of our personal accounts on the package manager and I wanted to ask about what people think about having potentially kind of a cloud events account that making multiple people would have access to four for the package manager releases.

E

So that's you know. For example, someone drops off some a maintainer list and no, we can't release the package because it's under their personal accounts or things like that. This is there's a practice that we've been doing for most of like Google's library releases, where we have group accounts that belong to a team and, and so anyone within that team can release libraries I. This came up for me because I'm I was doing the first release of a ruby, SDK and trying to figure out okay. Well, how should I do that?

E

Should I use my personal accounts in Ruby gems? The Ruby package manager is there kind of a common practice for a group accounts? You know what so I guess I wanted to see what people thought about is. Is this an issue that people are concerned about? Is it language specific? What's.

E

A

So my hands up I'll go first on I I. Think it's a good idea. I honestly, don't know how else is the case or handless right now, I think most men are probably using their personal account. For things least, that's been my experience from what I've, when I've interacted with folks and like they're you their personal accounts for, like I, don't say Travis CI, but it so I think I. Think of that kind of stuff.

A

You'll not only get actually is Travis CI right and that's not good, and so, like my real question for you, though, is in your experience when you've done this is it just a matter of the maintainer is just through backchannels share the password and user ID or whatever for these systems, or is there something a little more formal in where this information is stored?.

E

Yeah, that's a good question when, obviously, when we do it in at Google, we have mechanisms within Google to share secrets like passwords. So within.

I

E

Groups for a for a group like this I'm, not sure what the best approach for that is, I'm, definitely open to suggestions and we could just back-channel passwords, but maybe there should I mention not sure what what tools might be available to do that actively. So.

A

Let me pick on lance for a sec, because Lance I know nothing about JavaScript or NPM, but I'm assuming in order to upload stuff to forgive a user on term, probably NPM repository wherever it's called. It has to be an ID password protected right. So who wants that today?.

G

So it was Bobby, oh and then just added me as someone with the rights to upload. So it's not a single person that can push the NPM package, but it's a select group of people that are determined by you know: I, guess the maintainer x' right, okay,.

A

Slightly different scenario: does anybody know if there is an SDK out there that has the similar situation where it has to be a single password or identity.

E

Just to clarify for for Ruby at least it doesn't have to be a single identity. You can't have multiple owners so that I guess that is another potential approach for package managers that support it just to have several people all like all the maintainer x' on the on the package under their personal I'm. Just thinking about the group idea is the formalization of that. But if that's not feasible, then babies is having multiple owners would be also a way to pay forward. It.

A

Was your concern pretty much just about the Ruby SDK?

A

E

It was yeah, it's it's, the Ruby SDK, because I wasn't sure what our what our practice is, because I wanted to release and know how did I do that, and so it's kind of a question for the group. You know: how are we doing this, as you know, as all languages for a cloud events? Is there? Is there a common practice? So are we just kind of all doing our own thing?

E

Should there be a common practice? You know.

A

Anybody want to voice an opinion.

C

So so I put the thing in chat. We should ensure their cloud events. Project owns the repo and namespaces that we publish into.

C

So know, in other words, it shouldn't be an individual, although we can delegate access to it.

B

A

Your hands, oh yeah,.

G

In general, I like the idea of having something that's common and owned by you, know an organization as opposed to individuals. I, guess it like. Where do you stop? We've got Travis CI circle, CI code, a/c coveralls.

G

You know lots and lots of tooling that requires you know access to from, but like somebody has to own that and manage that. So where do you stop the common thing? Is it just when you publish to like a repository or something like that? Or is it all the little bits and pieces that go into actually having a you know, CI.

A

Well it. It seems to me that if anybody of me- and if anybody on these teams, who sort of manages one aspect of the tooling decides to walk away for whatever reason, we don't want to be an alert right and so I mean I, agree with what Mark is saying: I just I'm just trying to figure out the mechanics of it right because I'm like what Daniel is saying where they have a central place inside Google, where they can do things like share passwords and stuff.

A

We don't have that um I'm, just wondering how we actually get to where I think we want to be right without us, without a shared data store. There's.

G

A private repository not boom.

A

There you go sure, take the easy answer: glance jeez.

A

What do people think about that setting up a private repo that only certain people have access to, and we just stick passwords and information like that in there I mean I, guess that that is one way to go. I is that secure enough for people I mean I, know you're not taking. This was a check stuff into github, but as long as it's a prior repo is that okay, I.

G

Mean I guess you can also use just github secrets to couldn't I've never done that.

G

A

Was that work my.

E

Understanding of github secrets is that they're, basically right only and you won't be able to help them after right.

A

C

A

Don't know you guys want to go off and think about this or what I'm? Not it's really up to you guys to decide.

A

Because we I feel like we just been kind of winging it so now and it's and it's worked sort of, but it's probably not the best approach. Blanka yeah.

G

I mean I'll say that um I was actually really concerned when I started to get more heavily involved in the JavaScript SDK and Fabio was not around much and I. Didn't know how I would be able to get access to things like the code coverage reports and stuff like that. Fortunately, we managed to connect on that and.

E

G

You know do that, but mmm it didn't seem like there was any clear you know common way to handle this sort of stuff in it, and that was disconcerting when I first started working on it, yeah.

A

I'm thinking I'm wondering whether the CNC F has anything in this space to to help us any kind of tooling or something like I, can't think of anything offhand, but I guess I could reach out to Chris, anatec or Amy and see if, if they have something that we're just not aware of, and then you know revisit this next week yeah and see if they have any recommendations, I don't know anybody else have any other ideas.

F

Man, you guys are too quiet.

A

So what you want to do, someone needs to speak. I'm, not I'm, not maintainer in SDKs I have no stake in this. On.

E

I I think it's you know if you can find out. If there are any tools available the great if, if not, if it turns out that that there isn't, then maybe someone I'm happy to do it could just kind of think about a little bit right up, write up a proposal for something, maybe simple and straightforward to start off with, and you can vote on it or something. Okay,.

A

Cool yeah, okay, I'll, take the AI to reach out to Chris hand or Amy and see okay, anything else and that clicker topic then I, guess in the meantime you'll just add it right now.

E

Is necessary right for now I'm just publishing, using my personal account, so no yeah, okay,.

A

Okay, Lance is the hand new or old; oh sorry, yeah, that's old, okay, sure, okay, okay, anything else on this topic, then.

A

A my topic: do you guys still want to meet on a weekly basis, or should we switch back to every other week, I mean? Obviously we could still keep weekly and just cancel if there's nothing on the agenda. But it's up to you guys.

G

Personally, I'm fine going every other week because it does seem like there hasn't been a whole lot of material in the last little bit. Okay,.

A

G

A

Voiced an opinion.

A

Okay, I'll tell you what I'll, let me paste that they paste the topic and the proposal to go back to every other week in the SDK slack channel and if I don't hear any objections. Well, we'll do it I guess: lazy. Consensus is the phrase. Otherwise, if someone objects then we'll find out. Why? Because obviously they're not on the call, so they probably won't object. So, okay I'll do that.

A

Okay, any other topics you wanna bring up.

A

All right, in that case, we are done. Thank you, everybody and we'll talk again next week on the main call: okay, bye thanks.