[http] Boost.Http formal review is finished
The formal review of Boost.Http is finished, and I would like to thank all who participated. The following reviews have been recorded: - Antony Polukhin: No - Darren Cook: No - David Sankel: No - Lee Clagett: No - Niall Douglas: Yes, conditionally - Roland Bock: No - Tom Kent: No Please let me know if I have missed any. The final review results will be posted later.
On 8/17/15 2:08 AM, Bjorn Reese wrote:
The formal review of Boost.Http is finished, and I would like to thank all who participated.
The following reviews have been recorded:
- Antony Polukhin: No - Darren Cook: No - David Sankel: No - Lee Clagett: No - Niall Douglas: Yes, conditionally - Roland Bock: No - Tom Kent: No
Please let me know if I have missed any.
The final review results will be posted later.
I'm going to jump the gun a little and presume that this library will be rejected but I want to comment while the topic is still "hot". To me it's very unfortunate that so much effort has had to be expended by a library author to produce a library that is not accepted. It's also unfortunate that so many reviewers need to spend this much time to dig up enough information to reach this consensus. This illustrates my motivation behind the design of the boost library incubator. Imagine an alternate scenario. a) Vinicius submits his library to the incubator. He did this exactly as requested and fulfilled all the requirements listed in the incubator. I don't think he found the process onerous in anyway. So far so good. b) One person commented on his submission and Vinicius replied. So far so good. c) Now we come up with the review and only then do we get a really serious look at the library in all it's aspects. The criticism is constructive, but it's too late to change the submission. d) Had Vinicius gotten this feedback earlier, the submission would have been different or perhaps not even reviewed at all. e) Had people started to download the library, run the tests and try to use it in their own code a lot of information would have come out much earlier. This information would have been helpful to everyone involved. This didn't happen. Or at least, not that I know of. Neither the incubator nor github keep statistics on library downloads. I does keep statistics on views of the library page. These statistics can be displayed via the "Display Statistics" button on the library page. They show 701 pages views in the last 90 days. f) I notice that a couple of libraries submitted for formal review haven't submitted to the incubator. This concerns me as one of the motivations of the incubator was to make for information available and avoid a scenario whereby libraries "snuck though" the review process and ended up having some surprises which I was unhappy about. So I'm disappointed that the incubator hasn't really achieved what I hoped it would. On the upside, it doesn't require much maintenance so I'm inclined to keep it up. Occasionally I increment functionality when I see an easy/expedient way to do it. I'm also on the lookout for free/easy/clever ways to improve functionality. Robert Ramey
Robert wrote:
I notice that a couple of libraries submitted for formal review haven't submitted to the incubator. This concerns me as one of the motivations of the incubator was to make for information available and avoid a scenario whereby libraries "snuck though" the review process and ended up having some surprises which I was unhappy about.
Could you elaborate on your concerns? If a library is listed on the review schedule, has a link to source, has a link to documentation, and has had a mailing list thread requesting feedback: What information is not available to reviewers? Glen -- View this message in context: http://boost.2283326.n4.nabble.com/http-Boost-Http-formal-review-is-finished... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 8/17/15 9:55 AM, Glen Fernandes wrote:
Robert wrote:
I notice that a couple of libraries submitted for formal review haven't submitted to the incubator. This concerns me as one of the motivations of the incubator was to make for information available and avoid a scenario whereby libraries "snuck though" the review process and ended up having some surprises which I was unhappy about.
Could you elaborate on your concerns?
I don't follow all the reviews as closely as I'd like. But I do try to keep tabs on those which might impact me. In 2007 there was the review of Boost Exception which I didn't concern myself with as it never occurred to me that it would impact me in anyway. After a week, it had garnered two reviews. The review was extended another week. The final announcement didn't indicate how many reviews it had but I doubt it was more than two or three. So this get's folded into boost and it turns out it's redefining a fundamental boost configuration macro - I think BOOST_EXCEPTION which was used by the serialization library. This added - without my or anyone else's knowledge - many lines of new header code to the serialization library and a whole new dependency. There were/are a couple of other problems as well which are more subtle. I believe all this could have been avoided had the review process functioned better. This incident was main motivator for my making the boost library incubator. I've been hoping that we increase the number of reviews per library and certainly avoid the circumstance where a library alters the functionality of existing boost components after only 2 reviews! I believe there are other cases besides this one where there have been insufficient number of reviews - though none has had the impact that this one did.
If a library is listed on the review schedule, has a link to source, has a link to documentation, and has had a mailing list thread requesting feedback: What information is not available to reviewers?
well, not all libraries in the review queue have that information in a convenient manner. Consider the following libraries pending review a) Extended complex numbers - Sounds like it might be useful. But to check out the documentation and state of the package, one has to download the *.zip file, expand it, This does not encourage potential reviewers/users to inspect and comment on the package. b) Singularity - can't browse the documentation without downloading/cloning the package. It's been on the review queue for four years and so far as we know no one has even looked at it. But, all in all you're correct in that most of the information needed by reviewers is available. I guess my concern is that it's not always presented in a way which encourages users/potential reviewers to try the package and commend on them in advance of the formal review. It's that latter which I would like to encourage and think it would be helpful. Robert Ramey
On 17 Aug 2015 at 8:09, Robert Ramey wrote:
To me it's very unfortunate that so much effort has had to be expended by a library author to produce a library that is not accepted. It's also unfortunate that so many reviewers need to spend this much time to dig up enough information to reach this consensus. This illustrates my motivation behind the design of the boost library incubator. Imagine an alternate scenario.
a) Vinicius submits his library to the incubator. He did this exactly as requested and fulfilled all the requirements listed in the incubator. I don't think he found the process onerous in anyway. So far so good.
b) One person commented on his submission and Vinicius replied. So far so good.
c) Now we come up with the review and only then do we get a really serious look at the library in all it's aspects. The criticism is constructive, but it's too late to change the submission.
d) Had Vinicius gotten this feedback earlier, the submission would have been different or perhaps not even reviewed at all.
In fairness, Vinicius had substantial feedback privately sent to him long before the review by at least three people I know of (including myself). I explicitly did not post my feedback onto the incubator because I felt it was inappropriate given the development state of the library at that time. I think the Incubator is appropriate for libraries which have matured and are not undergoing continuing rapid development. Otherwise comments placed there are automatically out of date and misleading and could even been seen as an unwarranted permanent black mark uneraseable from Google. Personally speaking, I've always wished that after 500 github commits an Incubator comment would be deleted. I appreciate there is a fair bit of complexity implementing that automatically however.
e) Had people started to download the library, run the tests and try to use it in their own code a lot of information would have come out much earlier. This information would have been helpful to everyone involved. This didn't happen. Or at least, not that I know of. Neither the incubator nor github keep statistics on library downloads. I does keep statistics on views of the library page. These statistics can be displayed via the "Display Statistics" button on the library page. They show 701 pages views in the last 90 days.
I think no one uses a proposed Boost library really until it goes for review unless your name is Eric Niebler or someone equally famous, and even then I remember Eric telling me he reckoned no more than 50 people are really looking at Ranges in any depth. I think that's entirely the whole point of the Boost review really: expert eyeballs. FYI I know of about seven people who have ever even tried AFIO in 30 months. It's too niche, though when you see my brand new workshop tutorial with benchmarks on Friday I think that might radically change :). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 8/17/15 2:15 PM, Niall Douglas wrote:
On 17 Aug 2015 at 8:09, Robert Ramey wrote:
I think the Incubator is appropriate for libraries which have matured and are not undergoing continuing rapid development. Otherwise comments placed there are automatically out of date and misleading and could even been seen as an unwarranted permanent black mark uneraseable from Google.
Personally speaking, I've always wished that after 500 github commits an Incubator comment would be deleted. I appreciate there is a fair bit of complexity implementing that automatically however.
That would be a worthy suggestion. But until there is a large number of comments, it would be premature to find a way to implement it. I don't think it would be that hard to implement withing the current scheme.
e) Had people started to download the library, run the tests and try to use it in their own code a lot of information would have come out much earlier. This information would have been helpful to everyone involved. This didn't happen. Or at least, not that I know of. Neither the incubator nor github keep statistics on library downloads. I does keep statistics on views of the library page. These statistics can be displayed via the "Display Statistics" button on the library page. They show 701 pages views in the last 90 days.
I think no one uses a proposed Boost library really until it goes for review unless your name is Eric Niebler or someone equally famous,
Well, I can tell you that it happened a lot when making the serialization library. It's the one thing that kept me going after the library got rejected the first time. I think if the library fill a real known need and saves developers time, it will be downloaded. Again, I haven't found a way to add such statistics on this. Also I would very much like to see library usage statistics on current boost libraries as well. Our deployment scheme can't support this though.
and even then I remember Eric telling me he reckoned no more than 50 people are really looking at Ranges in any depth.
I think this is different. Eric, Louis, and others are offering a whole new way of doing things. Http, serialization, data_time, etc. address problems which people already have and need a solution for - usually in two hours!!! Of course boost has room for all kinds of stuff.
I think that's entirely the whole point of the Boost review really: expert eyeballs.
Agreed. I'm just trying to process more effective and expedient.
FYI I know of about seven people who have ever even tried AFIO in 30 months. It's too niche, though when you see my brand new workshop tutorial with benchmarks on Friday I think that might radically change :).
Maybe a year ago I went though the documentation of AFIO and wrote a comment based on that experience. I've seen that the package has improved enormously since then. I like to think that my comment made a small difference. (Incidently, I removed my old comment because I didn't think it was relevant any more.) I think I'm starting to get an idea of what problem the thing is supposed to address. Can't say for sure though - I'd have to spend more time on it. Based on this and the information above, I like to think that the incubator has been somewhat helpful in spite of the fact it hasn't realized all the aspirations I've had for it. Robert Ramey
On 17 Aug 2015 at 14:58, Robert Ramey wrote:
FYI I know of about seven people who have ever even tried AFIO in 30 months. It's too niche, though when you see my brand new workshop tutorial with benchmarks on Friday I think that might radically change :).
Maybe a year ago I went though the documentation of AFIO and wrote a comment based on that experience. I've seen that the package has improved enormously since then. I like to think that my comment made a small difference. (Incidently, I removed my old comment because I didn't think it was relevant any more.)
Your comment made more than a small difference in fact. It made me realise I'd need to implement a much more friendly user facing API. You are the Boost.Serialisation guy after all, if you're not lighting up with excitement then I'm doing something very wrong. I still don't have iostream serialisation support in AFIO, nor do I wish to add it (it's racy). However I have thrown serialisation folk a bone by making the new workshop tutorial iostreams based, so I show how to adapt AFIO to iostreams in a race free way.
I think I'm starting to get an idea of what problem the thing is supposed to address.
I'm hoping by the end of the new tutorial anyone reading will be convinced. I hope. We'll find out on Friday. I have the final step in the tutorial to finish before then, but otherwise it's ready. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 8/19/15 2:49 AM, Niall Douglas wrote:
On 17 Aug 2015 at 14:58, Robert Ramey wrote:
FYI I know of about seven people who have ever even tried AFIO in 30 months. It's too niche, though when you see my brand new workshop tutorial with benchmarks on Friday I think that might radically change :).
Maybe a year ago I went though the documentation of AFIO and wrote a comment based on that experience. I've seen that the package has improved enormously since then. I like to think that my comment made a small difference. (Incidently, I removed my old comment because I didn't think it was relevant any more.)
Your comment made more than a small difference in fact. It made me realise I'd need to implement a much more friendly user facing API. You are the Boost.Serialisation guy after all, if you're not lighting up with excitement then I'm doing something very wrong.
This is gratifying to me.
I still don't have iostream serialisation support in AFIO, nor do I wish to add it (it's racy). However I have thrown serialisation folk a bone by making the new workshop tutorial iostreams based, so I show how to adapt AFIO to iostreams in a race free way.
serialization is orthogonal to iostreams so I don't know if that's relevant. I would expect that some sort of support for iostreams would be almost a requirement.
I think I'm starting to get an idea of what problem the thing is supposed to address.
I'm hoping by the end of the new tutorial anyone reading will be convinced. I hope.
We'll find out on Friday. I have the final step in the tutorial to finish before then, but otherwise it's ready.
TL;DR I very much want you (and others of course as well) to be successful in your quest to get your library added to Boost. I believe that the http experience shows the wrong way to go about it. My personal experience with the serialization library was a tortured affair involving an initial rejection illustrates the promise and power of the Boost library review process. It was personally devastating to me to fail at this endeavor - but the rejection was correct as the first version of the library wasn't good enough. It's only due to a particular personality defect (pathological stubbornness) which resulted in me redoing the whole thing while incorporating all the feed back from the review. The rest is history - the library was accepted and eventually came to be probably one of the most commonly used boost libraries. Here is my advice - Do not do this. Get it right the first time. In order to spare others the disappointment, frustration, and huge amount of extra work, I was motivated to create the Boost library incubator. I've tried to summarize my experience in such a way as to help library authors be more successful. It's very hard to know whether or not it has been successful - the user feedback part has been a disappointment but its in large part done so we'll see. Here is my meta advice - Follow my advice at www.blincubator.com. It's meant to be almost a "form filling" exercise to create a boost quality library that will be accepted. In particular, a) spend more time and attention writing the documentation b) follow the documentation guidelines c) write, document and implement concepts d) write the documentation, code, and tests together There are two (at least) ways of thinking about creating a software library. a) It's a sub machine - like a starter motor for a car which can be included in any other car design. b) it's a mathematical proof. Given conditions a, b, c it will produce results x, y and z. The latter train of thought is more likely to be successful. This also casts a library as just an implementation of the ideas expressed in the documentation. As extraneous ideas are cast from the "proof" the library get's smaller - and paradoxically more useful. Less a bag of disparate features and more the manifestation of a clearly defined concept which can more easily composed. READ In particular, I do not want to see you (in particular) fail in this endeavor. To this end I will commit myself to reviewing and/or commenting on your library as soon as you tell me that you've made the changes you want to include and think it's ready. Hopefully, you'll find this useful in preparing for the review. You may or may not incorporate my observations, but at least you won't be caught with your pants down when it comes time for the review. Robert Ramey
On 8/17/2015 11:09 AM, Robert Ramey wrote:
On 8/17/15 2:08 AM, Bjorn Reese wrote:
The formal review of Boost.Http is finished, and I would like to thank all who participated.
The following reviews have been recorded:
- Antony Polukhin: No - Darren Cook: No - David Sankel: No - Lee Clagett: No - Niall Douglas: Yes, conditionally - Roland Bock: No - Tom Kent: No
Please let me know if I have missed any.
The final review results will be posted later.
I'm going to jump the gun a little and presume that this library will be rejected but I want to comment while the topic is still "hot".
To me it's very unfortunate that so much effort has had to be expended by a library author to produce a library that is not accepted. It's also unfortunate that so many reviewers need to spend this much time to dig up enough information to reach this consensus. This illustrates my motivation behind the design of the boost library incubator.
I think it is manifestly unfair to the author of the Boost.Http library to make these comments before a final review result has been made.
Imagine an alternate scenario.
a) Vinicius submits his library to the incubator. He did this exactly as requested and fulfilled all the requirements listed in the incubator. I don't think he found the process onerous in anyway. So far so good.
b) One person commented on his submission and Vinicius replied. So far so good.
c) Now we come up with the review and only then do we get a really serious look at the library in all it's aspects. The criticism is constructive, but it's too late to change the submission.
d) Had Vinicius gotten this feedback earlier, the submission would have been different or perhaps not even reviewed at all.
e) Had people started to download the library, run the tests and try to use it in their own code a lot of information would have come out much earlier. This information would have been helpful to everyone involved. This didn't happen. Or at least, not that I know of. Neither the incubator nor github keep statistics on library downloads. I does keep statistics on views of the library page. These statistics can be displayed via the "Display Statistics" button on the library page. They show 701 pages views in the last 90 days.
f) I notice that a couple of libraries submitted for formal review haven't submitted to the incubator. This concerns me as one of the motivations of the incubator was to make for information available and avoid a scenario whereby libraries "snuck though" the review process and ended up having some surprises which I was unhappy about.
So I'm disappointed that the incubator hasn't really achieved what I hoped it would. On the upside, it doesn't require much maintenance so I'm inclined to keep it up. Occasionally I increment functionality when I see an easy/expedient way to do it. I'm also on the lookout for free/easy/clever ways to improve functionality.
participants (5)
-
Bjorn Reese -
Edward Diener -
Glen Fernandes -
Niall Douglas -
Robert Ramey