[asio] Issues piling up

newer
Re: [boost] Fwd: Installing CMake...

older
Re: [boost] Fwd: Installing CMake...

Vinnie Falco

11 Oct 2018 11 Oct '18

3:36 p.m.

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

Show replies by date

Richard Hodges

11 Oct 11 Oct

7:04 p.m.

As a huge fan of asio, and a frequent user, I am also concerned about this. What would be the process of becoming a maintainer? On Thu, 11 Oct 2018 at 17:36, Vinnie Falco via Boost 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

Robert Ramey

7:26 p.m.

On 10/11/18 12:04 PM, Richard Hodges via Boost wrote:

...

As a huge fan of asio, and a frequent user, I am also concerned about this.

What would be the process of becoming a maintainer?

On Thu, 11 Oct 2018 at 17:36, Vinnie Falco via Boost 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

Is this true for the original ASIO version or just the Boost one? Robert Ramey

...

...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Vinnie Falco

7:58 p.m.

On Thu, Oct 11, 2018 at 12:32 PM Robert Ramey via Boost wrote:

...

Is this true for the original ASIO version or just the Boost one?

Both.

Edward Diener

10:36 p.m.

On 10/11/2018 3:04 PM, Richard Hodges via Boost wrote:

...

As a huge fan of asio, and a frequent user, I am also concerned about this.

What would be the process of becoming a maintainer?

Just say here you would like to maintain the asio library and introduce yourself and your background. Hopefully someone from the Boost Steering Committee, like Michael Caisse, will respond, and you will be chosen to maintain asio. Boost very much needs talented C++ programmers to maintain libraries, and who have an interest and working knowledge of particular Boost libraries.

...

On Thu, 11 Oct 2018 at 17:36, Vinnie Falco via Boost 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

Andrey Semashev

11:22 p.m.

On Fri, Oct 12, 2018 at 1:37 AM Edward Diener via Boost wrote:

...

On 10/11/2018 3:04 PM, Richard Hodges via Boost wrote:

...
As a huge fan of asio, and a frequent user, I am also concerned about this.

What would be the process of becoming a maintainer?

Just say here you would like to maintain the asio library and introduce yourself and your background. Hopefully someone from the Boost Steering Committee, like Michael Caisse, will respond, and you will be chosen to maintain asio. Boost very much needs talented C++ programmers to maintain libraries, and who have an interest and working knowledge of particular Boost libraries.

Since Asio is primarily maintained outside Boost, I would say contacting the author and offering help to him directly would probably be the way to go. I don't think it is the Boost Steering Committee's job to decide who should do the maintenance of a Boost library. It has always been the author's decision.

Edward Diener

12 Oct 12 Oct

12:24 a.m.

On 10/11/2018 7:22 PM, Andrey Semashev via Boost wrote:

...

On Fri, Oct 12, 2018 at 1:37 AM Edward Diener via Boost wrote:

...
On 10/11/2018 3:04 PM, Richard Hodges via Boost wrote:

...
As a huge fan of asio, and a frequent user, I am also concerned about this.

What would be the process of becoming a maintainer?

Just say here you would like to maintain the asio library and introduce yourself and your background. Hopefully someone from the Boost Steering Committee, like Michael Caisse, will respond, and you will be chosen to maintain asio. Boost very much needs talented C++ programmers to maintain libraries, and who have an interest and working knowledge of particular Boost libraries.

Since Asio is primarily maintained outside Boost, I would say contacting the author and offering help to him directly would probably be the way to go.

I agree. I should have mentioned that the author should be contacted first.

...

I don't think it is the Boost Steering Committee's job to decide who should do the maintenance of a Boost library. It has always been the author's decision.

If the author is not responsive then it should be decided by the Boost Steering Committee. If the author is still involved in maintaining his library, then of course he makes the decision.

Vinnie Falco

12:38 a.m.

On Thu, Oct 11, 2018 at 5:24 PM Edward Diener via Boost wrote:

...

If the author is not responsive...

I have to reiterate, the problem is not that the library is not maintained. It is, there are updates in every Boost release and Asio tracks networking-ts closely (obviously, since the sources are generated from the stand-alone version which networking-ts is based on). I'm only pointing out that many issues and pull requests don't seem to get any attention. Thanks

Vinnie Falco

12:08 a.m.

On Thu, Oct 11, 2018 at 3:37 PM Edward Diener via Boost wrote:

...

Just say here you would like to maintain the asio library

That's nice in theory, but Boost.Asio is generated by this script which runs on the stand-alone version of the source code: https://github.com/chriskohlhoff/asio/blob/master/asio/boostify.pl Making changes directly to Boost.Asio would essentially cause a fork, so this isn't really an option. Anyway as Andrey said, it should be up to the author to decide whether to bring on a helper. We don't have to make changes to Boost.Asio directly, we can just submit pull requests to the stand-alone Asio for new features and bug fixes, as these people have done: https://github.com/chriskohlhoff/asio/pulls Unfortunately, few if any of these pull requests get a response from the maintainer, which brings us back to the problem described in the original post... There are quite a few useful, complete features which contributors have taken the time to develop and submit but which have languished with no response, sometimes for years. Examples: Added wolfSSL Compatability for Asio instead of OpenSSL (5 months) https://github.com/chriskohlhoff/asio/pull/321 LibreSSL compatibility (1 year 7 months) https://github.com/chriskohlhoff/asio/pull/196 Add DTLS support to asio (2 years) https://github.com/chriskohlhoff/asio/pull/129 This one in particular is so sad, people have come back periodically to beg for attention to the issue but they are met with silence: Fix #116: Enables ECDHE temporary parameters in ASIO SSL # https://github.com/chriskohlhoff/asio/pull/117 Some of these pull requests even manage to elicit lively and productive discussions and revisions, but there's no official response. It would be nice to be able to close issues in Boost.Asio which are no longer relevant or resolved, to reduce the noise. To be clear, I am not suggesting that someone else should maintain the library. I am only bringing attention to the fact that there is a lack of official responses to issues in Asio's respective repositories, and that pull requests are often ignored. This affects me indirectly, since Beast is built on Asio. For example, I have to keep hearing from users about the "Boost.Coroutine is deprecated" warning: https://travis-ci.org/vinniefalco/beast/jobs/439893521#L1212 This is because Asio uses Boost.Coroutine which is supposedly deprecated. But there is an impasse between the authors of those respective libraries (Boost.Coroutine2 requires C++11, and Asio only requires C++03). And me and my users are the casualties. Regards

Edward Diener

12:38 a.m.

On 10/11/2018 8:08 PM, Vinnie Falco via Boost wrote:

...

On Thu, Oct 11, 2018 at 3:37 PM Edward Diener via Boost wrote:

...
Just say here you would like to maintain the asio library

That's nice in theory, but Boost.Asio is generated by this script which runs on the stand-alone version of the source code:

https://github.com/chriskohlhoff/asio/blob/master/asio/boostify.pl

Are you saying that their is code in Boost asio which relies on asio code outside the Boost repository. That does not seem like a good situation to me, unless that other code is publicly accessible. Even then it is better if all code directly related to a library is contained within the Boost repository of that library. I am of course not talking about some 3rd party library code which is popular and publicly accessible by everybody.

...

Making changes directly to Boost.Asio would essentially cause a fork, so this isn't really an option. Anyway as Andrey said, it should be up to the author to decide whether to bring on a helper.

We don't have to make changes to Boost.Asio directly, we can just submit pull requests to the stand-alone Asio for new features and bug fixes, as these people have done:

https://github.com/chriskohlhoff/asio/pulls

Unfortunately, few if any of these pull requests get a response from the maintainer, which brings us back to the problem described in the original post...

There are quite a few useful, complete features which contributors have taken the time to develop and submit but which have languished with no response, sometimes for years. Examples:

Added wolfSSL Compatability for Asio instead of OpenSSL (5 months) https://github.com/chriskohlhoff/asio/pull/321

LibreSSL compatibility (1 year 7 months) https://github.com/chriskohlhoff/asio/pull/196

Add DTLS support to asio (2 years) https://github.com/chriskohlhoff/asio/pull/129

This one in particular is so sad, people have come back periodically to beg for attention to the issue but they are met with silence:

Fix #116: Enables ECDHE temporary parameters in ASIO SSL # https://github.com/chriskohlhoff/asio/pull/117

Some of these pull requests even manage to elicit lively and productive discussions and revisions, but there's no official response.

It would be nice to be able to close issues in Boost.Asio which are no longer relevant or resolved, to reduce the noise.

To be clear, I am not suggesting that someone else should maintain the library. I am only bringing attention to the fact that there is a lack of official responses to issues in Asio's respective repositories, and that pull requests are often ignored. This affects me indirectly, since Beast is built on Asio. For example, I have to keep hearing from users about the "Boost.Coroutine is deprecated" warning:

https://travis-ci.org/vinniefalco/beast/jobs/439893521#L1212

This is because Asio uses Boost.Coroutine which is supposedly deprecated. But there is an impasse between the authors of those respective libraries (Boost.Coroutine2 requires C++11, and Asio only requires C++03). And me and my users are the casualties.

I think if an author and/or maintainer of a Boost library is not at all responsive to PRs and bug reports Boost should be able to assign another maintainer. But of course the current maintainer should be contacted first to see what his response to such a situation would be. I just do not want to discourage anyone who is capable and wants to help maintain a Boost library for which the current maintainer(s) are not addressing problems. We have far less maintainers than we have libraries so it is natural to want to encourage any capable person who wants to be a maintainer of a library which is not being actively maintained well.

...

Regards

Gavin Lambert

2:18 a.m.

On 12/10/2018 13:38, Edward Diener wrote:

...

On 10/11/2018 8:08 PM, Vinnie Falco wrote:

...
That's nice in theory, but Boost.Asio is generated by this script which runs on the stand-alone version of the source code:

https://github.com/chriskohlhoff/asio/blob/master/asio/boostify.pl

Are you saying that their is code in Boost asio which relies on asio code outside the Boost repository. That does not seem like a good situation to me, unless that other code is publicly accessible. Even then it is better if all code directly related to a library is contained within the Boost repository of that library. I am of course not talking about some 3rd party library code which is popular and publicly accessible by everybody.

No, that's not what he's saying. Asio exists in two forms -- as a standalone library and as a Boost-integrated library. Both have the same maintainer, and both are publicly available. The standalone library is considered the "real" source and the Boost version is periodically generated by a script and then an "update patch" committed. (Usually the two are fairly closely in sync but sometimes there's a longer delay -- the Boost version tends to be kept more "stable" than the standalone version.) Boost.Asio itself doesn't directly depend on any outside code, but it is still effectively 'read only' in that regard, since if someone independently made changes directly to this repository then they would be overwritten the next time the code was synchronised with the standalone repository.

...

I just do not want to discourage anyone who is capable and wants to help maintain a Boost library for which the current maintainer(s) are not addressing problems. We have far less maintainers than we have libraries so it is natural to want to encourage any capable person who wants to be a maintainer of a library which is not being actively maintained well.

As Vinnie said, Chris is still actively maintaining the library, insomuch as that relates to tracking changes from the standard and fixing critical bugs. But he's less responsive to feature requests. I don't think this is the appropriate forum for discussing that, though; concerns should be discussed with Chris directly. I assume it's just a case of disagreement about priority and time. In any case, unless Boost.Asio were made a true independent fork (which I assume wouldn't happen unless Chris stopped maintaining it entirely), any changes have to land first in the standalone version, so PRs or other maintenance requests have to be made there rather than here.

Domen Vrankar

8:24 a.m.

On Fri, Oct 12, 2018, 02:09 Vinnie Falco via Boost wrote: Snip

...

There are quite a few useful, complete features which contributors have taken the time to develop and submit but which have languished with no response, sometimes for years. Examples:

Added wolfSSL Compatability for Asio instead of OpenSSL (5 months) https://github.com/chriskohlhoff/asio/pull/321

LibreSSL compatibility (1 year 7 months) https://github.com/chriskohlhoff/asio/pull/196

Add DTLS support to asio (2 years) https://github.com/chriskohlhoff/asio/pull/129

This one in particular is so sad, people have come back periodically to beg for attention to the issue but they are met with silence:

Fix #116: Enables ECDHE temporary parameters in ASIO SSL # https://github.com/chriskohlhoff/asio/pull/117

Some of these pull requests even manage to elicit lively and productive discussions and revisions, but there's no official response.

I'm not too familiar with inner structure of asio but these pull requests seem really intrusive and of type "when new ssl lib comes along it should also be added direclty into asio lib" so it doesn't surprise me that they weren't accepted. That being said my guess would be that the same issue will arize with Networking TS once it gets merged into C++ - and there pull requests for such features must go through std library maintainers and the c++ committee. This makes me wonder if the patches are even the correct solution or would they be better as a standalone library(es) that don't need to polute asio with every man and his ssl version?

...

It would be nice to be able to close issues in Boost.Asio which are no longer relevant or resolved, to reduce the noise.

To be clear, I am not suggesting that someone else should maintain the library. I am only bringing attention to the fact that there is a lack of official responses to issues in Asio's respective repositories, and that pull requests are often ignored. This affects me indirectly, since Beast is built on Asio. For example, I have to keep hearing from users about the "Boost.Coroutine is deprecated" warning:

https://travis-ci.org/vinniefalco/beast/jobs/439893521#L1212

This is because Asio uses Boost.Coroutine which is supposedly deprecated. But there is an impasse between the authors of those respective libraries (Boost.Coroutine2 requires C++11, and Asio only requires C++03). And me and my users are the casualties.

I am using the experimental coroutine TS asio extensions (although I have a memory leak that still need to see if it's my code, coroutine TS [both vs c++ and clang], asio or beast issue) and there are also other options of using asio (all of them without the need of changing either asio or beast lib) so since boost.coroutine lib is being dropped dropping the feature in favour of existing alternatives is also an option so I'm once again wondering if the resolution is not the lack of maintanence but author's decision to discontinue this (would be the logical move imho) - only the author can answer. Just my 2 cents. Regards, Domen

...

Niall Douglas

11 Oct 11 Oct

7:36 p.m.

On 11/10/2018 16:36, Vinnie Falco via Boost 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?

In the end, its maintainer is busy. I can sorely empathise, do note how Outcome still ain't into Boost yet. Vinnie do I remember rightly that you're in charge of some slush fund for funding work on open source C++ or something? If so, it seems to me the answer to your problem is obvious: get a paid helper for Chris, and get those bugs pared down. Niall

Jamie Allsop

8:52 p.m.

On 11/10/2018 16:36, Vinnie Falco via Boost 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

I think it is fair to say from the commit history of Asio and the huge amount of work that has gone into modifying and enhancing the library to keep it in sync with the Networking TS that it is, in fact, being actively maintained. Some issues like #77 are in fact fixed, but the ticket hasn't been closed. (I guess there are multiple places now where issues get raised to add to the excitement). In an ideal world I'm sure we'd all be really good at that, but given the huge importance of Asio to the C++ language in general, no doubt some sort of time trade-off was made to prioritise that work over pure issue hygiene?

...

Two years: https://github.com/chriskohlhoff/asio/issues/124

Certainly an interesting example but also a somewhat complex feature request that brings with it a number of trade-off decisions that, (sadly for some) means this presumably is a lower priority than other Asio work - like the Networking TS and the many useful and significant updates that have been made to support that, not to mention Executors... Also from your contributions to the issue it looks like there is a work-around implemented for a primary use-case (Beast) making this less of a priority potentially. Honestly as heavy user of Boost I sympathise with the sentiment, but I think it is a real stretch, not to mention very unfair to the author and maintainer of the library, to fire out a message like this that seems to suggest Asio is not being actively maintained, or that there is some pressing issue that needs to be addressed.

...

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Vinnie Falco

19 Oct 19 Oct

2:51 p.m.

On Thu, Oct 11, 2018 at 8:36 AM Vinnie Falco wrote:

...

...issues...have been lingering in the Boost.Asio repository

Here's another example, today someone reported this warning about deprecated allocator<void> in Beast: https://github.com/boostorg/beast/issues/1272 But this problem is in Boost.Asio, which I reported in May: https://github.com/boostorg/asio/issues/109 I can't do much about this except rant on the mailing list. Regards

Vinnie Falco

7:16 p.m.

On Fri, Oct 19, 2018 at 7:51 AM Vinnie Falco wrote:

...

https://github.com/boostorg/asio/issues/109

This looks like a problem with MSVC not Asio, and is a duplicate of another closed issue so it is resolved (thanks Peter!) Regards

Miguel Ojeda

20 Oct 20 Oct

12:55 p.m.

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

2213

Age (days ago)

2222

Last active (days ago)

List overview

Download

16 comments

10 participants

participants (10)

Andrey Semashev
Domen Vrankar
Edward Diener
Gavin Lambert
Jamie Allsop
Miguel Ojeda
Niall Douglas
Richard Hodges
Robert Ramey
Vinnie Falco