On 11/12/2007, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > this process will inevitably go too far. (IMAP has too many modules.)
+1 I've seen this at work too, but it is still a useful way to explode the big ball of mud. > but this is an exercise in comprehension. once the code has been > broken down and the dependencies fixed then we can reaggregate. We can, but I'm betting that by the time we should we won't want to anymore. If the build-test-release cycle is efficient enough there's no real incentive, and it helps stop the ball of mud from reforming. > > > IMHO too many modules is an anti pattern. > > define too many without selecting an arbitrary numeric value :-) Literally? n+1 where n is the optimum number. ;-) (Sorry!) > > i think that JAMES needs to move towards finely grained COP ATM. this > will allow the dependencies to be fixed in an evolutionary manner. +1 we need to expose our internal dependencies, which is where the pain of making changes comes from, so that we can see them clearly and manage them effectively. > IMHO the future for trunk should be pruned releases. experimental and > innovative code should be allowed in trunk without having to convince > people of it's value a priori. first, the APIs are finalised on trunk. > (hence API modules.) before a release, immature modules and general > cruft would be pruned on the release branch. these modules which > didn't make the cut would still be available by compilation of a tag. Sounds like a sensible approach for managing this. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
