On 12/26/2010 8:31 AM, Dean Michael Berris wrote:
On Sun, Dec 19, 2010 at 12:43 AM, Lars Viklund<zao@acc.umu.se> wrote:
On Fri, Dec 17, 2010 at 9:34 PM, Lars Viklund<zao@acc.umu.se> wrote: On Fri, Dec 17, 2010 at 22:19, Dean Michael Berris <mikhailberis@gmail.com> wrote: Am 18.12.2010 09:47, schrieb Scott McMurray: The choice of whether the current system is sufficient is not made by some committee or some handful of users that get to decide whether the system is sufficient or otherwise.
Well, yes, and no.. Ultimately the choice is made by the Boost moderators and the people ponying up the server and personnel resources. They may be some consensus building on the dev list but AFAIR how to serve the Boost sources is not a "community" choice.
In the end, the version control you choose is rather tangential. As long as it's sufficiently competent (which Subversion in my eyes is), you'll survive.
I think you haven't been looking at -- or are ignoring -- the problems that Boost is already having when it comes to making the development effort more scalable.
I have mentioned in the past that the real problems Boost has, have nothing to do with the tools. But instead with the organization and process.
Of course, you may propose constructive criticism and suggest migration plans to other toolchains, with good arguments for why this is a good thing. See the mythical 'Ryppl' project, which aims to componentise Boost into a pile of Git repositories and some magical combination of scripts and CMake, aimed at letting you track exactly the versions of components you need.
Well, it's not mythical -- it's there, and the Boost Libraries have pretty much been broken up already. The CMake migration is taking a while and the only reason for that is there aren't enough help going into the CMake effort.
The fact that "there aren't enough people" to make a cmake version possible should be an indication that it should be reconsidered. If it's not possible for *one* person, working part time, to create and maintain the build system, it's already failed.
Remember that no tool is isolated. Changing from Subversion to <whatever> would result in many changes propagating to how test runners are set up, rewriting of commit hooks, modifying Trac (if possible) (although the SVN functionality is disabled there for now), requiring adaptation of any entity out there that use Boost's repositories in any way, including externals, build scripts, CI environments, etc.
Well, see, all these things you mention are really tangential to the issue of whether you're using Subversion or Git.
Trac can be (and I think, should be) abandoned for something that reflects better the workflow that Boost would want to encourage and that performs better on the machine that is available to it. If the solution is hosted for Boost then I would say it would be better. Migration is always going to be an issue, but it's a mechanical issue in reality. People just have to decide to do it, and then do it.
Well, that last past is your problem! It's not that people have to decide to do it.. It's that people have to demonstrate it's possible with actual use cases. For example the Cmake effort tried to make a build system equivalent to BBv2, and it did not entirely succeed in having the same features. The same applies to any system you might think of replacing. As a present example.. I'm working on replacing the test reporting system of Boost. But you don't see me trying to convince anyone a priory to switch to it or to devote resources to it. When I'm done with it, I'll show it to the community. And if I'm lucky I'll convince enough people that it's worth switching, shouldn't be hard in this domain though ;-) And the moderators, testers, and others devoting their personal resources will decide to switch.
The commit hooks can be ported (quite easily if I may say so myself): http://www.kernel.org/pub/software/scm/git/docs/githooks.html if there was really enough momentum towards getting Boost from Subversion to Git. The regression test runners could very well just change the commands they use in the script -- instead of checking out, you'd clone, and instead of updating, you'd pull.
All these things you mention are artificially made to look "hard" because it's all a matter of migration really. The "hard" part is accepting that there are better solutions out there already.
Awesome... Please show us a working Git+Trac (or equivalent flavor of software you are proposing) of Boost will all the history and trac tickets ported over, i.e. with a working migration plan, and I'll consider it. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail