speaker_label,start_time,end_time,text
spk_0,0.021150000000000002,0.6453333333333333,"And were live. Welcome everybody yet another weekly call for the new DS architecture design workflow. Um We, we have a one entry for now in the agenda. Uh Patrick, he wants to thank Carry for creating that issue um to investigate alternative solutions for syntax highlighting. She started very good questions as threads and he has left initial thoughts on it that may help investigation. Please feel free to share yours as well. I havent, I havent caught up yet. Uh Does anybody here that has any thoughts on this uh"
spk_1,0.6513333333333333,0.9728166666666667,topic? I I left the answers as well. So uh I think we can continue the discussion as synchronously on this topic. Uh Thank you Patrick and Carry for the discussion there.
spk_0,1.0094833333333333,1.8626666666666667,"OK. I think its interesting to get to the bottom of, of these questions especially um as were considering other ways of um getting that um information and prioritizing using different priorities, especially once we are loading the initial prioritized files or changed paths. Um We could make uh those come highlighted already, but then the rest of them could come non highlighted and then we can defer that to a later point in time based on user interaction, it would be really good if that is in fact affecting the time that it would get us there. Um And if it turns out, oh, sorry, go ahead."
spk_2,1.8911666666666667,2.1651666666666665,"Even if it turns out like this is like, you know, a red herring or a blind alley. Um just take a few minutes to document our thoughts or, you know, the state of the state of the tech today. Um That can be important for uh  where the process is an
 artifact."
spk_0,2.190166666666667,3.827316666666667,"For sure. It will, it will indeed. Um There is an open question in my mind that Im not sure if weve already addressed and especially in what language or technologies offer a superior performance is that when were, when we were working with um code intelligence uh implementation, we were using a specific file format to give in to giving that information to the front end. Uh Or, or I think that uh the LSF files. Um So the question here is whether theres any way to get the highlighting information to the front end without having to parrot the content of the files. If theres any way to give, send an annotated, annotated version of the Sinta version, sorry Sinha information. You could have the front end highlight the con that it already knows. Um So um yeah, just something Ill, Ill have my thoughts there and I think thats the best way, make sure that we keep the discussion with the relevant information. So since we didnt have an agenda, I was brainstorming and I think we can have a better use of our time. Um Anything anything else on this point that anybody wants to raise? Right. So lets continue discussion of sequence. Um Apart from that, anything else um that people have on their minds, questions, thoughts, things we should look into."
spk_3,3.8578333333333332,4.687,"Ill just give a small update that Im still documenting all the features that we have. So Im basically splitting this and into two dimensions. One dimension is the type of uh d that we have. It can be a code D, image de file D or just like a change path de. Um And also another dimension is which technology we are using. So is it magic quest tips which are using view files or is it Hamel template? Because the feature sets are a little bit different there. For example, the Hamel version has a toggle where you can switch between highlighted and raw file, which we dont have in the DS. So"
spk_0,4.700483333333334,5.592650000000001,"doing that, can you have a link to the issue? Uh I know we have an issue for it. I just cant find it at the moment in the, its definitely worth worthwhile. So thanks for doing that. Um The other thing II, I think we still have several uh open issues to take care of stuff like the definition of done and everything. So uh I know this or at least for me as a manager. This is a busy week for um because of assessments and everything, but it would be nice to get some movement there um on getting those issues closed by committing those changes to the documentation. And remember, we can always iterate, can always add more information later if we need to. Ok. Uh Just to have a point."
spk_4,5.621316666666667,6.040983333333333,"Yeah, I just wanted to kind of give an update on our end. Um The GLY side, were gonna start moving forward with the changes we discussed uh last week for um supporting uh page nated DS. Um So its kind of a re architecture of our G service. So if anyone has any other feedback, um they can put it in that issue. Um But I think were gonna start moving forward and implementing and just kind of seeing what its gonna look like and iterating on that."
spk_0,6.08315,6.213166666666667,"Thanks just, and, and just for clarity, it will be in it. It wont change any existing R PC. It will create new ones, is that it?"
spk_4,6.224166666666666,6.828166666666666,"Yes. Correct. Yes. So were gonna leave everything as is and then were gonna um add in two new RP CS. One thats kind of that fetches information about what the diff is gonna shape of the diff. And then the other one to actually diff a diff blobs um that the client would call in succession and we are exploring. Um This was mentioned uh last week too about potentially batching a series of, of files like batches of files. Um We are exploring that, that will require upstream changes. So that might be an additional R PC in the future as an optimization we can make."
spk_0,6.891333333333334,7.148166666666667,"Thats definitely interesting. Just so uh Im clear as well um for this to have an impact in the product, the code base needs to get updated to use the new RP CS. Are we the only ones leveraging these or will  other parts of the product leverage these as
 well?"
spk_4,7.169333333333333,7.693333333333333,"Um There is a couple other small areas that are using the uh existing commit DIR PC uh if I remember correctly. Um But definitely, yeah, I believe yall are the main use case for this, this R PC. So and so uh ideally, wed want to convert over uh at some point and maybe potentially eventually move everyone over and phase out the old one. Well see. Uh just this, the existing one does not scale well um with the shape of the repository as it gets larger."
spk_0,7.71965,8.623816666666666,"OK. Um I think its important to discuss this a little bit here because the time frame for this effort, what we were anticipating is having the blueprint published in the quarter four and then having some sort of implementation kick off within quarter one, which does not preclude us from exploring integrating these improvements in the code base before that. Um If it definitely gets the benefits, this would be implementation between rails and, and galley. Um, but if we think that that time is better invested in building the new discs in quarter one, then well have a discussion at that moment. But, um, I think its important to keep us in, in the loop of whats happening. I dont know how long this will take. If its a milestone work or like you said, the upstream changes will take a little bit longer but keep us posted and then we will, well adjust and well talk about prioritizing any adjustments."
spk_4,8.643650000000001,8.662666666666667,OK. Sounds good.
spk_0,8.680983333333334,8.725333333333333,Awesome anymore.
spk_1,8.752983333333333,8.980666666666668,Just a quick question about the gli limitation. Yeah. Uh Do we have a region already? The idea of how we do we want to implement it or is it still being discussed?
spk_4,9.006499999999999,10.258333333333333,"We have a pretty good idea of, of how we want to implement it. Um There, theres already, I can remember what the name of the R PC thats kind of similar for the, the first part. Basically, youre gonna call the client would, would, would call Gidley and get a, a summary of all the, the changes that are going to happen. Like all the file paths with their associated blog before and after um for the D and then with that information, the client would sequentially uh call or just follow up with uh calls for um a diff blobs R PC and provide the before and after blob and then it would just return ad per per file basically, and that allows us to scale better. Um, not have to do a one because on, on, even though it kind of looks like its page commit dips is page today. Really? On the back end theres a single G process that gets spawned and computes the whole D and then just chunks it back to the client. And the problem is if that one G process takes too long or too expensive, if the whole thing times out, it just doesnt scale. And theres already example repositories that are causing time outs and were finding people have to increase their time outs to avoid this issue. Um So, yeah,"
spk_1,10.26215,10.525166666666667,"I agree. I agree. And uh uh just for clarification, is it two RP CS or uh like the, the single or the first one you mentioned? Yeah. Its like metadata. Yeah, or something like this. Uh And, and then uh actual data. Yeah."
spk_4,10.534500000000001,10.7125,"Yes. Correct. It would be two separate RB CS. One thats um uh like I said, it kind of gives the summary and then the second one, it would be like D blobs would probably the name of it and just, just for each blob."
spk_1,10.7275,10.983833333333333,"Yeah. And the metadata R PC. Can it be pated as well? I mean, yeah, I can imagine that. Yeah, we can also have uh like a huge list of files. Yes. So we could, should apply PIN on PIN, right?"
spk_4,10.993316666666667,11.129166666666666,"Yeah, we could stream back a list of, of the actual uh metadata thats for the deaf. Yeah, we, we would pin that as well."
spk_1,11.145166666666666,11.198333333333332,Yeah. Makes sense. Thank you very much for information.
spk_0,11.248816666666666,12.961316666666667,"I think its, its pretty interesting. Uh because we, when you say metadata, initial metadata, we have encountered some edge cases when Im working in the Merger Quest stiffs. And one of them I Ill mention 21 of them was when oh gosh um with renames where the file path might not be as unique as we think. Because in the course of emerging quest, you can have multiple changes. They end up deleting a file, moving a different file to that path again. And I dont know how get resolves that. I, I know that there was an incident where an in an instance where we had a collision of file paths but different operations on those files, I cant remember exactly what the area was. So that was one and the other is that we already split the data into uh two requests to the back end on the merger quests. Uh One is for diffs metadata and that diffs metadata. I think its like interesting because I dont know if it will match what were getting from Gidley. But a lot of it we used to um compile like or just generate the statistics here on the top the counts of files and all that stuff. We use that depth gifs metadata to generate the file tree here on the left uh And this is the information that comes to the diffs metadata endpoint. Again, this is not a public api this is just an internal thing were using at the moment, but it does allow us to start rendering the, the U I for the, for the diff, right? It doesnt have the lines, just the information of each files. Is this something what youre looking to implement Justin similar?"
spk_4,12.972333333333333,13.81865,"Um Probably uh I think its uh its gonna be a variation of this R PC because theres the line numbers, the added line numbers and uh uh deleted line numbers. Thats another R PC. I think its like dip stats or something like that. And basically, but yes, we, we wanna do an extension of, of the R PC that presents this information. II, I cant remember the name right now. Um But I, I think this RP doesnt do rename detection right now and uh we need to extend it to do rename detection. Um Just to clarify one thing that you mentioned earlier. Are you did, did you say that you guys also um do additional like modification of the discs to determine rename detection on your end or? Um  Thats a good
 question."
spk_0,13.841483333333334,13.897483333333334,I dont know what we do because Igor
spk_1,13.910983333333332,14.12465,"I hope we dont. Yeah, because it would be like uh consume like memory, like uh resource consuming information. I think so, I hope we dont do it like this."
spk_0,14.136833333333334,14.312316666666668,"Yeah, I dont know, carry do you know if we do anything? But after we get the information from Gley for renaming what we need to talk to that."
spk_2,14.326816666666668,14.365666666666668,"I  dont, Im sorry. Could you repeat the
 question?"
spk_0,14.368,14.863,"Yes, Ill repeat. Do we do anything to the data we get from Gidley to detect renaming and uh like file clashes and stuff like that? Because we mentioned both before, I think Thomas worked on something about uh renamed files. The mode of operation that were being done to those files was slightly different. I cant remember exactly the scenario but the question then is, do we just get information from giddily and present it to the front end or do we do some operations to detect special cases?  I
 dont"
spk_2,14.865316666666667,14.912316666666667,"recall us doing anything on our side, on the real side."
spk_0,14.934666666666667,15.03815,"A look and then, yeah. OK. Yeah,  thatd be great because then that
 could be interesting."
spk_1,15.058833333333332,15.969483333333333,"Probably some additional additional like conditions were involved, something like binary data, something like this. Uh I also remember something uh like that Thomas investigated something like this. But uh yeah, also I dont remember the details, the details and regarding the des uh metadata, Ive noticed that uh we catch a lot. Yeah, when um when I see in the performance bar, um this metadata doesnt call any, doesnt perform any GLY calls and we probably like cash it and then uh like do it using SKR calls. And uh but at the same time when I compare with another version. Yeah, I see a git call but it d starts and as far as I remember D starts, uh, returns file names or something like this or, or maybe not. But"
spk_0,16.005333333333333,18.150333333333332,"yeah, and probably still makes sense to have a separate R PC for just the two stats for sure. Because you might want to get the blobs but not render that particular part of the U I. Yeah. So, yeah. Um cool. I just wanted to raise it just in case that wasnt known because its not a public api its just something that we internally use for the merger quest again. Doesnt mean that the new Ds will follow the same approach might be slightly different because it needs to account for other cases. All right. Um Thanks for looking into that. Uh Anything anything else you wanna talk about? Theres still the topic of the timing of the A P A call that it seems like it didnt happen last week as well. Um But I have some ideas. Um So my idea is to potentially oscillate between, I Ill add a point to the agenda, discussing timing of the way back go. Uh instead of oscillating between now and a very much uh later time come up with some al alternate time where its a bit closer for all of us to participate in Europe, but include Patrick, which would be a bit earlier, even if that excludes carry every other week. Um But I feel like were, we have a very highly engaged member that is not being able to make the same calls and, and that worries me a little bit. So I know that we are doing a good job keeping things as synchronously going. But uh and I thank everybody for the patience, but Ill uh Ill discuss it on slack again. Try to come up with a better timing uh to isolate between. Thanks for the thumbs up. Carry that. So now, cool. Any other thoughts, questions? If not, I can give you some time back. All right, thats a thumbs up. Um, thank you so much. Um, and, uh, see you around on another call."