Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)

Subject: Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-27 23:45:58

2010/12/28 Bjørn Roald <bjorn_at_[hidden]>:
> On 12/27/2010 09:05 PM, Vladimir Prus wrote:
>>
>> Dean Michael Berris wrote:
>>
>>> 1. Move Boost away from Subversion and let's use Git instead -- have
>>> each library be a separate Git repository, follow the model that Qt
>>> and the Linux follow, and have the maintainers develop their libraries
>>> at their own pace. Release managers then pull from the different
>>> repositories and work along with a team to stabilize a release that is
>>> supported as the de-facto Boost release.
>>
>> So, instead of having each maintainer merge/push his changes to the
>> release branch when he feels like that, you suggest that release managers
>> ask maintainers of 70 (or is that 100 already) libraries what revision
>> can be pulled to the release?
>
> Actually, I think there are multiple models of using git that can allow
> integrators to automate this along with models that allows sharing the
> workload among multiple trusted integrators. Â However, this idea of pulling
> changes to integrate is mainly used to allow the release managers and
> integrators full control by preventing arbitrary pushes while they attempt
> to do work. Â In some projects and organizations this is perceived as
> important. Given a Boost migration to Git and the fact that Git can be used
> both with push and pull models, there is really no need to change current
> boost policy unless it helps in the release process.
>

True, but, if you don't change the policy and process (which is really
the reason why the project isn't scaling in a manner that is suitable
for "explosive" growth) then using a better tool only addresses part
of the problem.

Of course just changing to Git can be done easily without having to
change the policy and process -- as changing those usually take longer
than just porting an SVN repository to Git. ;)

-- 
Dean Michael Berris
about.me/deanberris