| 1 May 2025 |
@joepie91:pixie.town | a PR will not fix this because it is a process problem, not a code problem | 15:52:52 |
@joepie91:pixie.town | core devs write these bugs into the code faster than you could possibly PR fixes | 15:53:02 |
@joepie91:pixie.town | that is why things never actually get more reliable | 15:53:10 |
@joepie91:pixie.town | * that is why things never actually get more reliable despite things getting fixed | 15:53:18 |
@emma:rory.gay | ive had more impactful changes merged tbh | 15:53:23 |
@emma:rory.gay | like not running an entire machine learning model if your sensitivity is set to 0 anyways | 15:53:42 |
@joepie91:pixie.town | if you simply do not have a culture of trying to get things "as right as possible within the constraints" then you will never get reliable code regardless of how much work other people put into trying to fix it | 15:53:55 |
@joepie91:pixie.town | and matrix core does not have that culture and that is why everything sucks | 15:54:15 |
@joepie91:pixie.town | it's a negligent approach to software development | 15:54:34 |
@joepie91:pixie.town | this just happens to be a particularly obvious example of the problem | 15:54:49 |
@emma:rory.gay | true | 15:55:10 |
KFears (they/them) | In reply to @joepie91:pixie.town it would be, but the point I was trying to make above isn't that it's suboptimal, because that can easily be responded to with "well I didn't have the time to get it right". the point I was trying to make is that it would've taken like 5 more minutes and zero structural code changes to deal with the low-hanging fruit only by doing a simple regex check, and that even that wasn't done, and that this is a recurring problem with element/matrix core code I have seen a lot of such code coming from corporate world. Not sure if there's a correlation here | 15:58:53 |
@joepie91:pixie.town | KFears (burning out): there is; a lot of companies are purely extractive towards their developers, in that they are expected to be 'shipping code' at all times, and they do not get the room to experiment and learn to improve their craft | 16:15:23 |
@joepie91:pixie.town | it's not the only factor, but pressure is often a factor in unnecessary corners getting cut, because people start taking the most obvious paths for everything, assuming that any further effort would slow them down, instead of actually doing the analysis | 16:16:10 |
@joepie91:pixie.town | and so people start associating "doing it right" with "costs a lot of time" even though often the opposite is true, not just in the long term but even in the short term | 16:16:50 |
@joepie91:pixie.town | this is very much a culture problem, ultimately | 16:17:26 |
@emma:rory.gay | i do a lot of shippiong code | 16:17:32 |
@emma:rory.gay | but at the end of the day im just fucking around | 16:17:52 |
| Rosuavio changed their display name from Rosario Pulella to Rosuavio. | 20:09:00 |
| asa joined the room. | 23:08:30 |
| 2 May 2025 |
uep | i thought mjolnir was essentially dead/unmaintained | 00:22:38 |
uep | i don't know if draupnir still has the same issue, it may already have been improved there even a little | 00:23:06 |
uep | (all the above issues are valid, just noting that in addition they're essentially fossilised here) | 00:24:19 |
uep | * (all the above issues are valid, just noting that in addition the specific consequences are essentially fossilised here) | 00:24:45 |
uep | even if such a PR might actually be accepted, it's less likely to be made, and maybe less likely to make it out into the world as a release | 00:26:15 |
| Brian May joined the room. | 01:15:26 |
Cat | Mjolnir was brought back into active development. | 08:27:21 |
Cat | And as for odds of getting into a release they do cut releases from time to time | 08:27:47 |
uep | TIL | 08:41:20 |
Cat | Like I won’t say mjolnir has the highest thruput feature wise or anything like that but actively developing yes. | 09:44:11 |