[Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build

[Terry Reedy]

On 2/6/2013 8:16 AM, Matthias Klose wrote:
> Am 05.02.2013 07:13, schrieb Terry Reedy:
>> On 2/4/2013 3:04 PM, Matthias Klose wrote:

>>>    - there were way too may regressions checked in on at least the 2.7
>>>      branch.

I think you are using 'regression' too freely. But that aside, I think 
you are pointing to a legitimate issue, in the first and maybe second 
example of how to handle 2.7.

>> Regressions? That normally means adding a bug as part of a patch, especially one
>> that was previously fixed. We continually add tests to try to prevent that. What
>> period of time do you mean 'were' to refer to?
>
>   - http://bugs.python.org/issue9374

 From what I read (but it was a long discussion), this patch fixed 
behavior that was agreed to be a bug. The disagreement was whether the 
bug was clear or obscure. Since the bug was long-standing, and since 
much code had accommodated to the bug, and even depended on it, the 
bugfix broke more code than usual. This is not a regression, but is a 
concern, and if I understand correctly, the fix was removed or revised 
for existing versions.

>   - http://bugs.python.org/issue15906

I did not understand the issue, except to note that it affected all 
versions, involved apparent ambiguity in the doc, and was caught by 
ubuntu testing.

>   - http://bugs.python.org/issue16012

This reported a clear regression, on all versions, not just 2.7, that 
was caught before release. As the person responsible for the regression 
said "Too bad it [the regressed behavior] wasn't tested for :(". We 
still need more patches to improve test coverage.

>   - http://bugs.python.org/issue10182

This fixed an all-versions bug in _sre. The initial patch was fine for 
3.x but not sufficiently adjusted for 2.7. Py_BuildValue needed to be 
replaced in certain places with PyInt_FromSsize_t rather than 
PyLong_FromSsize_t to maintain the external API. This was not caught 
because by the stdlib test but was by a third party who tests their 
package with tip. Yay for them. The process worked.

>   - http://bugs.python.org/issue16828

Again, an all-versions issue, not 2.7 specific.
http://bugs.python.org/issue14398
disabled compression of '' in the process of enabling compression of 
 >4GB strings. Not a bad tradeoff, really, but not best. Again, this was 
not caught initially because there *was* no stdlib test for ''. But 
there was in a 2.7 ubuntu package.

> not a complete list, all these are past the 2.7.3 release.

In only 1 of the 5 was there a 2.7-specific regression. I am not sure 
what specific change you would like. In the last three examples, would 
you want 2.7 left with the bug?

>>>   Is it just our vcs merge model that we first have to check in
>>>      on the branches, and then merge to the trunk?
>>
>> Mercurial works best if merges are done in the forward direction. However, this
>> is not relevant to 2.7 patches as they are pushed to tip but *not* merged. The
>> repository is a two-headed monster ;=).
>
> so it should be possible to delay patches for 2.7 until they don't show issues
> in 3.2 or 3.3.

Yes, however
1. Later may mean never.
2. If the regression is 2.7 specific, as with #10182, then not showing 
an issue for 3.x is irrelevant.
3. If the regression is general, then *at present*, the 2.7 regression 
is the most likely to be caught by external testing (mostly by unbuntu). 
That says to me that bug fixes for 2.7 *should* go into tip along with 
the others. I could even argue that the 2.7 fix should go in first.
4. If bugfixes are not applied to 2.7, that increases the distance 
between 2.7 and 3.x and possibly increases the difficulty of writing 2&3 
code.

If we do leave a fixed-in-3.x bug in 2.7, then perhaps, if it is 
possible to detect that the bug is being depended upon, there should be 
a deprecation warning in the code.

--
Terry Jan Reedy