Augur/8 Knot WG Meeting, Jan 20, 2026 ![rw-book-cover](https://img.youtube.com/vi/X_p_v8HahQk/maxresdefault.jpg) 🔗 **Source:** [Augur/8 Knot WG Meeting, Jan 20, 2026](https://www.youtube.com/watch?v=X_p_v8HahQk&pp=0gcJCdMKAYcqIYzv) Hello, welcome to the Auger 8 not auger meeting for January 20th, 2026 and um we have a very light agenda today but open to other things. Welcome to Johnson who's joined us and um Cali Adrian um the one thing that Adrian had thought of before Chaos Con and that's we're kind of like in a high velocity release process right now in preparation for Chaos Con. Um, so that's what we're kind of we've got kind of a light agenda, which is pretty typical, and we're trying to get a release out, which is also pretty typical. Um, so Johnson, before we kind of go on with our agenda and the poll request reviews that we were pl we were going to do here, do you have anything that that you want to bring up? Not really. Not really. All right. No, >> maybe I'll have some questions at the end, but um not for now. >> All right, that sounds good. So, right now I am staring at the startup screen to see if Adrian's branch works. >> Yeah. Adrian, have you What's the state of our like because we Yeah, I think there's a lot of We're all like testing different things actively right now. Yeah, I I have yet to um undo the state of that one repo. Um >> Okay. >> But I think the the I have an image that should be built for the new the second test. So I'll do that after this call. Um I've been getting a little distracted because I think um our department's trying to put together a promo video and I've been asked to record some people in the Boston office. So I'm like >> Slack messages and telling people to throw it on my calendar and I'll deal with it later. Yeah, that makes sense. Um, for some context, um, I it's probably worth like more of a conversation in like the maintainers call of like how do we want to handle this long term with the issue that comes from chaining. It doesn't seem like there was that the bug was from the augur side, but more of a celery issue. Um, either way, need to find a way around it. Um the first attempt that Adrian tried out yesterday um once I saw it this morning I was like oh I get why this doesn't work. Um and so by taking it out of the chain even though it was ordered um it means that the scheduling is ordered not the completion is ordered. Um so wasn't a good solution for the problem at hand. Um, but Andrew had suggested just putting the pull request comments function inside of the pull or it's pull request review comments and putting that inside of pull request review um to make it to where it has to be in order, but it's in the same um seems like a pretty good workaround, but probably is worth a discussion of how to actually fix the issue instead of patching the issue. Um, but we're looking for a patch for right now for the very least that we can keep collection moving. Um, because this is pretty tendering pretty much all progress on secondary collection. So, that's kind of what we're working on on the Red Hat side of house. Um, because for us, um, facade and core are kind of welloiled machines at this point. I mean, we still have there's some smaller errors that we want to work on, but um nothing like a major hindrance like we are with secondary right now. Um yeah. Do we want to look at that issue, Adrian? like um I don't have a I haven't up you know since we talked yesterday afternoon I haven't gotten myself up to speed with it entirely but is there something that um you think we can look at >> uh with our secondary things? >> Yeah. Um, I think it's mostly I'm I'm mostly I think it's mostly dependent on what our results of our second. So, the first test was just me tinkering around with sort of the ordering of the celery sort of workflow um to try and see if that worked and I don't it didn't seem like that worked. Um, so I I tried there's a suggestion from Andrew that he made on Discord yesterday that I was like, "Hey, that that's actually a that that it helps increase our road map because I didn't I didn't have any other ideas after that first one." So, we're trying that one now. I'll probably be deploying that after this call and we'll we'll probably know before the maintainers call whether or not that worked. Um, that might be a better conversation like if we want to deep dive into that, that might be better for the maintainers call cuz we we'll probably have like Andrew and some other people who pretty much wrote the collection process like there to help. Yeah, I mean I c I certainly know that the chaining is one of the strategies that we used to insert to make the dependencies between the tasks be handled by the app cuz it's really inefficient if the app starts to insert data into the database that doesn't have parent records because that basically just offloads the sequence of collection to um it offloads the sequence of collection to the database which gets extremely expensive on a server. So that's why the chaining exists. I don't doubt there is some kind of celery chaining issue. Um >> yeah, I'm not I'm not questioning why they have to be run in a particular or like I was I I was just asking because I I didn't 100% know, but I I I understand that they have to be in this done in the right order. Um it's just I think the fact that we had that chain nested within a group of other tasks in Celery, I think there's some known celery bugs at least for based on a quick search. um where like th those kinds of structures don't s like I guess there's some salary bugs with that and we were seeing that the the pull request reviews like the first part of that chain was running and getting scheduled and completing but we were not seeing anything even scheduled for the second one. Um and so it's like what what's going on here? Why is this not scheduling? Because if the second piece of that change is not scheduling, that whole group is probably not completing or that whole that whole line is probably not completing and then the whole group is not going and then it's not going to get marked as success. So, it's just kind of like I I do need I do probably need a lot more context on like how how scheduling works and how how all that's kind of supposed to work in terms of because I I know I think Callie's been trying to look at Flower and see like whether tasks are scheduled and whether they're completing and I I think I remember some conversations a while ago about how we may be only scheduling the number of tasks that like can be processed right like by the number of workers we have or something. So, we're maybe not Those maybe aren't being scheduled, but then maybe I I don't there might be some kind of weird stuff going on there that we could we could look into, but that might be better for the maintainers call. >> Okay, that sounds good. I don't have anything. >> Um I did see your message on Slack. Do you want to quickly jump back to your So that that issue you were testing. So it it seems like you said it worked, but you ran into a different error. Um you're >> Yeah, but I don't think the error I think the error is just like um unrelated to anything. >> Yeah. So that particular error when one of the routes is crashing because the like request reports isn't um like a function doesn't exist. Um one of the one of the commits or one of the PRs we've gotten recently resolves that. Um I think I I preemptively just sort of added that to the current milestone so you can find it easily if you want to test that and review that. But yeah. >> All right, that sounds it's added to the milestone now. >> Um, >> all right. So, this worked. I'm going to Sorry. Something stupid that I was doing. Okay, now I have to fix that. Sorry. What was that? PR name. >> Uh, the one with your issue 3516 I think is the number. They screwed up the drainage. >> I can I can pull it low. I can pull it on mine. And >> yeah, pull it on yours. And >> you're just trying to remove the commits for that one extra file. >> I'm trying to remove the commits for the extra file, which was basically me just making sure I had my GitHub configured, which was stupid, but that's where we are. Okay, I'll just force push that branch with the previous version. >> Meanwhile, it does look like things are running and I didn't get any errors. So, you might think it's definitely definitely fixes the bare metal issue. Sweet. I guess feel free to merge it. I don't I don't think this should affect I mean it it's yeah this should this should be fine um if it I mean it was passing all the tests I think before so >> hey I I it says I was requested for review but I did the review I thought >> it might have it might have um not submitting it would help but um >> I think also sometimes if if you force push it will dismiss all the approving reviews or thing. Uh, do you want me to rebase it as well or I guess it doesn't? >> No, it should it should be fine. This What do I want to do here? I haven't seen this before, but it's probably a by >> I think GitHub's been starting to like kind of like force that. I don't You don't super have to. I tend to prefer rebase. Um, >> all right. But >> yeah, >> but also if you click rebase, it's going to have to rerun all the tests. So if you're waiting for the tests to pass, then >> I think we're good. They passed already. >> Wait. Um, and then what what was I I wasn't sure how much I picked up of this from from the various maintainers calls, but like what are your kind of criteria for when to release? Like it sounds like you're kind of wanting the obviously to be able to >> bring up the main have it not have any major issues. >> Not issues is important. Stability is important. So like all the all the CR passes uh CI passes there are there's nothing on our road map for that release that's missing that we think we need and I think it sounds like right now we do want to possibly try to solve this issue with secondary collection before we release. like it seems like that falls under the category of something that's really important to fix that that we should also release that happening on other people's instances. >> Um I I don't see how it wouldn't, but we are the only instance that's reporting this problem. Yeah, because I also noticed I think when I was trying the initial version, >> what would you evaluate if I was experiencing the problem? >> Um, I can give you a good query or know if good is the right an easy query to figure that out. I'll put this >> huge fan huge fan of easy. >> Um because if you look at I'm gonna put this in the thread that's about this issue. Where is it? Um give me just a second. Um, I just send it the channel because then you can see how long it's been since you've had a You have to go to the bottom of all your NLES, but the first it orders your um like collection by the um last collected on date for secondary. And so you can kind of see if how long has it been since you've had successful secondary collection. Somewhere in December we stopped having successful secondary collection and I don't know why. That's also a big portion of it is like why did this like happen? Was it a upgrade? Did we upgrade some packages that ended up like unknowingly impacting this? Um maybe were the ones that were passmber. >> What >> did you say? September. >> December. >> You said December. >> December. Okay. Um yeah because the last time that we have seen any successful collection um for secondary has been in December but mostly my theory is that it might be repositories that don't have any PRs and so it never even gets and so there might be something that's like oh no PR reviews and so you don't need to go to PR commits. I'm not that's a that is a completely uninvestigated theory. >> So yeah, let me show you what I'm seeing. So I've got nulls first. That's the default behavior. >> So um pardon me. This is kind of a a wide query result, but the secondary data last collected in this column. Obviously, I'm getting secondary data. That fact makes me ask the question about whether or not the things that your instance may be stuck on are in fact very large repos if >> but they're not getting scheduled. Like it's like they're never get like that task is never getting scheduled. It's not that they're getting stuck. All of the other four tasks that are related to secondary are completing are getting scheduled and succeeding and the like pull request review comment is never being seen by our instance. And so it'd be interesting to see if your instance is scheduling if you can go to flower. Um I was curious to see if you control F >> on um I'll put this just in. >> All right. I'm in I'm in flower now. >> Just a collect. I just put it in persist like I'm I'm just putting these in Slack. So then you can see like they're there. um just to see if that task is ever scheduling. It's the very last thing. I already put it down there. >> Collect pull request review comments. >> Okay, hold on. Sorry. >> Yeah, if you just search for that in the tasks tab of >> copy and paste. >> Uh okay. >> Oops. >> Select. Yeah, >> if I typo it, it's really nasty. review >> comments. Yeah, >> I've got a bunch of them. >> There's a lot that looks like there. Um do like um do like secondary task. I'm curious if you're seeing secondary success. Um >> I would assume he is. >> Yeah. >> Yeah. >> So, I mean that I haven't looked into this. Obviously the smell is that there's some kind of scheduling issue on secondary but so is any nothing is collecting at all though. >> No everything but that everything but >> the comment task that you searched for is the thing that as far as I can tell seems to be blocking the success task from running >> because it seems like in your case both are going. >> Yeah. So ours are never even scheduling. So it doesn't even give our instances shot to have a sex a successful um secondary collection because if it never gets scheduled it can never succeed. >> Yeah. Yeah. So you're just you're saying if I'm hearing correctly pull request review comments never I don't if I made the same query on your flower dashboard I would see no successful completed pull request review comment tasks in my >> see nothing. It would just have a blank response. >> Nothing. >> None would be none would be pending. None would be like about to run just nothing at all. >> Yeah. >> But other secondary tasks are running. >> All of them. All the rest of them are running and succeeding. >> How big are so how big are the repos? So pull request review comments is never even starting or never succeeding. >> It is or oh comments is never being started. It is never being scheduled. So it doesn't have anything to do with size. the size this the size does not matter if it never even gets it doesn't get scheduled. >> What's the task before what what's the last task that you can see in the chain that's scheduled Adrian? >> I mean so all of the >> right before the pull requests like the pull requ the one that goes right before the comments one is we're seeing that succeeding we're just not seeing >> so pull request reviews is succeeding. >> Yes. >> Yes. But then for some reason the the task that's changed immediately after it is somehow not running. That's sort of what leads me to think that this is pro I feel like from my just super quick cursory search of open celery issues because my various AI assistants were saying like this is a common issue in celery and I I went and looked at their issues and and checked and it looks like there are quite a few issues in celery related to just various flavors of like nesting things in other nesting like chains inside groups or something like that. Um, so I suspect that that could be a very plausible cause. >> Um, yeah, >> the fact that it's only us is really strange, too. I'm not sure what the heck is happening there. >> The fact that it's quote unquote really you also is is a factor that just has me has me >> also you've got a bigger instance than us. So like it's not even like this was like some of my some of the tests like the test cases we were running yesterday were running f like I was seeing these successes on my local my tiny local dev instance our prod is not happy it's not working a like what you ran locally though yet I yes it showed successes but that's like that that was not a correct solution Um because the way that you implemented it yesterday did not require um pull request reviews to finish before pull request review comments. >> It should have that that's >> No, it didn't like because you you don't have any training just it it requires it to be scheduled beforehand, not that it has to finish beforehand. So it shows the scheduling order, but it allowed for that pull request review comments to start while pull request reviews was still going. But for smaller instances with a very for a very small repo, um you saw the successes, but it didn't but it didn't um require the ordering to keep to be correct. That's why we had the >> I think that's wrong. the the the docs I've been looking at for celery chains say that that that it's chains and celery allow you to link tasks together. The linked task is called when the task returned successfully. >> You took away the chain. >> No, I took the chain and I wrapped I instead of having the chain inside the group the chain was surrounding the group. >> I guess I can say in practicality on our instance that's not what happened. >> Yeah. I yeah I I know that but I also our instance is the one anomaly in >> I would be curious to see on your is your instance still running >> is your is your dashboard public? >> Um no we don't put anything public. >> Um you don't put any access to our repository but you do have access to it. Um, I'd be curious, Adrian, to look at the finish times or the like to see if the start time for pull request review comments on your instance is a actually after the finish time for the related pull request reviews because if it is then I'm like I'm happy to be wrong but then that I'm happy to be wrong makes it more interesting that it's a problem on our instance. I would be curious to see what if we're running a different celery version or something like that, but the screenshot that I saw from your instance showed them all to be successfully colleed, but I didn't I can't see if they the ordering was held to the way that it's supposed to. >> I can I'll I'm looking into that. Uh collect poll request review. Okay, so collect poll request reviews. received 1926 started 1926 succeeded 1926 this was all yesterday UTC and then the poll request review comments it's all 1927 for this is just for chaos auger repo I can screen share if that helps but >> yeah I just would look at each one because it's like it's a harder thing because if it's super quick I don't know if it's going to end like yeah let's look at each of the example examples Um because I believe you on that one. >> So this is this is collect pull request reviews for chaos augur. Um everything's basically 1926 UTC. Um so it basically started and finished within 30 seconds. >> Yeah. And so that's why I'm concerned is that >> like pull request review comments. Well, I think this uh >> because my thing is that it's I'm saying is that for something that is more than 30 like the in these longer repositories, it's requiring that it's like it the scheduling order I agree with that's happening but it's I think that it's allowing it to start or at least we could say on our instance it's allowing the scheduling order the receive order is correct but it is allowing the pull pull request review comments to start while pull request reviews is still going. And so with these shorter like with the 30 seconds ones um that it's holding up um which is anticipated. That's why I was going to say let's try to go through a couple different examples to see if that's holding for all of them. But if you only have really small repositories, even if this is a problem, I don't know if it's going to be shown. Um what's up Sean? >> Do do we know that it's running this the for the same repository? So is it collect do we know that it's collecting reviews and review comments for the same repository at the same time? for the one instance on our so we have we tried to run there was a patch that Adrian tried yesterday um and we only saw one pull request review comments get scheduled and that one got scheduled and was run and completed before its related pull request reviews was finished. >> All right. So, we have we have one that >> any of these repositories sufficiently large? I sort of >> I don't I would just say let's just look at like look at each one and like look at some reposi I I don't it's not like I'm not going to be able to like look at the names of these random repositories and know they're >> the USD might be on the larger side. So that's >> you can show more tasks too at the top. You can list a 100. >> I was I saw it though. So this is uh Z Galaxy B USD. >> That's comment. It's pull request. It's collect pull request. That's not what we want. >> Well, it was like 1410 and then this one was >> that's not reviews. >> That was We want pull request reviews. >> Reviews reviews. Pull request. Yeah. Pull request reviews and then pull requests. >> Just show more tasks. Yeah. >> Yeah. Oh, collect. Hey, there we go. So, that's not the right one. Okay. Reviews 1926. So, that was that ended like 30 to 44, 57 to 58. So, these are going pretty quick. >> Yeah. I mean, honestly doesn't matter. We're I I don't know if it matters with the patch that we're coming that we're about to use for this, but I would say that in the larger term, I think it's beneficial for us to un like to go down the rabbit hole to understand why this is happening. >> Agreed. >> Um that like and again I could be wrong. I don't know. Like it's you it's pointing to something being a little bit more complicated that it's not happening on Sean's instance and it's happening on ours. Um I would love our overenthusiastic contributors. Um if they want to be helpful right now, it would be great for them to and I might try to see if people will like if we can write this out. This would be a lot more useful for them to contribute would be to for them to check this >> to see if other people's Yeah. What I think I saw in the data though is that it did very rapidly move through pull request reviews and in a very brief time period after that do comments. >> Yes. >> And and it only matters from the sequence matters only because that tells me whether or not something that we expect to be working in celery is. It seems like celery is working the way we expect it to. But there is still this problem with your secondary collection. But I would say that the problem that we're seeing like with this solution would not show up in these like these are these tasks are finishing too fast for the error that we saw to pimp up because they're being received in the correct order. They are being scheduled in the correct they're like it's the chaining is >> like pull request reviews is always coming before pull request comments. The problem is is that pull request reviews was still actively running when pull request reviews comments was started and because comments doesn't have any comment like that it's it's able to finish so fast because the I would assume this is this is getting onto assumption land but there's no there's no pull request reviews for it to gather comments for because it hasn't collected the reviews. So pull request reviews comments is going to finish really quickly and then that's how you can see that inversion of like the the completion is not >> yeah going >> I need to ask Andrew about this. I can't remember if we did this for the poll request review task but in the case of of many of the tasks certainly in core and facade now we we have it so that it's only going to go back and collect things that it hasn't already collected. It's also possible that it's collected basically all the pull request reviews previously and in this particular case and that's why it's jumping through that fast and then jumping through comments fast because there's nothing new. >> That's that's what I suspect from my instance. Yeah. Like >> from your instance. Yes. From ours like even we were looking at this like hours later, pull request reviews was still going. Um I don't know if I wish I would have taken more screenshots. Um, I don't know if I ended up actually sending any screenshots to you. Yeah, I took one. Um, >> how long how long are we letting it run? And I'm only asking that because if these are larger repositories, it it just might be waiting for the finish signal. And I have seen this before where something I can see from a data perspective is finished, but for some reason it takes >> Flower like two hours to to to recognize it's finished. So, it's actually even worse than I thought. I'll I'll share my screen. >> Excellent. >> Uh that for you can see pull request reviews, comments, pull requests, reviews. You had pull request, reviews, comments, succeed. And this isn't even started yet. It's only received. >> So, that's possible if you've collected the reviews before. Like if >> this is these are nulls. >> There are no reviews. is there are no pull requests. I'm saying that like >> it sounds like it might be possible that like if because this has been we've been running we've been trying to hit secondary and try and figure this out for a while and I I I imagine like the the database would the would the database clear out review like so say pull request reviews runs it collects all the reviews stores them in the database but secondary doesn't fully complete and get stamped as with a new date if the instance gets restarted is augur going to clear out those entries in the review finishes, you're good. Like if if you bring it down while the task is still actively going, it will clear it out. But if you're if you if that singular task does finish, it will hold. Um but >> sometimes it's also a byproduct of when how frequently your instance of the Postgress database is doing checkpoints as well. But you're right. >> I should be fairly >> Callie's right. But sometimes if I have a checkpoint run, I will get the partial collection. >> But Callie's point, right? So it sounds like this is this screenshot is potentially expected then like this is okay behavior because if if because we've been seeing up until now collect pull request reviews run successfully and then we just never were seeing comments getting scheduled >> and now with this patch comments got scheduled and it ran successfully based on the the potentially based on the reviews that were previously collected. possibly theory. I guess I don't agree with that theory personally, but I would talk to like this would be something where it's like I would opt to Andrew because how would you even how would Augur know that it has the pull request reviews if the last collected on date is null and it hasn't even started? There's nothing there's nothing there for it to check. >> Like the database of the >> what? the pull request reviews are in the augur data whatever relevant auger data table it could just look through all like grab all the reviews for that >> if if secondary data so we'd have this we'd have to look at the way that the queries are being run but as a principle the secondary data collection if it's date of success is null augur is going to start assuming it hasn't collected anything if it has and that that that log entry in the the collection status table is wrong um augur will just pass over the ones that it's already collected very quickly. So that >> that's why I'm saying that there's no way that Augur knows, hey, this data is null, but there's data there until it starts the pull request review task. >> That's right. That that has to be the case. You're you're right that that it >> the pull request review task is already finished in the last the previous run, >> but it's not >> Augur doesn't know that. Augur in Augur's mind this has never happened because in Augur the date is for pull request the um last collected on date for secondary is null. So in Augur's mind this the these tasks have never run in the lifetime of the of the instance for these repositories. >> That's right. Once that date has a value, then Augur's like, "Cool, I have data up until this date, then I start from there." But but whenever once this task is started, then Augur is like, "Cool, I already have all this date. I'm not going to recollect recollect and then it goes." But it can't it's not going to know that until that task starts. Does that make sense? I think maybe I think we can I think we can also discuss like maybe having Andrew around I think would probably help because I'm >> Yeah, for sure. >> I'm not fully familiar with like like celery like scheduling versus >> I think I think what you're seeing there is a discontinuity Adrian between what is in the collection status table and what's running in celery. I've run into this myself on longunning repos before where the secondary data last collected never gets updated for example but the tasks all seem to have succeeded on on celery and flower and I so sometimes I have observed that if I wait many days it will eventually get marked completed other times I've observed that it appears when something runs for longer than some amount of time usually at least a week if it's if it finishes is I actually don't ever get to see that for some reason. So I have I've seen these I've seen anomalies like this before >> if not this particular one and I think I think they do arise from the the non deterministic nature of celery. So I think we're looking at the right place. >> We were like yesterday we before we realized that there was a task not scheduling. We were hoping it was a similar issue that we were seeing and I forget whether it was core or facade where all the tasks were running but because of I think it was like a because of a scheduling issue the success task was never going. So we were going to manually add the success like tag and put it in the date. But because we fi we we we figured out that no it's actually it's not success because this task is never running. So one thing that I'm happy about is that for like I think and the workaround that Andrew has given so like it's not I don't think this is a good long-term solution. I don't I think we should try to figure out what's going on. But I think that it does hold our data the data integ in integrity is intact and I'm hoping that we can get some of these repositories marked as for an initial collection and we can kind of like start to figure out the nuances about this a little bit more to figure out where this gap is. Um, but even as we go through this more, the workaround that that Andrew put forward feels more like it's just it's it's a solid it's it's a solid workaround which I don't know I don't know Sean if you are aware of what that is. I'm kind of just like it's pretty much >> I I am still catching up after being out for 10 days so forgive me. I I don't know. I was going to say it pretty Andrew suggested to just put the pull request review comments function call it at the end of pull request reviews >> that that would ensure that it gets called right >> and it would it would ensure ordering and it would ensure it gets called. Is that the longterm and that's why I'm like is that the long-term solution we want here? No, that's not really what we're trying to do. But it does solve it. And maybe we can start to figure out and it might be that we're just at a really weird asynchronous point of our like larger repository that is caused by a nature of all these null dates that really shouldn't that are like arbitrarily null and they're really large and rabbit's freaking out. Um, so >> yeah, >> it's gonna be interesting to bring that to Andrew tonight, especially once we test it and see how that goes. So, I think I think we've like we beat the horse very dead. Um, >> I'm we want to Have you gotten a chance to start it, Adrian, or we you've been kind of >> Not yet. I'll do that after this call. Um, I did also have a quick question for Sean as far as like the release process. I know. I mean, maybe this isn't necessarily like pre- chaoscon thing, but like >> I do eventually want to kind of learn like what what your process is for actually doing a release because it it does >> I feel like that would be helpful to just have some redundancy in how many of the core maintainers actually kind of know the release process. I I think you mentioned on Discord or something that you had it doc I don't know if that was No, I think that was that was something else. But um >> it was the install process that uh >> yeah that was the install process but like having documentation for like what what are the steps that a maintainer should go through to to do a release I think would be helpful to just have so that in case you end up like unexpectedly busy like I could always do a release. >> It's an artisan bespoke process right now very popular in Portland but not necessarily uh something you should do for open source software. Um so yeah we should write that down. Um, I think you're seeing a lot of the critical signals which are obviously the CI has to all work because I trust that now. I didn't used to trust that that was finding defects and really the bare metal smoke test is the next thing. So like that's almost constant where I'm constantly running a bare metal smoke test. Um, and I just update it whenever we have a candidate for release. Uh, I am almost always run trying to run off of main which is kind of our dev branch. uh so that I am not waiting until the end to see what's working. So I have a test instance working on that. But yes, we should write these things down. I agree. Um just to give you an idea though, it's I don't want you to think it's like some mysterious complicated process. It's I think you've seen most of the parts happen. You just haven't seen the artisan bespoke checklist. Um that uh just is in my mind, but it needs to be elsewhere. So >> yeah, if you if you get time at some point, I mean, it might have to be after Chaos Con at this point, but like >> feel free to just if you if you happen to write any of that down, like even just throw it in an issue and I can I can kind of take it from there. But >> yeah, I think I think what I'll do is while we're working on it tonight, I'll just make a note of all of the things I'm doing and that will be a a pretty good start at that. >> Yeah. If y'all I don't know why I potentially would be if y'all want any of my like point of view on this. I'm can't like I'm free from 6:30 to 7. Um but I don't know if I'm providing any new perspective that at this point y'all the two of y'all don't have. Um I >> I'll let Adrian make that call. I I I don't know. I I >> I think Cali I think the last invite I sent you for for last week's meeting um I think I made it like a recurring invite so you're you're free to drop into the maintainers calls. Um I don't I think as far >> saying do if you need it is a if you if my perspective is helpful I will come bring prioritize the thing that you would like me to have put in a voice within the third first 30 minutes. If you were like, eh, either way, >> we would never tell you that your perspect we would never tell you that your perspective is not helpful. I think I think it's a question of if it's, you know, >> helpful. It might speed us along on this path. >> Like I said, we'll see. Just let me know. I'm not >> Yeah. The other thing you should >> Andrew need anything for me? Need it before seven. >> Yeah. Okay. Yeah. Andrew and John are often late as well, so showing up at 5:30 or 6:30 your time might not even matter. So, >> um, but yeah, we're at time and I have another meeting. So, >> yeah, me, too. All right, sweet. I will talk to you'all later. >> Thanks, everyone. Have a great day. TS., Augur/8 Knot WG Meeting, Jan 20, 2026, YouTube, 01kp8jey0e17yf6f0q1h4t6fsx.