...

1. whatever I check in, the _whole_ thing has to build ok 2. if _my_ changes break someone else's code, _I_ have to fix that

I'd suggest to interpret GHC+corelibs as a unit, and to apply rules 1 and 2.

I was thinking of a unit of concern, not of any ownership or packaging (even the name "core"libs is ghc-specific: libraries ghc builds depends on).

But I do wish to point out that you cannot achieve both goals: "make GHC and its dependencies into a single unit" and "share the libraries with other compilers". At least, not without accepting some extra work on the GHC side to maintain both illusions.

Usually, the first time I hear about breakage affecting nhc98 or hugs is when you or Ross submit patches fixing said breakage!-) I think you are right: if the libraries are considered to be shared, then there are several such "units" which might affect each other via those shared libraries. Perhaps it helps to spell out the dependencies. In terms of changes in one place potentially having unwanted effects elsewhere, we have ghc <-> corelibs, ghc -> extralibs hugs -> corelibs+extralibs, ??hugslibs -> hugs nhc98 -> corelibs+extralibs, ??nhclibs -> nhc98 Actually, there are several forms of dependency: - changing the libraries cannot break hugs itself, but can make it unable to load or use any libraries, including the shared ones - changing (ghc-)corelibs can break ghc - changing nhc98-corelibs (which are?) can break nhc98 - changing hugs/nhc98/ghc can render each unable to load use some of the shared libraries (and others depending on these) Does that cover all cases? Changing ghc to make a library uncompilable by ghc only hurts ghc itself, but if the fix involves changing the library, the breakage might spread to hugs and nhc98. In principle, any changes to the shared libraries ought to be tested against all implementations sharing them. But as long as hugs and nhc98 are not part of a shared buildbot or validate system (neither of which are quite perfect even limited to ghc), breakage won't even be flagged for, let alone be fixed by submitters. While it is great that the two of you are always on the ball, is that something to be expected from all library maintainers all the time? Do all of them have to be subscribed to all of cvs-ghc, cvs-hugs, cvs-nhc98, and cvs-libraries, and fix any and all breakage arising in any and all situations, without their doing? Making it the submitters responsibility to look out for and fix any breakage caused by their patches simplifies the system and helps to ensure that any breakage resulting from changes is actually fixable (also in libraries outside the core+extralibs responsibility). In the time example, if ghc changes a warning flag to break the build, the immediate "fix" is to disable that new functionality, leaving it to the library maintainers to think about what the "proper" fix might be, possibly changing their code and re-enabling or leaving things as they are. Since those policies worked well in all projects where I have seen them used, I never really questioned them after I got my introduction. Is there a reason why they shouldn't or couldn't apply to the shared libraries and sharing haskell implementations? As I have mentioned, I'm worried that the move from extralibs to haskell platform will severe that responsibility, so library maintainers will have to become much more watchful for breakage affecting their packages, and more active in fixing such breakage. Claus