[review queue] What to do about the library review queue?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
158 messages Options
12345 ... 8
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
On 14.03.2017 17:53, Robert Ramey via Boost wrote:
>
> "Only those who have managed a boost review can expect their library
> submissions to be to be reviewed."

The qualifications needed to write a boost-grade library and the
qualifications needed to manage a review aren't the same. I don't think
it's sensible to couple the two tasks in the suggested way.

But I'm still concerned that most of the replies to the OP are far too
short-sighted: While I can feel the pain of a developer waiting for a
review, I don't think anything can be done about this, on a strictly
administrative level.

I'd actually be curious to see how many of the existing Boost libraries
are actively being maintained or developed. Far too often a library
managed to get through the review process, only to be orphaned later on
because the original author has lost interest and or there wasn't enough
critical mass in the user/developer community to keep the project going.
In an ideal world, a library would start its life within an existing
community of users and developers, so finding reviewers (including
someone willing to manage the review process) shouldn't be hard.
In contrast, if a library is stalled in the review queue, perhaps that
hints at there not being enough interest to [use, develop, review] it ?
So who would be helped if the review process was accelerated artificially ?

What if the criteria for acceptance (into Boost) would be changed such
that an active user and developer community was a prerequisite, as a way
to predict the project's livelihood ? Again, this would work best if the
library would be much more autonomous, so there was much less
integration work required to bring a library on board. Boost wouldn't
subsequently have to care for maintenance of the library. If a given
library would be unmaintained for an extended period of time, it would
simply be removed from Boost.

No single person (or group of persons) would have to be responsible for
certain tasks involving all of Boost (including but not limited to:
building, testing, releasing), making the overall (umbrella)
organization much simpler to manage and contribute to.


        Stefan

--

      ...ich hab' noch einen Koffer in Berlin...


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
On 15/03/2017 12:00, Stefan Seefeld via Boost wrote:
> On 14.03.2017 17:53, Robert Ramey via Boost wrote:
>>
>> "Only those who have managed a boost review can expect their library
>> submissions to be to be reviewed."
>
> The qualifications needed to write a boost-grade library and the
> qualifications needed to manage a review aren't the same. I don't think
> it's sensible to couple the two tasks in the suggested way.

Perhaps I am wrong, but I think it's already coupled the other way
around: currently in order to be a review manager you must first have
submitted (or otherwise maintain) a successful Boost library.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 14/03/2017 à 23:41, Steven Watanabe via Boost a écrit :

> AMDG
>
> On 03/14/2017 04:26 PM, Glen Fernandes via Boost wrote:
>> On Tue, Mar 14, 2017 at 6:12 PM, Raffi Enficiaud wrote:
>>> I suggest another way of rewarding people:
>>>
>>> - If the review manager is a library maintainer: by the end of the review,
>>> he/she gets the help of the boost community (including the ppl whose code is
>>> being reviewed) to get his/her backlog cleared. This includes development,
>>> patches, backlog cleanup, as well as management/coordination of those devs.
>>>
>>> - if the review manager is the author of a library under review or freshly
>>> reviewed for acceptance to boost, but still not part of any release: he/she
>>> will get the help of the boost community
>>> to make that happen as soon as possible (including open pending issues from
>>> previous reviews, documentation, integration, migration to boost.build, etc
>>> etc)
>>>
>>> Of course, we can iterate further
>>> - for each good and sound review, you get one ticket of your backlog closed
>>> by next release
>>>
>>
>> These actually sound like excellent ideas to me.
>>
>
>   Yes, it sounds great to me too, but...
> who is volunteering to do this work?
> "The boost community will do it" is much
> to nebulous for a practical proposal.
>

Of course! I was suggesting another reward model, which apparently
triggers attention and might benefit to all by offloading work.

I do not have very specific solutions for that, but I believe we can
converge quickly to something that can be close to consensual.

========================
Just throwing ideas there:

A- case "one review -> one ticket closed":

   1- best case: some one volunteers, contacts the reviewer and ask how
he/she can help, and the reviewer discusses with him/her what can be
done next (I've done and also seen that)

   2- worst case: no volunteer: falls back to the library author ... or
the "boost community maintenance team". Community maintenance team may
for instance hire (with the boost real money) freelancers to do the job,
but will monitor the quality together with the reviewer.


B- case "review manager -> backlog cleared"

   1- best case: several ppl volunteer, ask the review manager what are
the priorities, and do the work. Integrate that backlog story into the
agenda of the release managers for the coming release. Rationale:
without putting that on release manager desk, the work may shift too
much. If this becomes a general concern for those who have stake on the
next release, then it will raise awareness.

   2- intermediate case: ask the last 3 library authors whose library
has already been integrated to boost for at least 2 releases (rationale:
people still around and having their library in a more steady state than
right after the first integration to boost). Can be a mix of B.1 and
B.2, to the demand of the release managers maybe?

   3- worst case: falls back to the library author :-) or the Community
maintenance team again (same potential solutions as A.1 above)

... and so on

========================

all in all, I think we can just make democracy speak about what are the
preferences and vote for a sound scheme.

It is always pleasing when ppl volunteer, but I also understand how
limited we are all in our time and energy. So using some money might
also be a solution (although can also be controversial or problematic:
we would not want to hire ppl participating in boost already for instance).

========================

Some design benefits of this model:

- no money involved in the review process: review cleared from any bias
or motivation other than making boost better
- money might be used only for improving the state of boost (closing
tickets via freelancers for instance)
- ppl start looking at how to improve other libraries, and get to
understand the code, reach and collaborate new ppl ... basically
improves the communication over the code, and leverage potential for
better collaboration (disclaimer: I am not saying that the collaboration
is bad), removes the frontier of the submodules, etc...

Best,
Raffi


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/15/17 00:53, Robert Ramey via Boost wrote:
> I propose the follwing text
> to be placed in the appropriate place.
>
> "Only those who have managed a boost review can expect their library
> submissions to be to be reviewed."

I think this is not a good idea. This puts a lot more pressure on the
library submitters, who already have to meet a quite high bar of quality
set by Boost. Besides, a review manager is expected to be an expert
(more or less) in the domain of the library being reviewed - something
we can't tell if it's true or not about a new person who have just
submitted his first library for a review.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/14/17 16:07, Gavin Lambert via Boost wrote:

> On 15/03/2017 12:00, Stefan Seefeld via Boost wrote:
>> On 14.03.2017 17:53, Robert Ramey via Boost wrote:
>>>
>>> "Only those who have managed a boost review can expect their library
>>> submissions to be to be reviewed."
>>
>> The qualifications needed to write a boost-grade library and the
>> qualifications needed to manage a review aren't the same. I don't think
>> it's sensible to couple the two tasks in the suggested way.
>
> Perhaps I am wrong, but I think it's already coupled the other way
> around: currently in order to be a review manager you must first have
> submitted (or otherwise maintain) a successful Boost library.
>
>

It isn't coupled. The requirement is here:
<http://www.boost.org/community/reviews.html#Review_Manager>


--
Michael Caisse
Ciere Consulting
ciere.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/14/17 15:35, Edward Diener via Boost wrote:
> On 3/14/2017 8:01 AM, Niall Douglas via Boost wrote:
>> Dear Boost,
>>
>> I see that new candidate Boost libraries entering the review queue have
>> exploded in recent years, with no less than *twenty-three* proposed
>> libraries awaiting a review.
>>

<snip prose about many things>

>
> I would like to concur that the number of libraries awaiting review,
> because no review manager has stepped forward for those libaries, is a
> real problem with Boost. I also do not believe that people should have
> to wait years for a review.
>

Don't forget that a library author needs to determine interest.
Sometimes (often?) there is no Review Manager listed because there isn't
enough interest by the community or hasn't been enough promotion by the
author.

A library sitting in the queue for long periods of time without a Review
Manager might be an indicator that the author hasn't done enough
solicitation on the ML or that other people don't find the solution
interesting.

I see 15 submissions in the "queue" without a manager:
<http://www.boost.org/community/review_schedule.html> .  There are 7
with managers. One-third have managers ... it could be better. My
experience is that reviews that have managers but are lacking dates are
still getting all the t's crossed and i's dotted. There isn't a
fundamental problem, instead it is how the system is supposed to work.
The review manager needs to make sure it is ready to be reviewed.

We have had back-to-back reviews for the past couple weeks. We have
reviews scheduled for the next few weeks. I know that we are having
trouble getting a date for Boost.SIMD that hasn't overlapped with
another request. I think it will be a busy year of reviews if it continues.

I have more (hopefully constructive) thoughts ... but I'll continue
those in another thread.

michael

--
Michael Caisse
Ciere Consulting
ciere.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 14 March 2017 at 15:53, Robert Ramey via Boost <[hidden email]>
wrote:

> "Only those who have managed a boost review can expect their library
> submissions to be to be reviewed."
>

And the corollary: "Only those who had their library submission accepted
are eligable to be a review manager."

<not related directly to the above post and rant>

I don't think that $1000 'reward' is going to make any difference, so I
think it's a bad idea (also for other reasons). The alternative rewards
(Raffi R.) seems to me to be right from 1969, woodstock like, and we all
know how that ended.

I think that, as somebody in this thread (below) hinted at, if it is so
hard to find a review manager (and/or people to write a review), one has to
question the usefullness of that particular submission even without looking
at the code. Some stuff is simply very satisfying on an intellectual level
(for those sufficiently involved), but not necessarilly usefull (or useable
in real life), or simply to complicated.

I've been following the review of safe numerics lib closely. What strikes
me is that some really fundamental criticisme comes up, the author himself
states things need to be re-thought, floats are no more than an
after-thought, the stated purpose of this library is ambiguous (I'm
paraphrasing RR here), and still, still, reviewers vote to get it accepted.
Why?

I also think that in order to improve the impact of Boost, certain
libraries should be retired (at least those which are now standardised).
(Bigger/More is not better, Niall) Some other stuff should really go,
because those libraries are really no longer of this time. I'm thinking
like BGL (the manual is a book!!!), multi-array (talk about clumsy) and
several others, so somebody has an opportunity and is given a challenge to
create something better. Also un-maintained libs are candidates for
scrapping.

Boost should be like the STL (no doublettes), but obviously wider and more
future oriented of course. Forget the backward compatibility (VC8, VC9,
VC10, seriously. Look at Microsoft's past and learn (as they did) from them
or look at Clang-4, it only compiles only with VS2015+, a deliberate
choice). If one uses (a) compiler(s) that (is)/are so ancient that it
doesn't come with std::array f.e., then it should be no problem to just use
an old version of boost either, particularly on windows I would say, as
using old compilers, means using old (and unsafe and unsupported)
libraries. I am of the opinion that on windows boost should only support
the compiler versions that are supported by Microsoft, then boost can move
along with Microsoft (and STL) to a better future.

What I also think is wrong is that in some areas there are multiple libs
doing (sort of) the same thing. I should be able to go to boost.org and
find THE template meta programming lib, not wade through (often terse)
documentation (like presenting the library interface as "Reference
Documentation", one of my favourites) of several libs and decide based on
"throwing up a dime", which one I would chose (otherwise it would involve a
mini review of sorts).

Robert Ramey gave a presentation (Cppcon15 (16?)) regarding the process
people go through picking a library. I though it was interesting, because
(at the time I did not know RR was the author of the serialization lib), I
went through this process and rejected his library for exactly the reasons
he pointed out in his presentation, picking cereal (
https://uscilab.github.io/cereal/index.html) in stead. A one page manual,
header only. I solved my problem 5 minutes later. I've never looked back.
BGL no!, the same, using lemon instead... (I like food apparently :-) )

<end rant>

degski

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
On 3/14/17 6:22 PM, degski via Boost wrote:
> On 14 March 2017 at 15:53, Robert Ramey via Boost <[hidden email]>
> wrote:
>
>> "Only those who have managed a boost review can expect their library
>> submissions to be to be reviewed."
>>
> And the corollary: "Only those who had their library submission accepted
> are eligable to be a review manager."

The second does not follow from the first.  It's not a corollary

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/14/17 4:00 PM, Stefan Seefeld via Boost wrote:
> On 14.03.2017 17:53, Robert Ramey via Boost wrote:
>>
>> "Only those who have managed a boost review can expect their library
>> submissions to be to be reviewed."
>
> The qualifications needed to write a boost-grade library and the
> qualifications needed to manage a review aren't the same. I don't think
> it's sensible to couple the two tasks in the suggested way.

If the qualifications aren't exactly the same they are pretty similar in
my view.

> What if the criteria for acceptance (into Boost) would be changed such
> that an active user and developer community was a prerequisite, as a way
> to predict the project's livelihood ? Again, this would work best if the
> library would be much more autonomous, so there was much less
> integration work required to bring a library on board. Boost wouldn't
> subsequently have to care for maintenance of the library. If a given
> library would be unmaintained for an extended period of time, it would
> simply be removed from Boost.

> No single person (or group of persons) would have to be responsible for
> certain tasks involving all of Boost (including but not limited to:
> building, testing, releasing), making the overall (umbrella)
> organization much simpler to manage and contribute to.

This has a lot of common with my vision for the boost library incubator.
It would create and opportunity for the library to create a following.
It would permit reviews to be gathered in advance of the review.  so
that the role of the review would be more routine.

To my disappointment it hasn't been successful in this regard.  That is
my motivation for promoting this idea.

Robert Ramey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/14/17 6:22 PM, degski via Boost wrote:
> On 14 March 2017 at 15:53, Robert Ramey via Boost <[hidden email]>

> I've been following the review of safe numerics lib closely. What strikes
> me is that some really fundamental criticisme comes up, the author himself
> states things need to be re-thought, floats are no more than an
> after-thought, the stated purpose of this library is ambiguous (I'm
> paraphrasing RR here), and still, still, reviewers vote to get it accepted.
> Why?

The reviewers with such reservations indicate that it should be accepted
subject to the indicated shortcomings be addressed before the library is
admitted into boost.  The majority of libraries accepted into boost are
done so under these kinds of conditions.  This is the way it has always
been.

A much more interesting question: Why did you not submit a review
yourself?  I think it would have been helpful to me as an author and to
you in better understanding your own concerns.

> Robert Ramey gave a presentation (Cppcon15 (16?)) regarding the process
> people go through picking a library. I though it was interesting, because
> (at the time I did not know RR was the author of the serialization lib), I
> went through this process and rejected his library for exactly the reasons
> he pointed out in his presentation,

LOL - so I guess the presentation useful to you.

> picking cereal (
> https://uscilab.github.io/cereal/index.html) in stead. A one page manual,
> header only. I solved my problem 5 minutes later. I've never looked back.

> BGL no!, the same, using lemon instead... (I like food apparently :-) )

I'm not sure I get the above - but it's likely off topic anyway.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
2017-03-14 23:12 GMT+01:00 Raffi Enficiaud via Boost <[hidden email]>
:

> Le 14/03/2017 à 13:01, Niall Douglas via Boost a écrit :
>
>> Dear Boost,
>>
>> [snip]
>>
>>
> This is an interesting topic, thanks for bringing it!
>
> I therefore ask boost-dev what to do? Some options:
>>
>> 1. Pay US$1000 (one thousand) dollars to each person who manages a
>> review. In case you're worried Boost doesn't have the money, it does in
>> spades, that's not a problem. For $23,000 we could clear the current
>> review queue assuming none of the problems mentioned yet.
>>
>
> I suggest another way of rewarding people:
>
> - If the review manager is a library maintainer: by the end of the review,
> he/she gets the help of the boost community (including the ppl whose code
> is being reviewed) to get his/her backlog cleared. This includes
> development, patches, backlog cleanup, as well as management/coordination
> of those devs.
>
> - if the review manager is the author of a library under review or freshly
> reviewed for acceptance to boost, but still not part of any release: he/she
> will get the help of the boost community
> to make that happen as soon as possible (including open pending issues
> from previous reviews, documentation, integration, migration to
> boost.build, etc etc)
>
> Of course, we can iterate further
> - for each good and sound review, you get one ticket of your backlog
> closed by next release
>
> ... etc etc ...
>
> I believe this is win/win/win for the health of boost, reviewers and new
> libraries.
>

I am not sure it can be made to work, but I find the idea really great.
Releave review managers from their other, less demanding tasks they already
do for community.

Regards,
&rzej;

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
2017-03-14 13:01 GMT+01:00 Niall Douglas via Boost <[hidden email]>:

> Dear Boost,
>
> I see that new candidate Boost libraries entering the review queue have
> exploded in recent years, with no less than *twenty-three* proposed
> libraries awaiting a review.
>
> As the ongoing strength and vitality of Boost is inextricably linked to
> new growth, I think that waiting around for years for someone to
> volunteer to manage a review is not healthy. If a library author has
> invested the very significant effort to develop a Boost-quality library,
> the least Boost can do is to try harder to provide timely reviews and
> that means persuading more people to volunteer to manage reviews.
>

Niall, it is good you are bringing this up. Only sending this message has
resulted in one library finding a review manager and the time slot.

But let me share a number of observations. Even if all the ideas for
motivating review managers work, and you have more people willing to manage
the review than the candidate libraries, there will still be one
bottleneck: only one library can be reviewed at a time. I personally find
it a good thing and would like to keep it this way.

Now, maybe this is just a coincidence, but we are just after the review of
safe_numerics, in two days the review of Stacktrace starts; the week after
it finishes, we have CallableTraits scheduled. There is also a good library
waiting for review: PolyCollection. It already has a review manager. It
looks like, at least for now, the schedule is full.

Actually, I have a question to Joaquín Mª López Muñoz and Ion Gaztañaga.
What does it mean that the library in the queue has a review manager, but
does not have any time slot scheduled?

Your library, Outcome, I suppose it will shortly find a review manager, as
it looks useful and needed.

On the other hand, I find it surprising that a library like Tick is not in
the review queue. I would expect that it would be very welcome by many.

Another thought. When I look at the review queue, and also at the libraries
listed in BLIncubator, my personal feeling is that some libraries do not
fit into Boost. This is just my impression, but it rises a question.

There is no bar for libraries to be requested for a formal review, without
a review manager. Also, authors for some libraries maybe just want to get
some useful feedback, and not necessarily get their library into Boost.
Maybe we need some additional stage. BLIncubator was designed to fill this
gap. Maybe it can still be made to work. Maybe people who feel something
need to be done in the review queue, should go through the list of
libraries in BLIncubator, and give their authors feedback.

Maybe, we should be doing some informal pre-reviews. Take one library from
the queue. Contact the author; check if he/she is still alive, and discuss
with him why they want the library into boost and why we don't (or do) like
it, and what we would rather expect.

Maybe this alone would make the process go more smoothly.

Regards,
&rzej;

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> I also think that in order to improve the impact of Boost, certain
> libraries should be retired (at least those which are now standardised).
> (Bigger/More is not better, Niall) Some other stuff should really go,
> because those libraries are really no longer of this time. I'm thinking
> like BGL (the manual is a book!!!), multi-array (talk about clumsy) and
> several others, so somebody has an opportunity and is given a challenge to
> create something better. Also un-maintained libs are candidates for
> scrapping.

You may not remember that I have one of the most aggressive opinions on
deprecation of anyone here. If I had my way:

* All undermaintained libraries (as defined by unclosed issues) stripped
from main distro at six months, with warnings each month privately,
warnings to the public from four months onwards. There are libraries in
the Boost main distro with open bug count nine years old. That's
unacceptable in any set of libraries claiming to have quality.
Last time I looked in detail (before the corporate sponsorship effort),
about half of Boost libraries had maintenance issues, but there was a
hardcore 20% that is damaging the Boost brand and those need to go.

* All legacy libraries removed from main distro into a "legacy" distro.
I am torn on libraries like SharedPtr, those are a tough call. I'd leave
it up to the maintainer to choose e.g. StringRef is clearly legacy,
StringView is not.

* All C++ 14 only libraries put into a Boost 2.0 distro.

* All libraries in the review queue put into a "Boost unreviewed" distro.

I reckon about fifty libraries would remain in the main distro. Much
more manageable and focused. And by "put into a distro", I do NOT mean
release management, I mean an automated script on a cronjob. No manual
quality control, that is kept only for the main distro.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 15/03/2017 08:22, Andrzej Krzemienski via Boost wrote:

>> I see that new candidate Boost libraries entering the review queue have
>> exploded in recent years, with no less than *twenty-three* proposed
>> libraries awaiting a review.
>>
>> As the ongoing strength and vitality of Boost is inextricably linked to
>> new growth, I think that waiting around for years for someone to
>> volunteer to manage a review is not healthy. If a library author has
>> invested the very significant effort to develop a Boost-quality library,
>> the least Boost can do is to try harder to provide timely reviews and
>> that means persuading more people to volunteer to manage reviews.
>>
>
> Niall, it is good you are bringing this up. Only sending this message has
> resulted in one library finding a review manager and the time slot.

In truth I was surprised myself when I went to the review queue to see
if Outcome had been added and it was suddenly a lot longer than it used
to be.

I should stress that *this is a good thing*. Tons of people want into
Boost and have invested very significant effort to get libraries ready
for review. It was so very different only recently.

> But let me share a number of observations. Even if all the ideas for
> motivating review managers work, and you have more people willing to manage
> the review than the candidate libraries, there will still be one
> bottleneck: only one library can be reviewed at a time. I personally find
> it a good thing and would like to keep it this way.
>
> Now, maybe this is just a coincidence, but we are just after the review of
> safe_numerics, in two days the review of Stacktrace starts; the week after
> it finishes, we have CallableTraits scheduled. There is also a good library
> waiting for review: PolyCollection. It already has a review manager. It
> looks like, at least for now, the schedule is full.

A very valid point, but I had already a solution in my proposal. As I
had mentioned, I reckon about a quarter of the queue could obviously
never pass a review due to at least one glaring deficiency e.g. totally
inappropriate naming conventions. If we could improve on the filtering
before libraries enter the review queue, we could cut down its size
considerably.

In a lot of cases, the authors of those libraries don't realise their
glaring mistake, and waiting around years - or forever - to realise
their mistake isn't welcoming.

> Your library, Outcome, I suppose it will shortly find a review manager, as
> it looks useful and needed.

I hope so. But equally the majority feedback on Reddit when Outcome was
announced as finished was "I don't see a point in this library nor any
reason it should enter Boost". Most of said commentators hadn't passed
the landing page, and just to tickle you a bit Andrzej, they found issue
with that little code example on the landing page. "What's the
difference over std::optional<T> they cried?"

> On the other hand, I find it surprising that a library like Tick is not in
> the review queue. I would expect that it would be very welcome by many.

I would assume he's working on it since the Fit review, and I vaguely
remember him saying that somebody else's work greatly changed his and he
was going to rebase it to use theirs or something.

> Maybe, we should be doing some informal pre-reviews. Take one library from
> the queue. Contact the author; check if he/she is still alive, and discuss
> with him why they want the library into boost and why we don't (or do) like
> it, and what we would rather expect.
>
> Maybe this alone would make the process go more smoothly.

I've done this in the past, but only when I know the library author.
That also comes with moral hazard and problems. It's basically a self
selecting elite helping each other out only.

The problem, as it has been in Boost for a long time now, is lack of
recognised authority. Who am I to tell a library author anything? Who
are you? Only the Steering Committee members have any recognised
authority, and they intentionally don't use it. You may remember my
attempt to create a living document of best practices, and that ended up
going nowhere.

There are, and remain, long standing problems with political leadership
of any kind. I have proposed elections of a political leadership to set
any direction for Boost with ring fenced budget and turning the Steering
Committee into a pure Board of Directors with budget approval only, but
the Steering Committee rejected it.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Edward Diener via Boost
> Sent: 14 March 2017 22:36
> To: [hidden email]
> Cc: Edward Diener
> Subject: Re: [boost] [review queue] What to do about the library review queue?
>
> On 3/14/2017 8:01 AM, Niall Douglas via Boost wrote:
> > Dear Boost,
> >
> > I see that new candidate Boost libraries entering the review queue have
> > exploded in recent years, with no less than *twenty-three* proposed
> > libraries awaiting a review.
> I am certainly not against paying programmers for valuable work, even if
> that "work" is managing a Boost review. I am afraid, however, that
> paying a review manager might mean that someone will take on the task
> who is not qualified for it simply because money is being offered.

+1

I'd offer to manage a review, but I rarely feel qualified (and usually then there are others much better qualified).  Money isn't
going to help with that :-(

Although I'm not against paying on 'moral' grounds if that would really help.  We could offer money, but be very careful about who
we give it to.

I still favor some halfway house, a bit like BLincubator (though I didn't like the way it works much), so stuff can be better tried
'in anger' by far more people or more platforms - and most important refined (especially documentation).

FWIW

Paul

PS I still do not favour gratuitously removing support for older compilers, but strongly support new libraries (or 'Son of ...' v2,
v3 updates) that *only* support the newer/newest compilers.  




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Mar 15, 2017 at 4:53 AM, Niall Douglas via Boost
<[hidden email]> wrote:
> There are libraries in
> the Boost main distro with open bug count nine years old. That's
> unacceptable in any set of libraries claiming to have quality.
> Last time I looked in detail (before the corporate sponsorship effort),
> about half of Boost libraries had maintenance issues, but there was a
> hardcore 20% that is damaging the Boost brand and those need to go.

I've been using Boost for years now and I didn't even know about these
libraries with maintenance issues. And knowing about those issues now
does not deter me from continuing to use Boost - I will simply avoid
the libraries with problems and continue to use the good ones. Can you
provide some evidence that this problem has "damaged" the Boost brand?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
degski wrote:

> Robert Ramey gave a presentation (Cppcon15 (16?)) regarding the process
> people go through picking a library. I though it was interesting, because
> (at the time I did not know RR was the author of the serialization lib), I
> went through this process and rejected his library for exactly the reasons
> he pointed out in his presentation, picking cereal
> (https://uscilab.github.io/cereal/index.html) in stead. A one page manual,
> header only. I solved my problem 5 minutes later. I've never looked back.

Cereal looks like a very competent rewrite of Serialization in C++11, minus
support for raw pointers plus support for shared_ptr from day one, which is
a big structural advantage. At the time Boost.Serialization was written,
support for raw pointers and arbitrary object graphs using new/delete was
all the rage. It didn't age well. boost::shared_ptr wasn't standard too,
just some ordinary user-defined type, much less important than raw pointers.
:-)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[partly OT] Re: [review queue] What to do about the library review queue?

peterkochlarsen
This post has NOT been accepted by the mailing list yet.
In reply to this post by Boost - Dev mailing list
as a (not unhappy) user of boost, let me sketch how I believe that boost could be improved. Much of it reflects the opinion of Niall.

For proposed submissions to boost, it would be nice to have a "boost candidates" download available. In order to be accepted as a boost candidate, there should be adequate documentation and at least a hint that the code is of a reasonable quality eg. fulfilling boost coding standards, having unit tests etc. A short mini review would be adequate - eg. write a notice in boost groups and hear the opinions of anyone interested. Shipping such a library should be subject to specific tests succeeding. They are "use at your own risk".

For existing libraries, a bug list should be readily available, preferably shipped with the download. As a user, looking at the issues list is one of the first things I do before considering using it. Many old bugs raise a red flag and makes me think twice. Also an unmaintained library should be marked as such as should libraries that are deprecated, replaced by standard C++ features (shared_ptr comes to mind) or otherwise showing their age (boost MPL, which was an excellent library but now really needs a replacement such as metal).

With regards to review of libraries, I am not opposed to getting paid for doing so. I believe it is a big job and requires quite a lot of skill. I myself do not have the expertise to perform a review on most libraries here and I doubt I have the skills to be the review-manager.

There are loads of good libraries out there and it would be nice if more could be incorporated into boost.

/Peter
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review queue] What to do about the library review queue?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 15/03/2017 11:19, Vinnie Falco via Boost wrote:

> On Wed, Mar 15, 2017 at 4:53 AM, Niall Douglas via Boost
> <[hidden email]> wrote:
>> There are libraries in
>> the Boost main distro with open bug count nine years old. That's
>> unacceptable in any set of libraries claiming to have quality.
>> Last time I looked in detail (before the corporate sponsorship effort),
>> about half of Boost libraries had maintenance issues, but there was a
>> hardcore 20% that is damaging the Boost brand and those need to go.
>
> I've been using Boost for years now and I didn't even know about these
> libraries with maintenance issues. And knowing about those issues now
> does not deter me from continuing to use Boost - I will simply avoid
> the libraries with problems and continue to use the good ones. Can you
> provide some evidence that this problem has "damaged" the Boost brand?

The poor folk who have locked themselves into the unmaintained
Boost.Iostreams generally come to regret it. Additionally it should
never have passed peer review, its design is fundamentally flawed.

There are increasing problems with Boost.ASIO as it gets ever further
away from ASIO.

Boost.Test before develop branch finally got merged to mainline was a
real problem. Lots of wasted time for a lot of folk over many years.

Some feel that the lack of cmake based build and test is a brand
damaging problem. I'm less convinced of that personally, but then I
generally only use the header only Boost libraries which don't suffer
from being misbuilt by package repo maintainers etc.

Some Boost libraries have muxed in support for the C++ 11 STL, others
have not. That is causing big problems for some Boost users. I'd
personally throw all the C++ 11 STL unhelpful libraries into deprecation
by this stage.

I'm not subscribed on stackoverflow to other Boost libraries, but as a
general rule, frustration and pain expressed there is a good indicator
of ongoing brand damage. Again, without an active policy making
political leadership, there is nobody to identify brand damage, and even
if identified, no means of addressing it. If we at least could segment
the bad libraries into a "bad Boost" distro, it would be a huge improvement.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [partly OT] Re: [review queue] What to do about the library review queue?

Glen Fernandes
In reply to this post by peterkochlarsen
peterkochlarsen wrote:
> Also an unmaintained library should be marked as such as should
> libraries that are deprecated, replaced by standard C++ features
> (shared_ptr comes to mind)

shared_ptr (or Boost.SmartPointers in general) is not unmaintained,
and is not deprecated.

It actually has been evolving past the C++11 std::shared_ptr.
For example, boost::shared_ptr supported array forms in 1.53 and this
was eventually added to C++ in C++17.

(Interesting aside: That functionality above was even, and still is
used, in certain Microsoft projects, where boost::shared_ptr is used
instead of std::shared_ptr).

The same goes for other Boost libraries like Boost.Thread. They:
- May have features not in the C++ standard library equivalent
- May be evolving past the current C++ standard
- Are in use by actual projects and shouldn't be removed

Glen
12345 ... 8
Loading...