incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: fetch-all-cws.sh (was: Building a single Hg repository)
Date Wed, 06 Jul 2011 22:19:59 GMT
On Wed, Jul 6, 2011 at 5:59 PM, Mathias Bauer <Mathias_Bauer@gmx.net> wrote:
> On 06.07.2011 18:58, Greg Stein wrote:
>
>> The development process that OOo used to use, as I understand it,
>> looks incredibly heavyweight and slow moving. At Apache, you commit
>> your changes. If you have a large-ish feature you're unsure about,
>> then discuss it on the mailing list, and (maybe) go start a branch. In
>> many cases, it is possibly to develop even large features on trunk
>> because you can "hide" it or make it have near-zero impact on the main
>> trunk code.
>
> There's always a trade-off. I agree that for many code changes the
> development process of OOo was just too heavy. But OTOH it is a well
> known fact that bugs are best found as early as possible. In a large and
> complex code base with a lot of parallel work it happens too easy that
> ugly bugs slip in and cause a lot of trouble for other developers or
> even for users. Fixing them much later, when more code has been added
> and the developer already has moved his mind to something else is much
> more complicated. So a balance is necessary.
>

And different approaches might be used in different parts of the
cycle, or on different parts of the project.  For example, we might
declare a Commit-Then-Review policy except after beta, when we turn to
Review-Then-Commit.  Or we might be C-T-R for all documentation files
at all times (since they are trivial to review via diff's) while R-T-C
is always the policy for a specific list of shared modules, where
breakage would have a project-wide impact.

But generally coordination has cost.  If you are a very small group,
you don't need much formal coordination.  But as you get larger you
get to the point where the "friction" from errors outweighs the cost
of coordination.  But if you get even larger, the cost of coordination
is even greater, and unless you have high discipline coordination is
hard to achieve, outside of authoritative structures like corporations
or armies,  At some scale, nothing but loose coordination will scale.
At the far end you have free markets.

I think we're transitioning from a formally coordinated model led by a
corporation to a model that will have less formal coordination
structures.  This is necessary to grow the project in the absence of
corporate control.  But it will take some time to get used to it.


> Perhaps looking on other large projects (Firefox, Linux Kernel ...) is a
> good idea.
>
> Regards,
> Mathias
>

Mime
View raw message