Augur/8-Knot WG March 17, 2026 ![rw-book-cover](https://img.youtube.com/vi/hkejHxiCb5s/maxresdefault.jpg) 🔗 **Source:** [Augur/8-Knot WG March 17, 2026](https://www.youtube.com/watch?v=hkejHxiCb5s) All right, welcome to the Auger meeting for March 17th, St. Patrick's Day, 26th. Um, so this is the one that you the limit hourly processing for. >> Yeah, that's so that's something I noticed. So I I noticed our prod over the weekend slash my week off last week um wasn't behaving great. I think the first one first issue was the just the large fi large large file downloads from scorecard which is a different issue but then it also had an issue where it was just running out of memory and I was like hang on I thought we fixed all the memory problems and I looked into it and it turns out that yeah it's basically I noticed that the after I restarted it the graph in graphana of the memory usage would step down every hour basically consistently and that was like huh we just enabled an hourly task I wonder if that's the task And so it I it did seem like it was exactly the issue we discussed in the maintainers call last week, which is for large instances with tens of thousands of contributors, many of them may or may not have the two date fields that this job is looking for to decide like, hey, has this been filled in with profile data? >> So it was basically pulling in like 50,000 contributors every hour, not getting through all of them, and just like it's going to continue. And then the ne the next time the next hour a new one starts. And so it was just making copies and copies and copies of >> those 50,000. I think I think this task has two copies of the 50k of all the records in memory. >> Yeah. >> And it was starting a new one every hour and not finishing. So it was just like eating it had eaten like huge amounts of memory. Um this one's still being tested. >> So okay, >> I'm still running it in our prod. Um, it's I don't see why it would go wrong. If you feel like just yolo merging it, if you wait a little bit, I can confirm. >> The only thing I see difference is, and tell me if I'm getting this wrong, the only real difference I see is that you've made the syntax a little bit neater and you've put a limit of 500 items per query on it. But >> yeah, so that that's basically 500 per hour effectively. >> Yeah. Which just seems like an appropriate Yeah, that I so as I noted in the in the PR description, that might be a little bit low because I I think I initial when I was thinking of it, I was thinking of the 5,000 >> limit on REST API calls and I was like, okay, 500's reasonable relative to that, but I wasn't I was this was me like at 6 p.m. last night, tired brain. Um, >> wow. >> I was thinking that big instances are going to have multiple keys and so we a thousand might be a little bit more reasonable, but this will do the 500 an hour is 12,000 a day. >> So like even for like 50 50,000 plus contributors that haven't had profile data, this will like over a week this should this should get to full population. >> Yeah, it's going to tick through everything. And yeah, I mean I this is another one where I think it's pretty straightforward what you're doing here. And if it didn't fail on execution, the logic is simple and straightforward. You really haven't changed it other than there's there's really no there's no change in logic other than a a better syntax really. You just kind of laid it out better and this limit. That's it, right? >> Yep. Am I seeing that right? >> Yeah, that's that's the two commits that >> Yeah, I think the uh the third commit I think there might have been a third commit for something, but yeah, I think it was all just basically the formatting and the Yeah. Um, and then I think one thing if we're looking at things that we need for this coming release, um, I think it's also given that given John's comments in the the maintainers call last week, um, like since we had an error with how we were doing various parts of facade collection and contributor resolution that was causing data to be bad, like because it was kind of an automatic error in in augur. It should kind of be an automatic solution ideally. I don't know. I think Cali Callie's also been kind of brainstorming on things. It seems like you maybe had some items later in the agenda, but um I think that's going to be something that's important to include in >> which which John said which piece that John said. just just like he just I think he was just promoting the concept of >> if Augur broke it automatically, Augger should fix it automatically, >> right? Like I don't like it it >> as much as like >> I agree with that philosophy. >> Previous issues we've had like we've just been like hey like for the duplicate whatever duplicate repos issue >> it's just like hey Cali go run this giant script. Um, and it's like that that I mean I guess if we make the script nice and easy to use and put it in the release notes, like maybe we can rely on people to run it, but that's just another point of failure of like, oh crap, someone didn't read all the release notes from they upgraded from an old version and didn't see it >> and now they're on a new instance that has duplicate or like something's broken because >> that happen. Whereas if we if we have it sort of somehow automatic >> then we we can kind of be more sure that everyone's in a a known consistent state. >> I think that makes sense. Um so on the contributor fixing I've been testing a set of scripts that would need to be then rolled into augur. Um not quite done testing them yet. And so I think that based on what you're saying, I think that's I think that's what you're saying. >> Yeah, I think I think we'd eventually want to roll them into Auger. I'd want to make sure that they're like obviously robust and good good quality. Um >> I think Callie's also been sharing some notes with me like just we've got obviously we've got our own internal task tracking of what do we do about our instance. So I think I think um once Callie is kind of back from whatever she's working on um she'll probably like have some idea like there. I think we're kind of taking advantage of like the the the mental space of being out on break and then being able to sort of ruminate on things in the background. Um so hopefully there's maybe some interesting ideas that come from that that we can merge with your scripts and and just kind of come to a solution that's like >> sorry reliable for everyone. >> You're on break. What >> So Cali and I were both on PTO last week and I think Callie's taking a fair few days. >> Oh, okay. I didn't realize that. Yeah, >> because you were on a call last You were on a maintainer call last week. >> I Yeah, I I sometimes I'll try and pop in because the maintainers call the it's just regularly scheduled call like that's I usually try and pop into those regardless. But >> if you take PTO, you should take PTO as this is a life lesson from a person who hasn't always done that. Um you do burn out if you don't take your PTO. >> Yeah. I know generally I was I was generally doing it all but um >> I'm not yeah I'm not my intent my intention is only to provide uh the less the purpose of my life may be to serve as a warning to others and I have I have uh done work on PTO in fact I wrote a good deal of augur um the augur schema in um bise in uh 2018 So is this band this bandit thing this is probably in response to my observation that bandit was just littering the security tab. >> Um that that and also I noticed that I think there was a PR that got filed. I forget which one. It's probably linked in the underlying issue, but um there it was also uh do kind of spamming some of the PR reviews with unit test things. >> That's what I thought. I saw that too. >> I sort of just grabbed I think I just grabbed that line of PI project tommo from the I think from the bandit docs. So it should work. Um given that we also have the R directory is also called tests. But um yeah, that would that's probably going to help cut through it. I I did I did sort of add Bandit as sort of a redundant because I think I know GitHub already does their own they've got their own code scanning thing, >> but I'm not I wasn't sure it was necessarily catching because I know I know there's probably a lot of just like I've I've made PRs just in the last maybe not last few months but like re some relatively recently since Docker started working in Augur to like remove the logging of like sensitive information in the log like censoring API keys and stuff like just easy stuff like that. So I just was thinking like hey maybe this is another layer to to catch more of that kind of thing just so that people don't look at Augur and like oh my god is this a security nightmare. Um, >> yeah. >> I mean, I just >> making something that easy so broken. Like, what else is broken, right? >> But I threw that in the milestone 9 like that's um Oh, that this is a different Yeah, this is we're >> Yeah, I already that was so straightforward. I >> saw no reason not to. >> Um, >> this is effectively sort of a logging change anyway. So this isn't any >> and version. When you say version, that made me think version of augur. >> Yeah, version of augur. I the PR has actually changed from that now because I was trying to import the version number of augur from that uh metadata file, >> but it was it was causing issues because I think that's not technically part of the augur like project tree like augur module. So it couldn't import it. And so I just I think I just defaulted to like I think there's one place where we already import the version number. So I was able to reuse that. All the other places I just have augur and then like a little piece of text of like oh this is coming from the CLI, this is coming from the API, this is coming from whatever. Um I'm going to double check to see if I actually >> So what is what is setting the augur version? Um, what's it? I just I just >> No, the the version is this. So, this this is just setting a string that basically identifies which application the database connections are coming from cuz I like I've been I was looking in DBver just to see the list of connections and like I saw some that were obviously from the user account I created for for Graphfana access. >> Um, and then there was a couple, but basically everything had no name except for the connections that DBaver itself was making. And I guess they they've set it up to to set their like set like hey this is dbaver whatever. Um so that you know like this connection is like which application like where this connection is coming from basically. >> Um so I was just like this is sort of just a like nice to have quality of life like >> almost no one's probably going to even notice this but it might help with dugging of >> connections. Yeah. like um because I have my 8 knot server on a different IP than Augur, I can now tell the difference in the connections, but before that I really couldn't. So, I think this would be pretty helpful. I don't know. probably wait for someone else to look at it just because >> yeah this is this is I think this was I like I mentioned this um if you look at the milestone of this PR it's I put it in 0.94 like I was like okay not this next release but the one after just >> this.93 >> this isn't that important it's just it like I I think I'll usually maintain two milestones open at any given time is the the next release and the release after so I can kind of like okay this is more immediate priority than and this is like we get there when we get there kind of Yeah. >> So, um I don't >> And I'm guessing these builds are just a timeout crap. >> Um both of them failing is interesting. I need to I would probably that might be worth looking into. Uh, let me rerun them before you do that. Just because like depending on I' I've seen the I've seen it fail when GitHub gets busy, right? >> Oh, GitHub. Yeah. No, GitHub has I think GitHub's like status page has been all the rainbow colors in the last >> Yeah. >> I think they've been getting it pretty pretty hard with the AI scrapers. Um, >> yeah. I mean, I know Oh, >> during our maintainer call last week, my GitHub was extremely slow. >> Yeah, it was I think it was glitching out pretty hard for me as well. Um I also I bet I bet our that observation you made on our insights tab about how um we've just been getting like hundreds of clones a day. >> Oh, you think that's probably AI scrapers? That would make sense. Well, I don't but the thing the thing that is quite is making me wonder more is like if it wasn't AI scrapers and it's people actually using Augur then >> what do we hear from >> people more people using Augur means potentially exponentially more calls made to GitHub's API which they might I don't know if they'll be a like which is probably going to look a little bit like a scraper and so it's like I feel like we're almost contributing to GitHub's downtime problems not in a like bad way just in a like, hm, we we have an application that hammers their API pretty hard. >> Yeah. I just I mean, I still don't understand where who are all these people using Augur >> or who are all these people cloning Augur. I think it's bots. I love I love the visual clones in the last 14 days, too. It's like it looks like it just goes through the roof. I love that. Hang on, let me take a screenshot of that. >> That was yesterday. Like that's just because yesterday it was uh 470, but the day before that was a small number. >> That's just hilarious. I I just love the meme of that image. >> Yeah. So like, yeah, I don't know. Unique visitors seems pretty normal. Total views seems like these seem like normal numbers. It's the clone numbers that seem whack. It it's I bet you it's AI scrapers. >> Yeah. And I looked I looked and I've looked around the GitHub API and there's really no way to get any information about who's cloning it. >> You you you really can't like I don't you wouldn't you wouldn't be able to know. I don't think >> the best GitHub could probably give you is an IP address, but then they're not going to be that's like technically PII and they're not going to share that. Um, >> yeah, I thought about putting in an optional telemetry um snippet, but just because I'm curious, >> it might be I wonder if it's worth like because I wonder if we could do that kind of diagnostic script idea of like, hey, like do a little selfch check on your augur instance and then that can be kind of like we we can have it generate a little like text file format that's like, hey, here's a report like here's a little debugging report that you can submit if if you have an issue and then just encourage people to contact us with it or maybe I know places like Pi like applications like Pi Hole will have an option in their little debug like their little like self test menu like hey upload this report and make like it'll upload it to like a paste bin site or something or their own version of that >> and then give you a link that you can share in your issue or something. So maybe maybe we can do that. I don't know. I want to be careful not to like turn too many people away with with telemetry, but >> Yeah. No, exactly. It would have to be optional. I actually like your idea better because we're offering to help. And honestly, if you're running augur, you're going to want to check it and you're probably going to have something to submit if you've been running it for any period of time. And if nobody sends us anything and we've still got all these cloners, then I know there's some kind of odd bot activity happening. I also wonder too if this clones graph is it counting fresh clones or is it counting pull like pulls of new commits because if we've got like this almost looks like it could just be like a bunch of people who just have auger cloned already and are just periodically pulling for updates like if and so like I because I wonder so when were the dates that we last merged stuff to main because I know we did just now >> two months since since we um Oh, since we merged Yeah, we actually been merging stuff to Maine with pretty regrettity, >> right? >> Yeah. So, well, I'm curious if I'm curious if some of those dates line up with some of those big spikes on that graph because the LA So, the last one I see is March 12th. What was the What was the graph again? Uh, we only get two weeks, but let me >> Yeah, we can't I don't know if we can go back too far, but I'm like >> we can only go back two weeks unless we're pulling the data regular. >> Okay, March. So, March 12th. So, that doesn't really line up with that spike, but was it what was the >> like Okay, the 12th to the 16th, that's four days, and today's a Tuesday. >> So, March 10th March 10th was a a day we merged. There was some stuff on Maine. And that does line up with that big spike uh with the that sort of middle spike. >> Actually, we merged we merged a couple things. We merged quite a few things on March 10th. >> Yeah, that that would be the maintainers meeting. So, >> and then March 4th was the one before that which does line which lines up with the previous spike. So, I I I do sus I suspect it's I I wonder if that could just be I mean I imagine some amount of it is AI scrapers. I some of it is probably also just people like who have Auger cloned are like updating their clones which I guess is a good sign that people are keeping their instances up to date. >> Yeah. I mean anybody restarting Docker is going to pull this. >> Uh restarting yeah if you update your Docker install it'll you'll do that but I that's not necessarily an automatic thing. >> Okay. Um anyway is so I also wanted to I know uh there was kind of some efforts to include more 8not in these meetings as well. So I had I I think I know Kaio's Kyle's out today like he mentioned on Slack but >> um I did have some kind of updates that I think might be relevant to sort of bring >> you it's just in the agenda if you want to if you wanted to pull that up. Um >> but it's basically just um so we recently we're working on currently is reenabling the heat there are some heat map diagrams to kind of like which files have been touched at what times sort of in a in a grid view to help help you kind of see is a particular group of files or a particular subset of the repo like missing a maintainer and not been touched in a long time. I.e. I imagine you'd see something like jump start in our repository to that because that folder hasn't been touched in two years. Um, but it's just kind of another health metric. I think we disabled it because the queries were taking a really long time to run and we recently I think since we disabled it. Um, we we there's been other improvements to augur like ignoring being able to ignore repos. And so it's we're we're slowly bringing back we're trying to maintain we're trying to bring that back into 8 and re like reenable the queries move them into materialized views things like that. So there, so the first point with this is that there's now that we have some additional materialized to use to bring into auger upstream. >> Um, >> yeah, >> I'm not sure. I don't know >> especially if they're in especially if eight's expecting them. >> Yeah. So the problem with that is though I don't think our current Olympic like database migration config is able to do uh materialized views. I think a lot of our materialized views have just existed forever and that like they're in some of the old SQL scripts that are like the legacy migrations. >> I think Kelly and I created most of the materialized views like four years ago, maybe five year five years ago. >> Yeah. So do you think that was potentially before we added Olympic? it we were using. So it was it was kind of the state that you saw when you started working on augur where we had that giant script that created everything up to a point and then everything after that was Olympic but I guess no it was yeah so you know how we >> it sounds like >> yes I I think it was possibly before Olympic. Yeah, because it sounds like it sounds like a lot of like some of the stuff that Cali was referencing in that issue for bringing these data migration these uh materialized views in was looking at some of those older SQL files and I'm like we shouldn't edit those because a they're for older migrations and only apply to people upgrading from that old versions of augur and also like that's not going to apply to people upgrading their instance from this last version to this version. So I think we need to figure out a better way like a figure out a way to get Olympic to see materialized views and be able to define those in I don't know how we would do that like define them in maybe a Python model in our um in SQL Alchemy or something just because I like I think we definitely need to we need to have those versioned and controlled the same way we do our regular schema. Um >> yeah I'm just where are those scripts? >> Uh they are in application DB. It's in the it's alongside I think some of them are alongside all the other if you go to schema. No not sorry I lied. I said DB. Uh >> if you go to schema >> I think YIC there's there's a like some of the legacy migrations there's some files in there. I think there's several SQL files everywhere and I don't remember uh actually >> materialized view update. So yeah, explore materialized view update. This is three years ago. >> What's in that? Is that Oh, is no that's an Olympic file. What's what's in that? Um number four. Can you open that one? >> Yeah. >> Explore the one you were just looking at. >> Yeah. >> I love the um lexical graphic ordering. >> Yeah. I mean >> add material. So what's that function do? Add materialized views 15. Oh, that's just >> that's just raw. Okay. So I guess we could do it the raw SQL way. That's I don't like that. But it would be nice if we could get Olympic to like generate migrations to an app. >> I mean syntactically syntactically views are queries, right? materialized views are just physically persisted queries because that's a lot faster. Um, >> yeah, >> like logically for what a limbic does, I would wonder if it could support all the things that we need in a materialized view. Like um one of the things you may or may not know this that you want to make sure to have in any materialized view, you want to have a primary key because without a primary key, you can't refresh data concurrently. And if you can't refresh data concurrently, that locks that materialized view from any connection or use while it's being refreshed. Yeah, I mean that that's less of a problem for 8 because we we just regenerate all the materialized views when we clone the DB, but that's that's a very not typical setup because we're operating in such a scale that we can't have augur collection and 8 not running off the same DB or at least that was when we were behind on collection. So I think now it might be better now that we're caught we're relatively caught up. But >> yeah, >> I I'd like to make some more performance fixes before we try and remerge those two. Um, but speaking of performance too, I think one of the other things that this materialized view conversation brought up was I I was I was kind of poking around and I noticed >> I I filed an issue a little while ago about just the sheer size of the repo labor table and I realized >> that a lot of the queries for this a lot of the materialized views for this heat map join on that table. So I I suspect that the the bulk of that table is potentially what was causing this query to be so slow in the first place that we disabled it in 8 knot to begin with. >> Yeah. Um >> I that table is a huge percentage of the disk utilization >> because it's persisting the analysis from all time. um that's been extremely useful in uh I'm we're working my research group is working on understanding the evolution of complexity of software uh with the dawn of AI and having that history has been of phenomenal use to us. Uh however it is a giant table and the things that are useful could in could almost certainly be summarized down into a smaller table. So what I'm not even saying like remove the like I think having that history is useful. I'm just thinking that there's a lot of duplication between what we're storing in this table and what's existing in other places. Like I think we already have like PR files commit the commits table is already effectively commit files. We just need to rename that and fix that. But I think it might make sense to move towards Marie having a table that's like files that is referenced in other from all the other places that we can have files and then because then the repo labor is essentially just sort of analysis of those files, right? like it's looking at how many lines of this code is comments versus code versus I I forget exactly what it looks at, >> but it's got those like like the B the core of that table is like five columns that are just small integers. >> So, >> so I think if we can dduplicate storing like the file paths and the file names and things and put those in a different table and have that be a foreign key reference. So we did try that initially and the reason that we we sort of evolved away from it and I'm not saying that this is an unsolvable problem. I'm saying that we decided not to try to solve it. The when you're analyzing the pull requests and the files that's the files in that pull request at that point in time. When you're analyzing repo labor, those are the files in that repo at that point in time. Files are added and removed routinely. So there isn't actually in augur anything that is the canonical here are the files in this repo except for the most recent uh commit files. But but we don't actually have a a like a file reference that is independent from some analysis of the file whether it's pull request files uh commit files or the repo labor files. So there is no there is no list of files historically and I think we would need something like that to have a central files table because those three entities are going to be they'll have different inventories of files at any moment in time. There'll be one or two files that are new in one of them and one or two files that are missing in one of them. Do you see what I'm saying? >> Yeah. I think that would still be um you could still have that even with sort of centralizing the files table cuz like the files table could essentially like if any of like whether it comes from a PR or a commit or whatever like there's information that is the same across all of those sources where it's like what file is it like some of the some of the basic there's things that are common to the concept of a file I think >> like how putting those in one table would we might be able to do some dduplication but that's a a issue, but I think we'd still be able to look at it from the different views because it'll all be foreign key. Like we could do okay pull requests like we could have a table that links pull requests and the files that are in that pull request and you could do a join through that. >> What about So I'm just I'm just like thinking through the problems that we had when we tried to do this. What about when like I have a centralized list of files when there's a significant refactoring? Sometimes nearly every file moves around. So now what do we do with the history of the file? Do we keep that in a table? Because if we're using a centralized files inventory, the pull request files and the repo labor files path, they both need the history. They need to see the files at the moment in time that those analyses ran. Yeah, we don't need like I don't think we need to necessarily be trying to like like we could still store like multiple records for like if if you're looking at a particular like set of rows that are like for for this repo and like what like you you could like for example if you were to query this hypothetical future files table for a given repo I think it would be reasonable for you to see like okay here's like a thousand entries for basically the same file path all with different collection dates like okay this file was seen at all these different times maybe half of them are from a PR half of them are from a commit like several of them are like you could kind of I I don't I mean and then you could get into some of dduplication where like okay maybe it's one file and then but you could access it from from either a foreign key from the like pull request s or you could do a foreign key from the repo labor like multiple things looking at that one file but you'd still have several entries for that file path as it's like over time like every time it changes bas or something like >> okay >> uh you it it sort of depends on how you lay out the tables but I think we you'd still have the history I think I think it's entirely possible to still keep like okay this file like this file got added here and and to be able to find ways of like where it's where it was last seen and stuff. Um, >> okay. I mean, >> it's definitely going to require a lot of thinking through and planning, but I I think that's definitely a worthy direction to try and go in. Like, so I think I think a database should really be trying to map these concepts of like, okay, here is a file, here is a pull request, here is the relationship between the two, like, okay, here's how a file relates to a commit. um and try and kind of move towards normalizing things a little bit. >> So I have so one question I will have I have for Cali who's not here I understand but is the foreign analytical utility of that which I think what I'm hearing is it would lower the learning curve basically like a lot of these changes would reduce the learning curve for data scientists leveraging augur right? Yeah, that sounds that I think that's a yeah, that would probably be a benefit. Like that's I think that's just a benefit to helping kind of normalize the tables a little bit in like maybe don't go too overboard, but like yeah, having like having just a one place where you can look at files. Um, and then you can you can get different views of that depending on whether you're sort of joining into that table from a poll request or a commit or a repo labor or something. So then the then another question becomes is does the cost of doing all of this coordination when we're collecting data make sense or is this an example of a place where perhaps we need some kind of analytical version that we extract data from augur into. Um, I think that I think the costs during collection are probably relatively negligible. I know we could probably rely on I mean we can like SQL Alchemy does have pretty strong support for like doing relationships and things and and we could we could kind of rely on it a little bit more to like handle. Okay, we're going to just create this object and populate this like files files thing with whatever. And then it just sort of figures out where that table where that goes in the table. Um I I think I was thinking of something else too. Um we another one of the approaches I was also thinking of as far as like moving towards sort of trying to normalize our database is yeah taking advantage of things like materialized views to sort of since since 8n's already basically relying on the API the database schema anyway largely through materialized views I think we can kind of take advantage of that and use the materialized views as sort of like an outer castle wall of here is our sort of suggested like we'd rather you query these. Um, and then so then we if we need to shuffle other tables around, we can like if we we make a change to the schema for like some of the like PR files or something, we can make that change both in the in the core schema and in the materialized view such that the output of the materialized view doesn't change and so downstream applications don't like really have to worry about it. same with if we slightly tweak how we're processing the data in one of our REST endpoints, but the output JSON is still the same. Like I think we can kind of move towards that with materialized views or or I think even some of the um >> I think Michael in in the data engineering channel was trying to start a discussion on some like semantic layers and more sort of data tools for what it sounds like is doing a very similar thing. Um, so I think maybe we could do that and we could just sort of maybe define what our ideal perfect schema is, make materialized views for all those tables and then figure out how to cram whatever jank tables we have now into that and have that be sort of our defined public API. And then that'll build us some space so that we can internally take whatever time we need to migrate our core tables such that it's maybe a better like the queries that convert to those materialized views aren't as horrible and crusty and like terrible. >> Yeah. >> Um >> that makes I mean okay that that seems like a logical >> Yeah. It's it's it's a large effort. I don't think it's necessarily in the cards for this year, but I think like >> a lot of this stuff is like long like I I think I've been definitely trying to kind of look at issues of like okay what's like are there these big long-term goals that we can just sort of think about like every time we do a data migration can we just think about okay at least make sure that all the small changes we're making are at least taking steps either towards or not away from like these larger goals of normalizing the table like I think some of the smaller changes that I think we were talking about in previous weeks as far as potentially like using the um using like the the contributor aliases as sort of just the canonical source of emails instead of having an email in the contributors table and also a list of aliases like just having that all like here is a table that just lists the many emails that one contributor can have like just a simple many to one table structure. Um, I feel like I've been talking for a long time. Just I know SH just joined. So, is anyone else got other things to add to the agenda? >> Yeah. Hey, Schlock, we see you come in. We've just been looking at PRs and >> Hey guys. Yeah, I've I've been seeing I get those GitHub emails. It's just that I've been really busy with sort of interviews and everything. Uh, I haven't had a chance to do much, but I have my final Red Hat interview in like 15 minutes. So hoping that I'll be done with everything by the end of this week and then, you know, actually get back to order because >> I really don't have anything else to do recent. Uh I've, you know, defended my thesis. I'm I've submitted a couple of papers. So sort of like a prelude now. Just wrapping up all of the stuff and then get back to order. >> Yeah. >> Well, that's awesome. Congrats on the final round. >> Yeah. Thank you. Yeah. Let's see. Uh but yeah, other than that, I don't think I really have much to add. I'm just trying to, you know, listen more and see, you know, what are the biggest pain points and if there's something that I could contribute back. >> Yeah, if if you've got time. I think um I don't really have much like I my focus this week is mostly going to be on working with Cali on figuring out how do we clean up our data from some of the the collection bugs of the last few weeks. Um, if you really wanted something to do, I think getting started maybe on figuring out how how we can get to to like how how we can sort of bring in the materialized views into our database sort of versioning process with YIC I think would be helpful. I think I dro I think I found a couple of links to to sort of start the research process in whatever relevant issue is in this in these notes. Um, but I haven't really looked into it more than just a cursory click the first stock overflow link I found. >> Um, So if that's something that you've got you've got time for like towards the end of this week like it's not super high priority but it's like >> eight nod is starting to kind of introduce its own materialized views and that's not a very good user experience for someone who's just expecting docker compose up on two stacks and having it work. >> Yep. Yep. Yep. Obviously. Yeah. All right. Yeah, that makes sense. I'm not sure if supports materialize views. I think there's like a plugin or like a third party thing is what? Okay. >> What branch would I have? What branch of 8 are those materialized views required for Adrian? >> So right now that would be I'm worried that would be a breaking change for my 8 knot instance when I pull it the next time. >> So we we just released a new version just to pull in mostly performance like a particular sort of performance fix for the search bar. the the reenabling the it's reenabling the heat maps that's the thing that's gonna sort of cause a lot of this that has technically not been merged yet I think it's it's pretty close I'm probably going to be looking at it today and or this week um >> is it in dev >> it's just a feature PR it's just a PR feature branch >> um >> but yeah those feature branches do merge into dev so dev is equivalent to our main and then release and then main and 8 knot is equivalent to our release the naming is a little bit backwards but it's conceptually the same process of PRs go into a dev branch, go into a release branch. >> Yeah, I know. I think yours is a little bit easier for people to understand that they're working with a dev branch when they hit the repo. Honestly, like if I go back in time, I might rename our branches following your pattern. In fact, we can do that, but I'm not suggesting we do that right now. Just >> Yeah, >> it might make sense if the two projects were consistent as I think about that. So yeah, I mean I think if if it gets into dev if there would be a way that you could at least I don't know I think we should put something into augur to indicate that even if we don't have it automated it would be helpful to know that you have to create that materialized view or those materialized views whatever they were and have a script for it. Yeah, I know. I know. I've definitely I I think for our most recent sort of release of 8 knot I I did sort of push for having like a tagged version number and I think that was sort of moving towards the idea of putting in the eight not read me like okay here are the versions of augur that these versions of 8 knot was sort of designed alongside um >> right >> so that like if you're just trying to run an old version you know okay I need to be using one of these versions of augur with this version of 8not it as I don't really wanna necessarily have to like be super strict about that. Like I'd like the compatibility to be pretty open, but I think >> like especially if we've got things like this where like we're like there's new materialized views and new new things happening like that's why I think this process of being able to bring the materialized views in upstream because basically what's happened is our process for versioning DB has changed since we last realistically looked at bringing materialized views in. So we need to figure out okay how does that new Olympic process >> handle materialized views like I'd like to use Olympic if we at all can but like >> utter worst case is like we just have a folder of SQL files that is like the current materialized views and every time you upgrade augur we just wipe them and regenerate them which is going to be a royal pain for huge instances like ours but for the majority of the smaller instances it shouldn't be that impactful I don't know >> yeah Um, >> I mean I think I mean I'm just I'm thinking of myself right now. I I just don't want my 8 knot instances to break the next time I upgrade update 8 knot >> and I think most people are like that. >> Adrian Adrian quick question. Is there an existing issue that's tracking this materialized views uh issue? >> Yeah. So I think I put it it should be in >> this one here I think. >> Yeah. So there I think there's an issue on the a side and there's an issue on the eight knot side. >> Um Yeah, >> I think I made an eight not one that was like, "Hey, we should probably upstream these." And then I think Callie made this issue that was like, >> "Got it. >> Here's the upstream side of this conversation." >> Yeah. >> Um, >> gotcha. Gotcha. Okay. Okay. All right. Sounds good. I'll go through read through that conversation. Okay. I also see a Stack Overflow link as well. I'll read through that as well. Okay. Sounds good. Yeah, I think other than that my my focus in the sort of slightly more distant future is like okay starting to landing more like sort of more of those kinds of PRs Sean that we were merging last week as far as just like okay let's start moving like moving some of the functions we have to generate URLs into our actual GitHub API class and sort of starting to reorganize some code so that things >> we can sort of be like okay now Let's take this GitHub class and swap it out for a 4Jo1 or something and hopefully things work. >> Yeah, there's one other PR that Adrian did that I just wanted another set of eyes on before >> we it's this one. I'm looking for my chat window in Zoom as we run out of time in this meeting. >> This is I think this was actually this wasn't in the notes, but yeah, this is this is relatively recent. Uh it's a it's just a small quality of life. It just has augur basically assign its own name to connections that it's making into the database so that when you're in the like um sessions view whatever it's called in DB or your other tool of choice like if you're looking at just the list of all the sessions of that are connected to the database you can see which ones are from augur and which ones might be unnamed from other places. Um >> yeah, if you have a chance to review that schlock, but we're out of time now, so >> y >> we'll um let everybody go and um thank you both for all of the work that you do and making augur so much better than it was six months ago. >> Yeah, thank you guys for helping helping review all the PRs. Like I know we're still got a huge backlog, but I think we're working through it. hopefully do five or so small ones for for the big for each release and hopefully get through it eventually. >> Yeah. >> Yeah. And Yeah. Yeah. Yeah. We could go We should get at some point we should decide how to get rid of the ones that are stale and that the people aren't coming back to. >> I've been I've been starting to close some of those and just kind of like I' I'm trying to I think I tend to leave open the ones that like have maybe a kernel of being potentially like it might be worthy of someone like hey there's there's a kernel of good stuff here. Maybe maybe someone can take it over and and clean it up. >> Yeah, >> but I I might need to start being a little bit less friendly on that just because there's so many of them and it's just like I think I need to start learning the power of saying no by default. >> Yeah. Yeah. All right. Thank you both. I will see you see you online., Augur/8-Knot WG March 17, 2026, YouTube, 01kp8gjw9pak9vp4z7crwhjzdf.