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: Dave Abrahams (dave_at_[hidden])
Date: 2010-12-28 22:02:18

At Mon, 27 Dec 2010 23:30:20 -0600,
Rene Rivera wrote:
> 
> On 12/27/2010 8:49 AM, Dean Michael Berris wrote:
> > On Mon, Dec 27, 2010 at 12:17 PM, Rene Rivera<grafikrobot_at_[hidden]>  wrote:
> >> On 12/26/2010 8:31 AM, Dean Michael Berris wrote:
> >
> > Since the tools suggest and support a centralized development model,
> > how do you suggest you put in place an organization and process that
> > isn't centralized? This is not a rhetorical question, I really want to
> > know.
> 
> Well, I'd first ask if we want a decentralized organization and/or
> process. Or the question I really want to ask... Is a decentralized
> org and/or process have any advantages over the open Guild process
> we've been discussing?

The guild is a great idea.  We should definitely do it.  However, some
percentage of people will not want to be part of that structure.  The
question is, how seamless is the transition into being part of the
Guild, or part of Boost itself, when they decide to change?  Git makes
that work really well.  SVN, less so.  FWIW.

> > Are you seriously saying that you haven't seen any other workflow
> > besides the one that is already in place that will work for Boost?
> 
> No. I'm saying that the only way to know if a work-flow works is to
> try it (or some reasonable approximation to that). At worse, but
> optimal in effect, it means someone has to follow the new work-flow
> within Boost as a real-use case.

Yep.

> >> 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.
> >
> > Okay... So replacing Subversion with Git is going to be an issue
> > because... Git supports all the things that Subversion supports and is
> > a distributed version control system to boot? I don't see the logic in
> > that.
> 
> I never said it would be a problem to switch to Git. I did say no one
> has demonstrated it can be fully done. Say we switch to git.. How will
> a tester that doesn't have access to networking except for web, and
> possibly ftp, and more importantly doesn't have git on the testing
> machine, achieve pulling the sources and posting the results? 

Easy: github provides links that download tarballs :-)

> What extra requirements are there for testers, users, authors,
> review managers, release managers, etc. How does their jobs change?

Important questions.

> > but I think this is precisely the reason
> > why the Boost library development process isn't as community friendly
> > as the other open source projects are.
> 
> Perhaps, but it's also what's made it successful in other ways. So a
> key question is how to get more community involvement without throwing
> away the parts that work.

Yep.

> > Because there's this "I'll go
> > do it my way, and then show it to everyone when I'm done" attitude,
> > the opportunity for collaboration is lost except in the very end when
> > it's almost too late to make any changes.
> 
> It's closer to "We'll go do it our way, and then show it to everyone
> when we have something". But I think the start of the process is i
> minor part of the broken picture. The process of submission is as
> community driven as it can get. It's the process after acceptance and
> inclusion that is really broken at the moment.

+1

> > At any rate, I still look forward to a cooler way of seeing the
> > regression test results. :D
> 
> And I look forward to showing it.

+!

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com