> I don't entirely agree. I personally find it very hard to review large
> patches as the amount of mental context generally seems to grow
> super-linearly in the amount of code touched. Moreover, I think it's
> important to remember that the need to read patches does not vanish the
> moment the patch is committed. To the contrary, review is merely the
> first of many instances in which a patch will be read. Other instances
I wholeheartedly agree with everything you say. I don't see it as contradicting
in any way
principles that I outlined. It's just that sometimes doing a single logical
change to the code
requires a large patch and breaking it artificially into smaller patches might
matters worse. I believe this would be the case for this scenario. And honestly
speaking I don't
think that the patch here will be very big. But like you say, there's a
compromise to be struck.
> * when the patch is backported
> * when someone is trying to rebase one of their own changes on top of
> the patch
> * when another contributor is trying to follow the evolution of a piece
> of the compiler
> * when someone is later trying to understand a bug in the patch
> Consequently, I think it is fairly important not to throw out the
> structure that multiple, sensibly sized commits provides. Of course
> there is a compromise to be struck here: we don't want dozens of
> five-line patches; however I think that one mega-patch swings too far to
> the other extreme in the case of most features.
> - Ben
Lodz University of Technology
Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata.
Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę
prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie.
This email contains information intended solely for the use of the individual
to whom it is addressed.
If you are not the intended recipient or if you have received this message in
please notify the sender and delete it from your system.
ghc-devs mailing list