Add a meeting Rate this page

A

All right, it is three after the hour. What are we going to get started? I assume you guys can see my screen. Okay right, I'll. Take that as a yes all right, move forward, so I don't think that anything special to mention on the AI is when Austin gets on. If I don't know, please somebody remind me: we need to name to send the next SDK call community time. So for those of you are new. This is a time when people who don't normally join the group can bring up topics for discussion.

A

Is there anybody I'm a call who's new? They would like to bring up a topic and Josh already have your topic added to the agenda. I believe anybody else all right moving forward, then without Austin here for the SDK I. Don't think anything's really happened there other than the golang sdk repoed. That vmware was working on was just officially moved over this morning to our org and github.

A

So if there's anybody in the call who would likely add it as a maintainer to any of the SDKs, please let me know cuz right now, I think I've. Only added one person as a maintainer on one of the projects and obviously we need more because otherwise nothing's gonna get done so please, let me know if you won't actually work on those and um now the time to jump in as a maintainer. Well, there's nothing there!

A

um Kathy I, don't see her on the call. So I don't think. Anything's happened there, though relative to the work flow subgroup. She joined I'll, ask her again so and I forget some, please remind me: I, don't think anything's happened there. We did have a meeting relative to the Shanghai coop concessions. You can see the links to the document and the slides they're working on mainly Kathy Clemens myself will be doing some presentations for the intro and deep dive.

A

I, don't think it's a whole lot of stuff in there right now, I think Kathy's, the only one that's actually added some information to the slides, but whether you're going or not feel free to review those. And if you have any questions or comments or suggestions, please speak up and we'll try get them. It accommodated.

A

Eric work I haven't rolled out from anybody about the Interop demo. They were trying to do for coop con Seattle. So what I want to do is try to force discussion, so I will be sending out a doodle poll. Unfortunately, due to travels and stuff I need to make it end kind of early, so expect the doodle poll to come out later this afternoon, but I will shut it down by end of business tomorrow, with the hopes that we can maybe have a meeting early next week to start talking about the Interop demo.

A

Okay, so just the heads up keep an eye out for a doodle poll. Note alright and with that I think we now jump into PR stuff or discussions. So last time we were talking about casing of our properties and we had I think at least four different options in front of us now. Clemens you closed one. This morning, 327 I believed you want to talk a little bit about. Why you closed that? One.

A

Clemens I can't hear you for talking.

A

Can anybody hear Clemens was just me how.

B

About this yeah, the the microphone yeah so I had to PRS, which we basically we went through the last time, which are effectively the same. The second one and first one here in the list. They introduced an underscore character and then no separating all the terms with other scores, and it ended up looking very super clunky, I think and to effectively limit the choices. Unless someone really really really really wants to insist on the underscores and then I can go and revive it.

B

But so this is the one. Yes, so I caused that one, because ultimately I think the one where we have simply a certain character said two lowercase characters served in purpose and if we're doing a further cleanup of names where we strike like the event, prefix, etc. Then legibility is not going to be too terrible and so I'm, basically we're tracking the under squads on this.

A

Okay and someone on last week's call, it may have been Tim a care. Member mentioned that some web servers have problems with underscores. So I did a quick search this morning and I did find this link stuck into the agenda doc. That talks about some issues that some servers like nginx has with them. You can tell it to support it, but have to go out of your way to support it. So I thought that was kind of an interesting, a little bit of information and then.

B

And and then, if we, if we allow them and then we have to go, we met for HDPE, then they were so no matter what separator we use, we're running into different tastes, that languages and infrastructure half with the separators.

B

So that's why I'm favoring having none and then we have to save you some more case folding and that's why I'm favoring you all. You have lower case characters and that's how we avoid most of the problems and I understand people's desire for legibility, etc. But all you needs about interoperability and with the least common denominator approach.

B

We can achieve maximum legibility, interoperability at the price of some legibility, which is ultimately alleviated by having an SDK that then no seams native to the perspective runtime environment, where it can be passed out case or can't be camera case in central, ok,.

A

So let me know how to pick on Joshua kits Jesse. You had opened up I believe this is just an issue, not a PR, about promoting or suggesting the idea of a snake case thing using underscores. Would you like to talk to that at all.

C

I mean if we go all lowercase, then that solves my issues. So nothing to add really are. My issue was was like. Clemens was saying some of our databases. Don't you know are not case-sensitive, and so then we would have a little bit of difficulty in terms of these long. You know field names that would kind of get munched once they all became a single case.

A

Okay, so I like the idea of reducing the choices, because I think it makes any kind of boat we have easier. So let me ask this question: does anybody have any objection or concerns with Clemens closing 327, which is the one that adds the notion of allowing it underscore.

D

My only concern is that some people they point out that they would rather have underscores so nothing else.

A

So I guess what I'm wondering then, with that comment, are there other people on the colony this way? Are there people on the call who would like to advocate for having an underscore character in there? It has since reopened 327 and making that one of the choices for a for a vote, I.

E

Don't have been somewhat curious. What if the conversation would be all that different if it were a but I I'm, not I, don't know what's wrong being in here. Okay,.

C

Yeah I think that I think you would not find more system problems with dashes.

A

Okay, so I'm not hearing anybody asking for 327 to be reopened in that case am I correct and my assumption that were basically then back to I. Guess, I want to say two choices, but technically it's three because we could choose to do nothing and leave it as is, but the two alternatives for making changes are three 17, which is camelcase and 321, which is lower case. Everything with no underscores I believe those the two choices in front of us Kristof.

A

Would you like to talk to 317 I think you might have missed last week's phone call. We were talking about this, so I didn't get a chance really advocate for 317 I believe actually.

F

Was there listening, but we've run out of time: okay, yeah well, I, don't! But before we kind of start arguing names, I want to say that I opened the first PR and my main concern was that spec currently doesn't really define what the character said is that it allows why space control characters and so on, and it doesn't define how a chibi had wrestled and I think it's good that we now have two PRS to choose from and they both address these concerns so I'm also super happy as Clemens PR gets merged.

F

I think it addresses the same things and that's really a big step forward. So that's the big big picture for me: I still prefer camelcase, it looks nicer, and so what I did is basically I didn't touch any of the attribute names I kept on this camel case, but I restricted the character set to ASCII I disavowed. Basically, anything that is not enough and I'm a character.

F

The difference to Clemens is that I or the difference. Basically, that I still have the case until DBT yeah and that's basically it for the main spec and the question is: how do you do it in the HCP, which is actually I, think the only transport way? Maybe someone can correct me if I'm wrong, but I think all on our transport layers that we currently support also support a sensitivity.

F

So then the DHCP address are the only ones that don't, and so here that kind of the convention in HTTP headers is. Is that you separate words by all right. Try table this I. Wasn't that says: if there is a dash in front of a character, you have to treat it as uppercase and a bit if there's no, it should be lower case and given that we are in the Escalade character that it is actually fine.

F

This case, folding I'd say it's holding is a big mess if you're in utf-8, but since we're both FP, it should all work out. Yep, that's I think everything I want to say to it. Okay are.

A

There any questions for Christoph on his suggestion here.

A

Okay, in that case, let's open this up for a broader discussion. Then, are the people who would like to speak in favor or against either the two proposals, meaning 321 versus 317, to try to convince the group one way or another.

C

This is Josh I'll, just say that you know the one of the reason that I brought up 327 is because you know in but I think I mentioned in databases in some of our databases and there's no case sensitivity so that mapping kind of gets I know it looks better and I know. Camelcase looks better in face-on and elsewhere, but in some of the databases it would look very bad just pointing that out.

A

Okay, anybody else have any comments.

G

My only net is that if we choose 3:17, can we please decide the D on ID can be lowercase instead of having a between I and E. You probably.

A

Do that for the follow up? Er? Yes, hey any other persuasive comments, one way or the other.

A

You guys are not this passive I know you guys have strong opinions come on.

A

Okay, well, if no one wants to say anything high of the opinion, then that, because we only had two choice in front of us, the choice. Well, let me put this way: is there anybody who believes that we need to leave it, as is.

A

Okay, not hearing that it sound like we have to make some kind of change the consensus of the group, so it sounds like we have a boolean choice in front of us, 317 versus 321.

A

What I'd like to do, then, is start of do a formal vote and I think per the latest governance rules. It's going to get seven day vote so which gaenso and the beginning next week's call what I'll do is I will I'll put a comment in yeah. I do have some ports. Why not just one one PR to take a look at, but I think I sort of thought. This thing through I was I was actually gonna. Do a CI, vs boats, but I thought we had three choices.

A

So tell you what um I will figure out which PR to pick on and put a note in there asking people to vote one way or the other for 317 or 321, and you guys will have until beginning of the phone call next week to vote? Is there anybody who would like to vote right now? Otherwise I was just gonna wait for people that may put comments into the PR itself.

C

This is Josh. I can vote right now for 321, okay,.

A

Oh I'm, sorry Josh you're talking voting rights, I apologize, so oh those who have voting rights can we go back over here, get the link I apologize. This is yours, as you knew the group Josh. You had no clue about the wonderful bureaucracy we have so anybody any company that has a green box associated with their name has a can vote.

A

I'm assuming most people know whether they've been attending enough to know what they can vote right now or not. My machine is dead, slow, I, think, okay, so Microsoft wants to go for.

D

I'm.

A

Sorry wait Microsoft! You want to vote for what one.

B

Okay,.

A

I was gonna, say if I use a Kim, oh okay,.

A

Okay, is there anybody who'd like to vote right now, anybody else I'm, sorry.

H

Yes, Jim I was gonna, do 321 as well. Okay,.

A

Hey panel 321, anybody else would like to vote now. You don't feel obligated you guys can definitely wait till later, but if you want to get out away, til free speak up, Lorde's, driven 321, okay, anybody else, google, 321, okay, anybody else.

A

All right, not hearing anybody and Along Came okay is 3:17. Okay, that's the Brazil Bank right. Yes,.

D

Can.

A

I remember how to spell that.

A

Yep got it, and you said you only.

F

Citing you.

A

And you want a 317 correct: yes, okay got it all right! Anybody else would like to vote now, all right cool. In that case, please wait for the comment in in the PR and then you can vote over there and you have until the beginning of next Thursday's won't call to do that. All right is there any other discussion points on the case property casing issue people would like to bring up before we move on okay, Lou next on the agenda, protobuf I don't see Spencer on the call I Rachel that Thomas came.

A

What are you guys talk to the sir? Should we wait for him to be on the call I.

I

Can I can say some things about it if that's useful, I think if you had looked at this before and you had made comments, your comments have probably been addressed in this version, so it's worth looking at it again. This is this: doesn't try to serialize things any differently. It doesn't try to match up JSON to print a buff in any way. So it's just dealing with protobufs, so take a look see if there's anything like my expectation of this. Is that there's nothing controversial in this we'll see. If that's true.

A

Okay, I love, how sure it is by the way it's very short reading, like that anybody have any questions or comments on it. Anybody have a chance to look it over.

E

Okay,.

A

Yeah I did I, did make some relatively minor suggestions or comments in there Rachel, and maybe you can ping Spencer I. Think all my comments were mainly editorial or relatively minor touch things, but overall it seemed like it was okay to me. So thank you guys very much for doing that. Yeah.

A

Okay, anybody else are any questions or comments.

A

Why you guys are so quiet today. This is weird: okay, I guess, we'll keep moving on then Joshua make event ID optional. This should be fun. You want to talk to this one.

C

Sure yeah, so we started having some discussions. This issue and I mean so my my initial feeling was probably the same as I. Think what you guys initially decided was that hey, you know what an ID is. It's a good thing to have, and then we realized that you know we didn't. We actually didn't need it at all. We didn't want to have it because it would be come a secondary source of truth or what isn't a unique event for us and we're one company, but we have you know.

C

One group that's mission is to have an accurate accounting of events that happen in the company and we don't necessarily you know want to. We don't want to make the effort for the bureaucracy side too, to make sure that every group that's going to be submitting events into the platform is going to create the event IDs correctly.

C

So we said you know, there's no need for an event. Ide, there's no need for anyone to create one, because, even if we're not going to necessarily trust it so for us we just want you know the data that's coming in and, as I mentioned in the original comment, the data being who created the event in which system at what time and what type of event it is, is enough to uniquely identify the event in every case that we have.

C

So if we decide that we do want unique IDs that are a single field, then what we want to do is to create those at the platform layer which is downstream of where the event is initially created, so that we know that we're doing it. We know exactly what the logic is for, creating that unique ID.

C

We know that it maps one to one on us onto a certain set of fields. So that's that's the reason.

C

This whole thing came about and I know that there's there's definitely feelings that hey you know having that single event, ID field would make downstream certain downstream things easier, and the only thing I think that I mean, in addition to the deduplication reason, I think you know there's another reason to have a single field event ID on there, which is that you know if you have a system that needs to look up in a an event like you know, you just want to pull it up or have a URL to it, or something like that, then having a single field is a good thing.

C

My contention, though, is that at the point where you do need the single event, ID field, you can annotate the event with that. It's a you know, but not necessarily force everyone who is producing the event to create one, because that might just end up misleading folks.

C

So that's all I have to say about it.

A

I say some people coming off me at anybody. Want a question. I have that question or coming yeah.

B

And from the top front perspective, so if I'm from a it's a mediating, middleware visit messaging perspective, let's say you're producing an event and then you expect that an event to pump out somewhere else, and there are no three or four moving pieces and robbers in the middle that take care of taking event in holding it moving. It forwarding it and then making making it ultimately available to you just basically for Diagnostics when you say: hey, I'm, missing this event and I wonder where it is.

B

The great thing about the event idea is that it is a field that we know of because it is in cloud vents and that we will put into logs and so that we will have in our pricing information. So if you show up at our support, we'll be able to use that ID together with your tenant information to go with that event and and basic crazy, that's an evidence trail to help you if you are I'm using another combination, you're effectively forcing us as a cloud provider to do a correlation query through.

B

You know several trillion events at worst to try to find your event and so having an ID is fairly useful.

C

Yeah some so I saw this argument as well. I I think I mean that makes some sense for sure what I think about it, though, is that what you're talking about is kind of like a trace, ID use case and again I think that will certainly be useful under certain circumstances, like you said where you have complicated pipeline of things happening, but I think that using the event ID or the trace is necessarily I. Don't know I mean it's not necessarily the the ideal solution, because there can be a more dedicated field for for tracing.

C

If you need one, then you add it in yeah.

B

But see the point is me: as an infrastructure provider who builds generic messaging infrastructure right I. The point of almost the point of my work to participate in here is because we want we want cut. We want to have standardized minimal metadata that we can rely on that everybody says so that we can then provide services like traceability and Diagnostics Osetra and debug ability ultimately based on top of those features.

B

So so you turning on next are extensions to turn on features that we have that it becomes very complicated and that's why that's why message IDs are required in messaging systems and that's why these event IDs are made required here, because the middleware can help you with that and even if it's not complicated, even if it's just a topic with with a dispatcher um there are you already and you're, not operating it any or anyone to have traceability? And that's that's why the the ID here is hard yeah.

G

And just to add on to Clemens these cases, event, ID is also hugely important for idempotency and though it may be possible, within your specific application domain, to build idempotency on the specific events that you produce. The whole point of cloud events is interrupts and we want to make sure that anyone who receives a cloud event can use it for adding potencies. So like, though it may sound a little harsh.

G

If you want to pass our messages that are not cloud events within your system, that's fine but like once it actually goes to any other consumer. It should probably follow a standard convention on how to have things like idempotency or identification of these envelopes.

G

Cleric. Think I just go ahead. Yeah.

H

Sorry, um just to push on that on maybe Clements point a little bit as these events move between providers doesn't that tracing argument fall away there, because it's only in a must be as well since I read the spec is that eventid meds being globally unique to everybody or unique to a publisher or unique to a tenant cloud provider? I I always assumed it was an idea signed by the guy that generated it, and it was just unique to them unique.

A

Within the scope of the providers, what the spec says right.

H

Now the cloud provider or the provider of the event and I guess maybe I'm overloading the term now, because I think there are people on this call that would be looking to use these events or these structures outside of the context of a cloud infrastructure provider. Hi.

A

I apologize, I used the wrong word producer: that provider producer okay, the source, the extra source.

B

Identifier and then think of the.

H

Id being being routed to that right, okay, so it's unique within that source, ID yeah, but okay does that make it globally unique and I'm just pushing on your tracing use cases together together together.

H

Within a cloud provider platform, yes,.

B

I mean practically speaking, we we can also mandate that it will be good. We just haven't right.

H

Now I understand that I am just trying to understand the level of uniqueness that this group think is applicable.

J

Yeah I think this board has a very good discussion. So what's the unique scope, if you say this unique for further event producer scope, then a might not be unique. Further, I'm, sorry, this platform scope, it won't be it. It might not be unique globally. How can you I'm here with all these different producers? They can cooperate well that they all use different event. Ids.

K

Isn't it going to be contextualized within that the source contacts like Clarence said, but then again the domain through which that cloud event can travel is going to be security restricted anyway, and so then, that context is further further boundary within which it needs to be unique. So I, don't think saying it needs to be globally unique between everyone on the cloud provider is actually an issue, because the security implications of that would be massive. So as we have these boundaries, that's where the the uniqueness defines its context and that's where it's needed so.

J

You are seeing is unique globally. Is that your point I'm.

K

Saying it shouldn't have to be unique globally amongst everyone within a cloud environment, but within the development within the context, within of what is interoperating with that makes sense.

J

Not really right because, for example, if like for I'm a service platform, I could be always over I mean maybe like over time even sources different immense sources. How could how could I be sure those event sources? They cooperate, cooperate. Well, they are going to send out. You know they are going to assign the unique um event IDs, because.

K

There are unique sources in the first place, they will have a unique source and then each is gonna have yeah.

J

If it's algorri is unique per that source, but if I receive events from many different sources and from are those sources belong to different event? Producers, different vendors, I I- don't think you know as a even consumer as a service platform. I can be. You know, peace of mind, all those event. Ids are I unique globally and all you need her. The platform scope, I.

A

Think what I'm hearing them say, though, is that the event ID uniqueness is scoped to the source. Uri. Is that correct.

J

Yeah source, you are I, think that's not is that can be guaranteed, but I'm thinking you know we cannot guarantee, is unique globally or unique per the consumer scope. If that consumers, you know, receive events from different event, sources different event when their producers or vendors, so I I, think you know so the usage of this event idea. Although I agree, it's um it will ease implementation and just wondering actually I think this PR race, race raced a very good point.

J

So how I mean what is a scope we can use it I'm not saying we should not have it, but I think we need to clearly define this. So to avoid misunderstand your miss usage. Well,.

K

I think my point was the company that that we work with we're never going to reach all the security considerations that are required if our events again are going to be naked or non-encrypted within the context of other events, which we don't trust, there's always going to be some kind of security context which is trusted and within that security context you know who you're talking to, and you know the other organizations and that's the boundary within which you have the ability to understand whether or not it's going to be unique. So long.

A

Effectively.

K

So.

A

Let me just go to the speaker key. Some people do have their hands up. I'm Ryan. You had a question.

L

No I don't have a question, but I sounds like someone mentioned that the producer has its own uni, so the consumer just concatenate the producer and the event ID. That's a global, unique! Isn't that the case.

L

So it's the combination of producer, ID and the event ID is a global, unique ID. You.

A

Say produce right: do you mean the source ID right, the source, ID yeah.

B

Yeah yeah I think.

J

What I'm.

A

Hearing I think I'm. One hearing is sort of two different discussions going on here at once. One is Joshua's proposal which is to make it optional, but then there's a there's, a secondary discussion here, which just talks about whether the text around event ID needs to be clarified. With respect to the uniqueness aspect and I think those are almost separate discussions, because whether we adopt Joshua's proposal or not I think basically what I'm hearing it sounds like people do want a little more clarity around what the uniqueness is for the event ID.

A

Is that a fair statement?

A

Yes I, think so? Okay? So let's take that as a follow-on discussion, and it will start a separate thread about that one. But let's try to circle back around to the to the optionality aspect of event: ID I'm hearing a few people say that they think it's important to be there, which is why I was required in the first place.

A

Is there anybody, like obviously Joshua's on the side, to keep it optional? Is there anybody else who would like to speak in favor of making it optional.

A

Okay, I'm not hearing a whole lot of support for that position than Joshua. Is there something you'd like to pursue further I have more discussions in there or how do you want to go I.

C

Mean I think I think that's fair enough like if you know you, if you want to define the cloud platform to start at the point at which the event ideas has been defined. That's fine and we'll just we'll just keep our our stuff that doesn't have an event ID in it separate from that, and if we need to use any tools for an interoperability sake, then we'll transform it into a proper cloud event by creating the idea at that point. Okay,.

A

You said something in the introduction of your clear issue and they kind of stuck in my head. I just want to get some clarity when you're talking, you said something along the lines of there may be some some issue with people generating the the event ID properly, and it was the notion of it being generated properly. That I got a little confused by. Can you elaborate on on why people would have it difficulty, because it's just a string, it's not even a good. So what do you mean by properly.

C

Well, what I mean is that that it has the meaning that it intended that it's intended right. So, for instance, we mentioned somebody mentioned idempotency right. So if someone is, let's say, generating a good every time they make the call- and you know they do that free to retry. That obviously wouldn't be what we expected.

C

If some when this is something we've seen before, if people have accidentally set it to a constant value or not set it at all, and then it's a constant value and then obviously that's not what we want, and so by setting it properly, that's that's kind of what I mean or you know. Maybe they make it a hash of a certain set of fields, but they're, not the right set of fields got your home, so yeah, okay,.

A

Okay, so guaranteeing the uniqueness aspect. Okay, that makes sense. Thank you, yeah, okay, so then in case and so I'm moving forward here since I'm, not hearing anybody else, arguing in favor of this proposal am I hearing the the consensus of the group as of right now is that we could be closed. This issue.

A

I'm not tearing the objections of that so Joshua I, keep in mind that, just because we may close an issue doesn't mean that we can't reopen it, especially if new data pops in like, for example, you come across a use case that we just hadn't thought about that everybody does care about and making it required it becomes problematic. We can definitely reopen these things. Okay,.

J

Some.

A

Time- okay, cool okay before we move on, though, is there any other comments or questions on this one? Before we move on.

A

Okay, cool Thank, You, Joshua I appreciate you joining the call okay, so we have a Kafka transport, binding PR out there and it's been out there for quite a while. Oh let's see so August and unless I messed up I, don't believe. The author has actually commented on any of the questions, comments or anything in here and I've asked them several times to speak up or they're gonna address these questions or comments. I have heard back from them.

A

I did give them sort of a little bit of a warning shot saying you know if it'll speak, don't mention anything by this Thursday I'm going to propose that we actually close this. But what I want to first do is: ask. Is there anybody on the call who would like to champion this and own it going forward? I.

H

Was too afraid to say this, but I feel that is something we should have I.

A

Think I tend to agree, but without a champion it's gonna be a little hard. So do we have somebody willing to volunteer to drive this one forward.

K

Yeah I'm happy to take that on its new here. Okay,.

A

Now: okay, excellent. Thank you nail me.

K

Attend.

A

The minutes I'll add a comment to the issue or, if necessary, to the PR saying that you volunteer to do it and they obviously can speak up and object, but I think probably the best way to move forward is probably open up a follow on I'm sorry open up another PR that just picks up their commits and add stuff to it, because I don't think you have the access rights to actually modify their PR directly. That's.

K

Right: okay,.

A

Doug.

M

No, this is David Baldwin King. Add me to that as well, and I'll see if I can help you out or ask me my team helping you out see.

A

If you need.

M

It I'm not sure if you do or not, but now that's great thanks. Okay,.

A

Excellent, thank you very much. I felt a little weird closing it, but without any movement is a little hard. So thank you guys for much. Let's see last item on the agenda, this one has actually been there for a while from a process. I'm, sorry from a release process perspective I, don't think we're very clear about whether we're going to version each of our documents independently from each other or bundle them all together.

A

So when I did is put out this astromech proposal here to suggest that basically we take all of our normative specs and the primer and group them together. It has a single logical unit, which means, as we move to point two point, three or one point or whatever everything will get tagged with that particular version number, regardless of whether that particular doc itself has changed that way.

A

Everything's sort of added, consistent, semver number, the only doc as of right now that would not be included in there is the extension document since that's more like a wiki page more than anything else, but it would include the main spec, the primer, the transport bindings. All those things would get lumped together and so that that's my proposal for how we handle versioning of our Doc's.

A

What do people think.

A

Silence: okay, don't care hate it! It's.

I

Just it's just: it has a lot of implications. I think there it's not that I'm not like I, don't care, it's probably like. Is it worth thinking like it, it's probably worth laying out and being really explicit about how this works right like.

A

So.

I

Like we have a lot of moving parts, you have a lot of. We have a lot of specs right now and thinking about like what it was like for them to for them to like move along at their own pace or all move together through semantic versioning has different implications like say, I'm thinking about the JSON spec JSON spec is fine, but this other, like the proto spec needs to increment I, might be miffed if I had to like continually like increments.

I

Oh so, for example, if every time something increments, we increment every single thing we're going to get up to pretty high numbers, pretty quickly, for example, and I, don't know it's just why we're thinking about rather than just saying like this looks like I I, think I think this is probably the right thing to do. I'm just saying we should think about it for a second yeah.

A

And I'm, not yes, unless everybody was saying yeah, yeah yeah: let's do this. I was I, wasn't gonna say push to resolve this one today, I just wanted to bring it up to people's attention, because I do think we need to get this resolved at some point. So I agree with. You definitely take some time. Look this over!

A

Just let you guys know my biggest reason for choosing this path is because the idea of each spec being version independently scared me a little because of the the the let's remember that the cross-product of you know what spec of X goes with what spec of Y and which one match up it just sounds like it's gonna, be a maintenance nightmare or iorry a linkage nightmare trying to keep all those things in in sync letting people know which one to go with which spec it just subtly could be a real pain in the butt yeah.

G

I wonder if we can come up with a process that fixes that, where we don't end up in weird situations, we're like on one hand, I totally get the primer for version. 2 should be associate with version 2, but if I add to the primer in order to help people better use version 2 it's. Where did that now makes version 2.1.

A

So keep in mind that this doesn't necessarily mandate when we modified arms like when we increment the minor version number right. So, for example, a non-normative change could technically be a what's the third digit, the provisional.

G

But yeah I should have given a revisional bump in it. In the example, it still is a little bit weird that, like we can't improve the documentation and have that show up in the results for how to use one. No, no! No oh yeah.

A

Okay, um obviously I said don't want to push this thing takes on just take some time to think about it. Are there other ideas that people have on the call here that they'd like to offer? Even if it's just a something you just thought about that this exact moment it hasn't been five fully a thought through just to get some brainstorming going. I.

H

Think this sort of works because we should allow changes to document said the minor or patch level yeah. So you try to group a family of things together, yeah and that's really to me the major version: I guess it's, whether you you treat major and minor as a room, darris air releasable item, because all those other things are really saying. Yeah I want to add a Cathcart binding to version no got one that shouldn't change. The major release of that respectfully.

A

That is true because we are trying to follow the assembler pattern, so everything should be black was compatible with in we hang on by yes.

H

Exactly well, I mean it's whether you want to take you to X dot, Y or whether you just want to take you to X I mean we follow our API versioning internally at PayPal follows that major version, semantics yeah. So you you subscribe to a major version of something and everything is compatible with in that. So stuff can evolve minor or patch levels, and you can add new features yeah without all mappings without breaking stuff. So it's where you, where you want to pin the level of grouping that I think is important.

A

So that's interesting, I'm a little nervous about suggesting this, but sometimes additional text for clarity sake isn't necessarily a bad thing, even if it is a bit duplicate of the semver kind of defines all this already right. Members basically says: all minor versions are supposed to be compatible anyway, but would it be useful to call out that aspect in this definition that way, people understand that you know just because we goto 1.1 business I mean you have to jump up to one point one, because 1.0 is still fully compatible.

A

If you don't need the extra features at one point, one then you're perfectly: okay sticking, we look quite oh I mean, but additional text like that help, or would it run the risk of potentially saying the wrong thing and then being inconsistent with semver itself, because I don't like duplicating text.

A

Okay, not hearing anything I'm, not gonna, add unless someone says so. Okay, so take your time think this over it will still be on the agenda for next week. I, don't think we're necessarily a huge rush, but obviously before we get to one point, though, we need to make you know this kind of decision going forward.

A

Anything else on this topic before we move on okay, and that gives the technical at the end of the agenda. Are there any of these other PRS out there that are actually ready that I'd miss cuz I, don't think any of them are technically ready.

A

Okay, are there any other topics, then people would like to bring up for discussion at all on today's call. Oh.

A

Listen well, I'm, sorry, very hard time hearing you I think my connections really bad. Are you asking you're asking whether we're gonna have a meeting next week correct, yeah, I I assumed we were going to have one? Is there something going on that would make us not have a meeting next week.

A

I'm not aware of any.

D

Events and process I know the OSS.

A

Summit in Scotland is going on, but I didn't that was worthy of canceling. The meeting.

A

Okay, so didn't hear: oh I think we will have a meeting next week. I'm not hearing anybody mentioned some reason not to.

N

What kind.

A

Of.

N

I.

A

Don't know yet I'm, assuming we may talk about the versioning scheme. Well, have the result of the property casing, discussion.

N

I'm asking what is all.

A

All the work flow subgroup- oh I'm, sorry! So Cathy. Would you like to talk about that? Because? Because we haven't had a weekly meeting for the work flow subgroup for for quite some time, so I don't think there's going to be one next week for the work flow.

N

Kind of oh.

A

That was supposed to be a cancellation notice. All I think yeah that I, because I I apologize I misunderstood what you're saying I can't remember the person's name, I think the person name is Taylor the one of the CNCs sort of administrative people. They ping me yesterday asking whether they should remove the work flow, subgroup, calendar, invite and I said yes, because we were not doing a rate of a meeting anymore. So maybe they made a mistake and they sent out a modification rather than a cancellation, but it was supposed to be a cancellation.

A

Okay, so.

A

So Cathy creeping along here, but no call next week we are only having calls on, as has needed basis. Is that correct? Yes,.

J

That's correct, I think for the workgroup that draft I think we still need to go through it and there are some where I saw some arrows there. So maybe in after the coop come from hi I'm going to go through it, then you know post a new PRS to correct those things and other people's are welcome to go through it. And then you know pour issues or you know, pour PRS yeah.

H

Just as a point of process is that being managed in this group or is that a separate, a separate body how's that functioning today so.

J

Now is managed by this group yeah. Previously we had a separate sub group meeting we have. Then we reached some consensus on the first draft and then we decided there is no need for you know that intensive meetings so we're going to just discuss it in as part of this group, but if needed, you know we can always have you know another another meeting, specifically on the workflow draft.

J

Okay,.

A

To answer your question from our broader perspective, if the workflow specification that's been developed, becomes mature enough to warrant it being sort of a standalone entity, then I could see a new workgroup or whatever the proper word is for it being initiated. Since the cloud events is focused just on the cloud event, spec itself and the workflow sits on top of it. So I probably a separate entity at some point in the future. Once it gets mature enough yeah.

H

I I thought it was something like that and I think. Some of this is just the heritage of how this group it started up in the first place. Yeah this one yeah.

A

Yeah, okay, yeah: it's actually kind of funny, you think of it right, because you got the workflow subgroup, which is under cloud events, which is technically still sort of under the service workgroup. Even though they're somewhat separate entities, we have those kind of a weird relationship right now. So, okay, thanks yeah, okay, any other topics. If you want to bring up, we have five minutes left.

A

Okay, in that case, let's just quickly get those roll call. Stragglers. Gem I heard you I Renato. Are you there.

A

Renato, okay,.

O

Okay,.

A

Okay, perfect, thank you and Leigh Leigh I thought I thought someone pop in the agenda or the speaker queue Woodley, okay, Mike place! Are you there? Yes, I'm here and.

O

Which company are you with by the way I work on the saltstack project? I'm the maintainer there? Okay.

A

So I actually represent I already just worked them I'm. Trying to for for attendance purposes, I try to associate people with a particular company for voting rights, I.

O

Do represent them? Yes, okay,.

A

Cool just wanna make sure great. Is there anybody else for the attendance that I missed all right cool? In that case, we are done. Thank you guys very much and I'll talk to you next week and don't forget to vote, but please wait until I send out a note to our Comment to the issue.

A

Okay, thank you guys.
youtube image
From YouTube: CNCF Serverless WG Meeting - 2018-10-18

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects