Ahmed Charles wrote:
AMDG
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, ...
If you're doing any kind of serious work, the time investment per library will dwarf the effort of filing a ticket and sending an e-mail. For it not to do so, the work needs to be either superficial or heavily automated. Even then, to be sure that the massive changes haven't broken anything, you'd need to run the entire test suite after each round of changes. This wouldn't be any fun, either. It doesn't even matter. The process is not as inflexible as you think. Filing a ticket and notifying the maintainer is a matter of courtesy and respect, it's not a requirement. If you're good enough so that your changes are entirely beneficial, nobody will object. But that doesn't matter, either. The process is emergent from the structure of Boost in which maintainers are responsible for their libraries. This means that if your massive changes introduce bugs in some library, it will be the maintainer of that library who will have to deal with the bug reports. This naturally tends to make (active) maintainers somewhat protective. This all works fairly well in practice, if your measure working by the actual results. Stephen Kelly's situation is unique and one-off, because of the impending transition to Git. Normally, we'd do things in our old-fashioned, non-energetic, inflexible way across a few releases without entering the news.