Python version auditing followup

Python version auditing followup

[Eric S. Raymond]

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

Re: Python version auditing followup

[Junio C Hamano]

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?

Re: Python version auditing followup

[Joachim Schmitz]

Junio C Hamano wrote:
> 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 

Re: Python version auditing followup

[Junio C Hamano]

"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 onee port was done" to me.

RE: Python version auditing followup

[Joachim Schmitz]

> 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

Re: Python version auditing followup

[Junio C Hamano]

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

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.

RE: Python version auditing followup

[Joachim Schmitz]

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

Re: Python version auditing followup

[Junio C Hamano]

"Joachim Schmitz" <jojo@schmitz-digital.de> writes:

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

Re: Python version auditing followup

[Dennis Kaarsemaker]

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