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
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