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

Groups > comp.lang.python > #94080 > 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-18 21:34 -0400
    Re: Should non-security 2.7 bugs be fixed? Paul Rubin <no.email@nospam.invalid> - 2015-07-18 20:45 -0700
      Re: Should non-security 2.7 bugs be fixed? Rustom Mody <rustompmody@gmail.com> - 2015-07-18 21:04 -0700
      Re: Should non-security 2.7 bugs be fixed? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-19 14:52 +0100

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

On 7/18/2015 8:27 PM, Mark Lawrence wrote:
> On 19/07/2015 00:36, Terry Reedy wrote:
>> I asked the following as an off-topic aside in a reply on another
>> thread. I got one response which presented a point I had not considered.
>>   I would like more viewpoints from 2.7 users.
>>
>> Background: each x.y.0 release normally gets up to 2 years of bugfixes,
>> until x.(y+1).0 is released.  For 2.7, released summer 2010, the bugfix
>> period was initially extended to 5 years, ending about now.  At the
>> spring pycon last year, the period was extended to 10 years, with an
>> emphasis on security and build fixed.  My general question is what other
>> fixes should be made?  Some specific forms of this question are the
>> following.
>>
>> If the vast majority of Python programmers are focused on 2.7, why are
>> volunteers to help fix 2.7 bugs so scarce?
>>
>> Does they all consider it perfect (or sufficient) as is?
>>
>> Should the core developers who do not personally use 2.7 stop
>> backporting, because no one cares if they do?
>>
>
> 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?

I am suggesting that if there are 10x as many 2.7only programmers as 
3.xonly programmers, and none of the 2.7 programmers is willing to do 
the backport *of an already accepted patch*, then maybe it should not be 
done at all.

> 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).

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#94088

Terry Reedy <tjreedy@udel.edu> writes:
> I am suggesting that if there are 10x as many 2.7only programmers as
> 3.xonly programmers, and none of the 2.7 programmers is willing to do
> the backport *of an already accepted patch*, then maybe it should not
> be done at all.

The patch acceptance/approval process is frankly daunting.

[toc] | [prev] | [next] | [standalone]

#94090

On Sunday, July 19, 2015 at 9:16:08 AM UTC+5:30, Paul Rubin wrote:
> Terry Reedy writes:
> > I am suggesting that if there are 10x as many 2.7only programmers as
> > 3.xonly programmers, and none of the 2.7 programmers is willing to do
> > the backport *of an already accepted patch*, then maybe it should not
> > be done at all.
> 
> The patch acceptance/approval process is frankly daunting.

And it should be.
Ive used python for some 15 years now and more than any particular language
aspect or feature, the aspect that keeps it in my core tool box is its reliability:
Mostly it does what I expect, and allowing a teacher to open the interpreter in
a class and hack real-time on coding depends on a certain stability that I
personally find very valuable.

So I would like to make a distinction between *approvals* being daunting
and *discussions* (for patches) being tolerated though (mostly) not being accepted.

Of course I accept that this can be unrealistic: Having to email:
"Sorry -- Unacceptable" can itself get out of hand if/when the number of well-meaning ignoramus suggestions crosses a threshold 

[toc] | [prev] | [next] | [standalone]

#94116

On 19/07/2015 04:45, Paul Rubin wrote:
> Terry Reedy <tjreedy@udel.edu> writes:
>> I am suggesting that if there are 10x as many 2.7only programmers as
>> 3.xonly programmers, and none of the 2.7 programmers is willing to do
>> the backport *of an already accepted patch*, then maybe it should not
>> be done at all.
>
> The patch acceptance/approval process is frankly daunting.
>

Correct, which is why "PEP 0462 -- Core development workflow automation 
for CPython" https://www.python.org/dev/peps/pep-0462/, "PEP 0474 -- 
Creating forge.python.org" https://www.python.org/dev/peps/pep-0474/ and 
a separate core-workflow mailing list exist.

Admittedly things had stalled but I understand that they're being picked 
up again.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [standalone]

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

csiph-web