Subject: Re: [boost] A bike shed (any colour will do) on greener grass...
From: Ahmed Charles (acharles_at_[hidden])
Date: 2013-10-30 22:16:02
> Date: Wed, 30 Oct 2013 13:41:56 -0700
> From: watanabesj_at_[hidden]
> To: boost_at_[hidden]
> Subject: Re: [boost] A bike shed (any colour will do) on greener grass...
> On 10/30/2013 06:07 AM, Ahmed Charles wrote:
> > Short of boost being forked by a group of energetic people interested in making massive changes, how exactly will it ever migrate to C++11/14 with the current ownership model where people have to contact ~100 library maintainers if they want to make changes across the entire project? If all I wanted to do was create a branch to work on C++11/14 work or anything like it, not only would it require touching ~100 git repos, I'd have to send ~100 emails and create ~100 trac tickets with patches and then manage ~100 different conversations with ~100 different people, across different countries, timezones, native languages, cultures, etc. How do you ever expect anyone to ever want to do that?
> Your scenario is completely unrealistic in the
> first place. No one can make these kinds of
> sweeping changes in one shot without making serious
> errors. It simply isn't possible to understand
> all of boost at once at the level of detail
> needed to make major modifications correctly.
Proving that something isn't possible is really hard. I didn't what the scope of the changes would be, it could be as simple as adding C++11 as the default configuration when building each library (which probably has an alternative implementation that doesn't require changing each library individually, but that's beside the point). The point is that the boost process doesn't scale to the size of boost currently and isn't likely to scale in the future for any changes that effect many libraries and that while the technical issues with scaling are difficult, the process (political) issues are the main blocker for more of this sort of work rather than the technical ones.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk