[python-committers] branches and merging

[Mark Hammond]

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 at 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