On 3/03/2010 2:29 AM, Steve Holden wrote:
Antoine Pitrou wrote:
Le Tue, 2 Mar 2010 15:41:45 +0100, Dirkjan Ochtman<dirkjan@ochtman.nl> a écrit :
For the EOL issue, there is code, it needs testing. Martin Geisler (the primary author so far) and I issued a call for testing on python-dev last week, but without any response so far.
While I've done testing in the past, I haven't had a chance to do more since last week when it was indicated some of the bugs have been removed and it is now reasonable to test again. It seems unlikely I will find more testing time before next week (and it seems a little unreasonable to assume people can do these kinds of things with only one weeks notice when it has taken many months to get to the point where more testing is possible)
The people who have voiced their annoyance at the EOL situation should do the testing, really.
"Annoyance" isn't really the right word here - there was general agreement that we didn't want to accept 'regressions' over what SVN offers, and combined with the practical issues involved in using incorrect line-endings it seems reasonable to keep pushing for it.
It might be worth reminding people again that this can be tested effectively on platforms other than Windows. Alternatively, if people think there are no practical problems involved and I'm just whining, we could look at converting the repo using \r\n line endings and let non-windows users experience the lack of problems it would cause <wink>.
I expended a good deal of effort last year making sure that core developers who required them got MSDN licenses. This should surely enable some testing. If nobody wants to test for the Windows platform then all the work is going to fall on MvL, who surely has plenty to do without that additional load.
As above - while we obviously want people on Windows to test, it can be tested on any platform - particularly if people are willing to create a test repo with \r\n native line endings. People in this community regularly help design and debug issues which have no direct impact on their day-to-day work - which is obviously a good thing - and hopefully some are willing to help do that in this case too.
While suggesting we use \r\n line endings on the real repo is tongue-in-cheek, maybe we could provide a 'sandbox' copy of the Python repository with \r\n line endings to help spread the testing?
On a more practical note: Without native line-endings in hg, how would Windows binary distributions ship .py files? Would it ship with \n line endings (and therefore potentially confuse *users* of Python as well as developers) or would there be a conversion process (meaning a hg tree would be quite different than a binary tree even though the actual content is identical)?
IMHO we got in this mess because we didn't have sufficient involvement from Windows platform users during the DVCS evaluation - people saw that there was some accommodation to Windows, and assumed it would be sufficient for our purposes. It wasn't, and a year later we are only just approaching a solution.
I don't think that is correct. Let's say we did identity those problems during the DVCS evaluation - how would the outcome have been affected? At the time, bzr had zero support for end-of-line support, so selecting bzr wouldn't have been an outcome. The only outcome I could see would have been to choose to defer the process until one of the DVCS tools under consideration offers the support we need - which, in practice, is where we are today.
Cheers,
Mark