A good solution for this is to create an "asio-next" repository which tracks the original asio and stacks all the new features/PRs on top. In other words, when a new release of asio happens, asio-next is reset to it and the PRs are rebased again on top. That way, the changes are not forgotten, they are kept in a state where they work with all other features, tests can be run, people can easily use it, etc. Then, the maintainer of asio-next can be the gatekeeper of what features might be interesting and stable enough for mainline asio, removing most of the pressure from asio/Chris reviewing many big requests that may prove risky. If/whenever asio/Chris agrees that such a feature is good enough for mainline asio, it is picked into asio and removed from the asio-next stack. Finally, for Boost, whoever maintains the official asio-next also keeps a new Boost.asio-next library in sync. With this setup, users can easily pick asio-next tags or Boost releases to take advantage of all the new asio code (which would be relatively well tested). Or they can even merge themselves the branch/tree of the feature they want into their own asio fork, if they do not want the entire asio-next. At the same time, it lowers the time commitment for the official asio maintainer, plus keeps it more stable. This is basically what linux-next does to manage and test dozens of trees with new features. Cheers, Miguel On Thu, Oct 11, 2018 at 5:36 PM Vinnie Falco via Boost <boost@lists.boost.org> wrote:
There are issues which are years old which have been lingering in the Boost.Asio repository, and there are also old issues in the stand-alone Asio repository. It seems like these are being ignored, is there any strategy for addressing this?
Examples:
This one is going on a year: <https://github.com/boostorg/asio/issues/77>
Two years: <https://github.com/chriskohlhoff/asio/issues/124>
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost