Re: [boost] RFC: Community maintained libraries

Subject: Re: [boost] RFC: Community maintained libraries
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-12-07 21:12:52

On Dec 7, 2013, at 2:59 PM, "Niall Douglas" <s_sourceforge_at_[hidden]> wrote:

> On 6 Dec 2013 at 21:05, Rob Stewart wrote:
> 
>>>>> The traditional solution is forking of course, so those interested  enough fork a library and take it in new directions. Boost is 
>>>>> particularly fork unfriendly however - I don't believe anyone has  EVER seriously suggested forking any non-trivial chunk of Boost.
>>>> 
>>>> Signals2 is an excellent example of just such a thing. We also have cases like Lambda vs. Phoenix. 
>>> 
>>> That's evolution of a component, not forking which would involve  multiple libraries being taken in a new direction together.
>> 
>> You previously used the phrase, "those interested  enough fork a library", but when I challenge your point, you decide that forking
>> requires many libraries taken elsewhere? 
> 
> I'll copy and paste from 
> http://en.wikipedia.org/wiki/Fork_(software_development):
> 
> "The term often implies not merely a development branch, but a split  in the developer community, a form of schism"

That fits my example just fine. A second person thought Signals would be better if modified. The original maintainer didn't want to change it. Thus, a fork of Signals was created and we now have Signals2 alongside (the now-deprecated, IIRC) Signals.

> Forking isn't usually about software, it's about differences in the  philosophy behind the software.

Yep

[snip]

> Does this improve your understanding?

Thanks for all of that, but my "understanding" comment was WRT your "significant patches" commentary. (It's probably not productive to revisit that anyway.)

___
Rob

(Sent from my portable computation engine)