You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2019/11/04 04:52:53 UTC
Re: Merging branches/swig-py3 to trunk
Branko Čibej wrote on Tue, Oct 22, 2019 at 21:39:23 +0200:
> 1. we release 1.13.0 as planned next week when the soak period ends
> (pending any last-minute critical bugs found, of course);
>
> 2. immediately after the 1.13.0 release, we merge the swig-py3 branch
> to trunk; and,
Anyone wants to do the honours? (Do the merge, or write the 1.14 release notes
for it, or both)?
Re: [offlist] Re: Merging branches/swig-py3 to trunk
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Fri, Nov 08, 2019 at 08:13:20 +0000:
> If I did my search correctly, there is nothing about Python 3 in any of the
> 1.10 through 1.14 release notes. Haven't we got something to say about
> limited support (for build and test?) in some version before 1.14? All I
> could find was one py3 build fix (r1819444) merged to 1.10.x.
Are you looking for this? —
https://subversion.apache.org/docs/release-notes/1.9#python-2.7
It's interesting to notice that in that paragraph, we dropped support for py2.5
several years after it had gone EOL; and I remember that we added that
paragraph, not as a "planning ahead" thing well ahead of creating the 1.9.x
branch, but as a last-minute addition, shortly before the 1.9.0 final release.
That, and our failure to add support for Python 3 well ahead of py2's EOL, begs
the question of what _other_ dependencies of us are (or will soon be) EOL.
Cheers,
Daniel
Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Dec 10, 2019 at 11:30 AM Julian Foad <ju...@apache.org> wrote:
> Nathan Hartman wrote:
> > Regarding the 1.14 release notes and linking to the Python 3 work
> > in progress / status wiki page, I'm thinking of something along these
> > lines: [...]
>
> Looks good to me. I encourage you to go ahead and commit stuff like
> this without waiting for pre-commmit review.
Done in r1871142. Thanks for the encouragement. :-)
Cheers,
Nathan
Re: Merging branches/swig-py3 to trunk
Posted by Julian Foad <ju...@apache.org>.
Nathan Hartman wrote:
> Regarding the 1.14 release notes and linking to the Python 3 work
> in progress / status wiki page, I'm thinking of something along these
> lines: [...]
Looks good to me. I encourage you to go ahead and commit stuff like
this without waiting for pre-commmit review.
- Julian
Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Dec 3, 2019 at 3:14 PM Nathan Hartman <ha...@gmail.com> wrote:
> I'm placing a reminder to myself to update the 1.14 Release Notes with
> a link to this wiki page in "known issues" as discussed previously...
Regarding the 1.14 release notes and linking to the Python 3 work
in progress / status wiki page, I'm thinking of something along these
lines:
[[[
Index: 1.14.html
===================================================================
--- 1.14.html (revision 1871139)
+++ 1.14.html (working copy)
@@ -366,13 +366,30 @@
title="Link to this section">¶</a>
</h2>
+<!--
<p>There are no known issues specific to this release at the moment.</p>
+-->
-<!--
<p>There are some known issues in the Subversion 1.14 releases. These
may be fixed in later 1.14.x releases.</p>
--->
+<div class="h3" id="python3-work-in-progress">
+<h3>Python 3 support is incomplete
+ <a class="sectionlink" href="#python3-work-in-progress"
+ title="Link to this section">¶</a>
+</h3>
+
+Some Python scripts that are included in Subversion's release
+distribution do not support Python 3 yet.
+
+For an exhaustive list of all Python scripts and files that use
+Python, categorized by their Python 3 support status, see the
+<a href="https://cwiki.apache.org/confluence/display/SVN/Subversion%27s+Python+3+Support+Status"
+>Subversion's Python 3 Support Status</a> wiki page.
+</p>
+
+</div> <!-- python3-work-in-progress -->
+
</div> <!-- issues -->
<!-- (This section only makes sense when there are some issues listed in it.)
]]]
Cheers,
Nathan
Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
On Sun, Dec 1, 2019 at 6:32 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Nathan Hartman wrote on Sun, Dec 01, 2019 at 10:58:34 -0500:
> > On Thu, Nov 28, 2019 at 4:05 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > > Y'all might consider starting a wiki page or a jira issue tracking
> > > the categorization. I think it might be helpful to tracking the
> > > work done/punted/pending.
> >
> > Agreed. I just wanted to get an initial list that is more-or-less
> > accurate first. I think we're at that starting point now.
> >
> > Now, I wonder, how should we handle updates to the list as work
> > progresses? With the wiki we can move items around in the list. With a
> > Jira issue, would we add a comment with an updated list each time
> > item(s) change status?
>
> I suggest to just go ahead and create the wiki page.
Created the wiki page:
https://cwiki.apache.org/confluence/display/SVN/Subversion%27s+Python+3+Support+Status
I also added a link to it from the ManyHands page.
The purpose is to keep track of Python 3 support throughout all of our
scripts while work progresses to make everything compatible, so please
discuss any findings/changes/additions/observations here, or (if you
prefer) feel free to update the wiki directly...
I'm placing a reminder to myself to update the 1.14 Release Notes with
a link to this wiki page in "known issues" as discussed previously...
Cheers,
Nathan
Re: Merging branches/swig-py3 to trunk
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Sun, Dec 01, 2019 at 10:58:34 -0500:
> On Thu, Nov 28, 2019 at 4:05 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > I suggest to also grep for «sys.executable»; there are several
> > instances of that in trunk.
>
> I did such a search and sys.executable is found in:
>
> ./build/run_tests.py
> ./build/generator/gen_win.py
> ./build/generator/gen_vcnet_vcproj.py
> ./build/generator/gen_make.py
> ./subversion/tests/cmdline/svntest/main.py
> ./subversion/tests/cmdline/svnadmin_tests.py
> ./subversion/bindings/ctypes-python/setup.py
>
> I did not find files with extension other than .py containing
> sys.executable in latest trunk.
>
> I think nothing has changed about sys.executable in Python 3, so this
> should not affect anything.
Yes and no. sys.executable itself may not have changed, but code like
«subprocess.check_call([sys.executable, '-c', 'print "Hello world"'])»
would nevertheless be broken.
> > Y'all might consider starting a wiki page or a jira issue tracking
> > the categorization. I think it might be helpful to tracking the
> > work done/punted/pending.
>
> Agreed. I just wanted to get an initial list that is more-or-less
> accurate first. I think we're at that starting point now.
>
> Now, I wonder, how should we handle updates to the list as work
> progresses? With the wiki we can move items around in the list. With a
> Jira issue, would we add a comment with an updated list each time
> item(s) change status?
I suggest to just go ahead and create the wiki page.
> Meanwhile, here is a summary of the changes between my original list
> and the updated list by Yasuhito:
Cheers,
Daniel
Re: [offlist] Re: Merging branches/swig-py3 to trunk
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Tue, 12 Nov 2019 11:45 +00:00:
> Nathan Hartman wrote on Mon, Nov 11, 2019 at 22:13:54 -0500:
> > On Fri, Nov 8, 2019 at 3:13 AM Julian Foad <ju...@apache.org> wrote:
> > > svn 1.9 Py 2.7 supported, Py 3.x not working
> > > svn 1.10 Py 2.7 supported, Py 3.x+ supported for build & test, not
> > > working for bindings (?)
> > > svn 1.14 Py 2.7 unsupported (working in 1.14.0), Py 3.x supported
> > >
> > > For 1.10 I am offering an example of the form of summary, not sure what
> > > the actual status is.
> > >
> > > If I did my search correctly, there is nothing about Python 3 in any of
> > > the 1.10 through 1.14 release notes. Haven't we got something to say
> > > about limited support (for build and test?) in some version before 1.14?
> > > All I could find was one py3 build fix (r1819444) merged to 1.10.x.
> > >
> >
> > A table like that would be helpful. Hopefully someone knows what the
> > actual status of 1.10 is. I guess it can be tested. Only the latest,
> > 1.10.6, should be tested.
>
> On 1.10.x svnserveautocheck doesn't support py3, at least. (There may be
> additional issues.)
The svnserveautocheck issue is in the shell script driver — probably
some commit that hasn't been backported.
autogen, configure, and 'make all svnmover check' on 1.10.x pass with
PYTHON=python3.
Cheers,
Daniel
Re: Merging branches/swig-py3 to trunk
Posted by Julian Foad <ju...@apache.org>.
Nathan Hartman wrote:
> To see all of the above, visit:
> https://subversion-staging.apache.org/docs/release-notes/1.14.html
>
> All thoughts, suggestions, and improvements are welcome.
LGTM. I made some small tweaks in http://svn.apache.org/r1869849 .
- Julian
> In particular there is a TODO item to figure out and describe which
> versions of Python 3.x we support in 1.14.
Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
On Wed, Nov 13, 2019 at 12:06 AM Nathan Hartman <ha...@gmail.com>
wrote:
> > If the following looks like a reasonable start, I'd like to go ahead
> and commit it (and continue editing/fixing/improving)...
r1869776: I committed most of the text discussed earlier to **staging**.
More below:
On Tue, Nov 12, 2019 at 6:59 AM Julian Foad <ju...@apache.org> wrote:
> A thought about supporting older Python versions... Somewhere in the
> pipeline between community inputs and project outputs, should we
> distinguish between "we will not support ..." and "we will be glad to
> accept contributions that enable supporting ..."? How would this look?
>
> I am just getting the feeling that we, a small group of developers, are
> trying to make a decision by ourselves when perhaps we should be more
> actively reaching out to the wider community to invite them to influence
> the result. I know we have to decide to write something, but maybe we
> can write something that encourages the users (yes, the tiny proportion
> that might do something about it) to feel they can have a stake in it if
> they want to.
To address this, I added the text I posted here earlier in a separate
commit:
r1869777
To see all of the above, visit:
https://subversion-staging.apache.org/docs/release-notes/1.14.html
All thoughts, suggestions, and improvements are welcome.
In particular there is a TODO item to figure out and describe which
versions of Python 3.x we support in 1.14.
Cheers,
Nathan
Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Nov 12, 2019 at 6:59 AM Julian Foad <ju...@apache.org> wrote:
> A thought about supporting older Python versions... Somewhere in the
> pipeline between community inputs and project outputs, should we
> distinguish between "we will not support ..." and "we will be glad to
> accept contributions that enable supporting ..."? How would this look?
>
> I am just getting the feeling that we, a small group of developers, are
> trying to make a decision by ourselves when perhaps we should be more
> actively reaching out to the wider community to invite them to influence
> the result. I know we have to decide to write something, but maybe we
> can write something that encourages the users (yes, the tiny proportion
> that might do something about it) to feel they can have a stake in it if
> they want to.
+1 to that.
I agree that we should reach out and let the community know that new
new contributors (and old ones) are welcomed with open arms.
To answer "How would this look?" I propose that there should be a
new section added at the end of the release notes titled something
along the lines of "Enthusiastic Contributors Welcome!" It doesn't
have to be those words; it's just what I came up with so far. That
section would try to inspire and encourage new involvement.
In addition, in each of the Python sub-sections, I propose to add some
text to the effect that we welcome contributions to support additional
Python versions, and refer the reader to the new section.
It would look something like the following... I'm double-underlining
section headings and single-underlining subsection headings.
If the following looks like a reasonable start, I'd like to go ahead
and commit it (and continue editing/fixing/improving)...
[[[
What's New in Apache Subversion 1.14
====================================
(other text here)
Support for Python 3.x
----------------------
Some optional features of Subversion utilize the Python scripting
language.
Subversion's SWIG Python bindings and automated test suite now support
Python 3.x (and newer).
### TODO: Describe which minor releases of Python 3.x we plan to
support through the four-year LTS period of Subversion 1.14. Per
recent discussions on the dev@ mailing list, that might be some form
of "rolling" support: In each 1.14.x patch release, we would make an
effort to support the oldest through newest minor lines of Python 3.x
that Python upstream supports at the time of our release. However, we
could drop support for the oldest one if we have a compelling reason
to do so. ###
Of course, we welcome contributions that extend Subversion's Python
support to include other versions. See the section "Enthusiastic
Contributors Welcome" below.
Support for Python 2.7 is being phased out
------------------------------------------
As of 1 January 2020, Python 2.7 has reached end of life. This means
that Python 2.7 will no longer receive maintenance releases or
patches, even for security issues. All users are strongly encouraged
to move to Python 3.
As Subversion 1.14 is a Long Term Support (LTS) release with planned
support into 2024, well beyond end-of-life for Python 2.7, the core
Subversion developers cannot commit to supporting and testing with
Python 2.7, or to fixing bugs that affect Python 2.7 only, for the
duration of this support period.
This means that although Subversion 1.14.0 still technically works
with Python 2.7, any later 1.14.x point release may drop this support
if it becomes too difficult to maintain.
If you must continue using Python 2.7, our previous Long Term Support
release, Subversion 1.10, is supported until 2022. Python 2.7 support
will not be removed from Subversion 1.10.
Of course, we welcome contributions that extend Subversion's Python
2.7 support. See "Enthusiastic Contributors Welcome" below.
Python is Optional
------------------
Note that Subversion does not require Python for its basic operation.
If you are not using Subversion's SWIG Python bindings, automated test
suite, or other Python-coded tools that ship with Subversion, this
change does not affect you.
.
.
.
(snip several sections)
.
.
.
Enthusiastic Contributors Welcome!
==================================
You can contribute to Subversion!
As Subversion is an open source project developed and supported by
volunteers, we are always happy to welcome enthusiastic participants
to the community.
Whether you'd like to see support for additional versions of Python or
have ideas for some big new features, if you're willing to invest the
effort, Subversion can be anything you imagine.
Join the conversation by email:
https://subversion.apache.org/mailing-lists.html
Or by IRC at irc.freenode.net:
#svn channel: User chat and help using Subversion
#svn-dev channel: Get involved in development!
Get the source:
* Check out Subversion's source using Subversion:
svn checkout https://svn.apache.org/repos/asf/subversion/trunk/
* or download the latest release tarball:
https://subversion.apache.org/download.cgi
Join us today!
]]]
Thoughts?
If the above looks halfway reasonable, I'd like to go ahead and commit
that to the work-in-progress release notes.
Cheers,
Nathan
Re: Merging branches/swig-py3 to trunk
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Tue, 12 Nov 2019 11:59 +00:00:
> A thought about supporting older Python versions... Somewhere in the
> pipeline between community inputs and project outputs, should we
> distinguish between "we will not support ..." and "we will be glad to
> accept contributions that enable supporting ..."? How would this look?
We could say that Python >=3.5 are "tier 1" supported and Python <=3.4
are "tier 2" supported, in the sense that, for example, a bug that
affects Python <=3.4 only will not be considered a release blocker, but
patches for py<=3.4 will still be accepted, to facilitate developing svn
1.14.x on LTS distros that still package py3.4. [Here, 3.5 is the
oldest non-EOL Python minor line.]
> I am just getting the feeling that we, a small group of developers, are
> trying to make a decision by ourselves when perhaps we should be more
> actively reaching out to the wider community to invite them to influence
> the result. I know we have to decide to write something, but maybe we
> can write something that encourages the users (yes, the tiny proportion
> that might do something about it) to feel they can have a stake in it if
> they want to.
>
> - Julian
>
Re: Merging branches/swig-py3 to trunk
Posted by Julian Foad <ju...@apache.org>.
A thought about supporting older Python versions... Somewhere in the
pipeline between community inputs and project outputs, should we
distinguish between "we will not support ..." and "we will be glad to
accept contributions that enable supporting ..."? How would this look?
I am just getting the feeling that we, a small group of developers, are
trying to make a decision by ourselves when perhaps we should be more
actively reaching out to the wider community to invite them to influence
the result. I know we have to decide to write something, but maybe we
can write something that encourages the users (yes, the tiny proportion
that might do something about it) to feel they can have a stake in it if
they want to.
- Julian
Re: [offlist] Re: Merging branches/swig-py3 to trunk
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Mon, Nov 11, 2019 at 22:13:54 -0500:
> On Fri, Nov 8, 2019 at 3:13 AM Julian Foad <ju...@apache.org> wrote:
>
> > Nathan Hartman wrote:
> > > Question: Some Python scripts have not been updated for Python 3.x
> > > yet. Should those be listed in the release notes under "Known Issues"?
> > > Should a bug be filed? Or both?
> >
> > Both: an Issue tracking which ones are known broken or untested, and a
> > pointer to it in the release notes.
> >
>
> Recently, Yasuhito posted a thread titled "List of Python scripts
> importing svn.*" I think those are the scripts that need to be checked
> for Python 3 compatibility? Or is it necessary to check all Python
> scripts?
>
> Is it preferred to create one issue to track this, or to first check
> Python scripts and then create an issue per script that is found to be
> incompatible with Python 3?
Whatever is most convenient for the people doing the work.
For example, we could have an umbrella issue "Review Python scripts for py3
compatibility" and spin off individual issues for scripts that have been
reviewed and found to need work. We could have a wiki page tracking work done
and remaining. We could convert the #! line to «#!/usr/bin/env python3» for
any script that's been reviewed and found to work.
> > > [[[
> > >
> > > Support for Python 3.x:
> > >
> > > Some optional features of Subversion utilize the Python scripting
> > > language.
> > >
> > > Subversion's SWIG Python bindings and automated test suite now support
> > > Python 3.x (and newer).
> > >
> > > Support for Python 2.7 is being phased out:
> > >
> > > As of 1 January 2020, Python 2.7 has reached end of life. This means
> > > that Python 2.7 will no longer receive maintenance releases or
> > > patches, even for security issues. All users are strongly encouraged
> > > to move to Python 3.
> > >
> > > As Subversion 1.14 is a Long Term Support (LTS) release with planned
> > > support into 2024, well beyond end-of-life for Python 2.7, the
> > > Subversion developers cannot commit to supporting and testing with
> > > Python 2.7, or to fixing bugs that affect Python 2.7 only, for the
> > > duration of this support period.
> > >
> > > This means that although Subversion 1.14.0 still technically works
> > > with Python 2.7, any later 1.14.x point release may drop this support
> > > if it becomes too difficult to maintain.
> > >
> > > If you must continue using Python 2.7, our previous Long Term Support
> > > release, Subversion 1.10, is supported until 2022. Python 2.7 support
> > > will not be removed from Subversion 1.10.
> > >
> > > Note that Subversion does not require Python for its basic operation.
> > > If you are not using Subversion's SWIG Python bindings, automated test
> > > suite, or other Python-coded tools that ship with Subversion, this
> > > change does not affect you.
> > >
> > > ]]]
> >
> > Sounds good to me.
> >
> > Maybe add a note that in "3.x" we intend to choose a specific "x", in
> > case we forget to update the text when we choose one?
> >
>
> Can we just pick one now rather than put it off and forget?
We can. We can also commit that text right now, and even add TODO's in it
where needed (the 1.14 notes are still work-in-progress).
> I suggest some sort of "rolling" support for Python, where each 1.14.x
> point release will support all Python 3.x releases that are not EOL at
> the time of that point release.
+1 to not supporting EOL Python versions.
> That is:
>
> * When 1.14.0 is released, Python 3.5 will still have 8 months of
> support. Therefore, we will support Python 3.5 through 3.8.
I'd like to add an escape hatch here, to say that in new minor release we'll
make an effort to support the oldest minor line of Python that Python upstream
supports at that time, but may decide to only support, say, py≥3.6, should we
have a good reason to do so.
> * Then, as a hypothetical example, suppose that 1.14.2 is released in
> 2021. Python 3.5 would be EOL. Therefore, we would NOT support
> Python 3.5 anymore, but would support Python 3.6 through 3.9.
+1: A new patch release should support whichever Python versions the previous
patch release (in the same minor line) did, subject to Python EOL terms.
In a new 1.14.x patch release, will we we support all py3.6.y releases, or just
whichever one is current at the time of rolling the 1.14.x tarballs?
> Thoughts?
> > svn 1.9 Py 2.7 supported, Py 3.x not working
> > svn 1.10 Py 2.7 supported, Py 3.x+ supported for build & test, not
> > working for bindings (?)
> > svn 1.14 Py 2.7 unsupported (working in 1.14.0), Py 3.x supported
> >
> > For 1.10 I am offering an example of the form of summary, not sure what
> > the actual status is.
> >
> > If I did my search correctly, there is nothing about Python 3 in any of
> > the 1.10 through 1.14 release notes. Haven't we got something to say
> > about limited support (for build and test?) in some version before 1.14?
> > All I could find was one py3 build fix (r1819444) merged to 1.10.x.
> >
>
> A table like that would be helpful. Hopefully someone knows what the
> actual status of 1.10 is. I guess it can be tested. Only the latest,
> 1.10.6, should be tested.
On 1.10.x svnserveautocheck doesn't support py3, at least. (There may be
additional issues.)
Cheers,
Daniel
Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
On Thu, Nov 28, 2019 at 4:05 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Yasuhito FUTATSUKI wrote on Thu, Nov 28, 2019 at 20:36:25 +0900:
> > And there seems to be also some scripts calling Python
> > interpreter with -c option.
> >
> > I roughly searched:
> > [[[
> > $ find . -name .svn -prune -or -type f -print0 | xargs -0 egrep -i '(^|[^-])python.* -c'
>
> I suggest to also grep for «sys.executable»; there are several
> instances of that in trunk.
I did such a search and sys.executable is found in:
./build/run_tests.py
./build/generator/gen_win.py
./build/generator/gen_vcnet_vcproj.py
./build/generator/gen_make.py
./subversion/tests/cmdline/svntest/main.py
./subversion/tests/cmdline/svnadmin_tests.py
./subversion/bindings/ctypes-python/setup.py
I did not find files with extension other than .py containing
sys.executable in latest trunk.
I think nothing has changed about sys.executable in Python 3, so this
should not affect anything.
> Y'all might consider starting a wiki page or a jira issue tracking
> the categorization. I think it might be helpful to tracking the
> work done/punted/pending.
Agreed. I just wanted to get an initial list that is more-or-less
accurate first. I think we're at that starting point now.
Now, I wonder, how should we handle updates to the list as work
progresses? With the wiki we can move items around in the list. With a
Jira issue, would we add a comment with an updated list each time
item(s) change status?
Meanwhile, here is a summary of the changes between my original list
and the updated list by Yasuhito:
Moved to "Python 3 Supported":
. gen-make.py
Moved to "Python 3 Not Supported Yet":
. contrib/client-side/svnmerge/svnmerge-migrate-test.sh
Moved to a new section "Unmaintained":
. subversion/bindings/ctypes-python/test/*
. subversion/libsvn_subr/genctype.py
Added to "Python 3 Supported":
. Makefile.in
. build/ac-macros/swig.m4
. subversion/tests/cmdline/davautocheck.sh
. subversion/tests/cmdline/svnserveautocheck.sh
Added to "Not Checked For Python 3 Yet":
. tools/hook-scripts/mailer/tests/mailer-t1.sh
. tools/dev/benchmarks/large_dirs/create_bigdir.sh
. tools/backup/hot-backup.py.in
. tools/server-side/svnpubsub/svnpubsub.tac
. tools/examples/SvnCLBrowse
. contrib/hook-scripts/enforcer/enforcer
. contrib/server-side/load_repo_with_mergesensitive_copy.sh
Cheers,
Nathan
Re: Merging branches/swig-py3 to trunk
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Yasuhito FUTATSUKI wrote on Thu, Nov 28, 2019 at 20:36:25 +0900:
> And there seems to be also some scripts calling Python
> interpreter with -c option.
>
> I roughly searched:
> [[[
> $ find . -name .svn -prune -or -type f -print0 | xargs -0 egrep -i '(^|[^-])python.* -c'
I suggest to also grep for «sys.executable»; there are several instances of
that in trunk.
> ]]]
>
> and got:
>
> Python 3 Supported:
> Makefile.in
> build/ac-macros/swig.m4
> subversion/tests/cmdline/davautocheck.sh
> subversion/tests/cmdline/svnserveautocheck.sh
>
> Python 3 not supported yet:
> contrib/client-side/svnmerge/svnmerge-migrate-test.sh
>
> Not Checked For Python 3 Yet:
> tools/hook-scripts/mailer/tests/mailer-t1.sh
> tools/dev/benchmarks/large_dirs/create_bigdir.sh
Y'all might consider starting a wiki page or a jira issue tracking the
categorization. I think it might be helpful to tracking the work
done/punted/pending.
Cheers,
Daniel
Re: Merging branches/swig-py3 to trunk
Posted by Branko Čibej <br...@apache.org>.
On 28.11.2019 02:54, Nathan Hartman wrote:
> contrib/client-side/svnmerge/svnmerge-migrate-history.py
> contrib/client-side/svnmerge/svnmerge_test.py
> contrib/client-side/svnmerge/svnmerge.py
> contrib/client-side/svnmerge/svnmerge-migrate-history-remotely.py
I think we should move 'svnmerge' to the unmaintained and unsupported
category as well. It predates merge tracking support in Subversion
itself and I see no reason to keep it in contrib/ any more.
If anyone is still using it, they can get it from one of the old release
branches or tags.
-- Brane
Re: Merging branches/swig-py3 to trunk
Posted by Yasuhito FUTATSUKI <fu...@poem.co.jp>.
On 2019/11/28 10:54, Nathan Hartman wrote:
> FYI I have made a list of all our Python scripts, categorized in a
> very *preliminary* manner into one of three categories:
> * Python 3 supported
> * Python 3 not supported yet
> * Not checked yet
>
> It is preliminary because I've based my categorization on recent
> discussions. The intention is to test and then put each script into
> the correct category.
Thank you very much.
There are some Python scripts (or a template, or a generator)
which don't have '.py' file extension.
[[[
$ find . -name .svn -prune -or ! -name '*.py' -type f -print0 | xargs -0 egrep -l '^#\!.*python' | sed -e 's/^\.\///'
tools/backup/hot-backup.py.in
tools/server-side/svnpubsub/svnpubsub.tac
tools/examples/SvnCLBrowse
contrib/hook-scripts/enforcer/enforcer
contrib/server-side/load_repo_with_mergesensitive_copy.sh
]]]
Those are categorized to "Not yet checked".
And there seems to be also some scripts calling Python
interpreter with -c option.
I roughly searched:
[[[
$ find . -name .svn -prune -or -type f -print0 | xargs -0 egrep -i '(^|[^-])python.* -c'
./subversion/tests/cmdline/davautocheck.sh: REPLY=`$PYTHON -u -c "$prog" "$@"`
./subversion/tests/cmdline/svnserveautocheck.sh: REPLY=`$PYTHON -u -c "$prog" "$@"`
./subversion/tests/cmdline/svnserveautocheck.sh: $PYTHON -c 'import random; print(random.randint(1024, 2**16-1))'
./build/ac-macros/swig.m4: $PYTHON -c 'import sys; sys.exit(0x3000000 > sys.hexversion)' && \
./tools/buildbot/slaves/win32-xp-VS2005/svncheck.bat:python win-tests.py %TEST_DIR%\%FS_TYPE% -f %FS_TYPE% -c -r
./tools/buildbot/slaves/win32-xp-VS2005/svncheck.bat:python win-tests.py %TEST_DIR%\%FS_TYPE% -f %FS_TYPE% -c -r -u svn://localhost
./tools/buildbot/slaves/win32-xp-VS2005/svncheck.bat:python win-tests.py %TEST_DIR%\%FS_TYPE% -f %FS_TYPE% -c -r --httpd-dir="%HTTPD_BIN_DIR%" --httpd-port 1234
./tools/hook-scripts/mailer/tests/mailer-t1.sh:for rev in `python -c "print(\" \".join(map(str, range(1,$youngest+1))))"`; do
./tools/dev/benchmarks/large_dirs/create_bigdir.sh: (jot - "$1" "$2" "1" 2>/dev/null || seq -s ' ' "$1" "$2" 2>/dev/null || python -c "for i in range($1,$2+1): print(i)")
./contrib/client-side/svnmerge/svnmerge-migrate-test.sh:SCRIPT_DIR=$(python -c "import os; print os.path.abspath(\"`dirname $0`\")")
./INSTALL: C:>python win-tests.py -c -r -v
./INSTALL: C:>python win-tests.py -c -r -v -u http://localhost
./Makefile.in:COMPILE_SWIG_PY = $(LIBTOOL) $(LTFLAGS) --mode=compile $(SWIG_PY_COMPILE) $(CPPFLAGS) $(LT_CFLAGS) -DSWIGPYTHON $(SWIG_PY_INCLUDES) $(INCLUDES) -o $@ -c
./Makefile.in: $(PYTHON) -c 'import compileall; \
./Makefile.in:READLINK_PY=$(PYTHON) -c 'import sys,os; print(os.path.realpath(sys.argv[1]))'
]]]
and got:
Python 3 Supported:
Makefile.in
build/ac-macros/swig.m4
subversion/tests/cmdline/davautocheck.sh
subversion/tests/cmdline/svnserveautocheck.sh
Python 3 not supported yet:
contrib/client-side/svnmerge/svnmerge-migrate-test.sh
Not Checked For Python 3 Yet:
tools/hook-scripts/mailer/tests/mailer-t1.sh
tools/dev/benchmarks/large_dirs/create_bigdir.sh
> Since there are many scripts, I'm trying to find the "best" automated
> way to determine which are compatible with Python 3.
>
> I would prefer a static analysis method because I don't necessarily
> have a use-case to run every single script.
>
> So far I have installed pylint3 and played with it a bit.
I agree with your reason to prefer a static analysis method,
however I doubt that we can use automated tools that can detect
inappropriate bytes - str types handling, or valid usage of '/'
operator (,or some thing like that but I don't think of, right now).
If they can't, they can only detect which are incompatible with
Python 3 (and I guess not many scripts can be detected as
incompatible in this level, because it seems they were repeatedly
fixed toward Python 3 support).
> My preliminary list follows...
>
> If anyone happens to know (off the top of their head) that my
> categorization of a script is incorrect, please let me know.
>
> Once the list seems correct, I'll file an issue to help us keep track
> of progress, and link to it from the "Known Issues" section of the
> 1.14 release notes as discussed here some days ago...
Here is updated list, with suggestion in mail
<1d...@apache.org>.
List:
Python 3 Supported
==================
build/getversion.py
build/run_tests.py
build/transform_sql.py
build/generator/gen_win_dependencies.py
build/generator/gen_win.py
build/generator/gen_vcnet_vcproj.py
build/generator/swig/external_runtime.py
build/generator/swig/__init__.py
build/generator/swig/header_wrappers.py
build/generator/swig/checkout_swig_header.py
build/generator/util/__init__.py
build/generator/__init__.py
build/generator/extractor.py
build/generator/gen_make.py
build/generator/gen_base.py
build/generator/ezt.py
build/transform_config_hw.py
build/get-py-info.py
build/win32/make_dist.py
subversion/tests/cmdline/mod_authz_svn_tests.py
subversion/tests/cmdline/history_tests.py
subversion/tests/cmdline/dav_tests.py
subversion/tests/cmdline/input_validation_tests.py
subversion/tests/cmdline/log_tests.py
subversion/tests/cmdline/merge_automatic_tests.py
subversion/tests/cmdline/merge_reintegrate_tests.py
subversion/tests/cmdline/lock_tests.py
subversion/tests/cmdline/merge_tests.py
subversion/tests/cmdline/copy_tests.py
subversion/tests/cmdline/svnversion_tests.py
subversion/tests/cmdline/svneditor.py
subversion/tests/cmdline/basic_tests.py
subversion/tests/cmdline/svnlook_tests.py
subversion/tests/cmdline/prop_tests.py
subversion/tests/cmdline/merge_authz_tests.py
subversion/tests/cmdline/resolve_tests.py
subversion/tests/cmdline/revert_tests.py
subversion/tests/cmdline/svntest/tree.py
subversion/tests/cmdline/svntest/wc.py
subversion/tests/cmdline/svntest/testcase.py
subversion/tests/cmdline/svntest/actions.py
subversion/tests/cmdline/svntest/__init__.py
subversion/tests/cmdline/svntest/mergetrees.py
subversion/tests/cmdline/svntest/factory.py
subversion/tests/cmdline/svntest/deeptrees.py
subversion/tests/cmdline/svntest/sandbox.py
subversion/tests/cmdline/svntest/verify.py
subversion/tests/cmdline/svntest/objects.py
subversion/tests/cmdline/svntest/main.py
subversion/tests/cmdline/svntest/err.py
subversion/tests/cmdline/svnauthz_tests.py
subversion/tests/cmdline/schedule_tests.py
subversion/tests/cmdline/entries_tests.py
subversion/tests/cmdline/patch_tests.py
subversion/tests/cmdline/export_tests.py
subversion/tests/cmdline/iprop_tests.py
subversion/tests/cmdline/commit_tests.py
subversion/tests/cmdline/authz_tests.py
subversion/tests/cmdline/legacy/utf8_tests.py
subversion/tests/cmdline/move_tests.py
subversion/tests/cmdline/changelist_tests.py
subversion/tests/cmdline/mergeinfo_tests.py
subversion/tests/cmdline/redirect_tests.py
subversion/tests/cmdline/getopt_tests.py
subversion/tests/cmdline/shelf_tests.py
subversion/tests/cmdline/special_tests.py
subversion/tests/cmdline/svnsync_authz_tests.py
subversion/tests/cmdline/depth_tests.py
subversion/tests/cmdline/trans_tests.py
subversion/tests/cmdline/autoprop_tests.py
subversion/tests/cmdline/import_tests.py
subversion/tests/cmdline/merge_tree_conflict_tests.py
subversion/tests/cmdline/stat_tests.py
subversion/tests/cmdline/pegrev_parse_tests.py
subversion/tests/cmdline/svnrdump_tests.py
subversion/tests/cmdline/info_tests.py
subversion/tests/cmdline/switch_tests.py
subversion/tests/cmdline/externals_tests.py
subversion/tests/cmdline/svnadmin_tests.py
subversion/tests/cmdline/wc_tests.py
subversion/tests/cmdline/cat_tests.py
subversion/tests/cmdline/update_tests.py
subversion/tests/cmdline/mod_dav_svn_tests.py
subversion/tests/cmdline/upgrade_tests.py
subversion/tests/cmdline/iprop_authz_tests.py
subversion/tests/cmdline/blame_tests.py
subversion/tests/cmdline/svnmover_tests.py
subversion/tests/cmdline/svndumpfilter_tests.py
subversion/tests/cmdline/svnmucc_tests.py
subversion/tests/cmdline/svnfsfs_tests.py
subversion/tests/cmdline/svnsync_tests.py
subversion/tests/cmdline/tree_conflict_tests.py
subversion/tests/cmdline/checkout_tests.py
subversion/tests/cmdline/relocate_tests.py
subversion/tests/cmdline/diff_tests.py
subversion/bindings/swig/python/svn/wc.py
subversion/bindings/swig/python/svn/client.py
subversion/bindings/swig/python/svn/__init__.py
subversion/bindings/swig/python/svn/core.py
subversion/bindings/swig/python/svn/repos.py
subversion/bindings/swig/python/svn/fs.py
subversion/bindings/swig/python/svn/delta.py
subversion/bindings/swig/python/svn/diff.py
subversion/bindings/swig/python/svn/ra.py
subversion/bindings/swig/python/tests/auth.py
subversion/bindings/swig/python/tests/wc.py
subversion/bindings/swig/python/tests/checksum.py
subversion/bindings/swig/python/tests/setup_path.py
subversion/bindings/swig/python/tests/client.py
subversion/bindings/swig/python/tests/trac/__init__.py
subversion/bindings/swig/python/tests/trac/test.py
subversion/bindings/swig/python/tests/trac/versioncontrol/tests/__init__.py
subversion/bindings/swig/python/tests/trac/versioncontrol/tests/svn_fs.py
subversion/bindings/swig/python/tests/trac/versioncontrol/__init__.py
subversion/bindings/swig/python/tests/trac/versioncontrol/main.py
subversion/bindings/swig/python/tests/trac/versioncontrol/svn_fs.py
subversion/bindings/swig/python/tests/core.py
subversion/bindings/swig/python/tests/mergeinfo.py
subversion/bindings/swig/python/tests/utils.py
subversion/bindings/swig/python/tests/fs.py
subversion/bindings/swig/python/tests/typemap.py
subversion/bindings/swig/python/tests/delta.py
subversion/bindings/swig/python/tests/run_all.py
subversion/bindings/swig/python/tests/repository.py
subversion/bindings/swig/python/tests/pool.py
subversion/bindings/swig/python/tests/ra.py
subversion/bindings/swig/python/__init__.py
subversion/bindings/swig/include/proxy.py
gen-make.py
Makefile.in
build/ac-macros/swig.m4
subversion/tests/cmdline/davautocheck.sh
subversion/tests/cmdline/svnserveautocheck.sh
Python 3 Not Supported Yet
==========================
tools/server-side/fsfs-reshard.py
tools/server-side/svn-backup-dumps.py
tools/server-side/svnpredumpfilter.py
tools/server-side/svn_server_log_parse.py
tools/server-side/test_svn_server_log_parse.py
tools/hook-scripts/mailer/mailer.py
contrib/client-side/svnmerge/svnmerge-migrate-test.sh
Not Checked For Python 3 Yet
============================
tools/hook-scripts/log-police.py
tools/hook-scripts/persist-ephemeral-txnprops.py
tools/hook-scripts/mailer/tests/mailer-tweak.py
tools/hook-scripts/validate-extensions.py
tools/hook-scripts/control-chars.py
tools/hook-scripts/CVE-2017-9800-pre-commit.py
tools/hook-scripts/svnperms.py
tools/hook-scripts/validate-files.py
tools/hook-scripts/verify-po.py
tools/hook-scripts/svn2feed.py
tools/client-side/svn-viewspec.py
tools/client-side/mergeinfo-sanitizer.py
tools/client-side/server-version.py
tools/client-side/change-svn-wc-format.py
tools/client-side/svn-vendor.py
tools/client-side/svnviewspec_test.py
tools/dist/backport_tests_py.py
tools/dist/backport_tests.py
tools/dist/merge-approved-backports.py
tools/dist/changes-to-html.py
tools/dist/release.py
tools/dist/security/_gnupg.py
tools/dist/security/__init__.py
tools/dist/security/mailinglist.py
tools/dist/security/parser.py
tools/dist/security/adviser.py
tools/dist/security/mailer.py
tools/dist/backport/__init__.py
tools/dist/backport/status.py
tools/dist/backport/merger.py
tools/dist/advisory.py
tools/dist/backport_tests_pl.py
tools/dist/checksums.py
tools/dist/detect-conflicting-backports.py
tools/po/l10n-report.py
tools/examples/getfile.py
tools/examples/revplist.py
tools/examples/walk-config-auth.py
tools/examples/check-modified.py
tools/examples/geturl.py
tools/examples/putfile.py
tools/examples/svnlook.py
tools/examples/svnshell.py
tools/examples/blame.py
tools/examples/get-location-segments.py
tools/examples/dumpprops.py
tools/dev/graph-dav-servers.py
tools/dev/datecheck.py
tools/dev/gen-py-errors.py
tools/dev/normalize-dump.py
tools/dev/check-license.py
tools/dev/contribulyze.py
tools/dev/merge-graph.py
tools/dev/histogram.py
tools/dev/iz/find-fix.py
tools/dev/iz/ff2csv.py
tools/dev/scramble-tree.py
tools/dev/gen_junit_report.py
tools/dev/sbox-ospath.py
tools/dev/trails.py
tools/dev/wc-ng/count-progress.py
tools/dev/wc-ng/graph-data.py
tools/dev/wc-ng/bump-to-19.py
tools/dev/wc-ng/populate-pristine.py
tools/dev/mergegraph/save_as_sh.py
tools/dev/mergegraph/__init__.py
tools/dev/mergegraph/mergegraph.py
tools/dev/lock-check.py
tools/dev/wc-format.py
tools/dev/random-commits.py
tools/dev/analyze-svnlogs.py
tools/dev/mklog.py
tools/dev/find-control-statements.py
tools/dev/gen-javahl-errors.py
tools/dev/benchmarks/suite1/benchmark.py
tools/dev/benchmarks/RepoPerf/copy_repo.py
tools/dev/benchmarks/RepoPerf/win_repo_bench.py
tools/dev/mlpatch.py
tools/dev/which-error.py
tools/dev/find-bad-style.py
tools/dev/svn-merge-revs.py
tools/dev/verify-history.py
tools/dev/gdb-py/svndbg/__init__.py
tools/dev/gdb-py/svndbg/printers.py
tools/dev/log_revnum_change_asf.py
tools/dev/po-merge.py
tools/bdb/erase-all-text-data.py
tools/bdb/svn-bdb-view.py
tools/bdb/whatis-rep.py
tools/bdb/svnfs.py
tools/bdb/skel.py
tools/server-side/svnpubsub/svnwcsub.py
tools/server-side/svnpubsub/revprop-change-hook.py
tools/server-side/svnpubsub/daemonize.py
tools/server-side/svnpubsub/svnpubsub/server.py
tools/server-side/svnpubsub/svnpubsub/util.py
tools/server-side/svnpubsub/svnpubsub/client.py
tools/server-side/svnpubsub/svnpubsub/__init__.py
tools/server-side/svnpubsub/svntweet.py
tools/server-side/svnpubsub/watcher.py
tools/server-side/svnpubsub/commit-hook.py
tools/server-side/svnpubsub/irkerbridge.py
tools/server-side/svnpubsub/testserver.py
win-tests.py
contrib/hook-scripts/pre-lock-require-needs-lock.py
contrib/hook-scripts/case-insensitive.py
contrib/hook-scripts/remove-zombie-locks.py
contrib/hook-scripts/commit-block-joke.py
contrib/hook-scripts/pre-commit-check.py
contrib/hook-scripts/hook_toolbox.py
contrib/client-side/svn_apply_autoprops.py
contrib/client-side/svn-hgmerge.py
contrib/client-side/incremental-update.py
contrib/client-side/svn_export_empty_files.py
contrib/client-side/svn-merge-vendor.py
contrib/client-side/svnmerge/svnmerge-migrate-history.py
contrib/client-side/svnmerge/svnmerge_test.py
contrib/client-side/svnmerge/svnmerge.py
contrib/client-side/svnmerge/svnmerge-migrate-history-remotely.py
contrib/server-side/authz_svn_group.py
contrib/server-side/add-needs-lock.py
contrib/server-side/fsfsfixer/fixer/fix-rev.py
contrib/server-side/fsfsfixer/fixer/__init__.py
contrib/server-side/fsfsfixer/fixer/find_good_id.py
contrib/server-side/fsfsfixer/fixer/fixer_config.py
contrib/server-side/svn-tweak-author.py
contrib/server-side/fsfsverify.py
notes/move-tracking/path_pairs_to_eid_map.py
notes/directory-index/dirindex.py
notes/directory-index/logimport.py
.ycm_extra_conf.py
subversion/tests/manual/tree-conflicts-add-vs-add.py
tools/backup/hot-backup.py.in
tools/server-side/svnpubsub/svnpubsub.tac
tools/examples/SvnCLBrowse
contrib/hook-scripts/enforcer/enforcer
contrib/server-side/load_repo_with_mergesensitive_copy.sh
tools/hook-scripts/mailer/tests/mailer-t1.sh
tools/dev/benchmarks/large_dirs/create_bigdir.sh
Unmaintained
============
subversion/bindings/ctypes-python/test/localrepos.py
subversion/bindings/ctypes-python/test/wc.py
subversion/bindings/ctypes-python/test/setup_path.py
subversion/bindings/ctypes-python/test/remoterepos.py
subversion/bindings/ctypes-python/test/svntypes.py
subversion/bindings/ctypes-python/test/run_all.py
subversion/bindings/ctypes-python/setup.py
subversion/bindings/ctypes-python/examples/log.py
subversion/bindings/ctypes-python/examples/trunkify.py
subversion/bindings/ctypes-python/examples/mucc.py
subversion/bindings/ctypes-python/examples/example.py
subversion/bindings/ctypes-python/csvn/auth.py
subversion/bindings/ctypes-python/csvn/wc.py
subversion/bindings/ctypes-python/csvn/core/__init__.py
subversion/bindings/ctypes-python/csvn/ext/__init__.py
subversion/bindings/ctypes-python/csvn/ext/listmixin.py
subversion/bindings/ctypes-python/csvn/ext/callback_receiver.py
subversion/bindings/ctypes-python/csvn/__init__.py
subversion/bindings/ctypes-python/csvn/types.py
subversion/bindings/ctypes-python/csvn/repos.py
subversion/bindings/ctypes-python/csvn/txn.py
subversion/libsvn_subr/genctype.py
Cheers,
--
Yasuhito FUTATSUKI <fu...@poem.co.jp>
Re: Merging branches/swig-py3 to trunk
Posted by Branko Čibej <br...@apache.org>.
On 28.11.2019 02:54, Nathan Hartman wrote:
> Not Checked For Python 3 Yet
> ============================
[...]
> gen-make.py
This undoubtedly works with Python 3 because it's part of the
non-tarball build (it's used by autogen.sh).
> subversion/bindings/ctypes-python/test/localrepos.py
> subversion/bindings/ctypes-python/test/wc.py
> subversion/bindings/ctypes-python/test/setup_path.py
> subversion/bindings/ctypes-python/test/remoterepos.py
> subversion/bindings/ctypes-python/test/svntypes.py
> subversion/bindings/ctypes-python/test/run_all.py
> subversion/bindings/ctypes-python/setup.py
> subversion/bindings/ctypes-python/examples/log.py
> subversion/bindings/ctypes-python/examples/trunkify.py
> subversion/bindings/ctypes-python/examples/mucc.py
> subversion/bindings/ctypes-python/examples/example.py
> subversion/bindings/ctypes-python/csvn/auth.py
> subversion/bindings/ctypes-python/csvn/wc.py
> subversion/bindings/ctypes-python/csvn/core/__init__.py
> subversion/bindings/ctypes-python/csvn/ext/__init__.py
> subversion/bindings/ctypes-python/csvn/ext/listmixin.py
> subversion/bindings/ctypes-python/csvn/ext/callback_receiver.py
> subversion/bindings/ctypes-python/csvn/__init__.py
> subversion/bindings/ctypes-python/csvn/types.py
> subversion/bindings/ctypes-python/csvn/repos.py
> subversion/bindings/ctypes-python/csvn/txn.py
> subversion/libsvn_subr/genctype.py
I don't know what to do about the ctypes bindings. The truth is, they
appear to be completely unmaintained and largely untested. We should
probably consider removing them, or at least deprecating them.
-- Brane
Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
On Sat, Nov 23, 2019 at 12:38 AM Yasuhito FUTATSUKI <fu...@poem.co.jp>
wrote:
> Perhaps it is necessary to check all Python scripts except those we
> use on build and release which are already checked.
>
> At least I found those in tools/server-side couldn't work on Python 3:
>
> tools/server-side/fsfs-reshared.py
> (try to write str object on binary mode stream in
> write_fs_format())
> tools/server-side/svn-backup-dumps.py
> (fixed in r1870204)
> tools/server-side/svnpredumpfilter.py
> (AttributeError: module 'string' has no attribute 'strip')
> tools/server-side/svn_server_log_parse.py
> (import svn.core, bytes vs str)
> tools/server-side/test_server_log_parse.py
> (import svn.core, bytes vs str)
>
> (I didn't check files in tools/server-side/svnpubsub)
FYI I have made a list of all our Python scripts, categorized in a
very *preliminary* manner into one of three categories:
* Python 3 supported
* Python 3 not supported yet
* Not checked yet
It is preliminary because I've based my categorization on recent
discussions. The intention is to test and then put each script into
the correct category.
Since there are many scripts, I'm trying to find the "best" automated
way to determine which are compatible with Python 3.
I would prefer a static analysis method because I don't necessarily
have a use-case to run every single script.
So far I have installed pylint3 and played with it a bit.
My preliminary list follows...
If anyone happens to know (off the top of their head) that my
categorization of a script is incorrect, please let me know.
Once the list seems correct, I'll file an issue to help us keep track
of progress, and link to it from the "Known Issues" section of the
1.14 release notes as discussed here some days ago...
List:
Python 3 Supported
==================
build/getversion.py
build/run_tests.py
build/transform_sql.py
build/generator/gen_win_dependencies.py
build/generator/gen_win.py
build/generator/gen_vcnet_vcproj.py
build/generator/swig/external_runtime.py
build/generator/swig/__init__.py
build/generator/swig/header_wrappers.py
build/generator/swig/checkout_swig_header.py
build/generator/util/__init__.py
build/generator/__init__.py
build/generator/extractor.py
build/generator/gen_make.py
build/generator/gen_base.py
build/generator/ezt.py
build/transform_config_hw.py
build/get-py-info.py
build/win32/make_dist.py
subversion/tests/cmdline/mod_authz_svn_tests.py
subversion/tests/cmdline/history_tests.py
subversion/tests/cmdline/dav_tests.py
subversion/tests/cmdline/input_validation_tests.py
subversion/tests/cmdline/log_tests.py
subversion/tests/cmdline/merge_automatic_tests.py
subversion/tests/cmdline/merge_reintegrate_tests.py
subversion/tests/cmdline/lock_tests.py
subversion/tests/cmdline/merge_tests.py
subversion/tests/cmdline/copy_tests.py
subversion/tests/cmdline/svnversion_tests.py
subversion/tests/cmdline/svneditor.py
subversion/tests/cmdline/basic_tests.py
subversion/tests/cmdline/svnlook_tests.py
subversion/tests/cmdline/prop_tests.py
subversion/tests/cmdline/merge_authz_tests.py
subversion/tests/cmdline/resolve_tests.py
subversion/tests/cmdline/revert_tests.py
subversion/tests/cmdline/svntest/tree.py
subversion/tests/cmdline/svntest/wc.py
subversion/tests/cmdline/svntest/testcase.py
subversion/tests/cmdline/svntest/actions.py
subversion/tests/cmdline/svntest/__init__.py
subversion/tests/cmdline/svntest/mergetrees.py
subversion/tests/cmdline/svntest/factory.py
subversion/tests/cmdline/svntest/deeptrees.py
subversion/tests/cmdline/svntest/sandbox.py
subversion/tests/cmdline/svntest/verify.py
subversion/tests/cmdline/svntest/objects.py
subversion/tests/cmdline/svntest/main.py
subversion/tests/cmdline/svntest/err.py
subversion/tests/cmdline/svnauthz_tests.py
subversion/tests/cmdline/schedule_tests.py
subversion/tests/cmdline/entries_tests.py
subversion/tests/cmdline/patch_tests.py
subversion/tests/cmdline/export_tests.py
subversion/tests/cmdline/iprop_tests.py
subversion/tests/cmdline/commit_tests.py
subversion/tests/cmdline/authz_tests.py
subversion/tests/cmdline/legacy/utf8_tests.py
subversion/tests/cmdline/move_tests.py
subversion/tests/cmdline/changelist_tests.py
subversion/tests/cmdline/mergeinfo_tests.py
subversion/tests/cmdline/redirect_tests.py
subversion/tests/cmdline/getopt_tests.py
subversion/tests/cmdline/shelf_tests.py
subversion/tests/cmdline/special_tests.py
subversion/tests/cmdline/svnsync_authz_tests.py
subversion/tests/cmdline/depth_tests.py
subversion/tests/cmdline/trans_tests.py
subversion/tests/cmdline/autoprop_tests.py
subversion/tests/cmdline/import_tests.py
subversion/tests/cmdline/merge_tree_conflict_tests.py
subversion/tests/cmdline/stat_tests.py
subversion/tests/cmdline/pegrev_parse_tests.py
subversion/tests/cmdline/svnrdump_tests.py
subversion/tests/cmdline/info_tests.py
subversion/tests/cmdline/switch_tests.py
subversion/tests/cmdline/externals_tests.py
subversion/tests/cmdline/svnadmin_tests.py
subversion/tests/cmdline/wc_tests.py
subversion/tests/cmdline/cat_tests.py
subversion/tests/cmdline/update_tests.py
subversion/tests/cmdline/mod_dav_svn_tests.py
subversion/tests/cmdline/upgrade_tests.py
subversion/tests/cmdline/iprop_authz_tests.py
subversion/tests/cmdline/blame_tests.py
subversion/tests/cmdline/svnmover_tests.py
subversion/tests/cmdline/svndumpfilter_tests.py
subversion/tests/cmdline/svnmucc_tests.py
subversion/tests/cmdline/svnfsfs_tests.py
subversion/tests/cmdline/svnsync_tests.py
subversion/tests/cmdline/tree_conflict_tests.py
subversion/tests/cmdline/checkout_tests.py
subversion/tests/cmdline/relocate_tests.py
subversion/tests/cmdline/diff_tests.py
subversion/bindings/swig/python/svn/wc.py
subversion/bindings/swig/python/svn/client.py
subversion/bindings/swig/python/svn/__init__.py
subversion/bindings/swig/python/svn/core.py
subversion/bindings/swig/python/svn/repos.py
subversion/bindings/swig/python/svn/fs.py
subversion/bindings/swig/python/svn/delta.py
subversion/bindings/swig/python/svn/diff.py
subversion/bindings/swig/python/svn/ra.py
subversion/bindings/swig/python/tests/auth.py
subversion/bindings/swig/python/tests/wc.py
subversion/bindings/swig/python/tests/checksum.py
subversion/bindings/swig/python/tests/setup_path.py
subversion/bindings/swig/python/tests/client.py
subversion/bindings/swig/python/tests/trac/__init__.py
subversion/bindings/swig/python/tests/trac/test.py
subversion/bindings/swig/python/tests/trac/versioncontrol/tests/__init__.py
subversion/bindings/swig/python/tests/trac/versioncontrol/tests/svn_fs.py
subversion/bindings/swig/python/tests/trac/versioncontrol/__init__.py
subversion/bindings/swig/python/tests/trac/versioncontrol/main.py
subversion/bindings/swig/python/tests/trac/versioncontrol/svn_fs.py
subversion/bindings/swig/python/tests/core.py
subversion/bindings/swig/python/tests/mergeinfo.py
subversion/bindings/swig/python/tests/utils.py
subversion/bindings/swig/python/tests/fs.py
subversion/bindings/swig/python/tests/typemap.py
subversion/bindings/swig/python/tests/delta.py
subversion/bindings/swig/python/tests/run_all.py
subversion/bindings/swig/python/tests/repository.py
subversion/bindings/swig/python/tests/pool.py
subversion/bindings/swig/python/tests/ra.py
subversion/bindings/swig/python/__init__.py
subversion/bindings/swig/include/proxy.py
Python 3 Not Supported Yet
==========================
tools/server-side/fsfs-reshard.py
tools/server-side/svn-backup-dumps.py
tools/server-side/svnpredumpfilter.py
tools/server-side/svn_server_log_parse.py
tools/server-side/test_svn_server_log_parse.py
tools/hook-scripts/mailer/mailer.py
Not Checked For Python 3 Yet
============================
tools/hook-scripts/log-police.py
tools/hook-scripts/persist-ephemeral-txnprops.py
tools/hook-scripts/mailer/tests/mailer-tweak.py
tools/hook-scripts/validate-extensions.py
tools/hook-scripts/control-chars.py
tools/hook-scripts/CVE-2017-9800-pre-commit.py
tools/hook-scripts/svnperms.py
tools/hook-scripts/validate-files.py
tools/hook-scripts/verify-po.py
tools/hook-scripts/svn2feed.py
tools/client-side/svn-viewspec.py
tools/client-side/mergeinfo-sanitizer.py
tools/client-side/server-version.py
tools/client-side/change-svn-wc-format.py
tools/client-side/svn-vendor.py
tools/client-side/svnviewspec_test.py
tools/dist/backport_tests_py.py
tools/dist/backport_tests.py
tools/dist/merge-approved-backports.py
tools/dist/changes-to-html.py
tools/dist/release.py
tools/dist/security/_gnupg.py
tools/dist/security/__init__.py
tools/dist/security/mailinglist.py
tools/dist/security/parser.py
tools/dist/security/adviser.py
tools/dist/security/mailer.py
tools/dist/backport/__init__.py
tools/dist/backport/status.py
tools/dist/backport/merger.py
tools/dist/advisory.py
tools/dist/backport_tests_pl.py
tools/dist/checksums.py
tools/dist/detect-conflicting-backports.py
tools/po/l10n-report.py
tools/examples/getfile.py
tools/examples/revplist.py
tools/examples/walk-config-auth.py
tools/examples/check-modified.py
tools/examples/geturl.py
tools/examples/putfile.py
tools/examples/svnlook.py
tools/examples/svnshell.py
tools/examples/blame.py
tools/examples/get-location-segments.py
tools/examples/dumpprops.py
tools/dev/graph-dav-servers.py
tools/dev/datecheck.py
tools/dev/gen-py-errors.py
tools/dev/normalize-dump.py
tools/dev/check-license.py
tools/dev/contribulyze.py
tools/dev/merge-graph.py
tools/dev/histogram.py
tools/dev/iz/find-fix.py
tools/dev/iz/ff2csv.py
tools/dev/scramble-tree.py
tools/dev/gen_junit_report.py
tools/dev/sbox-ospath.py
tools/dev/trails.py
tools/dev/wc-ng/count-progress.py
tools/dev/wc-ng/graph-data.py
tools/dev/wc-ng/bump-to-19.py
tools/dev/wc-ng/populate-pristine.py
tools/dev/mergegraph/save_as_sh.py
tools/dev/mergegraph/__init__.py
tools/dev/mergegraph/mergegraph.py
tools/dev/lock-check.py
tools/dev/wc-format.py
tools/dev/random-commits.py
tools/dev/analyze-svnlogs.py
tools/dev/mklog.py
tools/dev/find-control-statements.py
tools/dev/gen-javahl-errors.py
tools/dev/benchmarks/suite1/benchmark.py
tools/dev/benchmarks/RepoPerf/copy_repo.py
tools/dev/benchmarks/RepoPerf/win_repo_bench.py
tools/dev/mlpatch.py
tools/dev/which-error.py
tools/dev/find-bad-style.py
tools/dev/svn-merge-revs.py
tools/dev/verify-history.py
tools/dev/gdb-py/svndbg/__init__.py
tools/dev/gdb-py/svndbg/printers.py
tools/dev/log_revnum_change_asf.py
tools/dev/po-merge.py
tools/bdb/erase-all-text-data.py
tools/bdb/svn-bdb-view.py
tools/bdb/whatis-rep.py
tools/bdb/svnfs.py
tools/bdb/skel.py
tools/server-side/svnpubsub/svnwcsub.py
tools/server-side/svnpubsub/revprop-change-hook.py
tools/server-side/svnpubsub/daemonize.py
tools/server-side/svnpubsub/svnpubsub/server.py
tools/server-side/svnpubsub/svnpubsub/util.py
tools/server-side/svnpubsub/svnpubsub/client.py
tools/server-side/svnpubsub/svnpubsub/__init__.py
tools/server-side/svnpubsub/svntweet.py
tools/server-side/svnpubsub/watcher.py
tools/server-side/svnpubsub/commit-hook.py
tools/server-side/svnpubsub/irkerbridge.py
tools/server-side/svnpubsub/testserver.py
win-tests.py
contrib/hook-scripts/pre-lock-require-needs-lock.py
contrib/hook-scripts/case-insensitive.py
contrib/hook-scripts/remove-zombie-locks.py
contrib/hook-scripts/commit-block-joke.py
contrib/hook-scripts/pre-commit-check.py
contrib/hook-scripts/hook_toolbox.py
contrib/client-side/svn_apply_autoprops.py
contrib/client-side/svn-hgmerge.py
contrib/client-side/incremental-update.py
contrib/client-side/svn_export_empty_files.py
contrib/client-side/svn-merge-vendor.py
contrib/client-side/svnmerge/svnmerge-migrate-history.py
contrib/client-side/svnmerge/svnmerge_test.py
contrib/client-side/svnmerge/svnmerge.py
contrib/client-side/svnmerge/svnmerge-migrate-history-remotely.py
contrib/server-side/authz_svn_group.py
contrib/server-side/add-needs-lock.py
contrib/server-side/fsfsfixer/fixer/fix-rev.py
contrib/server-side/fsfsfixer/fixer/__init__.py
contrib/server-side/fsfsfixer/fixer/find_good_id.py
contrib/server-side/fsfsfixer/fixer/fixer_config.py
contrib/server-side/svn-tweak-author.py
contrib/server-side/fsfsverify.py
notes/move-tracking/path_pairs_to_eid_map.py
notes/directory-index/dirindex.py
notes/directory-index/logimport.py
.ycm_extra_conf.py
gen-make.py
subversion/tests/manual/tree-conflicts-add-vs-add.py
subversion/bindings/ctypes-python/test/localrepos.py
subversion/bindings/ctypes-python/test/wc.py
subversion/bindings/ctypes-python/test/setup_path.py
subversion/bindings/ctypes-python/test/remoterepos.py
subversion/bindings/ctypes-python/test/svntypes.py
subversion/bindings/ctypes-python/test/run_all.py
subversion/bindings/ctypes-python/setup.py
subversion/bindings/ctypes-python/examples/log.py
subversion/bindings/ctypes-python/examples/trunkify.py
subversion/bindings/ctypes-python/examples/mucc.py
subversion/bindings/ctypes-python/examples/example.py
subversion/bindings/ctypes-python/csvn/auth.py
subversion/bindings/ctypes-python/csvn/wc.py
subversion/bindings/ctypes-python/csvn/core/__init__.py
subversion/bindings/ctypes-python/csvn/ext/__init__.py
subversion/bindings/ctypes-python/csvn/ext/listmixin.py
subversion/bindings/ctypes-python/csvn/ext/callback_receiver.py
subversion/bindings/ctypes-python/csvn/__init__.py
subversion/bindings/ctypes-python/csvn/types.py
subversion/bindings/ctypes-python/csvn/repos.py
subversion/bindings/ctypes-python/csvn/txn.py
subversion/libsvn_subr/genctype.py
Cheers,
Nathan
Re: [offlist] Re: Merging branches/swig-py3 to trunk
Posted by Yasuhito FUTATSUKI <fu...@poem.co.jp>.
On 2019/11/12 12:13, Nathan Hartman wrote:
> On Fri, Nov 8, 2019 at 3:13 AM Julian Foad <ju...@apache.org> wrote:
>
>> Nathan Hartman wrote:
>>> Question: Some Python scripts have not been updated for Python 3.x
>>> yet. Should those be listed in the release notes under "Known Issues"?
>>> Should a bug be filed? Or both?
>>
>> Both: an Issue tracking which ones are known broken or untested, and a
>> pointer to it in the release notes.
>>
>
> Recently, Yasuhito posted a thread titled "List of Python scripts
> importing svn.*" I think those are the scripts that need to be checked
> for Python 3 compatibility? Or is it necessary to check all Python
> scripts?
Perhaps it is necessary to check all Python scripts except those we
use on build and release which are already checked.
At least I found those in tools/server-side couldn't work on Python 3:
tools/server-side/fsfs-reshared.py
(try to write str object on binary mode stream in
write_fs_format())
tools/server-side/svn-backup-dumps.py
(fixed in r1870204)
tools/server-side/svnpredumpfilter.py
(AttributeError: module 'string' has no attribute 'strip')
tools/server-side/svn_server_log_parse.py
(import svn.core, bytes vs str)
tools/server-side/test_server_log_parse.py
(import svn.core, bytes vs str)
(I didn't check files in tools/server-side/svnpubsub)
Cheers,
--
Yasuhito FUTATSUKI <fu...@poem.co.jp>
Re: [offlist] Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Nov 8, 2019 at 3:13 AM Julian Foad <ju...@apache.org> wrote:
> Nathan Hartman wrote:
> > Question: Some Python scripts have not been updated for Python 3.x
> > yet. Should those be listed in the release notes under "Known Issues"?
> > Should a bug be filed? Or both?
>
> Both: an Issue tracking which ones are known broken or untested, and a
> pointer to it in the release notes.
>
Recently, Yasuhito posted a thread titled "List of Python scripts
importing svn.*" I think those are the scripts that need to be checked
for Python 3 compatibility? Or is it necessary to check all Python
scripts?
Is it preferred to create one issue to track this, or to first check
Python scripts and then create an issue per script that is found to be
incompatible with Python 3?
More below:
> The updated text:
> >
> > [[[
> >
> > Support for Python 3.x:
> >
> > Some optional features of Subversion utilize the Python scripting
> > language.
> >
> > Subversion's SWIG Python bindings and automated test suite now support
> > Python 3.x (and newer).
> >
> > Support for Python 2.7 is being phased out:
> >
> > As of 1 January 2020, Python 2.7 has reached end of life. This means
> > that Python 2.7 will no longer receive maintenance releases or
> > patches, even for security issues. All users are strongly encouraged
> > to move to Python 3.
> >
> > As Subversion 1.14 is a Long Term Support (LTS) release with planned
> > support into 2024, well beyond end-of-life for Python 2.7, the
> > Subversion developers cannot commit to supporting and testing with
> > Python 2.7, or to fixing bugs that affect Python 2.7 only, for the
> > duration of this support period.
> >
> > This means that although Subversion 1.14.0 still technically works
> > with Python 2.7, any later 1.14.x point release may drop this support
> > if it becomes too difficult to maintain.
> >
> > If you must continue using Python 2.7, our previous Long Term Support
> > release, Subversion 1.10, is supported until 2022. Python 2.7 support
> > will not be removed from Subversion 1.10.
> >
> > Note that Subversion does not require Python for its basic operation.
> > If you are not using Subversion's SWIG Python bindings, automated test
> > suite, or other Python-coded tools that ship with Subversion, this
> > change does not affect you.
> >
> > ]]]
>
> Sounds good to me.
>
> Maybe add a note that in "3.x" we intend to choose a specific "x", in
> case we forget to update the text when we choose one?
>
Can we just pick one now rather than put it off and forget?
I suggest some sort of "rolling" support for Python, where each 1.14.x
point release will support all Python 3.x releases that are not EOL at
the time of that point release.
That is:
* When 1.14.0 is released, Python 3.5 will still have 8 months of
support. Therefore, we will support Python 3.5 through 3.8.
* Then, as a hypothetical example, suppose that 1.14.2 is released in
2021. Python 3.5 would be EOL. Therefore, we would NOT support
Python 3.5 anymore, but would support Python 3.6 through 3.9.
Thoughts?
For reference, the Python support period graphic you linked before is
here: https://python-release-cycle.glitch.me
More below...
I think it would be useful to have the info also available in summary
> form, a small table. We might want to put the summary in various
> places, not just in the release notes but in maybe another web page
> and/or emails etc. Something like:
>
> svn 1.9 Py 2.7 supported, Py 3.x not working
> svn 1.10 Py 2.7 supported, Py 3.x+ supported for build & test, not
> working for bindings (?)
> svn 1.14 Py 2.7 unsupported (working in 1.14.0), Py 3.x supported
>
> For 1.10 I am offering an example of the form of summary, not sure what
> the actual status is.
>
> If I did my search correctly, there is nothing about Python 3 in any of
> the 1.10 through 1.14 release notes. Haven't we got something to say
> about limited support (for build and test?) in some version before 1.14?
> All I could find was one py3 build fix (r1819444) merged to 1.10.x.
>
A table like that would be helpful. Hopefully someone knows what the
actual status of 1.10 is. I guess it can be tested. Only the latest,
1.10.6, should be tested.
Cheers,
Nathan
Re: [offlist] Re: Merging branches/swig-py3 to trunk
Posted by Julian Foad <ju...@apache.org>.
Nathan Hartman wrote:
> Question: Some Python scripts have not been updated for Python 3.x
> yet. Should those be listed in the release notes under "Known Issues"?
> Should a bug be filed? Or both?
Both: an Issue tracking which ones are known broken or untested, and a
pointer to it in the release notes.
> The updated text:
>
> [[[
>
> Support for Python 3.x:
>
> Some optional features of Subversion utilize the Python scripting
> language.
>
> Subversion's SWIG Python bindings and automated test suite now support
> Python 3.x (and newer).
>
> Support for Python 2.7 is being phased out:
>
> As of 1 January 2020, Python 2.7 has reached end of life. This means
> that Python 2.7 will no longer receive maintenance releases or
> patches, even for security issues. All users are strongly encouraged
> to move to Python 3.
>
> As Subversion 1.14 is a Long Term Support (LTS) release with planned
> support into 2024, well beyond end-of-life for Python 2.7, the
> Subversion developers cannot commit to supporting and testing with
> Python 2.7, or to fixing bugs that affect Python 2.7 only, for the
> duration of this support period.
>
> This means that although Subversion 1.14.0 still technically works
> with Python 2.7, any later 1.14.x point release may drop this support
> if it becomes too difficult to maintain.
>
> If you must continue using Python 2.7, our previous Long Term Support
> release, Subversion 1.10, is supported until 2022. Python 2.7 support
> will not be removed from Subversion 1.10.
>
> Note that Subversion does not require Python for its basic operation.
> If you are not using Subversion's SWIG Python bindings, automated test
> suite, or other Python-coded tools that ship with Subversion, this
> change does not affect you.
>
> ]]]
Sounds good to me.
Maybe add a note that in "3.x" we intend to choose a specific "x", in
case we forget to update the text when we choose one?
I think it would be useful to have the info also available in summary
form, a small table. We might want to put the summary in various
places, not just in the release notes but in maybe another web page
and/or emails etc. Something like:
svn 1.9 Py 2.7 supported, Py 3.x not working
svn 1.10 Py 2.7 supported, Py 3.x+ supported for build & test, not
working for bindings (?)
svn 1.14 Py 2.7 unsupported (working in 1.14.0), Py 3.x supported
For 1.10 I am offering an example of the form of summary, not sure what
the actual status is.
If I did my search correctly, there is nothing about Python 3 in any of
the 1.10 through 1.14 release notes. Haven't we got something to say
about limited support (for build and test?) in some version before 1.14?
All I could find was one py3 build fix (r1819444) merged to 1.10.x.
- Julian
Re: [offlist] Re: Merging branches/swig-py3 to trunk
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Fri, Nov 08, 2019 at 01:39:46 -0500:
> Since you wrote "Any other opinions?" I assume you intended to send
> this to the list... (My reply follows below.)
Yes, that's correct. I'd intended to reply offlist but changed my mind partway
through drafting and neglected to change the headers back. Thanks for bringing
the discussion back to the list.
Cheers,
Daniel
Re: [offlist] Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
Since you wrote "Any other opinions?" I assume you intended to send
this to the list... (My reply follows below.)
On Thu, Nov 7, 2019 at 5:31 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Nathan Hartman wrote on Tue, Nov 05, 2019 at 10:59:32 -0500:
> > Correct me if I'm wrong but I'm guessing that for downstream's
> > support/planning purposes, if Python 2.7 could be dropped at any
> > 1.14.x point release, isn't that basically equivalent to saying that
> > Python 2.7 isn't supported at all on 1.14? Because it means that an
> > update could break things at any time.
>
> Yes.
>
> > I'd be perfectly happy to write something like this in the release
> > notes:
> >
> > [[[
> >
> > Support for Python 3.x:
> >
> > Subversion's swig-py bindings and automated test suite now support
> > Python 3.x (and newer).
> >
> > Support for Python 2.7 is being phased out:
> >
> > As of 1 January 2020, Python 2.7 has reached end of life. This means
> > that Python 2.7 will no longer receive maintenance releases or
> > patches, even for security issues. All users are strongly encouraged
> > to move to Python 3.
> >
> > As Subversion 1.14 is a Long Term Support (LTS) release with planned
> > support until 2024, well beyond end-of-life for Python 2.7, the
> > Subversion developers cannot commit to supporting and testing with
> > Python 2.7 for the duration of this release, or to fix bugs that
> > affect Python 2.7 only.
> >
> > This means that although Subversion 1.14.0 still technically works
> > with Python 2.7, any later 1.14.x point release may drop this support
> > if it becomes too difficult to maintain.
> >
> > If you must continue using Python 2.7, our previous Long Term Support
> > release, Subversion 1.10, is supported until 2022. Python 2.7 support
> > will not be removed from Subversion 1.10.
> >
> > If you do not use the swig-py bindings, automated test suite, or other
> > Python-coded tools that ship with Subversion, this change does not
> > affect you.
> >
> > ]]]
>
> Sounds good to me, modulo language changes (s/to fix/to fixing/ and
> s/swig-py/SWIG Python/). Supporting py2 in 1.10 until 2022 is probably
> possible, at least for those of us who use LTS distros that will still
> be maintaining py2.7 then.
>
> Any other opinions?
>
> > But I get the feeling there will be objections.
> >
> > Bottom line: We need to reach some sort of consensus on this issue.
> > I've stated my opinion, but I'll be happy to go with whatever this
> > community decides makes the most sense.
>
> Cheers,
>
> Daniel
>
>
Thank you for those corrections.
In addition, I've tweaked it some more and I added a sentence at the
beginning to "introduce" Python, to avoid assuming knowledge.
Question: Some Python scripts have not been updated for Python 3.x
yet. Should those be listed in the release notes under "Known Issues"?
Should a bug be filed? Or both?
The updated text:
[[[
Support for Python 3.x:
Some optional features of Subversion utilize the Python scripting
language.
Subversion's SWIG Python bindings and automated test suite now support
Python 3.x (and newer).
Support for Python 2.7 is being phased out:
As of 1 January 2020, Python 2.7 has reached end of life. This means
that Python 2.7 will no longer receive maintenance releases or
patches, even for security issues. All users are strongly encouraged
to move to Python 3.
As Subversion 1.14 is a Long Term Support (LTS) release with planned
support into 2024, well beyond end-of-life for Python 2.7, the
Subversion developers cannot commit to supporting and testing with
Python 2.7, or to fixing bugs that affect Python 2.7 only, for the
duration of this support period.
This means that although Subversion 1.14.0 still technically works
with Python 2.7, any later 1.14.x point release may drop this support
if it becomes too difficult to maintain.
If you must continue using Python 2.7, our previous Long Term Support
release, Subversion 1.10, is supported until 2022. Python 2.7 support
will not be removed from Subversion 1.10.
Note that Subversion does not require Python for its basic operation.
If you are not using Subversion's SWIG Python bindings, automated test
suite, or other Python-coded tools that ship with Subversion, this
change does not affect you.
]]]
All thoughts / observations / criticisms welcome...
Kind regards,
Nathan
Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Nov 5, 2019 at 1:30 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Nathan Hartman wrote on Tue, 05 Nov 2019 04:48 +00:00:
> > Subversion 1.14 continues to support Python 2.7 to ease the transition
> > to Python 3 for those who have not yet made the jump. As Subversion
> > 1.14 is a Long Term Support (LTS) release, this gives system operators
> > four additional years of Subversion support for Python 2.7. Note,
> > however, that Subversion 1.15 and beyond will gradually phase out
> > support for Python 2.7.
>
> I'm not comfortable with committing to supporting Python 2.7 for the
> lifetime of the 1.14 branch — which basically means until the next LTS,
> whenever that _actually_ is — when that Python version has been EOL'd
> upstream.
>
> I'd prefer to state that Python 2.7 works (as a point of fact), but
> support therefor might be dropped at any time, even in a 1.14.x patch
> release, at our discretion; and we don't promise to fix bugs that affect
> Python 2.7 only. Of course, we'd not drop support without a good
> reason, but I'd like us to have the option to do that.
>
> After all, if a security vulnerability is found in Python 2 in 2020, it
> might be impractical for us to even _find_ a Python 2 interpreter to
> build and test with.
>
I feel uncomfortable with that, too.
I wrote this to dev@ two months ago, on September 2:
> Py2 is EOL 1/1/2020. Keeping it in 1.14 which implies support until
> 2024 would be a mistake because support will only get harder.
> Imagine what happens when your OS vendor removes Py2 packages. Even
> if Py2 still technically "works" with 1.14 (because that makes it
> easier to support Py3 for the remainder of 1.10), I suggest to
> document that Py2 is explicitly NOT supported in the 1.14 release
> notes. The internal policy should be that once 1.10 support ends,
> changes are allowed to break Py2 support and/or not be tested with
> Py2.
But based on later discussions here, several people expressed concern
about dropping Python 2 support. For example, Mark Phippard spoke of
supporting RHEL 7. Debian still ships with Python 2.7.
I don't think a consensus was ever reached on which version(s) of
Python we actually intend to support in 1.14-LTS and what is the best
path forward for those still using Python 2.7.
Correct me if I'm wrong but I'm guessing that for downstream's
support/planning purposes, if Python 2.7 could be dropped at any
1.14.x point release, isn't that basically equivalent to saying that
Python 2.7 isn't supported at all on 1.14? Because it means that an
update could break things at any time.
I'd be perfectly happy to write something like this in the release
notes:
[[[
Support for Python 3.x:
Subversion's swig-py bindings and automated test suite now support
Python 3.x (and newer).
Support for Python 2.7 is being phased out:
As of 1 January 2020, Python 2.7 has reached end of life. This means
that Python 2.7 will no longer receive maintenance releases or
patches, even for security issues. All users are strongly encouraged
to move to Python 3.
As Subversion 1.14 is a Long Term Support (LTS) release with planned
support until 2024, well beyond end-of-life for Python 2.7, the
Subversion developers cannot commit to supporting and testing with
Python 2.7 for the duration of this release, or to fix bugs that
affect Python 2.7 only.
This means that although Subversion 1.14.0 still technically works
with Python 2.7, any later 1.14.x point release may drop this support
if it becomes too difficult to maintain.
If you must continue using Python 2.7, our previous Long Term Support
release, Subversion 1.10, is supported until 2022. Python 2.7 support
will not be removed from Subversion 1.10.
If you do not use the swig-py bindings, automated test suite, or other
Python-coded tools that ship with Subversion, this change does not
affect you.
]]]
But I get the feeling there will be objections.
Bottom line: We need to reach some sort of consensus on this issue.
I've stated my opinion, but I'll be happy to go with whatever this
community decides makes the most sense.
Nathan
Re: Merging branches/swig-py3 to trunk
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nathan Hartman wrote on Tue, 05 Nov 2019 04:48 +00:00:
> Support for Python 3.x:
>
> Python 3.x and newer are now supported by Subversion's swig-py bindings
> and automated test suite. Python 2.7 is still supported.
>
> Support for Python 2.7 to be phased out:
>
> As of 1 January 2020, Python 2.7 has reached end of life. This means
> that Python 2.7 will no longer receive maintenance releases. All users
> are encouraged to move to Python 3.
>
Neither maintenance releases nor even security patches.
> Subversion 1.14 continues to support Python 2.7 to ease the transition
> to Python 3 for those who have not yet made the jump. As Subversion
> 1.14 is a Long Term Support (LTS) release, this gives system operators
> four additional years of Subversion support for Python 2.7. Note,
> however, that Subversion 1.15 and beyond will gradually phase out
> support for Python 2.7.
I'm not comfortable with committing to supporting Python 2.7 for the
lifetime of the 1.14 branch — which basically means until the next LTS,
whenever that _actually_ is — when that Python version has been EOL'd
upstream.
I'd prefer to state that Python 2.7 works (as a point of fact), but
support therefor might be dropped at any time, even in a 1.14.x patch
release, at our discretion; and we don't promise to fix bugs that affect
Python 2.7 only. Of course, we'd not drop support without a good
reason, but I'd like us to have the option to do that.
After all, if a security vulnerability is found in Python 2 in 2020, it
might be impractical for us to even _find_ a Python 2 interpreter to
build and test with.
Re: Merging branches/swig-py3 to trunk
Posted by Nathan Hartman <ha...@gmail.com>.
On Mon, Nov 4, 2019 at 6:50 AM Julian Foad <ju...@apache.org> wrote:
> Julian Foad wrote:
> > I'll put up a skeleton 1.14 release notes file today, ready for someone
> > to fill in a section about Py3.
>
> r1869363.
>
> Who can write a note in there about the changes?
I'm guessing something along these lines... but as you'll see I'm making
some assumptions in areas where we haven't yet reached a consensus, so
please speak up if you disagree with something!!!
Support for Python 3.x:
Python 3.x and newer are now supported by Subversion's swig-py bindings and
automated test suite. Python 2.7 is still supported.
Support for Python 2.7 to be phased out:
As of 1 January 2020, Python 2.7 has reached end of life. This means that
Python 2.7 will no longer receive maintenance releases. All users are
encouraged to move to Python 3.
Subversion 1.14 continues to support Python 2.7 to ease the transition to
Python 3 for those who have not yet made the jump. As Subversion 1.14 is a
Long Term Support (LTS) release, this gives system operators four
additional years of Subversion support for Python 2.7. Note, however, that
Subversion 1.15 and beyond will gradually phase out support for Python 2.7.
Re: Merging branches/swig-py3 to trunk
Posted by Julian Foad <ju...@apache.org>.
Julian Foad wrote:
> I'll put up a skeleton 1.14 release notes file today, ready for someone
> to fill in a section about Py3.
r1869363.
Who can write a note in there about the changes?
- Julian
Re: Merging branches/swig-py3 to trunk
Posted by Julian Foad <ju...@apache.org>.
Branko Čibej wrote:
> Merged to trunk in r1869354.
Thanks!
> I'll let someone else handle the release notes. :)
I'll put up a skeleton 1.14 release notes file today, ready for someone
to fill in a section about Py3.
- Julian
Re: Merging branches/swig-py3 to trunk
Posted by Branko Čibej <br...@apache.org>.
On 04.11.2019 05:52, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, Oct 22, 2019 at 21:39:23 +0200:
>> 1. we release 1.13.0 as planned next week when the soak period ends
>> (pending any last-minute critical bugs found, of course);
>>
>> 2. immediately after the 1.13.0 release, we merge the swig-py3 branch
>> to trunk; and,
> Anyone wants to do the honours? (Do the merge, or write the 1.14 release notes
> for it, or both)?
Merged to trunk in r1869354. I'll let someone else handle the release
notes. :)
-- Brane