threads / discuss / 32416

Python version auditing followup

Subject: Python version auditing followup

## tl;dr

9 messages between Dec 20, 2012 and Dec 27, 2012.

replies: 8people: 4as markdown or json

Eric S. Raymond· Dec 20, 2012, 14:34 UTC · lore

Most of the Python scripts in the distribution are small and simple to audit, so I am pretty sure of the results. The only place where I have a concern is the git_helpers library; that is somewhat more complex and I might have missed a dependency somewhere. Whoever owns that should check my finding that it should run under 2.4

That was the first of three patches I have promised. In order to do the next one, which will be a development guidelines recommend compatibility back to some specific version X, I need a policy decision. How do we set X?

I don't think X can be < 2.4, nor does it need to be - 2.4 came out in 2004 and eight years is plenty of deployment time.

The later we set it, the more convenient for developers. But of course by setting it late we trade away some portability to older systems.

In previous discussion of this issue I recommended X = 2.6. That is still my recommendation. Thoughts, comments, objections?

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

In recent years it has been suggested that the Second Amendment
protects the "collective" right of states to maintain militias, while
it does not protect the right of "the people" to keep and bear arms.
If anyone entertained this notion in the period during which the
Constitution and the Bill of Rights were debated and ratified, it
remains one of the most closely guarded secrets of the eighteenth
century, for no known writing surviving from the period between 1787
and 1791 states such a thesis.
        -- Stephen P. Halbrook, "That Every Man Be Armed", 1984
Junio C Hamano· Dec 20, 2012, 18:30 UTC · re: Eric S. Raymond · lore

Re: Python version auditing followup

esr@thyrsus.com (Eric S. Raymond) writes:
Show 14 quoted lines
> That was the first of three patches I have promised.  In order to do
> the next one, which will be a development guidelines recommend
> compatibility back to some specific version X, I need a policy
> decision.  How do we set X?
>
> I don't think X can be < 2.4, nor does it need to be - 2.4 came out
> in 2004 and eight years is plenty of deployment time.
>
> The later we set it, the more convenient for developers.  But of
> course by setting it late we trade away some portability to 
> older systems.
>
> In previous discussion of this issue I recommended X = 2.6.
> That is still my recommendation. Thoughts, comments, objections?

I personally would think 2.6 is recent enough. Which platforms that are long-term-maintained by their vendors still pin their Python at 2.4.X? 2.4.6 was in 2008 that was source only, 2.4.4 was in late 2006 that was the last 2.4 with binary release.

Objections?  Comments?
Joachim Schmitz· Dec 20, 2012, 21:30 UTC · re: Junio C Hamano · lore

Re: Python version auditing followup

Junio C Hamano wrote:
Show 23 quoted lines
> esr@thyrsus.com (Eric S. Raymond) writes:
>
>> That was the first of three patches I have promised.  In order to do
>> the next one, which will be a development guidelines recommend
>> compatibility back to some specific version X, I need a policy
>> decision.  How do we set X?
>>
>> I don't think X can be < 2.4, nor does it need to be - 2.4 came out
>> in 2004 and eight years is plenty of deployment time.
>>
>> The later we set it, the more convenient for developers.  But of
>> course by setting it late we trade away some portability to
>> older systems.
>>
>> In previous discussion of this issue I recommended X = 2.6.
>> That is still my recommendation. Thoughts, comments, objections?
>
> I personally would think 2.6 is recent enough.  Which platforms that
> are long-term-maintained by their vendors still pin their Python at
> 2.4.X?  2.4.6 was in 2008 that was source only, 2.4.4 was in late
> 2006 that was the last 2.4 with binary release.
>
> Objections?  Comments?

We have a working 2.4.2 for HP-NonStop and some major problems getting 2.7.3 to work.

Bye, Jojo
Junio C Hamano· Dec 20, 2012, 21:39 UTC · re: Joachim Schmitz · lore

Re: Python version auditing followup

"Joachim Schmitz" <jojo@schmitz-digital.de> writes:
Show 10 quoted lines
> Junio C Hamano wrote:
>> I personally would think 2.6 is recent enough.  Which platforms that
>> are long-term-maintained by their vendors still pin their Python at
>> 2.4.X?  2.4.6 was in 2008 that was source only, 2.4.4 was in late
>> 2006 that was the last 2.4 with binary release.
>>
>> Objections?  Comments?
>
> We have a working 2.4.2 for HP-NonStop and some major problems getting
> 2.7.3 to work.

I do not think a platform that stops at 2.4.2 instead of going to higher 2.4.X series deserves to be called "long term maintained by their vendors". It sounds more like "attempted to supply 2.4.X and abandoned the users once onee port was done" to me.

Joachim Schmitz· Dec 21, 2012, 07:26 UTC · re: Junio C Hamano · lore

RE: Python version auditing followup

Show 23 quoted lines
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Thursday, December 20, 2012 10:39 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: Python version auditing followup
> 
> "Joachim Schmitz" <jojo@schmitz-digital.de> writes:
> 
> > Junio C Hamano wrote:
> >> I personally would think 2.6 is recent enough.  Which platforms that
> >> are long-term-maintained by their vendors still pin their Python at
> >> 2.4.X?  2.4.6 was in 2008 that was source only, 2.4.4 was in late
> >> 2006 that was the last 2.4 with binary release.
> >>
> >> Objections?  Comments?
> >
> > We have a working 2.4.2 for HP-NonStop and some major problems getting
> > 2.7.3 to work.
> 
> I do not think a platform that stops at 2.4.2 instead of going to
> higher 2.4.X series deserves to be called "long term maintained by
> their vendors".  It sounds more like "attempted to supply 2.4.X and
> abandoned the users once one port was done" to me.

Well, not entirely wrong, but not all true at too. I guess I need to defend the vendor here: It is not really the Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3, it is a volunteer and community effort. HP did sponsor the 2.4.2 port though (by allowing an HP employee to do the port inn his regular working hours). It is not doing this any longer (since 2007). Since then it is a small group doing this on a purely voluntary basis in their spare time (one HP employee amongst them, me). Same goes for the git port BTW. And for every other port provided on http://ituglib.connect-cummunity.org (this machine is sponsored by HP). Almost every other port, as some pretty recently made it into the officially supported O/S version, so far: Samba, bash, coreutils, vim, gzip, bzip2, Perl, PHP.

Bye, Jojo
Junio C Hamano· Dec 21, 2012, 18:28 UTC · re: Joachim Schmitz · lore

Re: Python version auditing followup

"Joachim Schmitz" <jojo@schmitz-digital.de> writes:
Show 17 quoted lines
>> > We have a working 2.4.2 for HP-NonStop and some major problems getting
>> > 2.7.3 to work.
>> 
>> I do not think a platform that stops at 2.4.2 instead of going to
>> higher 2.4.X series deserves to be called "long term maintained by
>> their vendors".  It sounds more like "attempted to supply 2.4.X and
>> abandoned the users once one port was done" to me.
>
> Well, not entirely wrong, but not all true at too.
> I guess I need to defend the vendor here: It is not really the
> Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3,
> it is a volunteer and community effort. HP did sponsor the 2.4.2
> port though (by allowing an HP employee to do the port inn his
> regular working hours). It is not doing this any longer (since
> 2007). Since then it is a small group doing this on a purely
> voluntary basis in their spare time (one HP employee amongst them,
> me).  Same goes for the git port BTW.

For the purpose of "if we draw the line at 2.6, would it hurt many people who have been happily using the existing release of Git that was happy with 2.4", it is dubious HP-NonStop counts. It is not like the users on that platform have been happily using Python based Porcelain at the fringe of Git, and drawing the line at 2.6 will not give them any regression.

It does add more things that needs to be done to the volunteer developers for that platform and the organization that may want to support the platform (as they have to finish 2.6 port if we decide to draw the line there), but that is a secondary consideration.

Joachim Schmitz· Dec 21, 2012, 18:44 UTC · re: Junio C Hamano · lore

RE: Python version auditing followup

Show 32 quoted lines
> From: Junio C Hamano [mailto:gitster@pobox.com]
> Sent: Friday, December 21, 2012 7:28 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org
> Subject: Re: Python version auditing followup
> 
> "Joachim Schmitz" <jojo@schmitz-digital.de> writes:
> 
> >> > We have a working 2.4.2 for HP-NonStop and some major problems getting
> >> > 2.7.3 to work.
> >>
> >> I do not think a platform that stops at 2.4.2 instead of going to
> >> higher 2.4.X series deserves to be called "long term maintained by
> >> their vendors".  It sounds more like "attempted to supply 2.4.X and
> >> abandoned the users once one port was done" to me.
> >
> > Well, not entirely wrong, but not all true at too.
> > I guess I need to defend the vendor here: It is not really the
> > Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3,
> > it is a volunteer and community effort. HP did sponsor the 2.4.2
> > port though (by allowing an HP employee to do the port inn his
> > regular working hours). It is not doing this any longer (since
> > 2007). Since then it is a small group doing this on a purely
> > voluntary basis in their spare time (one HP employee amongst them,
> > me).  Same goes for the git port BTW.
> 
> For the purpose of "if we draw the line at 2.6, would it hurt many
> people who have been happily using the existing release of Git that
> was happy with 2.4", it is dubious HP-NonStop counts.  It is not
> like the users on that platform have been happily using Python based
> Porcelain at the fringe of Git, and drawing the line at 2.6 will not
> give them any regression.
You asked for opions and obhections, you got mine ;-)
Junio C Hamano· Dec 21, 2012, 18:48 UTC · re: Joachim Schmitz · lore

Re: Python version auditing followup

"Joachim Schmitz" <jojo@schmitz-digital.de> writes:
Show 34 quoted lines
>> From: Junio C Hamano [mailto:gitster@pobox.com]
>> Sent: Friday, December 21, 2012 7:28 PM
>> To: Joachim Schmitz
>> Cc: git@vger.kernel.org
>> Subject: Re: Python version auditing followup
>> 
>> "Joachim Schmitz" <jojo@schmitz-digital.de> writes:
>> 
>> >> > We have a working 2.4.2 for HP-NonStop and some major problems getting
>> >> > 2.7.3 to work.
>> >>
>> >> I do not think a platform that stops at 2.4.2 instead of going to
>> >> higher 2.4.X series deserves to be called "long term maintained by
>> >> their vendors".  It sounds more like "attempted to supply 2.4.X and
>> >> abandoned the users once one port was done" to me.
>> >
>> > Well, not entirely wrong, but not all true at too.
>> > I guess I need to defend the vendor here: It is not really the
>> > Vendor (HP) that provided Python 2.4.2 or tries to provide 2.7.3,
>> > it is a volunteer and community effort. HP did sponsor the 2.4.2
>> > port though (by allowing an HP employee to do the port inn his
>> > regular working hours). It is not doing this any longer (since
>> > 2007). Since then it is a small group doing this on a purely
>> > voluntary basis in their spare time (one HP employee amongst them,
>> > me).  Same goes for the git port BTW.
>> 
>> For the purpose of "if we draw the line at 2.6, would it hurt many
>> people who have been happily using the existing release of Git that
>> was happy with 2.4", it is dubious HP-NonStop counts.  It is not
>> like the users on that platform have been happily using Python based
>> Porcelain at the fringe of Git, and drawing the line at 2.6 will not
>> give them any regression.
>
> You asked for opions and obhections, you got mine ;-)
Yeah, duly noted, and appreciated.
Dennis Kaarsemaker· Dec 27, 2012, 21:57 UTC · re: Junio C Hamano · lore

Re: Python version auditing followup

On do, 2012-12-20 at 10:30 -0800, Junio C Hamano wrote:
> Which platforms that are long-term-maintained by their vendors still
> pin their Python at 2.4.X?

RHEL 5.x and its clones still use python 2.4. It is supported by red hat until at least 2017 (though end of production phase two, Q1 2014, seems like a reasonable cut-off point).

-- 
Dennis Kaarsemaker

← back to recent threads