On Wed, Jul 6, 2011 at 5:59 PM, Mathias Bauer <mathias_ba...@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 >
