Sender | Message | Time |
---|---|---|
4 Sep 2023 | ||
osnyx (he/him) | In reply to @raitobezarius:matrix.orgWe're running stable releases. I am not sure whether we'd want all of our machines to run with a canary-systemd (🥶) but we might be able to do this for one of the few especially domain-rich machines – if there is a perspective of this helping things going upstream soonish. | 13:04:33 |
osnyx (he/him) | In reply to @raitobezarius:matrix.orgIs there anything I could've done better for upstreaming? On the one hand I was eager to implement something already i May, on the other hand I went the extra mile to go through your alternative proposals first. | 13:06:12 |
raitobezarius | Yeah I think the issue is that systemd development is faster with someone who is close to systemd, I had the same issues and decided to bite the bullet to avoid things lingering for too long | 13:06:50 |
raitobezarius | It's hard to do better than what you have done and I am happy you went through all the thousands cuts | 13:07:09 |
raitobezarius | I'd be happy taking your concurrency subject to Poettering and co to get it merged | 13:07:39 |
osnyx (he/him) | In reply to @raitobezarius:matrix.orgGood to hear, because I know a person who wasn't that intrigued that I eagerly jumped through all those hoops ^^ | 13:08:06 |
raitobezarius | The problem is having someone responsive for the C bits but I can try to pick up the pieces and see what is left to do | 13:08:07 |
raitobezarius | In reply to @os:matrix.flyingcircus.ioIt's usually very hard to please folks in open source development | 13:08:31 |
raitobezarius | In reply to @os:matrix.flyingcircus.ioIf I have something on this end, I will be sure to ping you as a guinea pig :p | 13:09:00 |
osnyx (he/him) | In reply to @raitobezarius:matrix.orgDepending on whether the PR will progress again, you could take https://github.com/systemd/systemd/pull/27985#issuecomment-1621702189 as a starting point | 13:09:51 |
osnyx (he/him) | In reply to @m1cr0man:m1cr0man.comAs I wrote in my comparison, the flock approach provides the concurrency guarantees in a broader scenario of cases. As most of you are worried of added complexity, in the end it's just a decision on which approach you as the maintainers (not just m1cr0man because of course you as the implementor understand what's happening there ;) )you feel more comfortable with and which you understand better. | 13:21:37 |
osnyx (he/him) | When it comes to (not) modifying the service script, let me argue that my change barely counts as such a modification from the semantical level. It's just an optional wrapper around the otherwise unmodified service script. | 13:23:55 |
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 hammer. 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… | 13:28:14 |
osnyx (he/him) | But that's just one perspective on it, I'm not interested in NIH but just explaining and – if they turn out to be solid possibly defend – my implementation decisions (= | 13:29:43 |
osnyx (he/him) | In reply to @raitobezarius:matrix.orgSo can I read this as a clear "we'll postpone the fix until systemd is ready" from your side and you won't even merge the m1cr0man PR? Then I need to prepare myself for maintaining a downstream acme fork. If yes, can I rely on you to push this forward? | 13:33:52 |
osnyx (he/him) | In reply to @raitobezarius:matrix.org* So can I read this as a clear "we'll postpone the fix until systemd is ready" from your side and you won't even merge the m1cr0man PR? Then I need to prepare myself for maintaining a downstream acme fork. If yes, can I interpret this as you taking on to push this forward? | 13:41:35 |
m1cr0man | 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 | 13:54:12 |
raitobezarius | In reply to @os:matrix.flyingcircus.ioI am not a blocker as said earlier | 13:54:31 |
raitobezarius | I will let m1cr0man do the call for the ACME module | 13:54:42 |
raitobezarius | It's their turf | 13:54:45 |
m1cr0man | In reply to @raitobezarius:matrix.orgI understand but your arguments are also valid. | 13:54:56 |
raitobezarius | Of course | 13:55:02 |
raitobezarius | But | 13:55:04 |
osnyx (he/him) | Good, because I read conflicting signals 😅 | 13:55:06 |
raitobezarius | I'd rather focus on bringing the feature to systemd | 13:55:08 |
raitobezarius | And let you folks figure out what you prefer to do here in Nixpkgs as long as you find an agreement :) | 13:55:19 |