Open Telemetry Uncategorized, 21 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-03-21 meeting

Description

Open Telemetry Meeting 1's Personal Meeting Room

A

A

All right, Larry.

B

Hi Tom, hey hi, guys.

B

Thanks for joining.

C

Good evening, yes, sir.

B

Yeah, what time it is I think it's pretty late for.

A

You right 7, P.M, okay,.

B

Yeah thanks thanks a.

A

Lot, tomorrow's meeting will be uh at npst or nine.

B

It should be nine I think.

A

I think I won't be able to make it okay.

B

A

C

A

Right time, right time will be 5, PM, okay, but next week will be 6 p.m.

C

Okay, yeah, so from your side, you are going to like daylight saving time in from the next week.

A

Yeah it's on Sunday.

C

B

Okay, I think probably uh I mean I didn't have any as such as I just wanted to discuss like what do you guys think in general I mean uh having Mark as a maintainer I mean I mean my concern. Was this couple of con couple of things? First thing was that in general it was more of a balance between approvers and voters. More of active approvals and active voters, I mean maintenance, I mean as of now. We are three active maintainers and then we have two approvers.

B

So if we move Mark as a maintainer, then we'll we will just have ubunters and as an active approval, I.

A

Mean in general, I.

B

Don't in general the thing is that I mean even as a maintenance also we have been doing the approval, the reviews and the approval, so that should not be a major concern, uh but yeah. This was one other thing which probably I was thinking, and the other thing was uh I mean I'm, not sure I mean I. Think he's Mark is very good, I mean in terms of his uh contributions, his technical abilities and uh the way he has been contributing. I mean I, don't see any concern on that.

B

The only one small thing was that probably I don't know. Maybe this is only me I sometimes I felt that he is too much of process oriented. He tries to put lots of processes in the in in, in the things uh probably that some sometimes that's uh I mean it's good, to have uh definitely a right process and right approach, but sometimes I think probably I've personally felt that that was stretching bit far in some of the occasions like like deprecation.

B

The current process, which we selected to duplicate uh any feature or any macro, probably I, felt that uh we added lots of process on that, and uh I mean that was. That was my control like.

B

If I mean it's good to have contribution in terms of future and even putting a process lately process to how we should have duplication, how we should have version controls all our good, then definitely we should have it, but not too much of process into that, and my only concern would be like if we start adding lots of processes on the on non-feature prospective things that that will probably probably I think in general will delay the things so I mean that was something probably I had observed and I mean in Intel like deprecation.

B

If you see we added lots of documentation output, how to deprecate macros, how to deprecate a given feature, probably I felt that we could have just decided some decided uh I mean it could have been much simpler to do a depreciation than to add enable macros, and then any uh um I mean that that's probably I think if you want again share. If we want to discuss on that, uh um let people just open the.

C

Are you sharing screen no.

B

I'm just trying to open that PR, uh which probably even has done it. Let me share it if I can open it.

A

Yeah I am maybe I can share something here. I think he he's a very product Centric.

A

That's why you see those processes, yeah.

B

A

That he's thinking about uh production, a lot and yeah.

B

I mean totally understand, like from various I, mean uh definitely those uh detailed he's very detailed oriented on lots of aspects. This definitely helps as a team yeah all right.

A

It could be just one issue: I mean if we go into detail in everything, um I mean I.

C

Mean I'm talking about.

A

The project that project is more like um a startup thing right, yeah.

B

A

Shouldn't have I believe it shouldn't have too many uh complicated stuff. So, like like the process you mentioned.

B

I feel that probably lots of things which we have laid down, which we have already agreed and I, really don't want to change them unless, until there is a valid reason of changing it, like versioning thing, ABI versioning, we already had decided I mean long time upfront that we won't maintain uh backward versions.

B

And right now, I think he's kind of proposed he's proposing to maintain multiple versions, I'm totally fine with the proposals, but I mean it's should not get uh I mean that that's my concern like he should know. It should not happen. Like we add lots of uh stuff in our uh lots of these non-functional features in our repo, which probably will not be really required in.

A

B

I mean just adding this example of my version control like if you want to have, if you want to maintain all the previous versions in our repo I mean just to and just to ensure provide a backward compatibility or just to ensure that nothing breaks to have a compatibility, and that may not be required all the time, and we already have uh I think documented that we for the API compatibility, we'll just increment the API version, and that will ensure that uh uh if somebody is having a preview version, they will at least have a compilation failure.

B

It will not be a so it will not at least they will not have any memory, corruption they will. The compilation will fail and which was something documented and now his proposal is to come up with multi to instead of that to have multiple versions maintained. Previous all, the previous mentions, of versions of the API should be maintained, which is fine, I. Think uh discussing and probably proposals are totally fine, but um my only concern as a maintainer, if he's trying to if we start, if we'll start pushing those stuff, that would be a problem.

B

A

Right, we agree with you and I I think these stuff should come when we are I mean when we have no more feature to develop and I mean not having.

B

A

When we are mature enough to, you know, spend time on this.

B

Yeah I mean a lot lots of things. Probably I I see the way that if, if the customers are asking, definitely we should. We should start thinking on that.

B

If there are lots of customers trying to ask those things, but without seeing any uh requests from the customer, so without really seeing any I mean any Demand on those things, we should not invest more time on those stuff uh so that that's the way I look into this I mean uh adding too much of features too much of too much of non-functional features too much of complexity will uh will would be difficult to maintain the uh repo. In the long run, I mean it's uh yeah.

C

I think I agree on this, for this one I think maybe like the in the future like for work on some significant, significant feature or something. Maybe we need to get agreement like between the maintenance to see. We will put a time on this like um traged the the Milestone or backs or work items right before we're working on that, instead of just to pick up something yeah I agree unless yeah.

A

Yeah I I have a follow-up suggestion. um Maybe we could follow what uh Ingress Engineers report is doing, I mean they. They also have uh many contributors and it's it's a.

B

A

Are many uh issues and PRS and so on, but how they handle uh things uh they have this. They are using these projects from GitHub and they uh they treat us the issues and features and and everything and it's also transparent and everybody can check and see. What's what's going to be done, what's in backlog and and so on, I I I was actually thinking about to have something similar for for open telemetry.

B

Yeah I think we started doing it, creating a projects.

B

But yeah I think probably we didn't see much traction through that and probably oh I think we didn't just follow it up on the longer and if you, if that's something we can, we can start doing it. If uh that can help us yeah.

A

I mean we, we probably could funnel everything through this, like I mean any feature or has is going to be added has to go through this, so there should be a triage approval from container and maintainers and approvers like with some criteria. I, don't know we say maybe 50 percent of I don't know like voting or something yeah.

A

B

I think that that's that's one good suggestion at least start start trashing it, and then some somebody should not just pick anything in the random without without any ask from the uh without which is not yet prioritized not yet prioritized yeah.

B

That's probably one thing, and probably we can discuss this triaging as part of one of the one of the community meeting. Probably we can spend, keep 20 30 minutes to try Edge and that's totally fine. If we all are there even even the approvals and maintainers are there as part of that.

A

C

Yeah sure yeah.

A

A

I mean I can share the link. You could.

C

A

C

A

um I, just don't know how to open the zoom. Okay.

B

Yeah I think we used to do this. I mean I, I. Think I got this.

A

I think we're gonna need it. Is this.

C

B

This is being there for long. We used to do it when we started doing it I think initially for traces also, but then we switched to Milestones. So we started.

C

Just creating questions I remember: we used a milestone, yeah.

B

So before that we also started doing for projects also but I mean I was trying to keep it updated. But then probably I didn't find much of the use and then I just start to move to Milestones but yeah. We can try it again once again, I think if it, if it's something we can manage to do a proper.

A

B

A

I can take over this one I mean I can um manage this, and it's mostly uh I think it's mostly automatic for Ingress repo I, think they managed by by labels or something so.

B

Just striving, as based on what like, based on the.

A

B

Release or what exactly how they do.

A

A

Yeah there are three four people: I think that they are like the main people approach, I, think I I, don't know how would they call? It should be something like a proverb, but they are actually developing features and really and they have bi-weekly meeting and and there they interior speeches and even bug fixes so triage all the issues.

B

A

So if you, if you want to.

B

A

Feature if you go through this process, it will be faster to to.

B

B

Okay, now how that is? Okay, probably let me let me look into this in into this project and let's see how they are doing it uh and but yeah. If you want to set up something like this I think definitely I, think if you feel it will help us feel free to do it and yeah.

A

I I can try this out and what is I think what is more important here is that everything is transparent, so yeah and everybody can check and see what is going to be actually developed and what is happening right now and so on.

B

Okay, uh but back to Mark, so what should we communicate to I mean? First of all, do we all agree that probably we have to wait for some of time for him to move it, move it to the maintainer I mean or if we all not. If we still don't agree, we can have some voting or I mean.

C

Yeah also yeah I share the source, as yours and also I have some like a concern and like, as you mentioned, um with a very product production oriented Focus, maybe for us I think uh we have some like policies in like merge code or something like that, but same sweet I think we we haven't been enforcing that right, maybe yeah with more maintenance like cam merge code. Maybe we need to put some enforcing on the rule like.

B

C

Like two company or two entities like that, so.

B

I'll just come again: Tom I mean I.

C

Mean for our, we have policy rate like merging code or checking code policy, but.

B

Same so probably.

C

A weekly remember: we are not enforcing that for every PR, maybe we we can like do some like for every future PR. We tag that as Tiny or small, so we can ignore. Any um policy is just merged it, so yeah I know for medium size and a large size. We like we.

B

Don't see for seeing the.

C

B

So we can start doing it.

A

There are I, I could probably prepare some GitHub actions, so uh I mean you can you can detect the size of the pr and report that and add some labels and based on those labels we decided like uh I, mean we say if it's smaller than 10 lines change, uh it's okay to merge with one and so on, but I.

B

Think it's good to go to good to documentary anything if you plan to do that like for.

A

C

B

Mean we can mention that smaller would be around approximately around 10 lines or 15 lines, and that can be done with one any one of the approvers yeah anything medium or large. Probably, we need more approvals, more approvals.

C

Yes, yes, yeah more approvals from from different companies right if we can do that, and so that would be great if we can enforcing that in our CI rule.

B

The only problem I felt earlier was that it used to delay our PR.

A

B

Should be open for a long time, and probably that's it's it's that something which can block we have limited. Each of us are limited amount of bandwidth to really spend and.

C

A

Was trying to add this okay to merge label yeah.

B

A

Things like uh it's from an.

B

A

Or maintainer and has one more one approved from maintainer approver.

B

A

And it's transparent, so it's visible, who made that label uh who added that label to the pr.

B

Yeah I used to use that I mean if you're okay to watch it, probably I just used to.

A

Randomly merge it without seeing.

B

What products so, which definitely helps yeah.

C

So what that's okay, to imagine me I mean because.

A

I think I've added to the description to it. So, okay, too.

C

A

I mean it basically means the policy that we have so it the pr is raised by someone from outside, and it has two approved approvals from a maintainer or an approver or.

C

A

By a maintainer or approver and has one approval from a maintaining or approve.

C

I see yeah so, but what's the difference like to add such labor, okay to merge and instead of just a merge it or.

A

I mean it just gives time for others. Maybe they want to read it also I mean I, see if there is no, no I mean it's just about that saving the time so I.

C

B

Yeah I guess gives at least indication to others like this is something which would be can be merged anytime. So if you want to stop.

C

You can do it now: okay, yeah, that's.

A

B

So I mean if you want to really enforce this, probably we should determine and.

A

C

I think we I think um we need um wait for the completion of this before we make Marcus maintenance. If we decide we're going to do that or do.

A

C

You guys think so: yeah.

A

Yeah and I, going back to maintainer I agree with the language. We could wait a bit I.

B

Mean I I don't see.

A

Any concern regarding his uh ability to do that he's.

B

Really really experienced.

A

B

A

I, he is I think he has a lot of experience with production and what he's doing I I see that it's coming from someone who is like lived with production code exactly.

B

Yeah I mean that that thing, probably we have to balance up, I mean he should we ensure that he should be motivated enough to keep to to at least con keep contributing to the project. Then he has some apprehension. I think we should see how we can meet it not immediately, but probably let us set up some uh proper triaging and uh some stuff in the project and then probably you can see if we could bring him with a.

C

Maintain yeah sure. Definitely you want him to contribute more yeah.

B

Yeah, so I think definitely yeah. We can probably we can tomorrow. We can talk about that that we had. We had a discussion. I think we don't see a issue anything so.

A

B

That there are lots of Maintenance, probably we should before that. We should put some process inside the I mean in terms of triaging and in terms of.

B

Setting up a proper merger guidelines.

C

Yeah and thirdly,.

B

We can bring him as a maintainer, so that may take few.

C

Weeks, yeah also like that yeah I think that's correct and that's why also what I suggested like besides that, like maybe like the more as we have more maintenance and then we need to even like even to figure out the like the release, rotation or something like that. We.

B

C

That as part of the process, then yeah yeah.

B

Exactly yeah yeah.

A

B

A

I think the only the the main thing to to be you know I mean to.

B

A

About probably at this point in time is keeping the um somehow this start up the speed uh alive not going to too much into detail for foreign.

B

Just want to keep this repo as simple as possible without much of the processes which are not really required. That's.

A

For sure, unless.

B

Until there is some customers are coming for anything which is not right. Probably, we should not really do anything proactively to fix the things which are not really required by the customers and spend our bandwidth on those scenarios. Those places yeah. It's.

A

B

That we should be specs compliant to be first, that's very important and then.

A

B

Definitely see anything else, we want to add.

A

And backward compatibility, I mean it's, it's three, two issues, yeah, you have to think about the past. Also like it's too much work, I mean we should um avoid it as much as we can right.

B

We should try to ensure that at least we don't break the customers flow of the code. I mean that we have done in last couple of weeks. We did it a long day. So probably we have to ensure that that's not being done um and.

A

B

Done probably, it should be documented, like we made, we make change, our cmake see, make options, or even we may. We can totally find to change our SDK, but it should we should ensure to document it properly, which is fine, which these things are definitely required, and we should do it, but not adding unnecessarily complexity in The Code by maintaining multiple versions and all those things that probably we have to take a call, whether it's required or not.

B

Okay, I think so that that's I think probably we agree that I think, let's, let's give some time, let's ensure that our we have proper process in terms of project Rising and the pr approvals and the merger I think that's probably paste place that in place in the in the repo and then I think once we feel the we are ready to have that many maintenance I think we can pull them in.

C

Probably we can like create some work items like to for each.

A

C

Items and put that into the link data to the pr to add the markets. Maintainer yeah yeah.

B

We can do that I think, have a process. We have in terms of project charging and uh more clarity on how on reviews and merging uh documenting it properly, and so we can do that. I think I, probably I can I can create couple of tasks and will need your help to really uh add more details on that yeah, yeah, okay, okay, uh anything else, domination, so I think we can communicate the same. Tomorrow's meeting, uh I.

A

Will not be able to join.

B

Yeah I'll I'll do that yeah and we can talk with him and.

B

You can never ask him to go through the recording. I want to be totally transparent when the thing something uh probably which is, which is I mean, which we have spoken here, which probably he should not be listening to I. Think that's totally fine. If you want to go through the recording yeah, what we discussed I.

C

Mean I don't see anything in.

B

C

And uh yeah, as we I think we agree on the apply but um like how about the timing, and do you have any idea like for the before the next release? We will expect to complete this, or maybe we need more discussion on this.

B

No I think probably a few weeks, let's not give any time plan in terms of before next release or something I think few.

C

B

Weeks, you can say: let's.

C

B

When we, we all are ready, uh we can. We can have another short meeting like this to see and then probably we will just pull him in yeah.

A

I mean we should also have the agreement on them.

B

Yes, on the timeline before we can.

C

B

Well, we can probably try to try to have a timeline among three of us if it says like to begin to within next three weeks. You can try to do that and then probably, if you can call them in three weeks from now, I.

A

B

A discussion before that and then we can do that.

A

And one more thing: um maybe we could also meanwhile provide him whatever he needs.

A

uh Pardon yeah.

B

A

Could provide him whatever he needs, I mean as an approver, but yeah.

B

He can provide any that's. That's totally fine I mean not that we uh yeah.

C

We also asked the like like to do release right. Maybe we can like ask approval to do release. That sounds like a reasonable request.

B

That that's, that should be fine, at least for your marks Mark's case, as we are already planning to move him to maintainer I.

C

B

So some stuff to sometimes so I think probably it's good to give him a feel of how we do I mean do a release yeah, which should be totally fine, I! Think: okay, yeah, okay, yeah thanks saan and Tom I think this was a good discussion.

C

Thanks, thank you. Have.

A

A good night bye.