[nightly] 10-Aug-2008 build of HEAD oni386-unknown-linux(cam-02-unx.europe.corp.microsoft.com)

[Claus Reinke]

>>   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