Em seg., 18 de ago. de 2025 às 16:28, Seth via Boost <boost@lists.boost.org> escreveu:
On Mon, Aug 18, 2025, at 9:24 PM, Seth via Boost wrote:
You don't have to ask. If you don’t, you lost on the “gaining trust” before you started.
That all said, I’m not convinced I saw the convincing reasons for forking. One repeated example was “using std::error_code and friends”. Standalone Asio already does this by default, so it would be a trivial change to split this conditional. However, the choice is on purpose (Boost System has more features than the standard library version), as pointed out by Peter Dimov before.
I’ve also seen reasonably responsive behavior from Chris, just mostly on the things he cares about. I’ve been very surprised when Emile Cormier posted his any_completion_handler (https://github.com/chriskohlhoff/asio/issues/1100) idea and Chris landed an improved version … in the next release or close to that. The subsequent work to that feature (and adjacent features like immediate executors, consign, channels etc) do suggest the value in keeping Asio development in one place.
https://github.com/chriskohlhoff/asio isn't a git repo that only accepts changes relevant to Christopher Kohlhoff. From my own experience: * Every design change proposed by the standard executors TS WG gets into ASIO eventually. This is no small amount of work, and it gets consistently done. * Every time I've reached out to improve FreeBSD support (even in niche cases), the changes were accepted (most of the times Chris rewrote the changes himself, but got the job done anyways). The only case where FreeBSD support still lags behind is a case where I haven't gotten the time to write a patch myself (nowadays I rarely contribute to ASIO as I'm spending my time elsewhere although I still use ASIO heavily a lot). I think the main problem in ASIO is a lack of clear contribution guidelines. Everytime I get a developer under my wing to do something to ASIO, I always have to explain the contribution process: * PRs are only accepted a couple of weeks prior to the next release. * Do include as much detail on why the changes you've done are important as possible in the commit messages. Get the patch right *the very first time* if you want timely responses. * You have to follow the commit history to see if your changes got accepted because most of the time Chris rewrites the patches to not delay fixes even further (instead of asking for changes and then waiting until you get the patches to his liking). The downside: you don't get automatic Github notifications when your request gets done. Just adding these guidelines in the README.md would help to clarify the ASIO contribution process and decrease frustration IMO. The process isn't perfect, but there is no perfect. Maybe someone to act as a bug triager could improve the process (e.g. fixing duplicate/invalid issues). This would save time not only for contributors who sent a patch and have to manually follow the git repo, but it'd also save Chris time as he wouldn't have to deal with the eventual lazy contributors who'd force Chris to waste time instead (as it's common in open source projects). To be completely honest, I shall also mention to the downsides that affected me in the past: * When I have multiple changes and one stacks on top of another, it takes multiple release cycles to get the whole feature-set into ASIO. Nowadays I'm no longer spending time on improving FreeBSD support for ASIO as the current model forced these changes to become a multi-year effort, and now I already moved on to a different project. -- Vinícius dos Santos Oliveira