Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years

Subject: Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-01-08 15:50:33

Stephen Kelly-2 wrote
> The most stark difference between Boost and KDE is that a KDE contributor 
> can push to all KDE repositories. The same is not true of Boost, and it is 
> designed that way. You write below it is a good thing. I don't agree. I 
> think there's a better middle ground to arrive at.

I DO believe that this is a good thing.  The problem is that many are
inclined to push
changes that don't consider all the users.  I have people suggest changes
which would up the requirement for the serialization library to C++11
which would freeze out a lot of current users with no functional benefit.
These "drive by" maintainers don't hang around for the consequences of
their changes leaving the original author with the task of finding and
fixing newly introduced bugs and problems.  Just letting anyone check
in changes would create a lot of work for current maintainers and 
discourage them from taking responsibility and pride in their work.  The
result would be a "dying" library which no one want's to take responsibility
for.

> That is also a contributor to why there are so many unmaintained libraries 
> in Boost. Far more libraries than are listed as the responsibility of the 
> CMT are actually unmaintained in reality - the dead pull requests and 
> desperate mails like
> 
>  http://thread.gmane.org/gmane.comp.lib.boost.devel/256063
>  http://thread.gmane.org/gmane.comp.lib.boost.devel/256571

I'm disputing there is a problem with orphaned libraries.  But just
letting anyone check in changes is not the solution.  Transfering
maintenance responsibility to another person is the only real
solution

>> It promotes conceptual integrity and
>> makes> for smaller, decoupled libraries.  
> 
> Decoupled? Erm, WAT?

de-coupled from either.  libraries which consist of better factored
code rather than a kitchen sink of features.

> That is definitely, simply, not a true description of Boost for many many 
> reasons.
> 
> Check your illusions :).
> 
>> One thing we do is that once a library
>> is accepted, it shuts the door to anyone proposing alternatives. 
> 
> There is definitely no consensus on this
>  http://thread.gmane.org/gmane.comp.lib.boost.devel/255318/focus=255359

Well, it's been mostly true.  We have limited library overlap.  state
chart/msm
geometry/? also come to mind.  But these are exceptions.  Mostly we
have functionality in only one library.  I think we need to loosen up this
a bit to promote better evolution.

> Another instance showing that there isn't generally cohesive opinion in 
> Boost. Maybe another effect of the lone-wolf design.

Boost does have, doesn't require and doesn't even encourage uniformity
of opinion - that's its strength.

>> If we had statistics on library usage, we could drop accepted
>> libraries from the "standard" distribution when they fall out of favor.
> 
> There are so many strong opinions opposed to that, you'd have to form 
> something of a community based on consensus before actually doing it.

I'm working on that - it takes a lot of time and effort.  But I firmly
believe
that we have move in this direction to keep from becoming obsolete.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/test-boost-test-owner-unresponsive-to-persistent-problems-for-multiple-years-tp4670242p4670808.html
Sent from the Boost - Dev mailing list archive at Nabble.com.