AsyncAPI Community, 27 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: AsyncAPI SIG meeting 47 (April 27, 2021)

Description

This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #47.

https://github.com/asyncapi/community/issues/23

Chat:
00:07:38 Lukasz Gornicki: https://github.com/asyncapi/spec/issues/513
00:16:39 Aayush Sahu: I agree with Lukasz. December is holiday month
00:34:34 Sergio Moya: For the record, this is the issue about the Intent-driven API for the Parser(s) - https://github.com/asyncapi/shape-up-process/issues/82
00:42:29 Sergio Moya: You are gone re-join your prior company
01:03:04 Lukasz Gornicki: https://github.com/asyncapi/spec/pull/531/files
01:03:43 Fran Méndez: https://github.com/asyncapi/spec/issues/513
01:04:14 Aayush Sahu: Bye.

A

Okay, I think recording has started so hi, I'm ukash and welcome to asking api public meeting. um Please be advised that this call is being recorded and it's going to show up on youtube.

A

So just take it into consideration. If you have, I mean not problems, but I mean you don't like it, but we have to do it because we want to be transparent with the community. So um that's if it comes to the intro um the agenda today, it's pretty uh pretty small but before we jump into the agenda items uh usual option, for um I think that actually everyone on the call have been here already, but if anyone would like to now jump in and introduce yourself to the community, oh wait.

A

I have to admit another person.

A

Hi, carlos, so I'm going back to what I was saying. uh So if anyone would like to introduce yourself uh while you're here on them on the call, that's the best time to do it, you don't have to do it. It's just that you have an option to like unmute now and and introduce yourself. So anyone would like to say something.

A

Don't be shy, we're pretty friendly here at least I think so.

A

Okay, uh that's just fine, so the agenda items um is like the main, the most important, and maybe that's why so many people joined is the 2.1 release.

A

But before we start the discussion, because I can't predict if it's going to be long discussion or not, maybe somebody has some questions that you'd like to ask before we jump into regular agenda items because you can't stay with us for the entire meeting, um but you would like to have some get some help from the community. So anyone would like to mention the topic you have before we jump into the discussion about the release.

A

Three two one: okay, so the release. uh Let me share, first of all, a link with.

A

You I just paste it in the in the chat, so the link takes us to an issue where we had a discussion about the specification release currents.

A

That was the last um issue on the last challenge we had to solve before um start planning before we could even start planning the the relay the release of the new version of the spec.

A

So we are already in linux foundation. We already have open governance model. We already have release cadence defined, so it's for now.

A

Basically on the discussion we had, uh it looks like we're: gonna release um new version of the spec every three months.

A

uh It's so and it's always going to be upfront, um communicated that, like okay, we release in april and then three months after april is july, um so so upfront we're gonna, know that we release on july.

A

We will have a feature branch for that and all the changes will be happening there in this in this future branch before the release.

A

Another important thing, because before I um we jump into the main discussion, is that we also have a new contribution guide, a new contribution guide for the spec, which is inspired by um by github by not github by by graphql and the in short, because you need to actually read the contribution guide to fully understand, but in short, it's. It works in the way that when you suggest a new change in the spec- and it goes through all stages and we're like we say, okay, this this proposal makes sense.

A

We should have it in the spec, then you are required, or also to open a request to a repository where we have a json schema for the specification, because json schema is not a specification.

A

It's just a a tool for us to validate using api documents, and you also, um I will have to open apr to um javascript parser um when that yeah adds support for this new feature in the spec, because that async api, uh like I would like believe I'm not sure if I can say about believing, but um our approach here is that when we release new version of the specification, uh the minimum basic should be available in tooling, so at least the the parser that users can use from day one um with the new version of the spec.

A

So that's briefly how it looks like from the contribution point of view. Now the the main topic is to to discuss. What's what are your opinions about the uh the date of the of the release? So we don't on. We don't specify exact date. I mean a day but just a month, and um there are two proposals so far and we're super interested with your opinions here.

A

So one is fran suggested in the issue that we could do it june already june, and but there's also a valid a comment from uh lorna about the um about yeah, making the release cadence friendly. For those who have, um I mean working companies when there are uh usually important things happening at the end of q, 1 q, 2 q, 3 q 4., so she she suggested that we should maybe avoid the the last month of the quarter, but maybe do it in the middle.

A

So that's why looking at the proposal, it would be either may or june and now yeah after this lengthy introduction, any thoughts about the the month of the release and keeping in mind that we want to regularly release every three.

B

B

uh What what's the real concern behind reducing that um range of time to be? Like, I don't know once a month, why not doing release more often.

A

So the thing is, is it's: um we never did it in such a way that we're gonna do it this time. That's that's what that would be my first um statement here, the other one is I mean at the end, it's um it's. It involves a lot of changes. It's not just a small change in the spec. It's also the the change in the uh in the in the json schema and you need to add feature to the to the parser, so that has to be coordinated at least first few releases until we learn.

A

Oh, let me admit front.

A

So at least few first releases we need to like learn how the how we can automate things, how we can, how we can do it smoothly. So that would be. um That would be my my answer here uh to the to the motivation before be behind these three bonds gardens um the initial idea from from fran. I remember was six months uh lorna suggested three months for me. I think it's it's fine.

A

I actually wanted to do what you sergio um just said like why not regularly released, and I tried to uh do a um proposal for that, but I wasn't able to like imagine how that would work continuously, um because with feature branches, you can do those uh release candidate releases separately from the master.

A

So technically, I think it's it's just uh much more complicated and that's why I would not do it more often like, but that's my personal opinion here.

C

I totally support zoltan speaking. If you hear me totally support that that, if you start trying to do this, doing too frequently is is is challenging first. So I think it's uh three months is a good good balance in uh in connection to your question about may or june, or what I think is more important, not over engineer for you guys. So just keep it simple start. I mean you can always adjust and I think it's more important to ask how a spec life cycle could fit into that.

C

It's not more about the people's engagement, but how, for example, a new spec version if you want to discuss that could affect, for example, this kind of life cycle, but I don't think it is a big deal to just choose what fits the best and just start doing it.

C

So that would be my input. Don't over engineer.

A

The good stuff about may is that then it's august and then it's november.

A

Otherwise, if we do june, then we end up also with releasing on december, where people this in december they're, uh I mean in different moods than work. I mean at least me.

D

uh Actually, I'm not sure it's good that we released in august because, to be honest, I would probably be on the beach or in the mountains somewhere like.

E

Precisely so yeah, I think it's good that it's it's.

D

It's actually good that it's september, because we're back to work most of the people are back to work, at least at some point of september.

D

August not sure it's it's top season vacation season, so so yeah. But the cool thing is that as lorna is that.

D

If we choose may, for instance, it will be in the middle of the quarter, which will be better to avoid will be best to avoid uh this end of quarter noise that you get from your company and from other things you might follow right. So so yeah that's good!

D

Maybe I don't know. Maybe we don't have to do it every three months. Maybe we can be a little bit flexible here and do it in may, but then september just to skip vacation season summer season in the in the north and hemisphere, so so yeah and then but then the problem is that yeah december, and then you have december holidays. So yeah.

F

D

Thing so maybe.

C

I think it's more like a question. What we're discussing right now with yourself is that wherever you're evaluating the regularity, I'm in the fixed regularity or you, you are interested on releasing more frequently meaning that you can say to the community or the outer world that okay, we have definitely four releases in this year or next year. We commit to that and in average it happens three months, but because of all this consideration, you're not fixing it. So you say that okay, average free once you're releasing something and then it could be.

C

So it's not like you have to decide on a fixed frequency. I mean, because the release is not depending on the machine, it's depending on you or or the community. I mean, I think it's totally acceptable if, for example, nobody is that in august to to accept the release, I mean so how you release that.

C

I mean, I think, the most important thing this also like don't raise on friday, because then you sit there and fix box on the weekend, so so and and then, because when we come back to the other question that the frequency of that, if it's, if it goes well and you want more fragments, so you will change that very fast to a more frequent release and that it's then the relevance of this thing is more indifferent, because if you have a monthly release for example, or average monthly release, so it doesn't matter if it's quarter or not or holiday or not, because you have roughly a monthly release.

C

But of course it's just about question of maturity or veal. Also.

G

You know I've got a quick question about what the versions would actually be that get released. So if you only have um a trivial change to the spec, would you release a patch version? If you only have uh a non-breaking change, would you release a minor version? If you have a breaking change, would you automatically release a major version of spec at at each release, sort of window.

D

Yeah, I think this. This is the the intent here right, so right, patches would be regularly. Yeah actually patches will will not wait. Patches are immediate right, yeah miners are miners and majors are the ones that wait to the release month. If you want, let's call it like this so yeah, because patches usually are just you know, typos and things like this. I mean we don't have to wait for this right. This can be automated, even if this can even be automated with a semantic version in in you know the semantic comment.

D

I always forget the name of this conventional comments, conventional currency, so so yeah that would be great and then yeah we might end up. I mean we'll try to do our best to now to group major uh or breaking changes right. So so we don't end up releasing every three months, a major version right.

D

So instead what we do is like okay. So this is a breaking change. We already have another three one, so let's group them together and put it into a specific release, even if it takes longer to release, but at least you release all of them together right, but yeah and some people are concerned that we release we might be releasing very often uh as a spec and and that we will be will end up. If we follow this convention, it's easy that next year we might be talking about facing kpi5.

D

It can be uh because if you keep releasing things like this and and you don't expect the breaking change, but then it appears- and you wait maybe six months and then it happens again.

D

You easily end up in five or six next year, right so which it's not that bad. If you think about it, but the thing is that the problem is that we're pro or not a problem I mean. But the thing is that the issue with this or the fear with this is that at least myself and some people as well are used to the open api release cycle and when. But the different thing here is that open api doesn't offer the tooling.

D

So it has to wait for adoption in the community right on the tooling to to to catch to catch up right, so that takes that puts a lot of pressure on releasing a new version of open api because then, or releasing very, very often with major with breaking changes because yeah, it's like you, have to wait for something you don't really control, but one of the things that we make it mandatory on the release cycle and the spec is that you should apply the changes to the at least for now.

D

The javascript, parser and json schema definition of the spec.

D

So that makes things easier to release a new version, because then some things will be just like, for instance, dale dale lane is working has been working on the kafka sassel. You know it's also authentication for kafka and all this stuff, and um it really doesn't mean much for the spec or for the tooling sorry for the for the parser. It means nothing, just updating the json schema definition and point into the new json schema.

D

So then, it's a matter of maybe the documentation, renderer or the code generators to actually use this value and do something with it. Okay, so the final value might be delayed.

D

But the thing is that we're trying here to decouple uh the release cycle of the spec with the tooling right, even though we might be able to keep up with the with the with the release cycle of the spec on the tooling side. But if it's not the case, it's also not a problem because at some point we'll get there right, but the thing the thing is that we don't have to make people wait for something just because we didn't manage to do it uh on this specific point in time.

D

For this specific feature right, so we can keep evolving and um and of course, but of course we will make it uh we'll make our best effort to to have the tooling support the latest and greatest, uh as in kpi spec, of course, but it doesn't have to be immediately right, or at least not fully supported, like can be, can be fully supported on the parser.

D

It has to be fully supported on the parser, but then I don't know documentation generator code. Generator might not make use of this new this new feature, but because the parser is is working with it. um You, the only thing you have to do on your code, generator on your documentation, generator is to update the parser. That's the only thing you have to do. You upgrade it and that that will work whenever you have time to implement it on your final product.

D

If you want, and but yeah at least the part that is core, which is the parser and the spec can evolve at the same time, right like pretty much like graphql right, then, if apollo, which is the final product, if apollo, doesn't support specific feature that is introduced in the latest version of graphql, that shouldn't stop graphql to release a new version right. It's a problem of apollo that whenever they have time and whenever they decide it's good for their business, they will support it, but the parser is there. The spec is there, everything.

D

Is there right- and it's already useful if you want to build something so yeah?

D

That's why we're sergio and jonas it's they're putting a lot of uh emphasis on the on the intent based intent, driven api right for the for the parser so to minimize these breaking changes as much as possible, even if the spec has breaking changes right so yeah.

A

And just to add to it, um the the plan is that we will always have this um kind of release, candidate branch for for the spec, for the json schema and for the parser, and I mean we didn't do the release. Yet. But technically it's possible that whenever we have new change that goes into this release candidate branch, we can release it as a release candidate um and we can automate it. So it's also by by default users, will get json schema and the parser.

A

But if the change is done at the beginning of the release cycle- and we have enough time to add support for new feature in other tools- we're going to do it and then at once we're going to release everything so so we're pretty pretty backed here by the tooling. I would.

D

Say yeah exactly we have the stages right. We have the different stages on the spec, so as as soon as you have something that is um stage two, which is draft, uh it's more or less mature enough already so tooling can already start implementing support for this feature uh more or less confidently like it's, not gonna change a lot for sure. It's probably gonna change but yeah. It might involve you changing some stuff here and there, but it's implementation will be more or less the same.

D

So so the thing is that you can start implementing this functionality. I mean you can start as soon as someone opens a a a proposal in stage 0 right.

D

You can start even at that time, but but it's safe to say that on on draft on the on the draft stage, you can already start implementing things on tooling and you can even release your tooling with this support under flag or something like you want to. You want to support the the latest uh draft number x.

D

uh I mean this is not new. We we, we all use tooling like this. Like um especially, you know the one space on specs, but, for instance, I don't know examples of this are chrome, chrome has or firefox has these flags that you can turn on or off uh depending if you want to try a new feature or not right and javascript, for instance, in the language itself, they follow the same pattern, so you might want to use a new, a new operator that appeared cool.

D

You can use it, but you have to run node with a specific flag. Okay, you know that you know what you're doing, if you're doing, if you're doing it, you know that it can change at any time. So it's up to you, but people can already use it, offer it and and and use it so fran.

F

E

C

uh It seems to me that we are first of all you as I understand you're binding the parser to the spec version, and then then we are blurring the two things a little bit together, that uh talking about the the versioning and the uh applying the features or using the features of a software or a spec like when you look at yeah. Like you just mentioned, open apis is just free or something like that or even http I mean so so when stuff on spec, yes, so kind of stability.

C

That kind of stability is kind of part of this world. I'm not saying that it has to be I'm just saying that this is how people experiencing the specs and, of course there was, for example, we see also changes like the java version. I guess when they just jumped in, and I don't. I can't remember where we are in java, 16 or 17, or something right now, after because they changed the release lifecycle, but I think at least it works to to communicate.

C

So, even though, if we say that this is this is a good thing, and this is the kind of agility, but I think it's important, for example, for the spec adaptation, like I'm thinking about corporates, for example, when they are, they have committees, for example swagger. Yes, these swaggers too, and they still, I I'm working with things that there are discussions that should be used free because we just committed to two or this kind of this kind of behavior of uh version, frozen versions like framework versions or everything. So it's respect is more like that.

C

So I think, if, if it will be necessary to somehow communicate how people can can adopt to this kind of real cycle of the spec, if you understand what I'm trying to save and because.

H

C

To the parser, so it's I'm not saying that it's bad! I'm not I'm not against it. To not misunderstand me, but at least like you just started this clarification, so how you do what kind of, for example, enterprise decisions you have to take, how you manage this in a in a corporate or enterprise environment. So, for example, not scaring people. Oh jesus christ, it's too much virgins. We cannot follow because our governance model is like me making decisions every year and how can we follow up and what are the migration costs of all these versions?

C

And everything, do you know what I'm trying to yeah so.

F

I think that's it's a communication thing, not not a decision thing, I'm just I just want to mention.

D

So if I understood well, I think um so. One thing that for sure we're not doing is tying the the parser version to the spec version. We're not doing this right, so the so the parser, the parsers will always support. Let's say.

G

D

So the the parsers will always support. uh I don't know. Imagine next year parcels will be supporting async a2 2.1 3 3.1, 3.2, 3.3, 4 5, whatever version we have right until a point where we decide that, of course, we're deprecating version 2 or we're. You know deciding that we're not supporting version 2 anymore or version 3 anymore, because it's been years already. You already had time to update right, but it's not tied so precisely because because of this, sergio and jonas are working on this api for the parser.

D

So you can keep your code, as is independently of the of the version of the spec that you're using right. Unless you want to use a new feature, of course, but for the existing features that from version 2 to version 5, all the common features that were already present in version 2, your codes will do should not be changing.

D

Unless you want to use something for version five, uh then of course you have to change your code because you have to add new functionality right, but um but that's the the whole idea is that, just because we release a new version of the parser, it doesn't mean that the parser will not work with previous versions of facing kpi. That's not what we're doing.

F

A

Welcome, okay, so um anyone anything to add to this um especially may versus june.

A

We also don't have, I mean also our approaches to not make decisions during the the meetings, so we're gonna share the the recording with the with the community in the issue and still wait a few days uh until next week, because next week is, may I mean I vote for june, but uh no suggestions here.

D

I I will, I will do another suggestion. I will put it on the on the uh on the issue which is using fixed months like we have.

D

We have, for instance, main we have september, we have january, and then I don't know we have to choose maybe march something like this february or march. That's it and we choose these months and they're always these months, and we make sure that these months are not conflicting with any uh vacation period or anything right. So good.

H

D

So it doesn't have to be every month exactly like, depending on the period the time of the year, but it's always the same. You said june september.

E

You want it to be june. Okay,.

A

I mean it's june, I'm in may september and then what you said.

D

May I mean I'm just I was just uh thinking about like may september, then, to avoid december because of uh holidays, we move it to january right and then we move it to march, maybe which is something between january and may right, more or less. I mean it's actually the middle, so I don't know something like this might work or we have three. These are four months four release months a year we can have maybe three and three release months a year, so we can play with them in a way that are they.

D

They are always um not conflicting with holiday spirits. Then it's just a matter of deciding which months, of course, but uh but my point with this is not about specific months but more about.

D

We don't have to be doing this every three months exactly right, but we have to be clear, which months are we going to release not now, but even the next year, and even in two years like this is not gonna change. It's always the same. Then we can. We can even promote this like uh it's uh release month in amazing kpi right, so we can even uh make parties online parties about it.

D

You know it's like it's release month or next release month, which is always the same, but it doesn't have to be a specific, fixed period of time.

A

It sounds like a plan, so I.

C

Support the idea to pointing a month, even if it's four or three or whatever but yeah you're pointing out months and then that's it.

C

And you have to fight over me and.

G

D

Well, it's it's up to I mean I, I understand the point of lorna on the issue saying that uh there it might be good to avoid end of uh end of quarters, but.

A

Yeah, um in the end, it's if it's defined up front uh nobody's stopping people from contributing to the spec. uh In the first two months of the of the quarter right.

D

You know, I think it's I mean, don't want to talk pro for hair, but um but I think it's more related to the noise. You know the the inherent noise in your daily life that you're already having emails and company communications and blah blah blah, plus it's in kpi release. So it gets diluted. The message gets diluted into the into your mailbox or you know uh what that's I mean I don't know um I mean now.

D

I I understand what this is saying, but, to be honest, when I was working as an engineer, uh I wasn't having this problem with the noise every quarter like for me every month was the same so just holidays. That's the only difference, so I wasn't caring about uh end of quarter or beginning of quarter. I think this is more for management and management levels. They they probably are more worried about it, but or they've received more.

H

I don't know how it.

H

I don't know how it is in the rest of the world, but at least here in canada, companies can define when their uh quarters end like when their year-end is and like, for example, solace is april, 30th, so april's a busy month for us. So um you know, I don't think it makes much difference. I mean every company could be different. At least here.

D

But that's fiscal year if I'm not mistaken right. So this is not quarters and yeah.

H

No but the quarters are derived from the fiscal year, so it's like you start with the year end date and then every three months there's a quarter in terms of our work. You know.

D

But it's still the, but it's still some months. I think because it's eight yeah.

H

It's still three months, this.

D

Fiscal year starts in april 1st, so it's still the same month.

H

Just well, it's yeah, the fiscal year starts in may, first actually for us may.

D

First april 30th.

H

Is the year end yeah.

D

H

It's offset by you know a month or two, so, okay, so.

D

Then this is different, yeah and then the months are not the same here. Okay, they didn't know. I I heard about it.

H

D

April, first, no not may 1st.

H

Yeah, in fact, that there's there's actually people recommend not doing like year-end like at december 31st, because people are away for christmas and stuff like that. So you know they actually recommend. Companies have odd year-end dates. You know that don't correspond with you know things like january, 1st or whatever. So maybe it's different in europe. Maybe everybody has the same year. End date. I don't know.

D

No, I think I mean in different companies. I've been working on they.

D

It was always different, like some companies were following the natural days of the month, like not through quarters from january to december, and some companies were starting on april 1st, which always sounded weird to me, but yeah. I only saw these two variations, never may first so yeah. Yet another reason to yeah.

H

I'm just suggesting.

C

It's not an issue after all. I think that's your point, then then it's like you cannot. You cannot address everybody because then you ending up discussing every month or every day and it's like what market you are addressing and stuff like that. I mean what is comfortable for you, guys in the community. I think that's more important.

C

So are we comfortable to release on a date or like that or not that's? It.

A

Virgin only because.

H

A

First time we're gonna do it right, so we need to configure a few stuff and and figure out things yeah. No.

D

That's that's true. I mean for the first time it's it's a little bit perimeter to choose make, but because it's next week so.

A

Basically avoid pressure right, I mean that's. Why.

H

A

Left my previous job to forget about pressure.

E

uh Okay, didn't I tell you.

E

That I had a call with your previous manager and went back.

D

And he told me that you're coming back so yeah and actually yeah, I mean I want to release a new version on december 31st man with the you know, with all the fireworks and with the real fireworks, which is actually january 1st, not december 24 uh 31st.

A

uh Small comment: um fireworks are not good, at least in poland. We run away from fireworks because they scare animals.

A

It will be the same here, but it's not so so I'm not signing up for the fireworks but still 31st of october of december. It sounds interesting, but no thank you.

A

uh Okay, so to summarize uh this week we should we should um decide on may june. I think we're all pretty pretty supportive for approach that we know upfront years ahead. When release happens, we just need to figure out what months, if it's four times a year three times a year, if it's yeah whatever and also the first release, I don't think it has to be according to the schedule, because it's a first release, we're gonna experiment. A lot. I think.

A

Okay, another topic related to the release, is the scope of the release.

A

um Of course again, um I don't think it's uh it's a place to discuss the scope of the release more important to communicate with you that I mean if the release happens, may or june.

A

uh That's the moment where you should probably push your topics um on the on the to the release schedule- and I was thinking like if we need maybe some kind of open, dedicated channel or sl on slack or maybe create an issue where people um could discuss the scope. So, for example, I mean- or you think we should go directly to people, because I, for example, I know walid.

A

He had a very good proposal with adding the message id to the spec, but I mean while it as many community members, he's not able to follow us every day because he has different job.

A

So, of course we can be proactive here and I can ping quality and ask him if he's available, to push forward his idea, et cetera, but maybe I mean proactiveness is one thing when, especially when we know people, but not every case is like that. So I was thinking if you have some ideas, how we should um yeah, where we should hold this discussion about the scope. Is it still general channel, do you think or any channel, as usual, nothing dedicated to the release? What's your what's your.

A

C

You're looking for a channel or a communication where you would in detail discussing links or.

A

Yeah, like like a support channel so first of all um discuss what should go into the release and who can be a champion for for the topic to push it forward, but also because it's a first time we do this release first time, we organize it in the way that it's uh discussed.

A

I guess it would be nice to have a like dedicated place where people know that they can go. Ask us questions and ask us for support how to like do this first um contribution.

A

That is not just not just job and issue but actually like from they from step, one till the end: uh how to get your topic into this pack uh in this first three days. So it's a support plus discussion, something like this.

C

I'm not big fan personally and bad experience with the designing up from how, when you separate the channel in a communication like slack or teams, or something because what I my right, but I realized that people has their opinion of what channel name should be, and then the discussion is about the channel name, for example, and that's very annoying. So I would have been talking about just the first one.

C

I would say that general is pretty nice and and to start with, and if, if the discussion grows to an extent that it's not manageable because you have to scroll back and so forth, you can still can spawn out and say that. Okay, this is the first series channel now, because it's like so volatile or something like that about the productivity.

C

I think it's a good idea to to to send notifications or property, but it's also remember that also gives you an extra thing in your shoulder to do that. So I would say that somehow I would automate that instead of saying that lucas, I have to remember that to being xyz about a topic or something because then at one point you you go crazy, I mean so, but that was a maybe a middle term.

C

At the first time I you know the main contributors already, and I think you just have to gather this, this team and on general as a start and start doing it I mean, and then I think the other thing is capturing again.

C

We just discussed this many times if you are able to capture the practice already in a sort of a issue or something so next time you don't have to discuss it because you captured the tips and tricks in the way I mean, but that that we have discussed that- and I think you have to practice already this kind of practice that capturing this kind of things in in in places.

C

So so I would do this way, but that's just.

C

A

Yeah, in my case, I I only think about this channel and good good idea about having it as a temporary, because I mostly will will support uh and it's gonna be probably me or and from, but maybe others if they want to jump in into this initial configuration, uh how to do it with conventional, conventional comments, etc.

A

So it's going to be a lot of discussion when and we always avoid having discussion uh in private channels and um and in general, having idioms like more more discussion about like focus only on the release, it's just. It can just generate.

H

A

I always try to avoid the noise on the general. That's why.

C

Okay, that's fair! That's what I said if you already know that that it's it'd be noisy, you were expecting that so yeah and then just open up, but with I I think I mean the channels. I always think that it's like precisely what you just said as you're thinking. I think it's good to point that it's temporary. So when it's done the knowledge, that's very important, because how expert what do you expect from a channel? Yes, that's true expectation, communicate, discuss things or you expect that this is the.

C

This is the source of knowledge, so you you want that people find things there and I think if in this case, it's more more like communication and it's very important to to keep it that and capturing the knowledge is some somewhere else. Yes, the practice, that's that's where the test, where the the the differentiation and, of course, if you already know that this will be noisy, I mean you do a channel or you do some separated things and that's it.

C

D

My only concern with this is that this channel will go unnoticed because nobody joins and people just don't know it's there. So my approach is my approach is to be that one like as a developer. You want to categorize things properly, but then I realized precisely because of you guys that you suggested this to be more reactive. So if it becomes noisy, then we react it and we create a new channel um when it becomes noisy.

D

When you know when we notice that it's it's already noisy, because we might think it's going to be noisy and then in the end, it's not so, and then people might not notice, there's a channel there or they don't know what it is about and they just don't join because they don't know what it is about so like, for instance, we have this. There's there's a lot of misunderstandings with channels like I mean not a lot but there's some of them like uh opening async api, some people, uh there's a channel called open sync api.

D

Some people think that this is the channel where we are open and uh and they can and it's open for them to ask questions there and when it actually was created to discuss about the fact of mixing open api and using kpi together as a single spec. It was an an old idea that popped out in the beginning of the times of the channel of the slack workspace. But people see open, async api and it's ah so.

D

This is the open channel for me to ask and this channel is there, and I mean nobody is nobody's using it and um so yeah. There can be misunderstandings like this like if you create a channel called what release support or something uh for release or what some people might look at it and it's like not for me and it might be for them, but yeah, I don't know so.

C

I'll see see you just come. You just come through my theory about discussing the name of the channel.

F

Yeah yeah exactly so, it's like.

D

I I prefer to go the other way around now I mean before I used to be like this, but now I prefer the other way around, which is let's be noisy, and whenever something is noisy, then we discuss what to do like. How do we categorize this? Maybe on the welcome channel and on the welcome message on slack that we have configured, we can explain more there, but not sure how many people are reading this message. To be honest, I am this kind of person that never reads these messages so so yeah.

D

So yeah. That's why I was like. I mean everybody is in general, so if we want to, if we want people to be aware of it, let's go let's use general and if it becomes a problem like with tooling like what happened with tooling, then we split and like what happened with the integrations with github releases and new issues and pr's that were initially were linked to general or tooling. I can't remember, and then they were separated out because of the noise, so so yeah like again like reacting to what happens.

D

We don't know we might think we know in advance, what's going to happen, but we might be growing and say so. Yeah.

C

H

Again, it's about.

C

It's it's about premature assumptions. That's that's what we talked about. I mean I think, addressing what you just mentioned. No one knows about. It again goes back to the practices about productivity and how how you use general. Yes. So, for example, if you say so, it's like lucas, you just mentioned that you want to notify people I mean, and then you can say that okay, there is there's a regular announcement. Regular, you just you know, re-reiterating the message and then it comes to release again. We talk about release yes or the first release.

C

Definitely so maybe it's just periodic or temporary, so I mean I doesn't matter how you start again just start and then just jump on it and don't discuss the name of the channel.

I

Is the remainder of the agenda for the last four minutes? Is it very full or can I ask a question.

A

That's the best moment to ask a question.

I

Yes, so I because I've just submitted a pr against the spec, and then I found out that this meeting is ongoing. So I thought that's a good good occasion to pick it up and and and just mention it so lucas pointed me at three uh issues this morning and and they reflect the issue that I've been running into, which is essentially that there is no link between channels and servers.

I

Essentially, a channel has a name and implicitly, it's assumed that all the servers have that channel and I've been writing an async api doc for a an application that needs to work with different servers. It it reads.

I

For instance, it receives messages from one server on a certain channel, and then it sends out messages to another server on another channel. So I need to link channels and and servers and as I said, there are three issues already on that and I've submitted a pr against the spec that, I think, would address that.

I

Just wanted to hear whether the whether it's it's acknowledged that this gap exists, whether it's it's seen as a gap or whether it's just nice to have.

D

Question mark so well, I just noticed it. I mean you opened it like a few minutes ago. Right, yes, okay, so.

I

No, no, but but the issues were old.

D

Oh yeah, yeah yeah, no, no, the issue is is like it's actually pretty old, I would say from from version one yes, but um yeah. I just want to add something here which is for those here in the call and watching the recording.

D

This is the way this is the way you want something to happen, just open up pr or it needs to uh preferably a pr, and even if it's not file a final version, which is probably never a final version until it takes time right. um Just do it like, like did right right now like this morning, we were talking about it, and now we have a pr where we can discuss over the changes. So that's I mean thanks for that man. That's that's perfect awareness.

D

I

To it's easy to write, markdown.

D

That's not that's not.

I

D

I'm actually gonna label this as a as an rfc, and um just so we don't forget about it. We don't lose it so yeah.

I

So so what what do you think about the relationship between servers and channels? What's the assumption always that all these servers would be for different environments and so would support all the channels in the document.

D

I think so yeah, I think, most of the times it has to do with environments, at least that's what I found out like development staging test and production, usually and and then.

D

Yeah, I don't think I don't think I ever heard of a different use case.

A

I mean there might be other use cases, but yeah there were people, sometimes asking about this uh exactly this situation, that you have two different brokers, two different like technologies, mqtt or kafka, and that um one application communicates with two different brokers. So you want to basically have have this linking so few people asked but like as emphasized about front set, but you're the first one to that actually created pr and and took time to exactly um to take it forward, but there there people talked about it. The challenge is, I mean challenge.

A

The thing is that, for example, in generator at the moment we have, let's say native support native support for approach that you have server per environment. So so there is a a core feature in the generator where you can, that you can use and generator will always pick um the server that you specify in the cli. You have a dedicated parameter um where you can say: okay, I now do code generation for um server a or.

I

That's the key in the map.

A

Yeah and the only my only um so I'm whenever I'm I hear about this idea, I'm so biased by this environment approach and this feature of generator that I can't imagine how will it work without it like when we have multiple servers, uh supported by the same by single application on production, for example?

A

So that's um a thinking challenge, for example, for me that I will have to go through looking at the proposal.

I

So in my scenario, I would have, let's say an ibm mq server in dev and improved, and I would have a I don't know, an mqtt server in dev and improv, and so your approach still works. It's just that the name of the server cannot be dev and brought. It must be ibm, dev, ibm, prod and mqtt dev mqtt pro so four different servers, four different names, because they must be unique in this map in the service map.

I

Yes, so that that needs to be.

D

And and answering and then or adding to your comment, you guys, I think one way to think about it without the usage of server on the generator on the cli.

D

One way to think about it is that the code handles this based on the environment variable, for instance, right or a given environment variable so, like I think, like in node.js, for instance, you have node m node, underscore m, which in production is usually production, and if it's not set, it's assumed that it's development right and uh so the code could be checking this for you right checking the node and for the m environment variable.

D

So so you don't have to pass it on the cli right, but again, that's a strong assumption of how your code works. So how.

I

The servers are named really, no, that's the assumption.

D

Exactly exactly so, that's why we thought in this initial idea of no, you pass the server you want to generate the code for, but yeah like in the case of general, for instance, the code will be always the same, it's just depending on an environment variable. Maybe uh it will point there or there right so um so.

A

Yeah, so I just pasted the link to the to the pull request from gerald, so thanks gerald for doing it.

H

A

Wants to jump in then please it's three minutes past ten, so you have to respect.

H

A

We're gonna finish: no worries, no worries, thanks for training. um So uh to summarize, um we can like we will finish discussion about the release uh this week in the release, cadence issue and.

A

That's it and I'm so tired that I don't know how to come finish. The call so, let's say thanks a lot uh for joining again with such a huge number uh again. We see each other in two weeks in the morning.

A

8 a.m utc, and I guess that in two weeks we will already know where, when exactly the release happens,.

I

D

Thank you, bye.