[Python-Dev] PEP 385: the eol-type issue

> - we're a distributed system, there's fairly little we can assume about clients

Not as Mercurial, no. As Python, we can certainly expect that all of our
contributors have read the developer FAQ, and set up their systems
accordingly. If all else fails, we can revoke commit access (or is
it "push access"?) if some committer doesn't get the configuration
right. We would, of course, prefer if it was very easy to get the
configuration right, so that problems don't occur in the first place.

> The first point means, for example, there will always be some clients> who don't have win32text enabled, no matter what, so you can't rely on> it, which is why I want to make the server hooks the primary line of> defense

I think it's a terminology issue only: don't say "primary", say "last".

Can we agree that the "last" line of defense will be the server hooks,
and the "primary" line of defense will be the client commits? "primary"
would mean that this is were most errors are detected and fixed; Mark
would really object to a flow where most errors are detected only
at the server.

> That doesn't mean I think> Windows users are second-rate, or anything like that!

If the server hooks were the primary line of defense, it would
effectively make Windows users second-rate: they will have to redo all
their changes over-and-over again, whereas the Unix users can push the
changes without any obstacles (just because they are less likely to make
mistakes).

If the client machines were the primary line of defense, Windows users
were treated equally: they would make as few mistakes as Unix users,
because the hooks do what they want correctly.

> I don't think either is bad. In the first case, you have one or maybe> two extra changesets. As we like to advocate small changesets that fix> one thing, a changeset fixing up whitespace is par for the course. ;)

Whitespace-only changes hurt the "annotate" feature, so we dislike them
very much in Python.

> Well, I'd be happy to help convince the hg crew to accept whatever we> come up with, but I'm not sure I'm the best person to come up with it.

That is all very well. See my other message (asking for volunteers)
as well. If you have more work you would prefer to delegate, please let
us know.

Regards,
Martin