enh <[email protected]> wrote: > heh. while i know what Theo means -- and his is also a valid philosophical > standpoint -- this kind of thing is one reason why i personally prefer > fewer implementations of things and more shared code between them :-) > > at least it leads to more consistency, and to having fewer places to fix. > (since i think we've all had enough counterexamples to not believe that > whole "many eyes" thing, the real question is "how easily/quickly can you > make fixes, and how easily/quickly can you distribute them?"... given how > few eyes are actually open, i'd rather have them all looking at the same > set of problems :-( )
Eyes will usually look at the version they are used to, and any effort to shink the number of versions will probably fail to re-adapt those eyes towards looking at another version with the same focus, as they are not familiar with the replacement. Additionally, all software efforts also face a limit on the number of cooks huddled in the kitchen, so I do not believe the development community grows in that way. I don't know of any succesfull examples where divergent teams merged into a single track. To me, it seems best if we urge everyone to craft their independent implementations towards consistency, and conversation on those details is important to get there. There is another problem in our tree: The use of external upstream managed code is a royal pain in the ass. We do it where we have to, but the process for managing that kind stuff is a culturally weird.
