 Sorry, as a reminder, sorry, I was having some issues. No, I shouldn't have echoing. Oh, I think even that's given the document part, we should probably wait for him. But on the other hand, I do want to start on time. I can try and he says he will be up to 15 minutes late. Okay, so let's just start, I guess. And we can come to his answer when he joins us. As a reminder, please everyone write yourselves in into the attendance document. Okay. Is there anything which people would like to do before as a quick and time box thing else we will just dive right into the continuation of the due diligence. The agenda that I've added also is strongly related with Bartek. Since he's one of the maintainers of your PC. Your PC Prometheus. So, yeah. Yeah, okay, but then it doesn't make sense. Then I guess we can just get started on the DD document. Share it and we can kind of review it again. Perfect. I was about to ask you. Yeah. Hopefully folks can see it. So I left all the comments so we can all review them live, but try to come into everything. So hopefully there are updates to any outstanding items I know many of you reviewed it over the last two weeks so thank you for taking the time to add some amount of assessment. We can continue kind of going section by section seeing if the updates are kind of covered, or if more additional information is required. So I'll skip the sections that are green because I'm assuming that we are happy with that section, we can always revisit if someone has concerns please raise them. So back to number three, does the project have production quality high demand high velocity quality type stuff there was a link to the adopters page and there was an asks to actually update this with what has been adopted. I haven't done that for most of the companies there are a few I haven't been able to get a hold of yet to actually add in the relevant components but at least the initial components are all listed here that was updated per request. Yeah, I guess any questions on that one. I can add several in there, which I do was not aware of it. Perfect. Comment here. That was you Jenna right. Yeah, you you want and you like anyone using it it can be like end user vendor or whatever. Yeah, right. Absolutely. Yes. Okay, cool. All the above. Yep. The one thing, which I'm pretty certain. So I'm just, I think we also talked about which components you call them components. So is this standard for metrics logs and traces for all for all of them or is the or do I assume correctly that those are the traces part I'm not going into that battle on on the document. Just asking for the overview so are all of those and tracing or do others also use metrics and or logs. So this begs a pretty interesting question. So open symmetry has multiple different components, each of those are known as their own sake within the project, but then there are data sources. I actually recently put in a whole bunch of documentation updates to kind of cover this. So you can see the different components that make up the project with instrumentation libraries of course being language specific. So the documentation proto everything's kind of built on top of, but data sources kind of represents another nuanced thing here in that traces metrics and logs are in scope for open telemetry. And each of these different components may support some amount of any one of these data sources. So I did not explicitly list the data sources in this table. And to your question directly Richie from a client library perspective, all of these are tracing specific, but in the case of the collector it is likely both traces and metrics, because many people pass metrics through the collector today. Okay, thank you. I wasn't aware of that naming difference and that you have those two orthogonal or yet another dimension. That's probably the more correct framing the phrasing. So personally I would like to see those in as well, ideally split by by the type of component if it's sending or receiving. But I think for the purpose of here as long as you just edit we can just close it as. Oh no we need to. Yeah. If you just say you do it. I'll get it done. I mean I'll put a note right here to get it added so you want to see data sources basically. And I think from what I just saw their components which send and which we see let me just get back into. Yeah, you're right. So the collector can both receive and of course send because it's a collector where instrumentation things are just sending to a destination. Yeah. So it shouldn't just be me talking. So what do other thing does it make sense to split up by data source and if yes does it make sense to do the second dimension of which direction components speak or are we over engineering this. So I think in terms of showing this to other people that makes a lot of sense right like as a potential user it's nice to see. We may struggle a bit to get users to actually bother to insert their names here and provide that level of detail. But you know as an end user it's always nice to see that stuff. Yeah we also try to call this out per language so like Java traces are in beta actually it's RC now this needs to be updated metrics or alpha logs are experimental. So you can see it per data source within each of these six as well. We don't explicitly call that on the adopters page, but each of these repositories list the state of the different data sources. Just for reference like there's there's a good number of adopters who aren't necessarily here because there's companies who adopt this who do not really participate in the community they just use it because the vendor tells them to use it or they decided to use it on the run. Yeah, I know that problem. So just to be clear, also from from the initial asked from from the to see which is put into that into that checklist. I don't think we need an exhaustive list like absolutely not it would be unfair to ask this of any project. It's much more about just showing that there is adoption and that's it. As there are so many orthogonal aspects of what observability means which are handled within open telemetry makes sense to make that more visible course is just so huge. But that's actually a plus for you in my book. One of one of the suggestions on Bartek's document was to maybe send incubation just traces or like in parts. So if you have adopters for different adopters for tracing dots for adopters for metrics and for logging maybe it's clear. If this is the choice. Yeah, and I think that's kind of an interesting topic so I mean I might be mistaken I don't want to speak on behalf of CNCF but the project is open symmetry. It can be made up of various different components and those components can be in different statuses, but the project is up for incubation, not the tracing part. And I kind of look at this similar to Kubernetes which is another very large project within CNCF. There are plenty of things in Kubernetes that are in alpha, but the Kubernetes project is graduated. I think it really matters that just the tracing data source is more GA ready than the other data sources, and I wouldn't want to subdivide by that just the data source because it's the project as a whole that's going for incubation not the traces part of it. And one thing I want to add to is that, you know, like, I think we're holding on too much the terms alpha and beta of being like indicators of quality versus that was actually like us as a project just more like trying to be very rigorous about like, hey what is stable versus not like alpha beta does unfortunately have negative implications that people will be less like, you know, excited to adopt things because I think things aren't stable. I think our adopters list actually shows that that isn't an issue with us as a whole project. And yeah, until like Steve's point where I like large projects there's always going to be some sections of it that just aren't stable where you can even make that argument with like on boy like on boy has a core set of filters that are fully supported and then they have things there that are always going to be experimental or other things like that. So, yeah, it's for the whole project as a whole not some sections of it. In retrospective honestly I think it goes beyond the scope of what a sick can can decide and it just needs to be a call by the TOC. I know that there was quite a bit of back and forth by the TOC on K3S as a sub project or not and asking sick governance I think about about looking at sub projects. I with my chairhead on I deliberately do not hold a strong opinion here for the very simple reason that I can see very good arguments in both directions. But I don't think it's it's fair of a mere sick to simply say yes or no to to actually interpreting policy this heavily. Again, I can see very good arguments in both directions. I agree with Steve's point on it being a consensus I think on this being better to move as a project because it just shows the overall velocity of the project. I can I can also see Bartek's point about this being potentially confusing when when it's this difference in in readiness or in actually being used but again I don't think we within the six should make a hard decision either way unless someone strongly disagrees or even slightly disagrees. I think this is probably something which which we just report as such to the TOC and they make the call. This is clearly what what our task is is to make a recommendation to the TOC right. It's not far to decide it's a recommendation. And if people feel strongly then we can point out yeah there you know there are concerns around that whatever which is part part of our diligence review. And again, think of, in case of communities, no one ever said communities can't gradually because you know CSI is not there yet. And, and if it's in the case for communities which is, you know, arguably a little bit wider than open telemetry. I think the same applies for open telemetry. It is the project that may or may not have certain parts that are on a certain level, as long as you're explicit about that. Clearly saying, look, traces, GA, whatever you want to call it production ready whatever you want to call it logging. This is experimental. This is something you might want to try out but it's not something that we consider yet ready for production. Very good with the expectation. Cool. So where does that leave us for a number of three. Richie had here a proceed on that. So I think. Yeah, again for the adopters just just put the data source as a, and I think you already did you. Yeah, you did so. As this is consensus based let's try with a consensus. SIG observability needs guidance from TOC or needs TOC to decide on project versus sub-project but that's the wrong framing. Steve, do you have better wording? C and C, TOC, explicit note here. No, no, I would actually make this as a call for consensus so we as a SIG can have consensus on asking TOC because that allows me to just close the point and move on. Got it. So do you want me to say what SIG observability? Just a second. I was going to put this in front of yours because fun fact I cannot type when I know people are watching me. Hang on, hang on. Why would we request advice for what we can point out something but we otherwise it's like they ask us, you know, can you do the due diligence we say, oh yeah sure but you know give us advice and then what then does that mean another round. Can we meet again and talk about that? I would not say request advice. What for? So they're not trying to to keep it in just first reply to your question. SIG observability is special in as much as TOC told us we should be doing or we could be doing more due diligence than other SIGs because the others are not as clearly scoped and so we basically offered to do more. So that is why we do more on the due diligence than other SIGs. That in turn means that this could be interpreted as us taking back this advice and then incorporating it. I don't have any problem deleting it so unless anyone feels strongly I will just delete it. I would prefer to delete it because otherwise like this is a process thing where it's kind of unclear what what's when will we get that advice? When do we like this might delay everything for months? No, like this the second we have consensus here or much more to the point right after this meeting I would be poking TOC about this so they know about it as soon as possible and then can act on it. This shouldn't be the right but again unless someone feels strongly we just have as a call for consensus and let's just do this. SIG observability requests a decision from CNC FTSE on project versus sub project. Comments anyone against all agreed? Good. Next one. Is the project committed to achieving CNC of principles they have committed roadmap and address any concerns so add a link to roadmap information so I've added several kind of roadmaps here as well as like a project board that kind of articulates this as well. Again remember that open symmetry is comprised of many different components. So roadmaps are typically done by those various components from a high level project perspective. Most of the roadmap is around getting the different data sources to GA. So last week actually there was an announcement already for the tracing specification reaching 1.0. In addition there were four languages that either have a GA release or an RC release that will become GA. So the milestone right now is basically in the first half of this year ensuring that we get the tracing side to GA across the different SIGs. And in parallel metrics work is actively underway so the goal would be to offer a GA hopefully of the tracing specification by mid year and get the client libraries in sometime the second half of the year. And of course that is working with the previous open metrics teams to ensure that we address the current outstanding issues. There's a working group for that to figure out those details. Logging is then planned for next year arguably it's already started, but from a GA perspective that won't be until 2022 at this point. And so this this topic is like very fuzzy again because what does that mean addressing concern right at what point the concert is addressed. So this brings essentially, I mean we can simplify this by, you know, the points raised by the community and concerns raised by the community. I gather from and shared on the Friday so are we can we assume that my dog is kind of those concerts that we can talk about addressing doesn't make sense or we can I don't know it's just proposition we can do whatever. Yeah, so I mean the way I would frame this is open symmetry is completely open source and anyone can come contribute so like the document you put together is great. We've already seen multiple people from the open symmetry community and outside comment on it. And then we should figure out like how to get this incorporated into the road maps but how everything is tracked today is like any other get have project, we have issues, we have released milestones, we have project boards, and now we have get have getter which is super exciting. So I'd say that make sure anything that you need or want captured is captured in issues or discussions, and then they absolutely will be addressed. The same applies to the SIGs and the working groups so take Prometheus and open metrics for example, the whole point of the working group is to solve the current issues between the compatibility between OTP and the open metrics where format. Right, so you, I definitely agree everything is tracked and everything looks like is controlled and kind of be on the way to solution in a year two or 10. Are we happy with that timeline and because there are so many things that are tracked but there is no clear even, you know, perception that this will be ever agreed on. But section four talks about the committed roadmap and being able to address issues in the community. I believe both those are being demonstrated it doesn't say when. Yeah, that's a fair point. Also, when isn't necessarily like, I think this is kind of common for all projects like open source projects. When is always the like nebulous like, will it ever happen, because we all are relying on, you know, like people working from different companies to contribute. Right, I think the most important thing here notice is that like we are tracking this information, and that, you know, also, like, that one's a good thing to notice, but also all the things that we've committed to in the past we are still delivering on them so it does show the like, our ability to execute on things we do commit to. And I think that's very common across all, like all CNCF projects. Yeah, I guess I would ask anyone on the call really does anyone have examples or concerns that like open symmetry is not taking this feedback not incorporating it into into like a working group or roadmap or some sort of item. Because if that's the case that I would argue number four is not being met. I'd be curious if that is happening and I actually be very concerned if it's happening. So getting that feedback I think would be extremely valuable. I have two examples but may I can I can let's speak others to as well. Okay, no, so I will bring it up. First one logging API right. I mean, and also I'm like, you know, observer all of this thing so I already work multiple multiple times wrong so what I'm seeing, but what I'm seeing right now is that the logging is some important goal and scope of this open project. But plenty of people, especially from the, at least what I spoke from the flu and deep community were like actively rejected to in terms of contribution or starting even discussing about the logging, you know, specification, because project was not ready. And this is to me, something that is tracked but well not delivering and not plan to be well I don't know not seeing any progress. So a couple things like we were talking about how we stick to our roadmap, like tracing and then metrics has always been the roadmap login came up because a few members wanted it and you're right there's some work has happened on it still experimental and I've been involved in that and T grand and Joan and others have been. But that's sticking to the roadmap by not not making logging front and center and not wanting to push out the things that we've already committed to. Okay, I'm not aware of people who have been rejected for making contributions like I've attended almost all the logging meetings I find that surprising that people are saying that their contributions were rejected. Sometimes people had reached out and said hey is this ready for prime time and we said no absolutely not. You know tracing is still our number one priority metrics is the number two priority will become the number one priority after tracing is done. But at no point I have I ever seen anyone be discouraged from participating other than just warning them, hey, you know only maybe 10% of the community is actually focused on this right now. So I think for logging specifically there's a sig dedicated to this with with meetings I was just pulling up the meeting notes real quick. I mean there's representatives from elastic fluent bit Google Walmart AWS sumo splunk. So I think that people are definitely getting together and things are being discussed. If there's a fear that like something's not being accepted or like advice is not being taken then we should clearly go address that. But like this would be the forum to kind of raise those concerns, and definitely anyone is welcome to attend we have regular meetings it's on the community page from a sig perspective kind of listing everything about logs. Are they coming back to your statement and I was also very surprised when I read that in your assessment there we said that soft rejection I and then people also asked for, you know, can you back that up like who said that when where can you back that up with something. That is, you know, somewhat publicly visible. Sure, I mean, I don't want to put people on spot right so I know but what if you say you know it has been softly rejected. I mean, I literally like someone need to have said, I want X and someone else would have said, you know, no. I think the rejection might be, you know, to brutal world, and I agree. Sorry for I'm not like, you know, native speaker. But what I rather meant is that the thing I heard a couple of times is that open telemetry said that, you know, let we don't want to focus on logging. Right now, we want to focus on metric and tracing. So, yeah, we are not talking about that right now. That's not a bad thing. Right, like that's like that every project does that. Right. It feels like CSI and Kubernetes right like there are certain aspects of Kubernetes that weren't addressed until later either. I think that's actually a sign of a healthy environment. I'm not acknowledging what your bandwidth is. It's prioritization. It's what we do every court. Everyone does a reporter. Let me let me understand. Is it about that the scope of open telemetry is not clear enough for you in terms of is like is the community behind it open to to get logging in there or not. Is it that actually someone tried to get logging in there and the open telemetry community said no, we don't want logging in there. Which one. So, mind of mind if I just chime in because I have a, there's a general feeling that metrics and logging are reinventing things that have already been invented and are well established and and created in the ecosystem. Obviously tracing was the big rock right and that's the focus and we're finally getting to the point where you know we can now have people use it in production that's awesome metrics is next but we have a vibrant and strong community and metrics around that's part of CNCF that's one discussion point and then secondarily logging standards are really, really difficult and there are some, you know, well established open source standards for this like ECS, which is an Apache open source framework for logging that kind of like embracing and extending things that already exist we seem to want to reinvent the wheel when it's already invented and it's functional and so I think that's the frustration that Bartek is talking about I feel the same way. I stopped going to the logging meetings because it's just way over engineered. I mean like the spec for logging is the most over engineered specification I've seen for logging that's ever been done by anyone. I don't think it's going to be implemented effectively and it just seems impractical to me. So there's a few points there so one, it sounds like your point is that you're disagreeing with the actual intent of the project right which wasn't the so maybe it should that be a follow up question that we actually go into. So we have open metrics and CNCF so why are we creating another metric standard. When one already exists that's used heavily in, you know, production systems today. So there's a few points that I would like to finish that for. So there's a few points one from. So I will give the perspective yes I'm on the GC for open telemetry but I'm going to give the perspective as a coup con co chair from in terms of interactions from the community. Open metrics barely got any attention over the past few years. Like, and so in terms of velocity in terms of people talking about it right there are like, you know you can make the argument that open metrics wasn't quite as visible compared to say open telemetry over the past few years. One other thing too that's CNCF where like CNCF has competing projects linker D and envoy are great examples. Right and the thing is is that it's not meant to say, this is the only way to do it CNCF is trying to host set of projects to give people different tools to whatever they want in a way that they want to do it. So people might want to use open metrics over over over open telemetry. That is great. Also, one thing too is that like open telemetry isn't necessarily only about forcing people to use open telemetry. Like, if you look at a lot of the implantations like if you look at the languages and also the collector. It also gives people a lot of tools so they could say like hey if you want to use open census metrics and open telemetry measures can use both. So it's not about only forcing and gives people a way flexibility to use what's best for them. I don't think you're trying to say something. No, you're probably. Yeah, I guess the one thing I'd add is just like there isn't one standard in the market today. So that's part of the problem that open symmetry is trying to solve for like, I don't know, use anything Jaeger and Zipkin to competing projects both do tracing be three header propagation versus W3 trace contacts both exist in the wild. Open symmetry needs to provide a mechanism so that people have a path forward for that. The same applies for metrics like open metrics is not the only metrics thing out there yeah it might be the cloud native one, but people are not all fully on that today and so they might even be in a hybrid world that they need to support like two standards at the same time. How do you do that. The answer is often like you have to deploy two different stacks and find a way to go integrate them like open symmetry is trying to make that easier. I mean, the final comment I'd add is just from a CNCF perspective like one of the principles is no king making. It doesn't matter that there's two things and open symmetry that does similar things that that's allowed according to to its charter. I just find that we're creating a lot of like additional complexity without a lot of benefit there's no clear explanation why we have a new metric standard and open telemetry versus using something that's used by hundreds of thousands of companies in production and why do we need a new metric standard. I understand why we need one for tracing logging, I don't know that we need another standard. It's not clear what's missing, what needs to be changed enhanced. Yeah, that's my concern with this and and Constance getting back to your other comment. These are not like projects where someone can go and implement it like open metrics is basically a standard a specification so this isn't something that a user can just go and implement they need to adopt a technology that implements open telemetry or implements, you know, open metrics for example. But it's fine. Obviously people don't want to discuss this I think it's a big issue and it overshadows the whole project at this point, beyond tracing. Yeah, yeah, I think it's time to move on. I don't know if this is especially relevant for this forum like Jonah if you want to bring up those concerns in the open telemetry community I think that's that's appropriate. But right now it's like four of us on that call Morgan, which call on the community call for hotel. The maintainers meeting or which, oh maintainers know I'm not on that one but I can bring it up there that's okay. Like, anyway, let's move on. Yeah, why we're moving on if this actually kind of made, you know, might have some input on the incubation graduation kind of moving. I guess, how do you think that's the case like there is a roadmap logs are not planned right now so I'm not sure how that impacts incubation. There are issues there are forums actually discuss them and like any issues raised or like there's a SIG meeting there's a working group there's I mean, there are forums to address that feedback, getting consensus from everyone and on the planet right I mean I think that's a goal, but like taking that feedback and trying to incorporate it and ensure that like everyone has a say and decisions are kind of being made on that I think does exist which is what number four is asking for. Okay, that's that's there are there are like major concerns that you are I mean looks like you want to move on to hide them some way this is what I see is that is that the right observation. I don't I don't think there's anything hiding it's all happening in open source forums today like if there are concerns about logging there's a logging SIG to discuss that. And logging is not GA so it's not like that feedback is not being taken. If we were having a conversation about logs GA and there's big concerns about introducing another standard I think that would change the conversation here quite a bit. No, no, but there are people who wants to bring you know some concerns and you are pushing to to move the recital commendation forward so I don't think that that's a good direction. I think actually it's more just focusing on the actual question number four and then bring this back up later that's more just focusing on that part. Totally. So I want to bring that there are concerns. And I don't think they addressed. So what would it take to address the concerns to get consensus on number four is there's something actionable. Because I mean we can we can disagree for forever but like if there isn't something tangible I'm not sure how we get out of this deadlock. One suggestion which I've been trying wanting to make is a set of specific statements which can be added as part of the reply to number four to to make your concerns visible and ideally address them but so for example, by making explicit that as of right now logging was next year and is not a priority just making this super explicit and writing this down. Putting not a timeline down to the second to to the metrics effort, but at least having a timeline on this would this be an approach which which you think is where you could have consensus or do you think that in the end you would just want to note this and on the consent consensus or what's what do you think. No, I'm up with propositions, but you know, I feel like we are putting this no kings making rule, you know, forward as a rule that is happening sure I agree. The same happened with Cortex and Thanos both are competing right but both were accepted to incubation. But this is much different situation where we have an open telemetry with well defined solid tracing and not the fine logging and barely defined metrics, in my opinion sorry for being brutal. But, and somehow we know they're overlapping with existing well adopted well defined solutions. And yes, we can just ignore this fact, but this is a problem that we are just actively recommend in beating solutions in our own family of CNC, CNC, that's no different than Cortex and Thanos, right like that. Let's, let's, let's, sorry, but I'm, I'm, I'm, I'm pulling on the head a little bit. So, maybe to to address the open metrics thing course there's back and forth and I'm uniquely positioned to speak about that one and about how how the due diligence is supposed to work. The metrics and premises heads on obviously I would prefer if other projects adapted that standard flat out period. That's obvious. That being said, Steve is absolutely right when he says, there is a no king making rule and that is absolutely what should happen cause else you're unduly blocking progress. Another thing which, which I've seen raised in the past and something which is one of my main concerns is confusion around the actual level of support of open telemetry for committee slash open metrics. Of course, most people just assume it's fully there and it's just not, which is fine. It's absolutely fine to not be there, or to be there after X amount of time as long as the messaging is clear. I would much rather try and focus on putting a timeline in on. We will take X amount of time to achieve compatibility and yes with my premises and open metrics set on I know that we need to define even more on what compatibility actually means like on top of the tests we did and everything which we have there's plenty of reference code which they don't have used and such yet it's clearly not enough so we need to deliver more. Let's head on again and this is, I'm being very deliberate in those different trains of thought. Sick head on. I would much rather see a specific way forward with a rough timeline where you just say we're open telemetry as the project which is complicated because I'm now as an open telemetry member and it really states X amount of time until progress X and obviously that X amount of time is not down to the second but it is a down to the month or something. Is this a way forward. I see Bogdan agree. You want to note. Steve, so yeah that seems. It's fine messaging is fine. I just want to. So Steve to make it explicit I'm not trying to put words in your mouth just to try and move this on. Yeah, yeah, write it down and we can talk about it. You actually have one dot all of open telemetry and you have GA of tracing as of one or two days ago correct. Yeah. So the next specification is 1.0.net also went 1.0 Java, Python, and something else is RC and will be GA here soon. And correct. I'll update it because it's not 100%. I want to make sure I'm explicit because like RC to assume that. Yeah. Yeah. But just as a rough thing of what I hope is a basis for consensus. Yeah, so for those on the call especially the open telemetry folks please validate and speak up on language here. The dates right now or rough estimates here. I think down to maybe the quarter would make sense, but as part of this driving the argument. Yeah, okay, so I think it's much better. Thank you for that. I don't want to like block anything right but by just saying hey we will fix something. And it's not immediately to me true that, for example, open metrics incompatibility with with metrics API or and spec will be actually, you know, result, because we have clear, clear point that were listed up which are. There's no even clear idea how to solve them and and even some some of them are trivial like this label GE or le on the histograms push versus pull and kind of how to integrate all of this. I was just saying, hey, we will, yeah, it will be compatible. Yes, everything will be fine. This is, this is great but if I as a sick technically, and up to recommend something and or recommend anyone in red hat to use open telemetry. If, and I, I don't see, because I know the technical details of it that the agreement is not possible easily. And there is also some kind of, you know, other concerns whatever discussions. So how can I recommend how how do I see this as a result. If we are just saying that this is will be done but there was no clear to me path towards that. And I agree it's very fuzzy but I see this not being. I see your point. I see your point, but I mean this is not the end of the road, right. This is the graduation to incubation. If I mean clearly you cannot ask for the couple of folks that are here representing hotel to speak for all its vendors including ourselves we are also there. But, you know, at some point in time, hotel wants to graduate, right, wants to be a, you know, like communities and committees and others wants to be that kind of project. And obviously people including ourselves will be held accountable if we say, well, you know, this is what we committed to or agreed upon in the context of creation to incubation, and we haven't done that. Right. To me, this is not the end of the road. This is clearly one stepping stone towards that. So, I'm perfectly happy with having having that explicitly in there, but also being mindful and aware. This will be reviewed and obviously people including ourselves will be held accountable regarding that. Cool. Yeah, I think, you know, I kind of, you know, think about this process as some step towards graduation. So if I see kind of this, some concern already. I just pointed, I want to point it out, definitely, like this can be, you know, kind of fine for incubation, but the goal is really ultimate goal is like full adoption and graduation. Can we point this down to the doc maybe that, you know, there are strong incompatibilities that are kind of the goal for even talking about graduation until we do that. Why are we talking about graduation though right like the goal is incubation and like can these concerns be addressed or is it a flat out no like there's a roadmap and that roadmap could be years, but there's a roadmap. And so I think you're right that if we were in incubation talking about graduation, then it's a whole new conversation. But we're not we're talking about moving from sandbox to incubation. I think this is a known issue. I think there's a working group to address it. I think there's strong consensus on both sides to try to get this fixed. So it feels like there is a concern raised, but there's also kind of a commitment here to do something about it. Right. And that's exactly what I, what I, I mean, I tried to address Bartek's. If I understand correctly, worry that, oh yeah, you know, we put that down here and then nothing ever happens and I'm saying, well, this is not this is quote unquote just incubation this is not yet graduation. So obviously, there will be another due diligence held, you know, towards graduation, and you know, clearly that will come up again. Right. So to me, this is an argument. Let's move on. Let's, you know, we clearly pointed that out here. This is in my understanding, clearly addressing that we do not need to further discuss that. So there's a yearly project reviews that happened by the TOC. And so they're going to like, because we do have to say like what are our goals like why didn't we achieve our goals and stuff like that there so there's also like that accountability happening over your year right because it's not just back, you know, at some point in time it's actually on a review. Yeah, so then we do have like there's actually quite a few plate of like processes in place to make sure they're being held accountable for our projects and we have like, you know, ways to talk about it. So, that could help. So I guess. So in the interest of time, from my perspective, there are currently two questions to be asked before I can make a call for consensus. The first is, is full permissive and open metrics accountability part of 1.0 and GA yes or no and that's I don't explicitly not have to explain opinion. It just should be noted and then based on everything which was added. If we can achieve consensus or if anyone wants to be on the record and not as not agreeing. Those are the two questions which seem to be relevant for the discussion and moving on. I would say that the first question is fully dependent on you defining what full compatibility means because I think as you pointed 10 minutes ago, there is a lack of what full compatibility means. But we can speak on that one bug and we can answer that right now since the first day of the project since open telemetry was founded, being able to import Prometheus metrics to pull those in from Prometheus clients and also export any metrics captured to a Prometheus server. Those have always been explicit requirements for metrics in open telemetry. Like we would not ship without doing that. Okay, that's a clear answer to to address the one point of Bogdan. It's not the case that it doesn't exist course a we have the reference implementation which is being rendered by several other projects and we have even competing companies who do not interact with with premises community at all, just implement Prometheus open metrics just from what they found on GitHub and in the spec. So it's there but I do agree that it that making more visible and giving specific pointers at here look at this and that thing. That's absolutely the case. Why does sense of what it means to be Prometheus compatible is basically if you ingest, and I clear you through Plumquil or something compatible that I get the same data out. And similarly, if I send data in. Sorry, if you enjoy the one is if you ingest data it should come out the same and the other is if you emit data, both your implementation and Prometheus should ingest the same thing. So those are the two definitions in the in the function sense, which is obviously not the do to the comma version of a spec, but on the functional level that is the intention of of Prometheus compatibility and I think we have maintained that for like before we talked at Google and like that has always been the case. But there are other questions that I don't know if there will be like is is up metric in scope of when you talk about full compatibility with Prometheus there are a bunch of other other things that I've defined. And that's what I mean, if somebody, if I claim that is fully supporting Prometheus somebody may come to us and say hey, by the way you don't set this still be or whatever things. Some internal things Prometheus have, and we do not respect so the protocol level, I do understand, but there are some other scenarios and other things that we may not fully support and that's why that's why I think in order for us to make a stamp and say it's fully 100% compatible with Prometheus. It's probably hard to have, but limiting this scope but we accept Prometheus data and emit Prometheus data in specific format and so on, it's way more reasonable but anyway, I don't want to Sorry just to close this mentally and now I explicitly don't wear the sick observability head, but the Prometheus and metrics that on the functional level it's clear course, both stillness handling and up metric our core design principles of how Prometheus functions and basically all users heavily rely on those properties. And that hasn't changed again since since Google London in 2017 that that has been consistently be the same reply I know we keep revisiting this topic but the reply hasn't changed to be fully compatible with Prometheus that is part of how Prometheus operates. If you want to have the discussion about just the data format, which is completely fine. Then that is different but that is then not what is currently written here and how I understood more. So, I don't care so to speak about the actual reply I just care about it being explicit in here. I see. So, Morgan, is it will include full or is it just the data format or the wire format or what is the intention. I mean realistically mid year, most likely will be the data format and everything but end of year I would say so the goal is to support full now when that will have been tried to stone that that is precisely the thing. Okay, so is this fair and sorry I'm pushing a little bit but we are already three minutes over time but I presume this is good Richie now that this is this is good. Okay. So, one we have a new year. What is happening Richie you're feeling some warning right. I'm typing. Sorry, it's not showing. I pause. It's on me. I was seeing it typing so it looks like it was good to me. And just for the record for the ones who aren't following closely and there is a proposal by Josh how you can actually make up and such work and stillness work within open telemetry as of today so I hope this is not on you or anything and I'm just trying to reflect the intention as Morgan you said end of this year. Yes, to sidetrack you Richard, but the logs line seems to be a little fussy or like if I read that with fresh eyes I'm not sure I understand it. Let's finish the first piece. Where should we put or where do you want to put with your open telemetry heads on where do you want to put 1.0 and GA is this for the data model and wire format or is it for the full semantics and all the bells and whistles. And I look to you for that. Yeah, I think it doesn't matter for us where you want to put it's an answer like the open telemetry project needs to tell the intention. Okay, let's let's put it at the first milestone one point zero. And not. Yeah, let's put that the first milestone and then that support for that. So data model and wire format will be 1.0. Okay, but then that means you're not competitive you explicitly not planning to be compatible with the actual working of Prometheus for 1.0 correct. So, so, so I'm less involved. I'm less involved in the metric stuff so so there's data model and wire format what was the other half for you. So the semantics, sorry, the data model I need to kill here. The semantics of how it works in particular still is handling it up and again we have been revisiting this topic for like four years now. Yeah, so it's a current topic. So I know it is a point of contention and I know it's not. And then question. Is this the internal semantics like like the semantics of using the API to generate a custom metric or is this the semantics of we pull in a latency metric that we automatically capture and generally in Prometheus you'd expect to have certain annotations on it. And you'd expect that to happen for an open telemetry as well. So this is a super high level functional definition of compatibility, other than just take the reference code and reimplement it line by line which is obviously not very good on the functional level. If you ingest data into system X, and you clear it again or take it out through a rotary drive or what have you, or if you expose data. It should function like Prometheus does, which has certain properties in particular around up and stillness handling course they are used in a lot of subtle ways. There's also stuff for out of band and such. The problem is if you just use the wire format and the data model of open metrics, you will not be semantically compatible with Prometheus which in my book with my chairhead on is totally fine. Yeah, I just feel we need to be super explicit about its course we keep returning to those kinds of topics. I think we should call it out as a goal I don't know if any of us on the call can give the firm answer to that just because of where we are with metrics and because there's only I think three or four of us. I would expect though that we would target that I don't know if I'm speaking out of turn, but let's let's leave these as an item for me to come back with an answer. I think these are the good estimates of the timeline but let me give get back with when we call one zero versus G is perfect for for not being able to give you an answer right. I'm also totally fine I mean we're over time I have a hard cut. Sorry, we'll come back with which of those two. Okay, is that statement fair but perfect. Michael do you want to comment on what you were unhappy with. Or you can just continue to the next. Yeah, no, that's fine. If everyone is fine with the locks. To me it was a little bit, you know, unclear, but I'm the only one I can live with that. I think we can also Michael come up with, with a more text if you want more details about what we plan to do this year versus what that's right. Sorry, I really need to drop, but feel free just write it in like everything below break go wild. Sorry for taking. I thought we thought we could actually close. Next time. Thank you so much for your conversations. Thanks folks.