Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
peterkochlarsen wrote:
Also an unmaintained library should be marked as such as should libraries that are deprecated, replaced by standard C++ features (shared_ptr comes to mind)
shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is not deprecated. It actually has been evolving past the C++11 std::shared_ptr. For example, boost::shared_ptr supported array forms in 1.53 and this was eventually added to C++ in C++17. (Interesting aside: That functionality above was even, and still is used, in certain Microsoft projects, where boost::shared_ptr is used instead of std::shared_ptr). The same goes for other Boost libraries like Boost.Thread. They: - May have features not in the C++ standard library equivalent - May be evolving past the current C++ standard - Are in use by actual projects and shouldn't be removed Glen -- View this message in context: http://boost.2283326.n4.nabble.com/review-queue-What-to-do-about-the-library... Sent from the Boost - Dev mailing list archive at Nabble.com.
Glen Fernandes wrote:
peterkochlarsen wrote:
Also an unmaintained library should be marked as such as should libraries that are deprecated, replaced by standard C++ features (shared_ptr comes to mind)
shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is not deprecated.
It actually has been evolving past the C++11 std::shared_ptr. For example, boost::shared_ptr supported array forms in 1.53 and this was eventually added to C++ in C++17.
And, since we managed to not get the array form of make_shared into C++17, boost::make_shared will remain relevant a few more years. This reminds me of the saying "looking for the lost keys under the street light." We have a problem, what can we do? I know, let's deprecate and remove boost::shared_ptr!
On 2017-03-16 01:56, Peter Dimov via Boost wrote:
Glen Fernandes wrote:
peterkochlarsen wrote:
Also an unmaintained library should be marked as such as should > libraries that are deprecated, replaced by standard C++ features > (shared_ptr comes to mind)
shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is not deprecated.
It actually has been evolving past the C++11 std::shared_ptr. For example, boost::shared_ptr supported array forms in 1.53 and this was eventually added to C++ in C++17.
And, since we managed to not get the array form of make_shared into C++17, boost::make_shared will remain relevant a few more years.
This reminds me of the saying "looking for the lost keys under the street light." We have a problem, what can we do? I know, let's deprecate and remove boost::shared_ptr!
Hi, I doubt that sarcasm will help solve the severe interoperability issues between the very close boost and std versions. I sometimes wish those libraries got never adopted for this reason. Best, Oswin
Oswin Krause wrote:
Hi,
I doubt that sarcasm will help solve the severe interoperability issues between the very close boost and std versions.
What severe interoperability issues?
I sometimes wish those libraries got never adopted for this reason.
By the standard? This would surely have cured the interoperability issues.
Hi, On 2017-03-16 13:03, Peter Dimov via Boost wrote:
Oswin Krause wrote:
Hi,
I doubt that sarcasm will help solve the severe interoperability issues between the very close boost and std versions.
What severe interoperability issues? sorry for the slightly late reply.
Interoperability issues between code that is designed using the std:: versions and code using the boost libraries. Starting with: mixing boost and std libraries as it was intended to be. boost::shared_ptr is an example that one can get to work [1], however it is not straight forward(look at all the slightly wrong code out there) and requires sacrifices in performance. Most other libraries are harder and the situation is often even undefined. For example, I have no idea what will happen when I use std::this_thread inside a thread started by boost::thread. Thus it is hard for me to write code that is agnostic to the threading library used. However, if i settle for boost::thread i also have to use boost::chrono. I could use preprocessor macros, but if I have to deliver a library, I have to make a hard decision.
I sometimes wish those libraries got never adopted for this reason.
By the standard? This would surely have cured the interoperability issues.
[1]http://stackoverflow.com/questions/12314967/cohabitation-of-boostshared-ptr-...
Oswin Krause wrote:
What severe interoperability issues?
Interoperability issues between code that is designed using the std:: versions and code using the boost libraries. Starting with: mixing boost and std libraries as it was intended to be. boost::shared_ptr is an example that one can get to work [1],
Yes, see http://www.boost.org/doc/libs/1_63_0/libs/smart_ptr/sp_techniques.html#anoth...
however it is not straight forward(look at all the slightly wrong code out there) and requires sacrifices in performance. Most other libraries are harder and the situation is often even undefined. For example, I have no idea what will happen when I use std::this_thread inside a thread started by boost::thread.
This specific case should work; even though the standard doesn't say what will happen if you use it in threads not started by std::thread, all implementations ought to support OS threads started by pthread_create or CreateThread as well. Doesn't matter if Boost.Thread is used.
Thus it is hard for me to write code that is agnostic to the threading library used. However, if i settle for boost::thread i also have to use boost::chrono. I could use preprocessor macros, but if I have to deliver a library, I have to make a hard decision.
This is a real problem, but your desire
I sometimes wish those libraries got never adopted for this reason.
is baffling. You do know that boost::shared_ptr predates std::shared_ptr by many years (the page above is from 2003) and is in fact the reason there is std::shared_ptr? That we made std::shared_ptr happen? How on Earth not adopting it would have made things better?
On 3/16/17 11:22 AM, Peter Dimov via Boost wrote:
Oswin Krause wrote:
I sometimes wish those libraries got never adopted for this reason.
is baffling. You do know that boost::shared_ptr predates std::shared_ptr by many years (the page above is from 2003) and is in fact the reason there is std::shared_ptr? That we made std::shared_ptr happen? How on Earth not adopting it would have made things better?
Actually, this raises the issue as to what's the point of adding something to the standard which is already effectively standardized. Robert Ramey
On 2017-03-16 19:22, Peter Dimov via Boost wrote:
Oswin Krause wrote:
What severe interoperability issues?
Interoperability issues between code that is designed using the std:: versions and code using the boost libraries. Starting with: mixing boost and std libraries as it was intended to be. boost::shared_ptr is an example that one can get to work [1],
Yes, see http://www.boost.org/doc/libs/1_63_0/libs/smart_ptr/sp_techniques.html#anoth...
Yes, but as far as i can see, this can impact performance. I see no way to implement this without allocating additional storage. S it acts reasonable, but far from nice.
however it is not straight forward(look at all the slightly wrong code out there) and requires sacrifices in performance. Most other libraries are harder and the situation is often even undefined. For example, I have no idea what will happen when I use std::this_thread inside a thread started by boost::thread.
This specific case should work; even though the standard doesn't say what will happen if you use it in threads not started by std::thread, all implementations ought to support OS threads started by pthread_create or CreateThread as well. Doesn't matter if Boost.Thread is used.
The documentation does not say so. This is the issue.
Thus it is hard for me to write code that is agnostic to the threading library used. However, if i settle for boost::thread i also have to use boost::chrono. I could use preprocessor macros, but if I have to deliver a library, I have to make a hard decision.
This is a real problem, but your desire
I sometimes wish those libraries got never adopted for this reason.
is baffling. You do know that boost::shared_ptr predates std::shared_ptr by many years (the page above is from 2003) and is in fact the reason there is std::shared_ptr? That we made std::shared_ptr happen? How on Earth not adopting it would have made things better?
I do know that. I have learned C++ 15 years ago, when shared_ptr was the new sh*t in town, so to speak. At that time, more often than not, boost used to play nice with the standard library: you could expect that all std algorithms would work with boost containers and all boost algorithms would work with std containers. And newcomers were told: prefer std and sprinkle some boost in between when necessary. This worked well over so many years and made boost to such an important cornerstone as the "inofficial c++ standard library". This changed with the adoption of some boost libraries into the standard. The rule: "work nice with std" was suddenly hard to fullfil and those boost libraries, honestly, look a bit out of place by now. Sometimes it feels like the boost and std are competing libraries and the boost version is not even acknowledging the existence of the std version let alone trying to play nice with it. So the c++ landscape got more complicated, not simpler by including the most successful libraries of boost. This is a tough sell.
Le 16/03/2017 à 19:09, Oswin Krause via Boost a écrit :
Hi,
On 2017-03-16 13:03, Peter Dimov via Boost wrote:
Oswin Krause wrote:
Hi,
I doubt that sarcasm will help solve the severe interoperability issues between the very close boost and std versions.
What severe interoperability issues? sorry for the slightly late reply.
Interoperability issues between code that is designed using the std:: versions and code using the boost libraries. Starting with: mixing boost and std libraries as it was intended to be. boost::shared_ptr is an example that one can get to work [1], however it is not straight forward(look at all the slightly wrong code out there) and requires sacrifices in performance. Most other libraries are harder and the situation is often even undefined. For example, I have no idea what will happen when I use std::this_thread inside a thread started by boost::thread. This must works as it must work for any native thread. Thus it is hard for me to write code that is agnostic to the threading library used. However, if i settle for boost::thread i also have to use boost::chrono. I could use preprocessor macros, but if I have to deliver a library, I have to make a hard decision.
Could you explain what is the problem having to use also Boost.Chrono? Vicente
Could you explain what is the problem having to use also Boost.Chrono? Let me answer your question with another question: What good is it to force boost.chrono on the user? If my application does not profit from using boost::chrono over std::chrono why should i have to use it?
Here is how i see it: std::chrono + fully described by the standard and supported by all major c++ environments + described in all online standard references for c++ + we can soon expect all newcomers to know about std::chrono + can be used without adding another dependency on an external library boost::chrono + larger functionality + very similar, but not the same as std::chrono mixing both: + converting between time points? + differences in time measured /different clocks? + why should there be two very similar libraries mixed in the same code?
Le 17/03/2017 à 10:18, Oswin Krause a écrit :
Could you explain what is the problem having to use also Boost.Chrono? Let me answer your question with another question: What good is it to force boost.chrono on the user? If my application does not profit from using boost::chrono over std::chrono why should i have to use it?
Well, don't use it then. Who is forcing you to use Boost.Chrono?
Here is how i see it: std::chrono + fully described by the standard and supported by all major c++ environments + described in all online standard references for c++ + we can soon expect all newcomers to know about std::chrono + can be used without adding another dependency on an external library
boost::chrono + larger functionality + very similar, but not the same as std::chrono A report on any difference is welcome. I'm not saying that there are not.
mixing both: + converting between time points? I've not think about this, but a patch is welcome. + differences in time measured /different clocks? Chrono library doesn't specify how to convert between clocks. Neither std nor boost. Could you clarify your concern? + why should there be two very similar libraries mixed in the same code?
I suspect that because you have some parts of your code that use Boost.Chrono because std::chrono is not available.However you have other parts that can use std::chrono. In this case, I would suspect that for the parts that interact you will use Boost.Chrono. Best, Vicente
On 3/23/2017 11:56 AM, Peter Dimov via Boost wrote:
Vicente J. Botet Escriba wrote:
Well, don't use it then. Who is forcing you to use Boost.Chrono?
Boost.Thread, as stated in the original message?
This is why I wrote CXXD for other developers to use. Inevitably I foresaw that someone would say "Why does your library use boost XXX when I want to use C++ standard XXX instead ( or vice versa )." And yes, CXXD supports chrono as one of its dual libraries. This is off-subject for this post but I am glad for the opportunity to prove a point regarding CXXD.
Boost - Dev mailing list wrote
Glen Fernandes wrote:
peterkochlarsen wrote:
Also an unmaintained library should be marked as such as should libraries that are deprecated, replaced by standard C++ features (shared_ptr comes to mind)
shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is not deprecated.
It actually has been evolving past the C++11 std::shared_ptr. For example, boost::shared_ptr supported array forms in 1.53 and this was eventually added to C++ in C++17.
And, since we managed to not get the array form of make_shared into C++17, boost::make_shared will remain relevant a few more years.
This reminds me of the saying "looking for the lost keys under the street light." We have a problem, what can we do? I know, let's deprecate and remove boost::shared_ptr!
I did not intend to imply that boost::shared_ptr was a problematic part of boost. I just expect that for most of us, we should prefer std::shared_ptr. Thus, a note should be put in the documentation that there is also a standard shared_ptr. I just took a few minutes to look at the documentation and see that this information is already present, so shared_ptr has no problems in that regard. I just would prefer if this documentation was put at a more prominent position. For shared_ptr, there is another problem, however. I went to the track list and found a number of open bugs. Not, I guess, because shared_ptr is buggy, but because the bugs are not maintained. As an example, the newest bug #12604 is still marked as open: I guess it should not be. The same is the case for the second bug I examined (8485). Also bugs such as 6829 (slow in MSVC) should not be marked as such. If a function is slower than it could be it should be marked as an enhancement/feature request, not as a bug. Except, of course, if the function is so slow that it is absolutely useless. /Peter -- View this message in context: http://boost.2283326.n4.nabble.com/review-queue-What-to-do-about-the-library... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Thu, Mar 16, 2017 at 3:20 AM, peterkochlarsen via wrote:
For shared_ptr, there is another problem, however. I went to the track list and found a number of open bugs. Not, I guess, because shared_ptr is buggy, but because the bugs are not maintained.
#12604 is still marked as open: I guess it should not be. The same is the case for the second bug I examined (8485).
Yes, a lot of the bugs in Trac should be closed (marked as fixed). I think we're more diligent in closing Github Issues than Trac Issues lately. We can change that (until we truly move to Github Issues).
Also bugs such as 6829 (slow in MSVC) should not be marked as such.
Word choice "bug" versus "feature" aside, that one was also fixed, a long time ago. Glen
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vinnie Falco via Boost Sent: 16 March 2017 12:10 To: boost@lists.boost.org Cc: Vinnie Falco Subject: Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost <boost@lists.boost.org> wrote:
...until we truly move to Github Issues
What needs to be done in order to make this happen?
Make sure that we do not lose the BIG history in Trac, including many links documentation issues in Trac, (for example https://svn.boost.org/trac/boost/ticket/12908), and make all this available in GitHub. Nobody has been prepared to do this, so many projects are still using Trac. If projects are moving to use GitHub instead (or starting new projects using GitHub entirely), it would be helpful if somehow users who referred to Trac to find or report bugs would be altered to this. I don't know how to do this, but it would be a first step. (I'd also like to know how best to provide an equivalent to the above examples of a link to Trac). After a decade or two, the stuff in Trac will become of historical interest only, but until then ... Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On Thu, Mar 16, 2017 at 8:57 AM, Paul A. Bristow via Boost <boost@lists.boost.org> wrote:
If projects are moving to use GitHub instead (or starting new projects using GitHub entirely)
If my library makes it into Boost I would vastly prefer to continue using GitHub issues
On 16/03/2017 12:10, Vinnie Falco via Boost wrote:
On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost <boost@lists.boost.org> wrote:
...until we truly move to Github Issues
What needs to be done in order to make this happen?
A decision needs to be taken on how best to port the Trac issues into github. Some years ago I volunteered to upgrade Trac to a version capable of auto syncing github and Trac issues because the Trac we use is very, very ancient and is a giant unpatched security hole. I got nowhere, so I gave up. You'd be surprised how hard it is to change anything spanning more than one library at Boost. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
On 16/03/2017 12:10, Vinnie Falco via Boost wrote:
On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost <boost@lists.boost.org> wrote:
...until we truly move to Github Issues
What needs to be done in order to make this happen?
A decision needs to be taken on how best to port the Trac issues into github.
This implies that we want to port the Trac issues into Github. This is not a requirement. The 'organic' way to migrate to new things is just to move on. Trac is legacy; leave it in read-only mode so that history is preserved, but there's no need to do anything else. Except, of course, point people to Github instead of Trac, and make sure all libraries have Github issues enabled. There's no need to fight the natural course of things. Github is obviously a way better infrastructure; Github PRs once you get CI up and running is so much superior than Trac patches that it's not even a contest. We just need to acknowledge that on our front page.
On 03/16/17 18:01, Peter Dimov via Boost wrote:
Niall Douglas wrote:
On 16/03/2017 12:10, Vinnie Falco via Boost wrote:
On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost <boost@lists.boost.org> wrote:
...until we truly move to Github Issues
What needs to be done in order to make this happen?
A decision needs to be taken on how best to port the Trac issues into github.
This implies that we want to port the Trac issues into Github. This is not a requirement. The 'organic' way to migrate to new things is just to move on. Trac is legacy; leave it in read-only mode so that history is preserved, but there's no need to do anything else.
If we move to GitHub issues, I would rather have all open tickets moved from Trac there. Leaving them open in read-only Trac is not useful, and you can't request the reporters to duplicate the tickets on GitHub. All open tickets should preferably be in one place.
Andrey Semashev wrote:
If we move to GitHub issues, I would rather have all open tickets moved from Trac there.
That's again a difference in philosophy; I'd rather not because if a ticket has remained open in Trac for, say, seven years, porting it is of no use; and if it's a fresh ticket, the proper way to deal with it is to fix and close it, not port it.
On Thu, Mar 16, 2017 at 10:43 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
Andrey Semashev wrote:
If we move to GitHub issues, I would rather have all open tickets moved
from Trac there.
That's again a difference in philosophy; I'd rather not because if a ticket has remained open in Trac for, say, seven years, porting it is of no use; and if it's a fresh ticket, the proper way to deal with it is to fix and close it, not port it.
I believe the technical term is "clean slate". :) Emil
On 03/16/17 20:43, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
If we move to GitHub issues, I would rather have all open tickets moved from Trac there.
That's again a difference in philosophy; I'd rather not because if a ticket has remained open in Trac for, say, seven years, porting it is of no use; and if it's a fresh ticket, the proper way to deal with it is to fix and close it, not port it.
Well, not all tickets can be fixed easily. And the fact that the ticket hangs for several years doesn't mean it's not valid now.
Andrey Semashev wrote:
And the fact that the ticket hangs for several years doesn't mean it's not valid now.
A difference in philosophy, as I said. Yes, in principle all open tickets should be preserved for all eternity because, even though nothing was done for seven years, after five more years someone might actually do something. But the odds say otherwise. It's much more likely that the ticket is either obsolete, or will never get any attention.
On 3/16/17 11:07 AM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
And the fact that the ticket hangs for several years doesn't mean it's not valid now.
A difference in philosophy, as I said. Yes, in principle all open tickets should be preserved for all eternity because, even though nothing was done for seven years, after five more years someone might actually do something. But the odds say otherwise. It's much more likely that the ticket is either obsolete, or will never get any attention.
Often times when something is on the list for X years, it's because it's not actually fixable with a readonable amount of effort. For example, for the serialization library there's an issue in that one can't serialize a pointer to a pointer. This could be fixed, but not without upending a whole lot of stuff. And since it's a very, very rare case, it's more practical to expect the user to work around it in some way. But it's worth leaving on the list "forever" until the library is re-implemented. It's also valuable for the next person who comes upon this so the whole back and forth about it doesn't have to be repeated. So if you want to move git issues - fine. Just leave the trac as a readonly archive. If we "require" git, note that we'll be strapping ourselves to git for a very long times. Good or Bad it should be considered. If that's good, we might just deemphasize distribution via zip file and just encourage people to clone the git repository. For me this is a convenient way to work. But what about when boost outlives git - as it has a host of other projects, services (like sourceforge) Robert Ramey
On Thu, Mar 16, 2017 at 2:54 PM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
If we "require" git, note that we'll be strapping ourselves to git for a very long times. Good or Bad it should be considered. If that's good, we might just deemphasize distribution via zip file and just encourage people to clone the git repository. For me this is a convenient way to work.
But what about when boost outlives git - as it has a host of other projects, services (like sourceforge)
I think when you say git you mean GitHub (since issues are a GitHub feature not a git feature). GitHub has an API allowing you to extract all the issues, so if Boost does outlive GitHub then there is a path for migrating all of the data by extracting it first: https://developer.github.com/v3/
On Thu, Mar 16, 2017 at 2:08 PM, Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Thu, Mar 16, 2017 at 2:54 PM, Robert Ramey via Boost <boost@lists.boost.org> wrote:
If we "require" git, note that we'll be strapping ourselves to git for a very long times. Good or Bad it should be considered. If that's good, we might just deemphasize distribution via zip file and just encourage people to clone the git repository. For me this is a convenient way to work.
But what about when boost outlives git - as it has a host of other projects, services (like sourceforge)
I think when you say git you mean GitHub (since issues are a GitHub feature not a git feature).
GitHub has an API allowing you to extract all the issues, so if Boost does outlive GitHub then there is a path for migrating all of the data by extracting it first: https://developer.github.com/v3/
I love GitHub's interface and am happy to use it for now, but we should already be planning the next transition even though we don't know where we will be going. Ideally we'd have some server running this API daily, so that if one night GitHub decides that you have to start paying to use issues and the API, we already have a backup. Same with the source code, today everyone is using GitHub for source code and collaboration, but do we have a backup (our own server at git.boost.org?) for the day when GitHub decides not to play nice anymore? We've already seen the pain on the distribution side with sourceforge, where we wanted to leave, but didn't have the infrastructure that would allow us to. I don't have any answers to these questions, but I'd rather see boost hire someone to manage these things and pay for our own services/hardware than to pay for reviewers. Tom
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 16 March 2017 18:08 To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
Andrey Semashev wrote:
And the fact that the ticket hangs for several years doesn't mean it's not valid now.
A difference in philosophy, as I said. Yes, in principle all open tickets should be preserved for all eternity because, even though nothing was done for seven years, after five more years someone might actually do something. But the odds say otherwise. It's much more likely that the ticket is either obsolete, or will never get any attention.
Yes - but the fact that the issue has been considered, even if put into the 'too difficult drawer', is still really useful information. So we must NOT just wipe the slate! KISS (Keep It Simples Sirs) - just let library authors decide when they start or move to GitHub issues. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Paul A. Bristow wrote:
So we must NOT just wipe the slate!
All right, all right. If you like your slate, you will keep your slate. How about we just change our page http://www.boost.org/development/bugs.html to encourage people to submit pull requests (or, failing that, Github issues) instead?
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 17 March 2017 13:13 To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
Paul A. Bristow wrote:
So we must NOT just wipe the slate!
All right, all right. If you like your slate, you will keep your slate.
How about we just change our page
http://www.boost.org/development/bugs.html
to encourage people to submit pull requests (or, failing that, Github issues) instead?
Fine by me. Low cost, and KISS ;-) Paul
On 03/17/17 16:13, Peter Dimov via Boost wrote:
Paul A. Bristow wrote:
So we must NOT just wipe the slate!
All right, all right. If you like your slate, you will keep your slate.
How about we just change our page
http://www.boost.org/development/bugs.html
to encourage people to submit pull requests (or, failing that, Github issues) instead?
I'm ok about recommending PRs but not issues. Bugs should be reported to the system chosen by the library maintainers. For some, it is still Trac.
On 17.03.2017 10:40, Andrey Semashev via Boost wrote:
On 03/17/17 16:13, Peter Dimov via Boost wrote:
Paul A. Bristow wrote:
So we must NOT just wipe the slate!
All right, all right. If you like your slate, you will keep your slate.
How about we just change our page
http://www.boost.org/development/bugs.html
to encourage people to submit pull requests (or, failing that, Github issues) instead?
I'm ok about recommending PRs but not issues. Bugs should be reported to the system chosen by the library maintainers. For some, it is still Trac.
I suggest each library gets its own home page (on http://boostorg.github.io/<library>, or somewhere else if that doesn't exist yet), which contains some boilerplate (default) project info with pointers to docs, issue tracker, and other project-specific info. Library maintainers can then customize that page according to their own needs. (I'm already using that approach for http://boostorg.github.io/python/, but this is obviously not yet advertised from Boost's main website.) Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 03/17/17 17:50, Stefan Seefeld via Boost wrote:
On 17.03.2017 10:40, Andrey Semashev via Boost wrote:
On 03/17/17 16:13, Peter Dimov via Boost wrote:
Paul A. Bristow wrote:
So we must NOT just wipe the slate!
All right, all right. If you like your slate, you will keep your slate.
How about we just change our page
http://www.boost.org/development/bugs.html
to encourage people to submit pull requests (or, failing that, Github issues) instead?
I'm ok about recommending PRs but not issues. Bugs should be reported to the system chosen by the library maintainers. For some, it is still Trac.
I suggest each library gets its own home page (on http://boostorg.github.io/<library>, or somewhere else if that doesn't exist yet), which contains some boilerplate (default) project info with pointers to docs, issue tracker, and other project-specific info. Library maintainers can then customize that page according to their own needs.
(I'm already using that approach for http://boostorg.github.io/python/, but this is obviously not yet advertised from Boost's main website.)
I've done that for my libraries, only I used README.md for that. For example: https://github.com/boostorg/log It seems appropriate since that file is visible online and will get checked out by default if the user clones git. It is also distributed in Boost releases.
Andrey Semashev wrote:
I've done that for my libraries, only I used README.md for that. For example:
Perfect.
Stefan Seefeld wrote:
On 17.03.2017 10:40, Andrey Semashev via Boost wrote:
I'm ok about recommending PRs but not issues. Bugs should be reported to the system chosen by the library maintainers. For some, it is still Trac.
Some Boost libraries disable Github issues, presumably for this reason. But the main page needs to be simple and clear. It should direct people to http://github.com/boostorg/<library>. Listing individual preferences on the main page doesn't scale.
I suggest each library gets its own home page (on http://boostorg.github.io/<library>, ...
The libraries already get their own pages at http://github.com/boostorg/<library> - they just need to use their README files as intended. If Trac is to be used, disable issues, point people to Trac in README. If the /newticket link can set the component appropriately, all the better. If not, tell people what to set the field to, explain the importance. But frankly, in my opinion at least, pull requests are much, much superior to issue/ticket workflows for our purposes. If you're reporting a bug, put the failing test in the PR; this is work that has to be done either way, is much easier on the maintainer than describing a problem in words, and CI integration means that the compiler output for the failure is immediately available in a browser.
On 17.03.2017 11:16, Peter Dimov via Boost wrote:
Stefan Seefeld wrote:
On 17.03.2017 10:40, Andrey Semashev via Boost wrote:
I'm ok about recommending PRs but not issues. Bugs should be reported to > the system chosen by the library maintainers. For some, it is still > Trac.
Some Boost libraries disable Github issues, presumably for this reason. But the main page needs to be simple and clear. It should direct people to http://github.com/boostorg/<library>. Listing individual preferences on the main page doesn't scale.
I suggest each library gets its own home page (on http://boostorg.github.io/<library>, ...
The libraries already get their own pages at http://github.com/boostorg/<library> - they just need to use their README files as intended.
Sure, library maintainers can use http://github.com/boostorg/<library>, but these are not yet used as the canonical source of information. The main library listings on www.boost.org don't point to those. Switching from the centralized listing in http://www.boost.org/doc/libs/ to the above (and similarly getting rid of http://www.boost.org/development/bugs.html) would be one other substantial step towards modularization. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On 3/17/17 7:50 AM, Stefan Seefeld via Boost wrote: I suggest each library gets its own home page (on
http://boostorg.github.io/<library>, or somewhere else if that doesn't exist yet), which contains some boilerplate (default) project info with pointers to docs, issue tracker, and other project-specific info. Library maintainers can then customize that page according to their own needs.
You mean something like this: http://blincubator.com/bi_library/safe-numerics/?gform_post_id=426 ?
(I'm already using that approach for http://boostorg.github.io/python/, but this is obviously not yet advertised from Boost's main website.)
Stefan
On 17.03.2017 12:29, Robert Ramey via Boost wrote:
On 3/17/17 7:50 AM, Stefan Seefeld via Boost wrote: I suggest each library gets its own home page (on
http://boostorg.github.io/<library>, or somewhere else if that doesn't exist yet), which contains some boilerplate (default) project info with pointers to docs, issue tracker, and other project-specific info. Library maintainers can then customize that page according to their own needs.
You mean something like this: http://blincubator.com/bi_library/safe-numerics/?gform_post_id=426 ?
Yes, exactly. Stefan
(I'm already using that approach for http://boostorg.github.io/python/, but this is obviously not yet advertised from Boost's main website.)
Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ...ich hab' noch einen Koffer in Berlin...
On 16.03.2017 13:35, Andrey Semashev via Boost wrote:
On 03/16/17 18:01, Peter Dimov via Boost wrote:
Niall Douglas wrote:
On 16/03/2017 12:10, Vinnie Falco via Boost wrote:
On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost <boost@lists.boost.org> wrote:
...until we truly move to Github Issues
What needs to be done in order to make this happen?
A decision needs to be taken on how best to port the Trac issues into github.
This implies that we want to port the Trac issues into Github. This is not a requirement. The 'organic' way to migrate to new things is just to move on. Trac is legacy; leave it in read-only mode so that history is preserved, but there's no need to do anything else.
If we move to GitHub issues, I would rather have all open tickets moved from Trac there. Leaving them open in read-only Trac is not useful, and you can't request the reporters to duplicate the tickets on GitHub.
All open tickets should preferably be in one place.
Why not let individual project / library maintainers decide how to implement the move (or whether they want to move to github issues at all ?) Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Why not let individual project / library maintainers decide how to implement the move (or whether they want to move to github issues at all ?)
Trac is global, so you can't stop people from opening tickets there for just some libraries. (Another benefit of using Github (which some will perceive as a drawback) is that you can't open an issue in Github without specifying the library, as you can in Trac.)
AMDG On 03/16/2017 12:10 PM, Peter Dimov via Boost wrote:
Stefan Seefeld wrote:
Why not let individual project / library maintainers decide how to implement the move (or whether they want to move to github issues at all ?)
Trac is global, so you can't stop people from opening tickets there for just some libraries.
(Another benefit of using Github (which some will perceive as a drawback) is that you can't open an issue in Github without specifying the library, as you can in Trac.)
And the corresponding disadvantage is that if someone opens a ticket against the wrong component, it can't just be reassigned (I've seen this quite often in trac although it's partly the fault of vaguely defined components like Building Boost and Documentation). In Christ, Steven Watanabe
On 3/16/17 11:01 AM, Stefan Seefeld via Boost wrote:
On 16.03.2017 13:35, Andrey Semashev via Boost wrote:
On 03/16/17 18:01, Peter Dimov via Boost wrote:
Niall Douglas wrote:
On 16/03/2017 12:10, Vinnie Falco via Boost wrote:
On Thu, Mar 16, 2017 at 8:06 AM, Glen Fernandes via Boost <boost@lists.boost.org> wrote:
...until we truly move to Github Issues
What needs to be done in order to make this happen?
A decision needs to be taken on how best to port the Trac issues into github.
This implies that we want to port the Trac issues into Github. This is not a requirement. The 'organic' way to migrate to new things is just to move on. Trac is legacy; leave it in read-only mode so that history is preserved, but there's no need to do anything else.
If we move to GitHub issues, I would rather have all open tickets moved from Trac there. Leaving them open in read-only Trac is not useful, and you can't request the reporters to duplicate the tickets on GitHub.
All open tickets should preferably be in one place.
Why not let individual project / library maintainers decide how to implement the move (or whether they want to move to github issues at all ?)
Stefan
I think this is a very worthy idea. But I get PRs as well as trac issues. Hmmm is there a way to diable the PR mechanism on git and just link to the trac archive? Robert Ramey
On Thu, Mar 16, 2017 at 10:43 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
A decision needs to be taken on how best to port the Trac issues into github.
Here's an alternative, lock Trac so no new issues can be created, inform users they should open new issues using GitHub, then fix all the open issues remaining on Trac so there's nothing to port :)
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vinnie Falco via Boost Sent: 16 March 2017 15:25 To: boost@lists.boost.org Cc: Vinnie Falco Subject: Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
On Thu, Mar 16, 2017 at 10:43 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
A decision needs to be taken on how best to port the Trac issues into github.
Here's an alternative, lock Trac so no new issues can be created, inform users they should open new issues using GitHub, then fix all the open issues remaining on Trac so there's nothing to port :)
That might be a bit nuclear - what about all the outstanding issues and discussions in the process of being fixed? So perhaps we just need to recommend new issues be raised in GitHub, and Trac will fossilize itself. Paul PS How should we reference GitHub discussions in 'history' documentation so that I (and the search engines) can find them? The equivalent of, for example, https://svn.boost.org/trac/boost/ticket/12908). --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Paul A. Bristow wrote:
From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vinnie Falco via Boost Here's an alternative, lock Trac so no new issues can be created, inform users they should open new issues using GitHub, then fix all the open issues remaining on Trac so there's nothing to port :)
That might be a bit nuclear - what about all the outstanding issues and discussions in the process of being fixed?
Vinnie's suggestion is to disable new issue creation; outstanding issues will remain unaffected. It was I who proposed putting it all on read-only. :-)
PS How should we reference GitHub discussions in 'history' documentation so that I (and the search engines) can find them? The equivalent of, for example, https://svn.boost.org/trac/boost/ticket/12908).
For references, don't links to Github work fine? F.ex. https://github.com/boostorg/build/issues/168 Not sure about search engines.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov via Boost Sent: 16 March 2017 17:28 To: boost@lists.boost.org Cc: Peter Dimov Subject: Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
Paul A. Bristow wrote:
From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Vinnie Falco via Boost Here's an alternative, lock Trac so no new issues can be created, inform users they should open new issues using GitHub, then fix all the open issues remaining on Trac so there's nothing to port :)
That might be a bit nuclear - what about all the outstanding issues and discussions in the process of being fixed?
Vinnie's suggestion is to disable new issue creation; outstanding issues will remain unaffected. It was I who proposed putting it all on read-only. :-)
PS How should we reference GitHub discussions in 'history' documentation so that I (and the search engines) can find them? The equivalent of, for example, https://svn.boost.org/trac/boost/ticket/12908).
Not sure about search engines.
Ah well that's a big issue - I've found it very useful to find links to questions that I've asked and had answered a couple of years previously several times ;-) Eyes passim as they say in Private Eye :-(
For references, don't links to Github work fine? F.ex. https://github.com/boostorg/build/issues/168
Well, I could not find this particular one but it is newish and hard to find unique search terms, but others came up, so I think the bots are indexing OK. Are others confident from experience that searching does work? I doubt if moving tickets will be worth the effort (since it is in such short supply ;-). I'd prefer the cheapest most organic method of just saying on the Boost site that the way to report issues is now to use github. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Paul A. Bristow wrote:
... for example, https://svn.boost.org/trac/boost/ticket/12908).
A good opportunity to use a pull request adding a (currently failing) test instead. :-)
Boost - Dev mailing list wrote
On Thu, Mar 16, 2017 at 3:20 AM, peterkochlarsen via wrote:
#12604 is still marked as open: I guess it should not be. The same is the case for the second bug I examined (8485).
Yes, a lot of the bugs in Trac should be closed (marked as fixed). I think we're more diligent in closing Github Issues than Trac Issues lately. We can change that (until we truly move to Github Issues).
Also bugs such as 6829 (slow in MSVC) should not be marked as such.
Word choice "bug" versus "feature" aside, that one was also fixed, a long time ago.
Glen
I believe many people are frightened by this, so it would be nice if we could fix this situation. If trac is dying, I would propose that you closed public access to the database or made it obvious for potential boosters that the status of the issues are not to be trusted. Refer to github instead. /Peter -- View this message in context: http://boost.2283326.n4.nabble.com/review-queue-What-to-do-about-the-library... Sent from the Boost - Dev mailing list archive at Nabble.com.
Glen Fernandes wrote
peterkochlarsen wrote:
Also an unmaintained library should be marked as such as should libraries that are deprecated, replaced by standard C++ features (shared_ptr comes to mind)
shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is not deprecated.
It actually has been evolving past the C++11 std::shared_ptr. For example, boost::shared_ptr supported array forms in 1.53 and this was eventually added to C++ in C++17.
(Interesting aside: That functionality above was even, and still is used, in certain Microsoft projects, where boost::shared_ptr is used instead of std::shared_ptr).
The same goes for other Boost libraries like Boost.Thread. They: - May have features not in the C++ standard library equivalent - May be evolving past the current C++ standard - Are in use by actual projects and shouldn't be removed
Glen
I am not talking about removal, just a note that there is a standard replacement and a brief cap on their differences. Most people should prefer using the standard library, reconsidering if they really need the array-version of shared_ptr. By the way, I am a happy user of boost::thread, and have not taken the time to move to std::thread yet. -- View this message in context: http://boost.2283326.n4.nabble.com/review-queue-What-to-do-about-the-library... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Thu, Mar 16, 2017 at 3:09 AM, peterkochlarsen via Boost wrote:
Glen Fernandes wrote
peterkochlarsen wrote:
Also an unmaintained library should be marked as such as should libraries that are deprecated, replaced by standard C++ features (shared_ptr comes to mind)
shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is not deprecated.
It actually has been evolving past the C++11 std::shared_ptr. For example, boost::shared_ptr supported array forms in 1.53 and this was eventually added to C++ in C++17.
(Interesting aside: That functionality above was even, and still is used, in certain Microsoft projects, where boost::shared_ptr is used instead of std::shared_ptr).
The same goes for other Boost libraries like Boost.Thread. They: - May have features not in the C++ standard library equivalent - May be evolving past the current C++ standard - Are in use by actual projects and shouldn't be removed
Glen
I am not talking about removal, just a note that there is a standard replacement and a brief cap on their differences. Most people should prefer using the standard library, reconsidering if they really need the array-version of shared_ptr. By the way, I am a happy user of boost::thread, and have not taken the time to move to std::thread yet.
There is no "should" here. I let most people decide for themselves what they prefer. e.g. You may intend to move to std::thread, that's fine. Others may choose to continue to use boost::thread and boost::shared_ptr because they may not want to keep switching between std and boost for whatever reason(s). (In some cases, those reasons could be as simple as wanting newer features in Boost libraries that evolve faster. In other cases, it might be as simple as their organization updates Boost versions faster than they migrate to new compiler versions). As for documenting that there exists a standard version and describing the differences, sure: I can see the value in that. Glen
Boost - Dev mailing list wrote
On Thu, Mar 16, 2017 at 3:09 AM, peterkochlarsen via Boost wrote:
Glen Fernandes wrote
peterkochlarsen wrote: Most people should prefer using the standard library, reconsidering if they really need the array-version of shared_ptr. By the way, I am a happy user of boost::thread, and have not taken the time to move to std::thread yet.
There is no "should" here. I let most people decide for themselves what they prefer. e.g. You may intend to move to std::thread, that's fine. Others may choose to continue to use boost::thread and boost::shared_ptr because they may not want to keep switching between std and boost for whatever reason(s).
(In some cases, those reasons could be as simple as wanting newer features in Boost libraries that evolve faster. In other cases, it might be as simple as their organization updates Boost versions faster than they migrate to new compiler versions).
As for documenting that there exists a standard version and describing the differences, sure: I can see the value in that.
Glen
Agreed. I probably meant to write "Most people would". And this is an opinion where you have given good reasons as to why some might prefer not to switch. /Peter -- View this message in context: http://boost.2283326.n4.nabble.com/review-queue-What-to-do-about-the-library... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (15)
-
Andrey Semashev -
Edward Diener -
Emil Dotchevski -
Glen Fernandes -
Niall Douglas -
Oswin Krause -
Paul A. Bristow -
Peter Dimov -
peterkochlarsen -
Robert Ramey -
Stefan Seefeld -
Steven Watanabe -
Tom Kent -
Vicente J. Botet Escriba -
Vinnie Falco