| 4 Sep 2023 |
 m1cr0man | It's added complexity to the Acme units. I've been pretty adverse to feature additions because it creates new failure scenarios and it's already got crazy feature creep but in this instance it's pretty important to have a rate limit and I've seen the effects of it first hand. | 13:58:14 |
 osnyx (he/him) | In reply to @m1cr0man:m1cr0man.com
I think your arguments are solid. I'm not on board for waiting for systemd to add features (and your hammer saying is the same reason why). Like I said if you're willing to just be around to take questions or PR fixes into that portion of the module, I'm happy to see your one merged. I do think it is more complicated but I can live with that if I'm not the only one that understands how it works.
I would like you to copy over the test case I made though, to prevent future regressions That's why I wanted to get another opinion of the team regarding not the only one that understands how it works.
I try to get the tests in this week. | 13:59:31 |
 raitobezarius | I think it's fair that we set the "direction of the ACME module" to: we can welcome this feature and urge/usher into an era where systemd will provide it and we can decrease the complexity in the future | 14:05:46 |
| m1cr0man | I also want to upstream some stuff to Lego, so between the two hopefully complexity will fall over the next while. | 14:11:31 |
| osnyx (he/him) | * My take on the "let's solve it with systemd unit options alone" approach is just the idea that we must be careful to not fall into the when all you want to use is a systemd-253 hammer, everything looks like a unit option nail.
It might be a hammer you know, but that hammer bight also just be adding things to the evergrowing list of interwoven systemd unit relationships… | 14:24:55 |
| osnyx (he/him) changed their display name from Oliver Schmidt to osnyx (he/him). | 20:10:48 |
