| 1 Apr 2024 |
 Samantaz Fox | A problem I often encounter myself is "Oh, I'm fixing this, and I see this nearby code that can be fixed in a similar way, so let put the two together". And repeat that until ending with a PR that rewrites a lot of code. | 14:03:30 |
 ibicha | I'm loving this conversation btw!
On the topic of big PRs, I frequently ask folks to split things up into smaller changes, because it drastically increases the time to approval, simplifies reviews, and increases overall attention of the reviewer. I agree with MOST of what's being said here https://google.github.io/eng-practices/review/developer/small-cls.html | 14:07:16 |
| Samantaz Fox | Interesting, thanks for the link :) | 14:09:18 |
 TheFrenchGhosty | Samantaz Fox: If you did read everything, I hope you didn't take the wrong way what I said. As I said I personally think it's going FAR too slow compared to what it could be, but I understand why you want to do it this way (even if I wouldn't do it this way) | 14:12:37 |
 iv-bot | <dostoyevsky2> It's probably been already discussed but I don't understand how yesterday's fix works: https://github.com/iv-org/invidious/pull/4552/files | 14:14:21 |
| TheFrenchGhosty | From what I understand it's using a value that the YouTube backend expect (a value that was found by reverse engineering the official clients I'm guessing) | 14:16:09 |
| Samantaz Fox | TheFrenchGhosty I don't 100% agree with everything you said (e.x instances breaking). But other than that, I'm not perfect, and I'm open to positive criticism. | 14:17:48 |
| Samantaz Fox | dostoyevsky2: in essence, when requesting data from Youtube, we're passing extra parameters. We don't know what these parameters do exactly (we don't have names to put on those values) but by observing what the official client does, we can deduce that this or that works/doesn't. | 14:19:33 |
