what happens between "fixed in development" and "available in release"?
Hi, Question is in the subject. What has to happen after a fix of a bug in development stage before it enters an official release? Do not get me wrong, I like boost and all it does for the community and all the effort people put into it. And i really would like to help to speed up certain...processes, but for this i have to know what can block this step? Apparently a bug in serialisation - which totally breaks my software to the point where it can not be compiled on several linux distributions und MacOsX since release of boost 1.56 - is fixed in development even prior to 1.57 and is still not available in 1.58. And what I hear from several mails across the mailing list, this is not the only change that got stuck. And somehow i have the feeling that the new boost release cycle won't make the situation any better. As I said, do not get me wrong, but this situation becomes unbearable as these boost versions spread more and more through the ecosystem and there is really nothing on my side I can do about it, except rolling my own implementation and maintaining it, until this whole thing is faded out of all major distributions(you might already get the feeling that I am not really happy about doing that). if there is something i can do to help, I will do it. But I now know that "report bugs and investigate possible fixes and send patches" does not necessarily lead to a fast fix and i am pretty frustrated by the situation. Best, Oswin
On 3/18/2015 10:40 AM, oswin krause wrote:
Hi,
Question is in the subject. What has to happen after a fix of a bug in development stage before it enters an official release?
Do not get me wrong, I like boost and all it does for the community and all the effort people put into it. And i really would like to help to speed up certain...processes, but for this i have to know what can block this step?
Apparently a bug in serialisation - which totally breaks my software to the point where it can not be compiled on several linux distributions und MacOsX since release of boost 1.56 - is fixed in development even prior to 1.57 and is still not available in 1.58. And what I hear from several mails across the mailing list, this is not the only change that got stuck. And somehow i have the feeling that the new boost release cycle won't make the situation any better.
As I said, do not get me wrong, but this situation becomes unbearable as these boost versions spread more and more through the ecosystem and there is really nothing on my side I can do about it, except rolling my own implementation and maintaining it, until this whole thing is faded out of all major distributions(you might already get the feeling that I am not really happy about doing that).
if there is something i can do to help, I will do it. But I now know that "report bugs and investigate possible fixes and send patches" does not necessarily lead to a fast fix and i am pretty frustrated by the situation.
Putting '[serialization]' as the start of the subject to your message has more chance of alerting the Boost developer of the serialization library to your issue. Also citing the actual bug report that has been fixed in serialization on the 'develop' branch would help to specify the actual case of which you are concerned.
On 18.03.2015 22:31, Edward Diener wrote:
On 3/18/2015 10:40 AM, oswin krause wrote:
Hi,
Question is in the subject. What has to happen after a fix of a bug in development stage before it enters an official release?
Do not get me wrong, I like boost and all it does for the community and all the effort people put into it. And i really would like to help to speed up certain...processes, but for this i have to know what can block this step?
Apparently a bug in serialisation - which totally breaks my software to the point where it can not be compiled on several linux distributions und MacOsX since release of boost 1.56 - is fixed in development even prior to 1.57 and is still not available in 1.58. And what I hear from several mails across the mailing list, this is not the only change that got stuck. And somehow i have the feeling that the new boost release cycle won't make the situation any better.
As I said, do not get me wrong, but this situation becomes unbearable as these boost versions spread more and more through the ecosystem and there is really nothing on my side I can do about it, except rolling my own implementation and maintaining it, until this whole thing is faded out of all major distributions(you might already get the feeling that I am not really happy about doing that).
if there is something i can do to help, I will do it. But I now know that "report bugs and investigate possible fixes and send patches" does not necessarily lead to a fast fix and i am pretty frustrated by the situation.
Putting '[serialization]' as the start of the subject to your message has more chance of alerting the Boost developer of the serialization library to your issue. Also citing the actual bug report that has been fixed in serialization on the 'develop' branch would help to specify the actual case of which you are concerned.
I believe the core question was how could he (the poster) contribute to speed the things up. About the process, not so much about the particular library or the particular bug. Something I was wondering about in the past, too. Your reply emphasizing indicates that there probably isn't a single "Boost-wide" process but that everything is in the hands of library maintainers, and that it differs from library to library. Cheers, Leon
Putting '[serialization]' as the start of the subject to your message has more chance of alerting the Boost developer of the serialization library to your issue. Also citing the actual bug report that has been fixed in serialization on the 'develop' branch would help to specify the actual case of which you are concerned.
I believe the core question was how could he (the poster) contribute to speed the things up. About the process, not so much about the particular library or the particular bug. Something I was wondering about in the past, too. Your reply emphasizing indicates that there probably isn't a single "Boost-wide" process but that everything is in the hands of library maintainers, and that it differs from library to library. This is exactly my question. If it would be in the hands of the single
Hi maintainers to push their changes to release, this would be kind of unfortunate as this makes it hard to enforce any policy, e.g. "this type of bug is serious and can not be delayed" or "every library needs a 'development' and a 'bug fix' branch and the latter is always merged into release". I guess, right now, bug fixes can be delayed when there are other changes in development that still needs testing. Best, Oswin
On 3/19/2015 12:46 AM, oswin krause wrote:
Putting '[serialization]' as the start of the subject to your message has more chance of alerting the Boost developer of the serialization library to your issue. Also citing the actual bug report that has been fixed in serialization on the 'develop' branch would help to specify the actual case of which you are concerned.
I believe the core question was how could he (the poster) contribute to speed the things up. About the process, not so much about the particular library or the particular bug. Something I was wondering about in the past, too. Your reply emphasizing indicates that there probably isn't a single "Boost-wide" process but that everything is in the hands of library maintainers, and that it differs from library to library. This is exactly my question. If it would be in the hands of the single
Hi maintainers to push their changes to release, this would be kind of unfortunate as this makes it hard to enforce any policy, e.g. "this type of bug is serious and can not be delayed" or "every library needs a 'development' and a 'bug fix' branch and the latter is always merged into release". I guess, right now, bug fixes can be delayed when there are other changes in development that still needs testing.
A number of libraries are in the hands of more than one maintainer.
On 18 Mar 2015 at 15:40, oswin krause wrote:
Question is in the subject. What has to happen after a fix of a bug in development stage before it enters an official release?
Do not get me wrong, I like boost and all it does for the community and all the effort people put into it. And i really would like to help to speed up certain...processes, but for this i have to know what can block this step?
Apparently a bug in serialisation - which totally breaks my software to the point where it can not be compiled on several linux distributions und MacOsX since release of boost 1.56 - is fixed in development even prior to 1.57 and is still not available in 1.58. And what I hear from several mails across the mailing list, this is not the only change that got stuck. And somehow i have the feeling that the new boost release cycle won't make the situation any better.
If Robert is holding back a fix to Seralisation, I would be sure he has a very good reason to do so.
As I said, do not get me wrong, but this situation becomes unbearable as these boost versions spread more and more through the ecosystem and there is really nothing on my side I can do about it, except rolling my own implementation and maintaining it, until this whole thing is faded out of all major distributions(you might already get the feeling that I am not really happy about doing that).
if there is something i can do to help, I will do it. But I now know that "report bugs and investigate possible fixes and send patches" does not necessarily lead to a fast fix and i am pretty frustrated by the situation.
Most Boost libraries with active maintainers are pretty good about merging develop to master regularly. Those libraries without active maintainers I would personally avoid as you're always going to be fighting to find someone willing to merge fixes. A huge advantage of header only Boost libraries is you are free of dependency on the system provided version. Although you shouldn't do this, often you can get away with replacing a header only library locally with the latest, yet still link to the shared library dependencies of a much older Boost version. I should stress the "get away with" part of that statement. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
If Robert is holding back a fix to Seralisation, I would be sure he has a very good reason to do so. I trust him. However, in the ticket regarding the bug, he told me that it is fixed in development and that I could check out the development branch if I needed it very urgently. This was for me a "should be available in the next release" which was enough for me to not poke any further. But it is now 2 releases since then. If there were problems I would have liked to hear about it as I would have been willing to test and/or provide further patches. Most Boost libraries with active maintainers are pretty good about merging develop to master regularly. Those libraries without active maintainers I would personally avoid as you're always going to be fighting to find someone willing to merge fixes. Is there a list of libraries searching a new active maintainer? It does not really state in the official documentation which libraries to stay away from and i am not remembering people asking for some bug-fix
A huge advantage of header only Boost libraries is you are free of dependency on the system provided version. Although you shouldn't do this, often you can get away with replacing a header only library locally with the latest, yet still link to the shared library dependencies of a much older Boost version. I should stress the "get away with" part of that statement. I do not really want to run into ODR violations(and serialization is not
Hi, maintainers. I would certainly willing to clean up the bug-tracker of one of the libraries I use. On the other hand: i do not mind bugs in a library I just mind bugs in a library that just pop up after an update. header only). I was thinking about providing my own code for this file and just include it first, trying to diagnose if the "official" version was included first and bail out with an error if it was. But this is a) super messy b) prone to ODR violations and c) i have to maintain the fix for several years. The cleanest solution for a regression like this would be if the fix would be out and a patch would be available so that we can poke the distro maintainers to include it into their libboost-1.56/7/8.
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
Those libraries without active maintainers I would personally avoid as you're always going to be fighting to find someone willing to merge fixes.
Sounds like sage advice. As a Boost user, how do I know which is which? - Pat
On 19 Mar 2015 at 8:58, Patrick J. LoPresti wrote:
Those libraries without active maintainers I would personally avoid as you're always going to be fighting to find someone willing to merge fixes.
Sounds like sage advice. As a Boost user, how do I know which is which?
Check the release notes to see if the changelog hasn't mentioned the maintainer in many years. Ditto for the commit log. Another good sign is how old the oldest unfixed bugs on the issue tracker are. By those measures, perhaps as many as 20% of Boost libraries are looking unmaintained or poorly maintained. Symptom of maturity. If a maintainer formally resigns or is known to be no longer available, the CMT can take over the library. However, most orphaned libraries right now are still technically maintained by their named maintainer even if we haven't see the maintainer in many years. The problem as always is finding new maintainer willing to sacrifice themselves sufficiently to be a good library maintainer. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Oswin Krause wrote
Hi,
Question is in the subject. What has to happen after a fix of a bug in development stage before it enters an official release?
What has to happen is that I have to merge the serialization develop branch to the master branch. My procedure is: a) switch my local copy of the serialization library to master branch. b) merge in current develop branch c) update my local modular boost tree - which is always kept on the master branch d) (re)run all serialization library tests with clang and gcc compilers for DLL and static libraries and debug and release libraries. These combinations come to about 2000 tests which are presented in a giant table which has to come out all "green" This isn't really enough as it should include a couple of versions of VS but I don't have that around. In this particular instance, I had trouble with step c). This is not unusual as I have to confess the git submodule setup is pretty confusing and I don't do it all that frequently. When I finally managed to get this done, I found that the code that I use to review the results (tools/regression) has been removed from the master branch. Of course this was a surprise to me! Apparently I'm the only one that uses this code (not a huge surprise, I'm not sure why though). So now I have to remember how to get this thing built again and figure out where I'm going to keep it. So all in all this ends up taking a lot more time than one would expect. You might ask - why not just merge develop into master and watch the test results? I would answer that I've learned the hard way that taking a "shortcut" can lead to repercussions which such up lots, lots more time. Even investing the effort above, the bug that provokes this email still managed to creep in and was not detected by my tests. Note that all the above doesn't actually include the time finding reported bugs. These are pretty infrequent these days - but are often a major bitch to reproduce, find and fix. Often they are artifacts of standard library implementations which are very time consuming to track down. I hope that answer's your question. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/what-happens-between-fixed-in-development... Sent from the Boost - Users mailing list archive at Nabble.com.
On 19 Mar 2015 at 8:41, Robert Ramey wrote:
In this particular instance, I had trouble with step c). This is not unusual as I have to confess the git submodule setup is pretty confusing and I don't do it all that frequently. When I finally managed to get this done, I found that the code that I use to review the results (tools/regression) has been removed from the master branch. Of course this was a surprise to me! Apparently I'm the only one that uses this code (not a huge surprise, I'm not sure why though). So now I have to remember how to get this thing built again and figure out where I'm going to keep it.
So all in all this ends up taking a lot more time than one would expect.
I hear this. It cost me 200 hours to make a release of AFIO. That's six weeks of working till 5am night after night after your day job, with associated exhaustion, poor performance at work, and family irritation with you. Once per year for me I think, no more.
You might ask - why not just merge develop into master and watch the test results? I would answer that I've learned the hard way that taking a "shortcut" can lead to repercussions which such up lots, lots more time. Even investing the effort above, the bug that provokes this email still managed to creep in and was not detected by my tests.
Personally speaking, I'd do that exact merge straight after a Boost release. That gives you the time to find and fix any problems before the next release. In other words, develop lags master by one major Boost release. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote
On 19 Mar 2015 at 8:41, Robert Ramey wrote: Personally speaking, I'd do that exact merge straight after a Boost release. That gives you the time to find and fix any problems before the next release. In other words, develop lags master by one major Boost release.
My practice is to a) decide to address something - feature tweak like adding support for std smart pointers, fixing outstanding bugs or whatever. b) fix them in develop. This includes ancillary stuff like adjusting documentation c) run my test scenario as described above d) merge into master. I do this independent of the release schedule and do it is "smallish" chunks. This generally works pretty well and the serialization library on the master is of the state "no known fixable bugs". It does suck a lot of CPU time but that's free for me now. The problem comes when something "breaks". I might forget how to do something, the build system might have evolved, etc. Then I have to call some mental subroutine which takes a lot of time to get back on track. The risk of this happening dissuades me from doing this procedure more often. In this particular case, he release came up in the middle of my cycle. Having said this, the situation is still much, much better than it use to be. a) The git system is pretty friendly for making fixes on branches and merging them in. b) the git submodule system works pretty well for us. It permits me to leave all the rest of boost (that I depend upon but don't mess with) on the master branch while the stuff I'm working on is on develop. A great way to keep other's experiments from sawing the chair out from under me. c) C++ standard libraries and compilers are better saving time chasing stuff down there On the other hand boost build is still too fragile - it seems every time I want run it I have to do another troll of how the exact command line to use, or whatever. I found it easier to set up CMake for serialization and use that. But then of course i risk being surprised when I want to run boost build tests to be sure I'm still in sync. So much progress has been made. Still more to go. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/what-happens-between-fixed-in-development... Sent from the Boost - Users mailing list archive at Nabble.com.
On 19/03/2015 18:23, Robert Ramey wrote:
Niall Douglas wrote
On 19 Mar 2015 at 8:41, Robert Ramey wrote: Personally speaking, I'd do that exact merge straight after a Boost release. That gives you the time to find and fix any problems before the next release. In other words, develop lags master by one major Boost release.
My practice is to
a) decide to address something - feature tweak like adding support for std smart pointers, fixing outstanding bugs or whatever. b) fix them in develop. This includes ancillary stuff like adjusting documentation c) run my test scenario as described above d) merge into master.
I do this independent of the release schedule and do it is "smallish" chunks. This generally works pretty well and the serialization library on the master is of the state "no known fixable bugs". It does suck a lot of CPU time but that's free for me now. The problem comes when something "breaks". I might forget how to do something, the build system might have evolved, etc. Then I have to call some mental subroutine which takes a lot of time to get back on track. The risk of this happening dissuades me from doing this procedure more often. In this particular case, he release came up in the middle of my cycle.
I am just a boost user, not developer, and don't follow this list closely. Here are my 2 cents, I hope they are not completely off: What about making an upcoming release, e.g. 1.59, a "bug-fix" release only with the goal that all (or almost all) open issues get merged to master? No new features get added. If a library is stable (i.e. no open issues) leave it as it is (freeze it) and communicate that to other maintainers, so they can rely on a given version. Same for boost build and other tools, provide reference versions to rely on, no extensions. Give maintainers the time to get their issues fixed, do thorough testing etc. - if it takes half a year or longer, so it be, fine. As user I too find it increasingly difficult to overview the status and reliability of boost versions, and switching to a new release can make matters worse (for me as user) then sticking to a "working" previous release. On the other hand I think that I can understand the tremendous amount of effort and commitment required from library maintainers. And yes I know that things can break so unexpectedly and distract for ages from main aims (last time here: a VS extension installed broke the default configurations set by boost build, and that did take us a lot of time). So as user I feel the responsibility to not expect miracles or unrealistic things from maintainers. Note that my proposal aims at helping both users and maintainers: The former to get a hopefully stable release, and the latter to give them the time needed to make their developments and testing, without everything else in boost changing all the time. Thomas
On 20 Mar 2015 at 8:43, Thomas wrote:
I do this independent of the release schedule and do it is "smallish" chunks. This generally works pretty well and the serialization library on the master is of the state "no known fixable bugs". It does suck a lot of CPU time but that's free for me now. The problem comes when something "breaks". I might forget how to do something, the build system might have evolved, etc. Then I have to call some mental subroutine which takes a lot of time to get back on track. The risk of this happening dissuades me from doing this procedure more often. In this particular case, he release came up in the middle of my cycle.
I am just a boost user, not developer, and don't follow this list closely. Here are my 2 cents, I hope they are not completely off:
By sheer good fortune myself and Robert are the leads of the two most articulated schools of thought on the future of Boost. We disagree, though less than in the past. I think C++ Now may see us move closer again.
What about making an upcoming release, e.g. 1.59, a "bug-fix" release only with the goal that all (or almost all) open issues get merged to master? No new features get added. If a library is stable (i.e. no open issues) leave it as it is (freeze it) and communicate that to other maintainers, so they can rely on a given version. Same for boost build and other tools, provide reference versions to rely on, no extensions. Give maintainers the time to get their issues fixed, do thorough testing etc. - if it takes half a year or longer, so it be, fine.
As user I too find it increasingly difficult to overview the status and reliability of boost versions, and switching to a new release can make matters worse (for me as user) then sticking to a "working" previous release. On the other hand I think that I can understand the tremendous amount of effort and commitment required from library maintainers. And yes I know that things can break so unexpectedly and distract for ages from main aims (last time here: a VS extension installed broke the default configurations set by boost build, and that did take us a lot of time). So as user I feel the responsibility to not expect miracles or unrealistic things from maintainers.
Note that my proposal aims at helping both users and maintainers: The former to get a hopefully stable release, and the latter to give them the time needed to make their developments and testing, without everything else in boost changing all the time.
I'll answer this from my perspective on this. Robert may do so from his perspective. Since the economic crash around 2008-2009, commercially sponsored work on Boost has enormously dried up which forced some of the big names to leave for greener pastures (e.g. Boost Consulting wound up), plus we got hit with a double whammy of the C++ 11 STL providing much of Boost, thus eliminating the commercial need to sponsor Boost specifically fixes in Boost. I have managed to make an hourly paid living this past year from some very limited Boost related commercial sponsorship, but just recently they decided that C++ takes too long and are rewriting everything into Rust, so I suspect I'll have to leave Boost for greener pastures myself in six months or so. Anyway, from my perspective the big problem is funding, or lack thereof. It takes a lot of time and effort to fix bugs, and very few maintainers want to exchange their unpaid family time for fixing bugs when they could be doing interesting stuff instead. Don't get me wrong, I think the community has done a lousy job relative to other open source communities on the business side of things on constantly lobbying for and funnelling monies into Boost - we only gained a Donate facility last year, and it was I who made that happen, and it tooks months of effort. I also think we do a lousy job of creating incentives (Robert would call it blackmail) for commercial sponsorship of older libraries by routinely kicking anything not maintained out of the main distro so we regain a lean, slim and tightly focused Boost. I personally am aiming to fork Boost into a C++ 11 only 2.0, and indeed this C++ Now I'll present on tooling to help with that. Myself and Robert do agree though that users don't pay their fair share. They get high quality libraries, but don't pay a commensurate amount for that. Equally, many of them would *like* to pay for it, in particular they would *love* to pay for timely bug fixes. The Steering Committee has not smiled on those arguments though. And without community consensus, it's tough to create movement. I might add that Robert has his incubator http://rrsd.com/blincubator.com/ where I think he has a bug bounty system configured? I personally think the bug bounty system needs a monthly emailed scoreboard, with escrow for the bounties. Again though, that would need community consensus to make happen. There is a strong antipathy against making Boost into a viable business. Stemming from its origins, it's supposed to be about the pet "hero" library project, not making a living. Robert is speaking at C++ Now about the future of Boost, and I'll be there too. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote
Since the economic crash around 2008-2009, commercially sponsored work on Boost has enormously dried up which forced some of the big names to leave for greener pastures (e.g. Boost Consulting wound up), plus we got hit with a double whammy of the C++ 11 STL providing much of Boost, thus eliminating the commercial need to sponsor Boost specifically fixes in Boost.
My view is simpler. I believe that boost has been successful in it's original mission and needs to find a new / related one. I have my own agenda for this "new" mission and I work hard to promote it.
Myself and Robert do agree though that users don't pay their fair share.
LOL, I have no expectation that life is going to start being "fair".
They get high quality libraries, but don't pay a commensurate amount for that. Equally, many of them would *like* to pay for it, in particular they would *love* to pay for timely bug fixes.
But I am interested in finding a way to fund quality library development. And I to my my mind this line of thinking points in the right direction. I have some ideas - but they aren't well developed and I'm happy that others are thinking about it and making suggestions.
The Steering Committee has not smiled on those arguments though. And without community consensus, it's tough to create movement.
I don't think that a consensus is possible, but neither do I think it's a requirement. I don't think boost needs to have anything to do with funding library development/maintainence. In fact, for a number of reasons I think it's better if doesn't. This is still a wide open topic.
I might add that Robert has his incubator http://rrsd.com/blincubator.com/ where I think he has a bug bounty system configured? I personally think the bug bounty system needs a monthly emailed scoreboard, with escrow for the bounties. Again though, that would need community consensus to make happen.
I don't have such a "bounty" system configured. I'm not convinced that its the way to go. If you look at www.blincubator.com you can find the information regarding "library sponsorship". It isn't featured prominently as I have my hands full with other stuff and I'm not in a position to promote it. I'm also reluctant to dilute my current focus of getting the incubator "sold" as "the" way to get a library developed and reviewed. But I am interested in it.
There is a strong antipathy against making Boost into a viable business. Stemming from its origins, it's supposed to be about the pet "hero" library project, not making a living.
This is why I think that funding of library development has to occur outside of boost. Boost can maintain it's role of gatekeeper of software quality while permitting funding of libraries independent of boost. Certainly, some libraries have been funded this way - Gil .
Robert is speaking at C++ Now about the future of Boost, and I'll be there too.
Thanks for plugging my talk. It's 8:30 in the evening of the first day. I certainly hope that I get more than the 35 attendees I got the last time!. I've looked over the conference schedule. There are a number of presentations of varying lengths which touch related topics. It is my plan to preview the substance of my presentation with those other presenters in advance. This will give them the opportunity to contrast their ideas with my proposals if they so desire. This could be the most exciting Boost Conference yet !!! Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/what-happens-between-fixed-in-development... Sent from the Boost - Users mailing list archive at Nabble.com.
On 19.03.2015 16:41, Robert Ramey wrote:
Oswin Krause wrote
Hi,
Question is in the subject. What has to happen after a fix of a bug in development stage before it enters an official release? What has to happen is that I have to merge the serialization develop branch to the master branch. My procedure is: a) switch my local copy of the serialization library to master branch. b) merge in current develop branch c) update my local modular boost tree - which is always kept on the master branch d) (re)run all serialization library tests with clang and gcc compilers for DLL and static libraries and debug and release libraries. These combinations come to about 2000 tests which are presented in a giant table which has to come out all "green" This isn't really enough as it should include a couple of versions of VS but I don't have that around.
In this particular instance, I had trouble with step c). This is not unusual as I have to confess the git submodule setup is pretty confusing and I don't do it all that frequently. When I finally managed to get this done, I found that the code that I use to review the results (tools/regression) has been removed from the master branch. Of course this was a surprise to me! Apparently I'm the only one that uses this code (not a huge surprise, I'm not sure why though). So now I have to remember how to get this thing built again and figure out where I'm going to keep it.
So all in all this ends up taking a lot more time than one would expect.
You might ask - why not just merge develop into master and watch the test results? I would answer that I've learned the hard way that taking a "shortcut" can lead to repercussions which such up lots, lots more time. Even investing the effort above, the bug that provokes this email still managed to creep in and was not detected by my tests.
Note that all the above doesn't actually include the time finding reported bugs. These are pretty infrequent these days - but are often a major bitch to reproduce, find and fix. Often they are artifacts of standard library implementations which are very time consuming to track down.
I hope that answer's your question.
Robert Ramey Hi Robert,
Thank you for your reply. I am reading all replies and comments but right now I do not see that I can propose anything to help the current situation or to "relieve the burden", other then waiting patiently until this is done. In general it seems to be a bit problematic to actually help boost overall. Maintainers seem to have a very high workload (which only very few people would accept to do besides work) and there is not much one can do to help. Squashing bugs is one thing. If the merging and testing part takes 200h this is something i would not be able to do. So what do you guys think: is there something one can do with a reasonable workload ~20h/month to help the overall situation?
On 20 Mar 2015 at 14:45, oswin krause wrote:
So what do you guys think: is there something one can do with a reasonable workload ~20h/month to help the overall situation?
A big problem for a lot of Boost libraries is lack of issue verification, so when someone submits an issue you really could do with an independent third party to replicate it. That usually filters out a good 70% of reported issues, so it's very valuable. Any maintainer hugely appreciates it. Another useful thing to do is to configure a Jenkins CI or a Travis CI for a project which runs a useful subset of unit tests per commit. Since I added Thread to my Jenkins install, Vicente the maintainer - who won't use Windows - hasn't broken the Windows build on develop branch. A big help. Finally, for bug fixes or feature adds the no 1 biggest mistake contributers make is not clearing how best to fix or add the feature with the maintainer before writing any code. This cause is a big part of the 50% or 60% ignoring of patches and pull requests submitted. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
So what do you guys think: is there something one can do with a reasonable workload ~20h/month to help the overall situation?
Yes for sure: 1) focus: decide which parts of Boost you're interested in and largely stick to those. 2) Try to help the maintainer make the test suite bullet-proof. IMO the best maintained libraries are those with the most complete test coverage. Obviously it varies a bit how much this helps: things like thread, futures, or other things that hit the OS directly are likely to be the hardest to test empirically, which may be why Niall has had such a hard time! 3) Filter bug reports, try to reproduce, convert bug reports into PR's, with really good enhancements to the test suite to prevent recurrences. 4) Talk to the maintainer, find out what really needs doing, what the blockers are, how PR's can be structured so that accepting the patches is a no-brainer. 5) If a library has a lot of bug reports and/or PR's try to figure out why that is. OK no lib is perfect, but we should be aiming for as close to "zero maintenance" as we can get (excluding new features and/or modernizations). Is it lack of testing? A conceptual deficit? Poorly structured code that can't be maintained? Above all.... don't be scared to get stuck in! HTH, John.
participants (1)
-
Edward Diener -
John Maddock -
Leon Mlakar -
Niall Douglas -
oswin krause -
Patrick J. LoPresti -
Robert Ramey -
Thomas