| Some advice to people submitting changes: | | Back in the days when I was maintaining Hugs, changes were substantially more | likely to be merged into the main base if they were decomposed into a number of | small, independent changes whose impact and consequences could be understood in | isolation from the other changes. The same issue crops up from time to time for the Linux kernel development community, wherein the keepers of the kernel (Torvalds, Cox, et al) are much more likely to accept patches in the form Alastair describes, precisely for the reason he mentions, and those whose large, all-encompassing patches are rejected get hot under the collar. Assimilation of large chunks of code implementing new subsystems (ie, the ReiserFS file system) is slow indeed. So this is not by any means a new problem. I tend to sympathise with Alastair/Johan. For us, keeping GHC working on one platform is not too difficult. Trying to ensure that it keeps going on all supported platforms without inordinate amounts of effort, is IMO easily the biggest engineering challenge we face. </red-herring> J