> Out of curiosity, what is typically the convention on that?

In theory every issue should be about a single problem and therefore have a single patch to fix it.  Sometimes a secondary "problem" that is not strictly related to the first one arises, for example when a cleanup is necessary before applying the patch, or when a new feature is added and a few places get changed to use it.  In these cases is not worth opening another issue, so both the patches are attached to the same issue, but committed separately because they address two different "problems".

> Sometime people forget to add a News or Acks entry and have to
> followup with an addendum. (Mark's patch still lack that, for 
> instance.)

Avoiding to include the NEWS entry in patches is common, because the file gets updated often and it will most likely cause conflicts.  `make patchcheck` remind us to add it -- assuming you don't forget to use it.

> Ezio's patch looks fine to me, though as Meador points out in the 
> Rietveld review, there are a couple of omissions that could be fixed.

Adding keepends there would have made the line too long, required some splitting and probably made the code less readable overall, so I prefer to keep it out.

> Personally, I'm not so convinced of the value of upgrading all the
> existing uses of splitlines to use 'keepends'; I just wanted to be
> able to do this in *new* code. :-)

If we can make old code more readable too and we already have a patch to do it, why not?  (one instance also had the comment # True == keep line ends)