Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #94156 > unrolled thread

Re: Should non-security 2.7 bugs be fixed?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Should non-security 2.7 bugs be fixed? Terry Reedy <tjreedy@udel.edu> - 2015-07-19 15:38 -0400

#94156 — Re: Should non-security 2.7 bugs be fixed?

On 7/18/2015 10:33 PM, Devin Jeanpierre wrote:
> On Sat, Jul 18, 2015 at 6:34 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> On 7/18/2015 8:27 PM, Mark Lawrence wrote:
>>> On 19/07/2015 00:36, Terry Reedy wrote:
>>> Programmers don't much like doing maintainance work when they're paid to
>>> do it, so why would they volunteer to do it?
>>
>> Right.  So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core
>> developer reviews and edits the patch until it is ready to commit, why
>> should either of them volunteer to do a 2.7 backport that they will not use?
>
> Because it helps even more people.

Writing another 3.x patch would also help other people and might be more 
'fun'.  That is the situation I am in with respect to Idle.

> It gets really boring submitting 2.7-specific patches, though, when
> they aren't accepted, and the committers have such a hostile attitude
> towards it. I was told by core devs that, instead of fixing bugs in
> Python 2, I should just rewrite my app in Python 3. It has even been
> implied that bugs in Python 2 are *good*, because that might help with
> Python 3 adoption.

Like Steven, I would be interested in specifics, though I do not 
disbelieve you.  I do not believe those two attitudes are exactly 
official policy, and I may request more discussion of them on pydev.

>>> Then even if you do the
>>> work to fix *ANY* bug there is no guarantee that it gets committed.
>>
>> I am discussing the situation where there *is* a near guarantee (if the
>> backport works and does not break anything and has not been so heavily
>> revised as to require a separate review).
>
> That is not how I have experienced contribution to CPython.

I know.  Some core developers are trying to revamp the issue-patch 
handling process to remove some of the busywork, use our time more 
efficiency, and make it work more smoothly for everyone.

But let me try again.  I am discussing a situation where a core 
developer has either requested or already agreed to apply a 2.7 
backport.  I have seen such in the past, but maybe this is now rare.

I specifically would like to be able to request backports for Idle 
patches and get responses.  When requested, I really would apply 
responses that worked.  Really.

But I now realized that most people would rather write a patch, on their 
own schedule, for an issue that bugs them, and perhaps use it locally, 
even if rejected for the repository, than write a guaranteed patch 
'right now for a issue of no interest to them (and which might require 
python knowledge they do not have).

> If the issue was closed as fixed before I contributed the backported
> patch, does anyone even see it?

Yes.  All changes on as issue, including uploads, are emailed to all on 
the nosy list regardless of open/closed/... status.  However, I would 
inquire first.  "If I backport the committed bugfix to 2.7, would you 
apply it?"

-- 
Terry Jan Reedy

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web