Last day to vote/reject on proposed EOL names

[Talden]

> Regardless though, I still think it would be reasonable to have that file
> marked as 'exact' and reject the commit.  I think having an eol option
> *only* handling this unusual case - and no other practical reasonable
> cases, isn't doing anyone any favours, least of all the vast majorty of
> users who really only want 2 options in practice, but need to decode
> many more descriptions to ensure they really are getting what they want...

Another example would be source-code where the compiler doesn't care
but the various IDEs/Editors don't all maintain EOL consistency and
don't all deal with displaying mixed EOLs correctly.

NB: You can change a comment line in a script in an editor that screws
the EOLs. Running an expensive test for this might be preferable - but
again, I won't be able to sell the necessity to run what could be
extensive tests for updating a piece of documentation.

--
Talden