Shouldn't both logging proposals be reviewed in the same formal review?
According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue). It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost. Therefore, wouldn't it make sense to review both libraries in one (longer) formal review? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Andreas Huber wrote:
According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue).
It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost.
Therefore, wouldn't it make sense to review both libraries in one (longer) formal review?
Regards,
Andreas, Because the delay in starting library reviews is caused by the lack of review manager volunteers instead of the lack of time to hold reviews the order of reviews is determined by who has a manager and is ready to go. The order in the list (It really isn't a queue.) is determined by when the library is submitted for review. (New submissions go at the bottom.) So, don't read any significance into the position in the list. As for scheduling a joint review: That was tried with the Thread Pool libraries and I heard many comments from people who were not happy reviewing two at once and no one who was happy. This included the review manager, the library authors and some of the reviewers. So, I am not inclined to run two reviews at the same time unless someone has a very compelling explanation for why this time would be different. I have not spoken with Ron about this, so I don't know if his opinion is the same or different. John Phillips Review Wizard
John Phillips skrev:
As for scheduling a joint review: That was tried with the Thread Pool libraries and I heard many comments from people who were not happy reviewing two at once and no one who was happy. This included the review manager, the library authors and some of the reviewers. So, I am not inclined to run two reviews at the same time unless someone has a very compelling explanation for why this time would be different. I have not spoken with Ron about this, so I don't know if his opinion is the same or different.
Well, IMO having two seperate reviews of the same library is almost meaningless **if the two libraries are both ready at the same time**. IMO any review should include the comparison with *any* other library that tackles the same problem. That's the only way we can make sure that our new library has a very high quality. Any submitted library should include such a comparison done by the author, where he explains what he has done differently, and why his approach is better etc. Reviewers should strive to do the same, and see if they agree with the author. So please do "double" reviews whenever they occur. -Thorsten
"John Phillips" <phillips@mps.ohio-state.edu> wrote in message news:hdt4vf$ufm$1@ger.gmane.org...
As for scheduling a joint review: That was tried with the Thread Pool libraries and I heard many comments from people who were not happy reviewing two at once and no one who was happy. This included the review manager, the library authors and some of the reviewers.
Actually, I don't care much how the review periods are scheduled (lib1 first, lib2 first or joint), but I still think we should somehow ensure that we end up with at most one logging library. I don't see a better way than giving the reviewers only three choices (accept lib 1, accept lib 2, reject both) instead of four. For the unlikely case of a draw a special procedure could be put in place. Thoughts? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Am Tuesday 17 November 2009 20:32:22 schrieb Andreas Huber:
"John Phillips" <phillips@mps.ohio-state.edu> wrote in message news:hdt4vf$ufm$1@ger.gmane.org...
As for scheduling a joint review: That was tried with the Thread Pool libraries and I heard many comments from people who were not happy reviewing two at once and no one who was happy. This included the review manager, the library authors and some of the reviewers.
Actually, I don't care much how the review periods are scheduled (lib1 first, lib2 first or joint), but I still think we should somehow ensure that we end up with at most one logging library. I don't see a better way than giving the reviewers only three choices (accept lib 1, accept lib 2, reject both) instead of four. For the unlikely case of a draw a special procedure could be put in place.
Thoughts?
one review manager for both libraries, even if there are seperate review periods. as far as I know the review manager isn't bound to the "votes" anyway, so he should be able to summarize all the problems people see in either library and suggest a way to address those, be it by accepting one of the two libraries, merging them, or rejecting both.
Stefan Strasser wrote:
one review manager for both libraries, even if there are seperate review periods. as far as I know the review manager isn't bound to the "votes" anyway, so he should be able to summarize all the problems people see in either library and suggest a way to address those, be it by accepting one of the two libraries, merging them, or rejecting both.
+1. One review manager will surely do a better job than two different managers. But this should not be mandatory. We are lacking managers, and strict binding libraries with managers will make things worse.
On Mon, Nov 16, 2009 at 4:38 PM, Andreas Huber < ahd6974-spamboostorgtrap@yahoo.com> wrote:
According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue).
It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost.
Therefore, wouldn't it make sense to review both libraries in one (longer) formal review?
I definitely support this effort. I mean, how stupid would we feel if we review the first one, and then a little bit later we review the other one and find out it's a strict superset of the first, and also completely superior? Things like this need to be unquestionably prevented, regardless of the logistics that need to go into making it happen. I understand that a dual-review was tried before and nobody liked it. Instead of just concluding "therefore parallel reviews don't work", I think the conclusion should be "we need to address the concerns people had with parallel reviews at the time". also, i think it should be mandatory for each library author to review the other author's library. Zach
Zachary Turner <divisortheory <at> gmail.com> writes:
...
also, i think it should be mandatory for each library author to review the
other author's library.
1. I second that. It is only common sense and the usual practice that every suggestion comes with a comparison summary of what that suggested functionality introduces new or does better compared to the existing facilities. And surely the lib. authors are the best positioned to provide such summaries. 2. IMO we should avoid fragmentation (of the user base and dev. efforts) and inevitable confusion. Therefore, there should be only one boost::log library. Having two separate reviews puts those libraries on uneven footing which is unfair and detrimental to the ultimate outcome. 3. Does it *have* to be lib1 *or* lib2? In the end, we do not want lib1 or lib2 or lib3. Instead, we want the best and that is probably a joint effort and selective combination of all the above. Given the situation, would that be unrealistic to ask the respective authors to come up with a joint proposal? Would not that eliminate all timing and squabbling issues and ultimately deliver the best outcome to the community? Best, V.
2009/11/17 Vladimir Batov <vladimir.batov@wrsa.com.au>:
Given the situation, would that be unrealistic to ask the respective authors to come up with a joint proposal?
As they undoubtedly took different approaches, I think trying to ask them to pick one would be unreasonable. The review process ought to do a much better job with each evangelizing their preferred approach. It would be great if both authors collaborated on whatever combination or variation is eventually accepted, but I don't think we can force that, nor should we try to.
Scott McMurray <me22.ca+boost <at> gmail.com> writes:
As they undoubtedly took different approaches, I think trying to ask them to pick one would be unreasonable. The review process ought to do a much better job with each evangelizing their preferred approach.
Yes, I understand and unfortunately such a development is not that uncommon. I was just hoping it might be possible to raise above mine-vs-not-mine stand-off and to achieve something in collaboration rather than in an elimination fight. To me both approaches are not that different from the user perspective (I admit only glancing over the functionalities and interfaces) given that the functional set for a logging library is pretty well defined. Like sinks management, formatting management, hierarchical streams, etc. I believe both libraries are quite similar in that regard from the user perspective. Obviously, I can easily get this wrong. However, I suspect when the authors submit their comparison summaries, the functionality lists will be 90% overlapping.
It would be great if both authors collaborated on whatever combination or variation is eventually accepted, but I don't think we can force that, nor should we try to.
I never had any force in mind. I just do not like to see where the situation is developing and I was merely hoping that it could be resolved amicably and to greater common good. Best, V.
Vladimir Batov wrote:
Scott McMurray <me22.ca+boost <at> gmail.com> writes:
As they undoubtedly took different approaches, I think trying to ask them to pick one would be unreasonable. The review process ought to do a much better job with each evangelizing their preferred approach.
Yes, I understand and unfortunately such a development is not that uncommon. I was just hoping it might be possible to raise above mine-vs-not-mine stand-off and to achieve something in collaboration rather than in an elimination fight. To me both approaches are not that different from the user perspective (I admit only glancing over the functionalities and interfaces) given that the functional set for a logging library is pretty well defined. Like sinks management, formatting management, hierarchical streams, etc. I believe both libraries are quite similar in that regard from the user perspective. Obviously, I can easily get this wrong. However, I suspect when the authors submit their comparison summaries, the functionality lists will be 90% overlapping.
While from the user's perspective the libraries may look similar, the internal architecture may differ significantly. One wins in one case, the other wins in another case. Some features may just not fit well in the foreign library or just may not be needed. Therefore it's quite difficult to produce a combined solution. In such cases, given the two libraries satisfy the acception criteria, I think both libraries may be included into Boost.
Scott McMurray wrote:
2009/11/17 Vladimir Batov <vladimir.batov@wrsa.com.au>:
Given the situation, would that be unrealistic to ask the respective authors to come up with a joint proposal?
As they undoubtedly took different approaches, I think trying to ask them to pick one would be unreasonable. The review process ought to do a much better job with each evangelizing their preferred approach.
It would be great if both authors collaborated on whatever combination or variation is eventually accepted, but I don't think we can force that, nor should we try to.
Generally any time two or more developers suggest the same library on the list there is a quick suggestion that they try to work together and pound out one "better than either original choice" library. Sometimes the developers follow this suggestion, other times they don't. I too would prefer that they always do, but it doesn't happen. John
Vladimir Batov <vladimir.batov <at> wrsa.com.au> writes:
[...] there should be only one boost::log library.
I do not agree here. We have boost::bind, fusion::bind and lambda::bind AND proto (the solution to everything). We have regexp AND xpresive. We have several xml parsers (in serialization and in spirit). We have spirit1 and spirit2x. I used them all and of course I look forward to having one single library that fits all of my needs. But that is extra effort again. And logging *is* a big thing. So maybe we could deliberately choose to play country AND western this time (Sorry I could not help it: just enjoyed watching that movie on sunday again). Seriously: Sometimes it is hard to see which library wins. And as I proposed some years ago: What we definitely need is a ranking of libraries by quality vote. If both libraries fulfill the high quality measures of boost, let us include both and then see what the market says, probably also aiming at merging both over the years. Of course I'd prefer this to be done *before* inclusion. But for logging I'd propose to be realistic. Only after intensive use we will find all the odds. And: I'd prefer 2 boost libraries of the same kind over none.
Having two separate reviews puts those libraries on uneven footing which is unfair and detrimental to the ultimate outcome.
Agreed. Markus
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Markus Werle Sent: Wednesday, November 18, 2009 9:42 AM To: boost@lists.boost.org Subject: Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review?
Only after intensive use we will find all the odds.
+1 And have years of lots of users feedback to refinement/development.
And: I'd prefer 2 boost libraries of the same kind over none.
+1 Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Paul A. Bristow wrote:
Markus Werle wrote:
Only after intensive use we will find all the odds.
+1 +1
And have years of lots of users feedback to refinement/development.
And: I'd prefer 2 boost libraries of the same kind over none.
+1 +1
Knowing there are, or likely will be, multiple libraries for similar purposes, the documentation of each must clearly describe the purpose, applicability, goals, and relative merits. IOW, each such library must do an outstanding job of assisting potential users in choosing among the competitors. Given that information, if users prefer one over the others, then it is clearly the winner and then Boost must decide how to deprecate and eventually remove the losers. If users talk of blending features, then merging libraries -- or at least portions thereof -- should be considered by the authors/maintainers, which will also lead to deprecating and removing the other libraries. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Zachary Turner wrote:
On Mon, Nov 16, 2009 at 4:38 PM, Andreas Huber <
... I definitely support this effort. I mean, how stupid would we feel if we review the first one, and then a little bit later we review the other one and find out it's a strict superset of the first, and also completely superior? Things like this need to be unquestionably prevented, regardless of the logistics that need to go into making it happen. I understand that a dual-review was tried before and nobody liked it. Instead of just concluding "therefore parallel reviews don't work", I think the conclusion should be "we need to address the concerns people had with parallel reviews at the time".
also, i think it should be mandatory for each library author to review the other author's library.
Zach
I believe my statement was that I'm not inclined to do it unless someone can tell me why this time will be different. So, if you can explain what the process needs to be to make reviewing them together work well, I'm all ears. John
On Tue, Nov 17, 2009 at 10:45 PM, John Phillips <phillips@mps.ohio-state.edu
wrote:
Zachary Turner wrote:
On Mon, Nov 16, 2009 at 4:38 PM, Andreas Huber <
...
I definitely support this effort. I mean, how stupid would we feel if we review the first one, and then a little bit later we review the other one and find out it's a strict superset of the first, and also completely superior? Things like this need to be unquestionably prevented, regardless of the logistics that need to go into making it happen. I understand that a dual-review was tried before and nobody liked it. Instead of just concluding "therefore parallel reviews don't work", I think the conclusion should be "we need to address the concerns people had with parallel reviews at the time".
also, i think it should be mandatory for each library author to review the other author's library.
Zach
I believe my statement was that I'm not inclined to do it unless someone can tell me why this time will be different. So, if you can explain what the process needs to be to make reviewing them together work well, I'm all ears.
John
It's difficult to do that because I wasn't involved the last time such a review happened and it didn't go well, so I'm not in touch with all the issues. That being said, certainly each person needs to review the other person's library. Did that happen the first time a parallel review was attempted? Maybe it is just my naivete in not being familiar with the issues from last time, but I'm having a hard time understanding why doing a parallel review isn't hands down the obvious choice. Or rather, I'm having a hard time understanding why knowingly going into a review of a library with another very very very similar library only slightly further along in the review queue is even an option. I can't see any possible benefit to doing reviews this way, aside from "it's logistically easier than doing it the other way", and I also can't see any downsides to doing a parallel review, other than "it has some issues that need to be ironed out". On the other hand, the converse is definitely true -- that there are serious (and more importantly, long lasting) problems with not doing a parallel review. If Andrey's review is going to be first, and that's just the way it is, I can accept that -- but then delete the other library from the queue and just say there's no room for it at this time (assuming Andrey's gets accepted). How is the community served by having two virtually identical libraries? What if both of these libraries get accepted, and then 6 months later, I decide to submit YALL (yet another logging library) for review? Is it possible to have 3 logging libraries in boost? Where do we draw the line for "maximum number of virtually identical libraries allowed in boost"? Zach
Zachary Turner wrote:
On Tue, Nov 17, 2009 at 10:45 PM, John Phillips <phillips@mps.ohio-state.edu
wrote:
Zachary Turner wrote:
On Mon, Nov 16, 2009 at 4:38 PM, Andreas Huber <
...
... ...
It's difficult to do that because I wasn't involved the last time such a review happened and it didn't go well, so I'm not in touch with all the issues. That being said, certainly each person needs to review the other person's library. Did that happen the first time a parallel review was attempted?
The archives have the review process. Go take a look to get a better understanding. I also got a few off list mails about it, but they expressed the same problems as you'll see in the archives. The first problem is that the effort to review scales at least combinatorially in the number of libraries, and more likely in the number of submodules in the libraries. This is because the reviewer has to do five things. Understand how library 1 does a job, consider the strengths and weaknesses of that method, understand how library 2 does a job, consider the strengths and weaknesses of that method, and compare the relative strengths and weaknesses. If the library does several things, then the reviewer has to iterate on this process and finally produce some sort of overall ranking, along with reasons and hopefully suggestions for improvements. As a result, I don't recall a single person giving a full comparative review to both libraries. Most only had time to give a partial review to one library and didn't talk about the other at all. So, the review manager couldn't see what any one person thought about both libraries. Another problem is that the discussion threads get confusing. There are frequent switches between the two libraries, and it becomes hard to follow what comments are about what library, or in response to what previous statements. This could be solved by disciplined conversational patterns, but probably at the cost of lively discussion. There were more problems, but this should get you started.
Maybe it is just my naivete in not being familiar with the issues from last time, but I'm having a hard time understanding why doing a parallel review isn't hands down the obvious choice. Or rather, I'm having a hard time understanding why knowingly going into a review of a library with another very very very similar library only slightly further along in the review queue is even an option. I can't see any possible benefit to doing reviews this way, aside from "it's logistically easier than doing it the other way", and I also can't see any downsides to doing a parallel review, other than "it has some issues that need to be ironed out". On the other hand, the converse is definitely true -- that there are serious (and more importantly, long lasting) problems with not doing a parallel review.
Honestly, those of us who participated in the discussion that lead to the joint Futures review had the same opinion at the time. It seemed like a good idea, but when we actually did it we found it did not work well at all. So far, I have no good ideas for how to make it work better, but maybe someone else does. John
If Andrey's review is going to be first, and that's just the way it is, I can accept that -- but then delete the other library from the queue and just say there's no room for it at this time (assuming Andrey's gets accepted). How is the community served by having two virtually identical libraries? What if both of these libraries get accepted, and then 6 months later, I decide to submit YALL (yet another logging library) for review? Is it possible to have 3 logging libraries in boost? Where do we draw the line for "maximum number of virtually identical libraries allowed in boost"?
Zach _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Zachary Turner wrote:
also, i think it should be mandatory for each library author to review the other author's library.
I don't think this is a good idea. I participated John Torjo's library and despite the fact I tried to be as objective as I could I ended up comparing my library with John's. As you may imagine, my opinion was biased.
2009/11/19 Andrey Semashev <andrey.semashev@gmail.com>:
I don't think this is a good idea. I participated John Torjo's library and despite the fact I tried to be as objective as I could I ended up comparing my library with John's. As you may imagine, my opinion was biased.
I think intentionally-biased "this is why my way is better" notes from both authors would be a nice way of discussing the various trade-offs in the review.
Scott McMurray wrote:
2009/11/19 Andrey Semashev <andrey.semashev@gmail.com>:
I don't think this is a good idea. I participated John Torjo's library and despite the fact I tried to be as objective as I could I ended up comparing my library with John's. As you may imagine, my opinion was biased.
I think intentionally-biased "this is why my way is better" notes from both authors would be a nice way of discussing the various trade-offs in the review.
In that case both authors will most likely give negative reviews to the opponent's library. I know, review managers are not bound with votes, but it still counts in the final review report. I don't think it would be ethical of me to influence review results of my opponent.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: Thursday, November 19, 2009 6:50 PM To: boost@lists.boost.org Subject: Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review?
I don't think it would be ethical of me to influence review results of my opponent.
I disagree with this strongly - it would be unhelpful for BOTH you NOT to review the others library. (Just as review managers can, and should, make their own personal review as well as making a judgement reading all the other reviews). You are bound to have expert views and can point out pros and cons of the other library. We know who you are ;-) And we know when "you would say that" - so we can cope with any bias. But your view will still be informed. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Scott McMurray wrote:
2009/11/19 Andrey Semashev <andrey.semashev@gmail.com>:
I don't think this is a good idea. I participated John Torjo's library and despite the fact I tried to be as objective as I could I ended up comparing my library with John's. As you may imagine, my opinion was biased.
I think intentionally-biased "this is why my way is better" notes from both authors would be a nice way of discussing the various trade-offs in the review.
In that case both authors will most likely give negative reviews to the opponent's library. I know, review managers are not bound with votes, but it still counts in the final review report. I don't think it would be ethical of me to influence review results of my opponent.
I think, the attitude you are expressing should be respected. Formal reviews on the boost list can be quite tough, and although most library contributors, after years of hard work and dedication deserve nothing less
2009/11/19 Andrey Semashev <andrey.semashev@gmail.com> than appreciation, what they often get is a lot of critique (at a level most developers only dream of). If there are competing libraries, the situation is even harder. For the competing contributors, it is not only difficult to accept and to deal with critique and reject votes expressed by developers, they have also to deal with the difficulties and moral implications of judging their opponent. Rejection votes from the opponent not only can be hard to bear, they also may cause resentments between the competing authors, which IMO can be observed with Luke and Barent currently. This is a luxury the community should not afford because those guys are supposed to work together creatively instead of investing their brainpower in flame wars. I suggest, for the case of competing libraries, that the contributors are supposed to review the opponent's library but to refrain from voting. In their reviews, there should be a special emphasis on appreciation, learning form the others code and a perspective of possible future collaboration. Joachim
Joachim Faulhaber wrote:
I suggest, for the case of competing libraries, that the contributors are supposed to review the opponent's library but to refrain from voting.
+1 (I was already thinking the same.) If a competitor votes, the review manager should ignore it, of course. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Stewart, Robert wrote:
Joachim Faulhaber wrote:
I suggest, for the case of competing libraries, that the contributors are supposed to review the opponent's library but to refrain from voting.
+1 (I was already thinking the same.)
If a competitor votes, the review manager should ignore it, of course.
Agreed.
Joachim Faulhaber wrote:
I suggest, for the case of competing libraries, that the contributors are supposed to review the opponent's library but to refrain from voting.
+1 (I was already thinking the same.)
If a competitor votes, the review manager should ignore it, of course.
Why should the review manager ignore a YES vote of an author of a competing library? Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com
Hartmut Kaiser wrote:
Why should the review manager ignore a YES vote of an author of a competing library?
Because he shouldn't count votes in the first place when he tries to come to a decision? But I agree that the review results should state the number of YES and NO votes, and the vote of a competing author should clearly be included in this statistic, independent of whether it is YES or NO. Regards, Thomas
Hartmut Kaiser wrote:
Why should the review manager ignore a YES vote of an author of a competing library?
Because he shouldn't count votes in the first place when he tries to come to a decision?
It was not me suggesting the review manager should ignore the vote of a competing author. And if the OP has not meant this literally but merely in the sense of 'the review manager should ignore the opinion expressed by a competing author', then I repeat my question: why should a review manager ignore a positive (or for that matter a negative) opinion of a competing author? So the bottom line is: I don't think the review manager has any right to ignore any opinion expressed during the review whatsoever. But he has the responsibility to weigh any of the expressed opinions and to form a coherent decision based on what has been discussed.
But I agree that the review results should state the number of YES and NO votes,
Nobody expressed doubts wrt to this. What are you trying to say?
and the vote of a competing author should clearly be included in this statistic, independent of whether it is YES or NO.
I don't think votes of competing authors are less significant than others. Those usually have deep knowledge of the domain in question, so special treatment of those votes not only contradicts democratic principles, but also gives those votes a different significance. It all boils down again to the review manager's competence, not only his abilities to understand the domain, but also in his competence and maturity to correctly handle difficult - let me phrase it as - problems related to human interaction. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com
Hartmut Kaiser wrote:
...
It all boils down again to the review manager's competence, not only his abilities to understand the domain, but also in his competence and maturity to correctly handle difficult - let me phrase it as - problems related to human interaction.
Regards Hartmut
------------------- Meet me at BoostCon http://boostcon.com
I agree wholeheartedly. It is the most important consideration when deciding whether someone is well suited to managing a review. John
Hartmut Kaiser wrote:
It was not me suggesting the review manager should ignore the vote of a competing author.
You are right. Your question temped me to answer, but what I wanted to say was more related to the discussion in the thread itself than your concrete question. Hartmut Kaiser wrote:
But I agree that the review results should state the number of YES and NO votes,
Nobody expressed doubts wrt to this. What are you trying to say?
I'm trying to say that there are votes during the review process, and that they do have their function (among others they will be counted and stated in the review results), but the review process is something different than a public voting. To review a library means first of all to look at the library, its documentation, its code, its use cases, and to try to somehow write down what one has found during this process. Another function of the vote in this process is to encourage the reviewer to clearly take position with respect to the library he has reviewed. Regards, Thomas
On Thu, Nov 19, 2009 at 3:57 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com> wrote:
Joachim Faulhaber wrote:
I suggest, for the case of competing libraries, that the contributors are supposed to review the opponent's library but to refrain from voting.
+1 (I was already thinking the same.)
If a competitor votes, the review manager should ignore it, of course.
Why should the review manager ignore a YES vote of an author of a competing library?
Only because if that became the rule, it somewhat implies that NOT VOTING == a NO vote. Or at least suggests as much.
Regards Hartmut
------------------- Meet me at BoostCon http://boostcon.com
Tony --------- hope to see you there
And for my thoughts on reviewing the logging libraries, in general: - I didn't follow the other combined review closely - the plural of anecdote is not data (ie one case might not be enough to generalize from) - if we do separate the reviews this means: Review Lib A reject/approve/ask for changes/etc Review Lib B reject/approve/ask for changes/etc But since we, in this case, do know that somewhat similar (if at least by general topic of 'logging') libs are being proposed, then why not: Review Lib A comment/ask for changes/ etc Review Lib B comment/ask for changes/etc reject/approve A, B ie don't reject/approve A before reviewing B. Otherwise B seems to be at an unfair advantage. ie if B is significantly different (in scope, trade-offs, etc), then we can accept both. If there is significant overlap, then the feeling is "well B is fine, but we already have A..." ie separate reviews, single approval? Tony
Gottlob Frege wrote:
Review Lib A comment/ask for changes/ etc
Review Lib B comment/ask for changes/etc
reject/approve A, B
ie don't reject/approve A before reviewing B.
Lib A would be left in limbo for an indeterminate time, with this approach, which isn't particularly fair either. The assumption in this entire discussion is, of course, that no reviewer of Lib A knows of or considers Lib B when reviewing Lib A. It seems reasonable to dictate that a review manager alert potential reviewers to known competing library(ies) at the start of Lib A's review. Reviewers can then decide, quite independently, whether to examine the competing library(ies) when reviewing Lib A. If Lib B gives a reviewer a reason to dislike something that might otherwise have been thought not unacceptable in Lib A, that reviewer might then find fault with Lib A and vote against or conditionally for it. If a reviewer doesn't examine Lib B, then Lib A might be found worthy of acceptance despite reservations or some level of discomfort. Boost is about promoting C++ and library ideas, with an eye to improving or extending the language and standard library. If there are multiple libraries for the same purpose in Boost, then that implies that more discussion and design is necessary to find the right balance of features, power, and simplicity for a version to be in the next standard or to remain in Boost long term. Competition is good. Duplication isn't. I doubt we'll get much of the latter, but if so, that implies that merging competing libraries will be that much easier. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 11/20/09, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Gottlob Frege wrote:
Review Lib A comment/ask for changes/ etc
Review Lib B comment/ask for changes/etc
reject/approve A, B
ie don't reject/approve A before reviewing B.
Lib A would be left in limbo for an indeterminate time, with this approach, which isn't particularly fair either.
True, but there seems to be long time between acceptance (often conditional) and final submission anyhow. It would be nice of course for libB to be reviewed asap after libA. But I don't disagree with you overall. Just trying to offer suggestions.
Hartmut Kaiser wrote:
Joachim Faulhaber wrote:
I suggest, for the case of competing libraries, that the contributors are supposed to review the opponent's library but to refrain from voting.
+1 (I was already thinking the same.)
If a competitor votes, the review manager should ignore it, of course.
Why should the review manager ignore a YES vote of an author of a competing library?
Your question gave me pause, but I stand by my assertion. A competitor will be biased against the competition, so will typically be more negative than an objective reviewer. Hence, a no vote must be discounted on that basis. Knowing that, however, a fair competitor may be inclined to vote yes or tip the scale unduly in favor of the competing library to avoid the appearance of being unfair or biased, rather than because the competing library deserves to be accepted. A vote either way, from a competitor, is uncertain and should be discounted relative to purportedly unbiased reviews from those not authoring a library under review. We have said that competitors should be required to submit a review because of their domain knowledge and because of the comparative judgments it is likely to contain. The review manager can use the information from such reviews to assist in deciding among the submissions. Any voting, however, is not trustworthy. Note that the foregoing in no way necessitates simultaneous reviews, but should apply when competing libraries are in the review queue. If a potential competitor has yet to submit a library for review, then the foregoing doesn't apply, though it would be appropriate for that reviewer to disclose their own competing efforts. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Joachim Faulhaber wrote:
... I suggest, for the case of competing libraries, that the contributors are supposed to review the opponent's library but to refrain from voting.
I disagree. The standard I prefer is full disclosure and trust the manager. If there is some reason why special consideration should be given to your review, make that clear. This is true whether you believe that consideration should be positive or negative. Then, write the best review you can. We try hard to make sure our managers are intelligent and suited to the task. I trust them to weigh your concerns and complements appropriately as long as they know any special circumstances. John
In their reviews, there should be a special emphasis on appreciation, learning form the others code and a perspective of possible future collaboration.
Joachim _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andreas Huber wrote:
According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue).
It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost.
Therefore, wouldn't it make sense to review both libraries in one (longer) formal review?
I think reviewing both at the same time is very desirable. At present, I don't have an opinion whether both, only one, or neither should be accepted, but it's seems unlikely that the right decision can be made while looking at a single library, and pretending the other one does not exist. - Volodya
Vladimir Prus wrote:
I think reviewing both at the same time is very desirable. At present, I don't have an opinion whether both, only one, or neither should be accepted, but it's seems unlikely that the right decision can be made while looking at a single library, and pretending the other one does not exist.
What if one library appears later in the queue and the author was counting on the extra time to prepare? What if another library is rushed in order to join the fray? That library will surely fare poorly, but might have proven better in the long run. What if another library appears months later that is clearly better? Can it be added to Boost? Just because two libraries aren't reviewed together doesn't mean the other issues resulting from multiple, similar libraries, won't arise. Having said that, and not recalling any of the parallel review issues that make the Wizards reticent today, I can understand your interest in reviewing both as a means to head off two libraries being in Boost when one might be clearly superior. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Mon, 16 Nov 2009 23:38:54 +0100, Andreas Huber <ahd6974-spamboostorgtrap@yahoo.com> wrote:
According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue).
It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost.
Therefore, wouldn't it make sense to review both libraries in one (longer) formal review?
I don't know if it makes any sense at all to review John's library. According to http://torjo.com/log2/doc/html/index.html it hasn't been updated for one and a half years while Andrey is actively working on his library (for how long has the library be in the queue?). I've been following the development of both libraries and admit that I also prefer Andrey's (I used John's before I switched to Andrey's). But John's library looks abandoned anyway? Boris PS: Actually John's entire website looks abandoned - is he still around here?
On Wed, Nov 18, 2009 at 4:12 AM, Boris Schaeling <boris@highscore.de> wrote:
On Mon, 16 Nov 2009 23:38:54 +0100, Andreas Huber < ahd6974-spamboostorgtrap@yahoo.com> wrote:
According to the schedule, John Torjo's Log2 library will be reviewed soon
(currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue).
It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost.
Therefore, wouldn't it make sense to review both libraries in one (longer) formal review?
I don't know if it makes any sense at all to review John's library. According to http://torjo.com/log2/doc/html/index.html it hasn't been updated for one and a half years while Andrey is actively working on his library (for how long has the library be in the queue?). I've been following the development of both libraries and admit that I also prefer Andrey's (I used John's before I switched to Andrey's). But John's library looks abandoned anyway?
Boris
PS: Actually John's entire website looks abandoned - is he still around here?
If this is the case (as hinted to by another poster later in the therad as well, who mentions that the library is exactly the same as when it was first submitted), then I see no reason to review it at all, and then this becomes a moot discussion. Assuming all that info is correct and John is no longer around, then I would only support reviewing this library if Andrey's is rejected.
Hi, Andreas Huber-3 wrote:
According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue).
It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost.
Therefore, wouldn't it make sense to review both libraries in one (longer) formal review?
Regards,
-- Andreas Huber
When replying by private email, please remove the words spam and trap from the address shown in the header.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AFAIK, even if we have a review manager for the review of the John Torjo's library, the library has not been changed since it was rejected. I have never understood why it is on the review schedule. Anyway, I think that we should review a library as soon as the review manager and the author have found a date. Of course compare other libraries covering the same domain are welcome at the functional and performance level. Best, Vicente -- View this message in context: http://old.nabble.com/Shouldn%27t-both-logging-proposals-be-reviewed-in-the-... Sent from the Boost - Dev mailing list archive at Nabble.com.
Andreas Huber <ahd6974-spamboostorgtrap <at> yahoo.com> writes:
It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost.
Therefore, wouldn't it make sense to review both libraries in one (longer) formal review?
How many libraries have passed review and never merged to a boost release? After a library is accepted, it can be YEARS (if ever) before a library is in shape to be merged. Having two libraries with different approaches to different but overlapping portions of the logging problem space in the review process can only be a good thing. Don't combine the reviews.
Andreas Huber wrote:
According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue).
It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost.
Therefore, wouldn't it make sense to review both libraries in one (longer) formal review?
Hi, It's a shame I'm joining the discussion at this late stage. I'll try to post my answers as original posts came. First, I'm not against a dual review. Actually, some time ago I thought it would be a good idea. However, I recognize that the undertaking for the reviewers would double at least, so I fear that the quality of such review would suffer. Potential reviewers may actually be pushed away by the amount of work they would have to do, and I must say, my lib is already quite scaled by itself. John's experience that he expressed later in this thread seems to confirm it. On the other hand, if we have two candidates, it would be strange not to compare them between each other, at least in some informal way. I don't have a general solution to this dilemma, but in case of logging we have users that have had experience with both libraries. I would be most grateful if they participated the review, whatever form the review may take. Second, regarding the "duplicate" libraries in Boost. My opinion is that we should avoid duplicates as much as reasonable. There are cases in Boost when one library is a superset over the other, in terms of features. I think, such duplications don't give much benefit to the users and should not be encouraged. However, there are cases when one library does something significantly better, while this particular feature cannot be equivalently improved in its analogues. In this case the library has a right to live side by side with other implementations. The point of the review (or separate reviews) is to detect how much overlap there is between the libraries and if there are applications where one library performs significantly better than others. If library A has its unique killer features that cannot be imported in library B (which may be in review queue or in Boost already) then I don't see why it should not be accepted.
participants (19)
-
Andreas Huber -
Andrey Semashev -
Boris Schaeling -
Gottlob Frege -
Hartmut Kaiser -
Joachim Faulhaber -
Joel -
John Phillips -
Markus Werle -
Paul A. Bristow -
Scott McMurray -
Stefan Strasser -
Stewart, Robert -
Thomas Klimpel -
Thorsten Ottosen -
Vicente Botet Escriba -
Vladimir Batov -
Vladimir Prus -
Zachary Turner