Subject: [boost] Distributed Development Process (was Re: Development Practices (Proposal Progress))
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-18 13:03:56
On Thu, Jan 13, 2011 at 9:15 PM, Beman Dawes <bdawes_at_[hidden]> wrote:
> On Tue, Jan 11, 2011 at 10:36 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>> Create a new one... Â I don't think we want to tweak "the process." Â I
>> think we want to create an alternative process for people who are
>> interested in following a more modern, decoupled development model.
>> Eventually, if it works, the other one will die of underuse. Â The
>> thing is that you have to make sure that your proposal doesn't clash
>> with the way we do things now: for example, it can't create
>> significant new work for the release managers.
tl; dr; -- feedback on
would be very much appreciated!
> Excellent points!
> For example, I'd very much like to move both the libraries I maintain and my
> release management work to Git. I've been using it for a while now on
> various projects, including one very small (three contributors) distributed
> project, and find Git preferable by a wide margin. But others will want to
> stick with SVN at least for awhile. Because Git can track a Subversion
> repository, it is probably possible to use both without undue trouble.
I have the same experience -- and I've worked with larger teams that
have been using Git exclusively with wonderful results.
It's the difference between a concurrent lock-free queue and one that
has a critical section on all the member functions. One invites a lot
less friction and enables more fluid workflows while the other, not so
> While I'm leery of anything that would "create significant new work for the
> release managers" on an ongoing basis, I am willing to put in some extra
> work during a transition.
> Areas where I personally don't want any big changes yet are the Boost build
> and regression testing systems. Alternatives for either of these systems
> don't appear anywhere near ready for prime time WRT Boost.
Right, I haven't gotten thinking about that part yet, but I think
others are already working on that front. :)
> The formal review system needs a drastic rework to make it more parallel and
> remove bottlenecks, but I don't have anything beyond vague feelings about
> how to do that.
Yes and I intend to address that in this document:
I haven't gotten to the part on the specifics yet but I think it would
be good to get feedback on what's already there. :)
-- Dean Michael Berris about.me/deanberris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk