Is program_options unmaintained?
Hi, a couple of weeks ago, I reported a bug in the program_options library to the author, Vladimir Prus, but received no response. Then I tried reporting the problem on the boost-users mailing list, but didn't receive a response either. Since then, I've seen at least one other poster on the boost-users list wondering about this library, but did not receive a no response either. Does anyone still maintain the program_options library? More generally speaking, what is the procedure if it turns out that a Boost library *is* unmaintained? Take care, Peter
Peter Simons wrote:
Hi,
a couple of weeks ago, I reported a bug in the program_options library to the author, Vladimir Prus, but received no response. Then I tried reporting the problem on the boost-users mailing list, but didn't receive a response either. Since then, I've seen at least one other poster on the boost-users list wondering about this library, but did not receive a no response either.
The right procedure to report a bug is via svn.boost.org. Using boost-users mailing list might get you a fast response or might not, depending on luck. Reporting a bug via personal mail is suboptimal, in many way.
Does anyone still maintain the program_options library?
I do, but these days I can't guarantee specific response time for program_options questions. Putting bugs in svn.boost.org makes it somewhat more likely that they will be fixed. Patches, of course, are even better.
More generally speaking, what is the procedure if it turns out that a Boost library *is* unmaintained?
There is none, to the best of my knowledge. Do you want to become a maintainer? - Volodya
Hi Vladimir,
The right procedure to report a bug is via svn.boost.org.
Ticket #2613.
Does anyone still maintain the program_options library?
I do, but these days I can't guarantee specific response time for program_options questions.
With free software, there are generally no guarantees for anything -- the Boost license states that quite clearly --, so it would be foolish to expect free software authors to respond within specific time frames. Anyone who has that expectation should be willing to pay for those services. I'm not paying you, so I expect basically nothing. However, when a library is being actively maintained, it means that someone *is* fixing bugs that come up. It might not happen overnight, it might even take a few weeks, but eventually reported bugs are going to be fixed. That is what makes the difference between code that's being maintained and code that is not. I reported a bug twice, but received no response whatsoever. I have observed other people receive no response either, not even a mere "have no time right now, I'll look at it later". Given those circumstances, I don't think it was unreasonable of me to wonder whether the library is still being maintained.
More generally speaking, what is the procedure if it turns out that a Boost library *is* unmaintained?
There is none, to the best of my knowledge. Do you want to become a maintainer?
Why do you ask? Would you like to find a new maintainer for program_options? Merry Christmas, Peter
Peter Simons wrote:
Hi Vladimir,
The right procedure to report a bug is via svn.boost.org.
Ticket #2613.
Thanks, I've added some follow-up questions to that issue.
Does anyone still maintain the program_options library?
I do, but these days I can't guarantee specific response time for program_options questions.
With free software, there are generally no guarantees for anything -- the Boost license states that quite clearly --, so it would be foolish to expect free software authors to respond within specific time frames. Anyone who has that expectation should be willing to pay for those services. I'm not paying you, so I expect basically nothing.
However, when a library is being actively maintained, it means that someone *is* fixing bugs that come up. It might not happen overnight, it might even take a few weeks, but eventually reported bugs are going to be fixed. That is what makes the difference between code that's being maintained and code that is not.
There are different degrees of being maintained -- from "response is usually within a day" to "officially discontinued". I can agree that response time for program_options questions tend to significantly more than for, say, Boost.Build, and it follows that program_option is less maintained. But for all practical purposes, see below.
I reported a bug twice, but received no response whatsoever. I have observed other people receive no response either, not even a mere "have no time right now, I'll look at it later". Given those circumstances, I don't think it was unreasonable of me to wonder whether the library is still being maintained.
Well, upon looking at your original email in my inbox, other of the reasons I did not replied immediately is that your email does not clearly state what the bug is exactly -- see my comments to the issue.
More generally speaking, what is the procedure if it turns out that a Boost library *is* unmaintained?
There is none, to the best of my knowledge. Do you want to become a maintainer?
Why do you ask? Would you like to find a new maintainer for program_options?
Because while we can discuss at length whether the average historical response time falls in the range of "unmaintained", and what to do about it, the only thing that might make practical difference is somebody's help. - Volodya
Hi Vladimir,
Well, upon looking at your original email in my inbox, other of the reasons I did not replied immediately is that your email does not clearly state what the bug is exactly -- see my comments to the issue.
there is no reason whatsoever to justify how you spend your time. The program_options library is free software and I consider myself fortunate to be able to use this fine code. I have submitted an example program that produces the following output: | Supported options: | --help this is a sufficiently long text to requ | ire word-wrapping | --prefix arg (=/h/proj/tmp/dispatch) root path of the dispatch installation Personally, I like about program_options that it goes to great lengths to produce nicely formatted help texts for the user and I believe that the result could be even better if the message generated in the case above would be word-wrapped at white space rather than in the middle of a word. It's not a major problem, no doubt, but it would be nice to have that case improved. I would love to hack the code myself and to submit a patch, but unfortunately I cannot because I lack the time to do it. I'd find it to be awesome if it would turn out that you care so much about the library that you'll sit down in your spare time and do it. If you don't, however, I don't any right to complain and I won't. I wish you a merry Christmas, Peter
participants (2)
-
Peter Simons -
Vladimir Prus