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: Rene Rivera (grafikrobot_at_[hidden])
Date: 2010-12-28 00:30:20

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?

>>> 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.
>
> Eh?
>
> 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.

>> 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? What extra 
requirements are there for testers, users, authors, review managers, 
release managers, etc. How does their jobs change?

Or maybe you've already mentioned all that, and I just missed it :-\

>> 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.
>
> Cool.
>
> Now though, imagine when you're done with replacing the test reporting
> system and instead of the community getting in what they think it
> should have and also be able to help out in the effort, you slave
> through that on your own and in the end other people think what you've
> done is insufficient.

No problem.. Wouldn't be the first time ;-)

> Because you've hidden this work from the
> community, you're not giving the community a chance to help you out
> even in a little way by looking at what you're trying to accomplish
> and maybe seeing things differently from your vision of the solution.

Practically what I've found out is that there's plenty of vision and no 
follow through.

> Maybe it's not your style,

In this case it's because I have ulterior motives outside of Boost. I.e. 
it's not an open-source project I'm working on.

> 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.

> 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.

> 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.

> It might just be me though thinking that Boost might benefit from
> greater community involvement and encouraging collaborative
> development over the current system. If that's the case, then I pretty
> much give up on that, maybe try much luck again at convincing people
> in the list to maybe give Git and JIRA a chance next year. ;)

It's not just you that's thinking about it, as evidence from the various 
community discussions recently. Just remember that you are dealing with 
a very skeptical, stubborn crowd here ;-)

-- 
-- 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