On Thu, Jan 13, 2011 at 9:15 PM, Beman Dawes <bdawes@acm.org> wrote:
On Tue, Jan 11, 2011 at 10:36 AM, Dave Abrahams <dave@boostpro.com> 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 https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess 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 much.
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.
Cool. :)
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: https://svn.boost.org/trac/boost/wiki/DistributedDevelopmentProcess 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