Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: David Abrahams (dave_at_[hidden])
Date: 2008-11-21 12:19:57

on Fri Nov 21 2008, "Tomas Puverle" <Tomas.Puverle-AT-morganstanley.com> wrote:

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of
> boost-request_at_[hidden]
> Sent: Thursday, November 20, 2008 5:42 PM
> To: boost_at_[hidden]
> Subject: Boost Digest, Vol 2373, Issue 4
>
>> Yes, this is an unfortunate situation.  If you indeed want to try to
>> make sure this kind of silent breakage doesn't happen again, there's
>> something you can do about it: write a page of library maintenance
>> guidelines on the wiki at http://svn.boost.org.  We are sorely
>> missing a policy on this, and when less-experienced library authors
>> come along, they often don't hew to the same standards that many of
>> us take for granted.  If you don't have write permission for the
>> wiki, please let us know and we'll send you an invitation.
>
> Hello Dave,
>  
> This is a good answer but not the one I was looking for.  

Naturally, nobody likes to be asked to fix the problem they're
complaining about.  Such is the open-source world, I'm afraid.

> It's a politician's answer, in that it doesn't really answer my
> original query.

Umm.  Trying not to be insulted, here.  

I disagree.

Your original query was not a "query" at all.  You asked no questions.
There was a list of (valid) complaints.  The only actionable item I saw
there (which you snipped out of the context of my quote) was the
expression of a laudable desire "to try to make sure this kind of silent
breakage doesn’t happen again," and *that* is what I responded to.

> Let me just put a few of my thoughts here:
>  
> What was described in my original email are bad practices in any
> project, not just boost.  
> Given that the boost developers are presented frequently as "the best",
> it isn't unreasonable
> to expect that they would understand that causing silent breakage (and
> the other points I made)
> is bad.  

Maybe not.  The truth is that not all of our developers can be "the
best."  Every time a library written by someone who doesn't already have
a library in Boost is accepted, we gain a new developer.  Of course, you
also have some power to control the quality of Boost developers, by
participating in the review process.

> It takes a lot of work for a library to get accepted and the library
> has to meet very high standards.  

Usually, I hope.  There have been a few libraries --- which shall remain
nameless --- that I didn't think met Boost standards when they were
accepted.  When I noticed that happening, I started to pay more
attention to the review process.

> However, it seems that once a library is accepted, the maintainer is
> pretty much free to do what they please.  

Yes.

> I think it may be wise to apply the same level of rigour to the
> continued development.  Do you think that a boost library that was
> broken should be rolled back?

Quite possibly.  Depends what you mean by "broken" and "rolled back."

> About the wiki: The desire to solve this problem has to come from
> within, not from without.  

I've got some bad news for you, Tom: you're "within."  The Boost
community is made up of more than just its volunteer developers, and
they don't have time to do everything.  I personally have the desire to
write up such a page, but not the time right now.

> Given how big some of the personalities are on this mailing list, do
> you think it's likely they would listen to someone who has not
> contributed a complete library to boost?

Yes, and so do you, or you wouldn't bother complaining about stability
here, where nobody would listen.  "Big personalities" have little to do
with it; Boost library authors generally highly value the input of their
users, and are eager to learn.  That's part of why they participate
here.

You may think you're being asked to set Boost policy on your own, but
that's not how it works.  Boost is driven largely by consensus.  We'll
discuss and tweak the document together in this forum until we can
arrive at a consensus that it should be adopted.

> Finally, I'd like to mention that within a large organisation, it's
> not possible to upgrade to the latest version of boost as soon as it
> comes out.

I know that well.

> The difficulty of rebuilding all of the internal systems just makes
> this impractical.  As you are aware, a lot of people avoid the .0
> releases.  What does this say to you?  

It says they are cautious.  Cautious people often have that as a blanket
policy; not just with Boost. What does it say to you?

> I understand (and applaud) boost's efforts to try to to eliminate this
> notion with tighter release cycles etc but the problem is that it's
> much harder to lose people's confidence than to regain it.

I think you mean the opposite.

> I like using boost and am very grateful to all the developers who make
> it happen.  Having said that, SNAFUs such as the current Boost.Range
> or the MT problem with Boost.Function in 1.34 threaten to make it
> irrelevant in "serious" development and relegate it to the position of
> a great "toy library" you can see how C++ standard compliant your
> compiler is.

I know; it's a problem.  If you still want to try to prevent this sort
of thing in the future, I suggest you take up my earlier encouragement
to write up a policy page.  

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com