Hi all, As some people may have noticed, I've been working on reviving GHC's External Core printer. I have two conflicting goals: get some work done (to the extent that for me, this is a prerequisite for a larger project), and contribute patches to GHC so that other people can benefit from my work.
The goals conflict because seemingly most of the times I try to commit patches, my work stops for at least a couple hours while I bring my source tree up-to-date so I can run validate. Though the changes I'm making are seemingly unlikely to break anything else (since they're confined to the External Core path, which nothing else depends on), I still don't want to be the one who checks in untested patches and breaks everything. Now, usually the work stoppage is just a matter of waiting for darcs to complete. But today the HEAD was broken. so since I didn't know how long it was going to take for a patch that fixed it to get checked in, I spent a couple hours trying to roll back patches to get into a state where I at least had a version of GHC that would build so I could continue with other work while waiting for the fix to get checked in. This didn't work, so now I'm waiting while a new tree checks out from scratch. Is there a way to insulate myself from GHC breakage (and I realize that in the HEAD, a certain amount of breakage is inevitable) while still checking in my changes on a regular basis? I see two alternatives: 1) commit my changes frequently, on a branch and merge it to the HEAD at some future time (but past experience has shown that merging it later is just too painful) 2) never commit my changes until I consider my work "done", then commit them all at once (but it generally seems better to commit small amounts of code often; plus, this has more or less the same problem with merging) Do other people have any thoughts/experiences related to this? Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I'm a nonbeliever, but I believe in your smile." -- Laura Nyro _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
