classification
Title: Drop support of Windows Vista and 7 in Python 3.9
Type: Stage: patch review
Components: Windows Versions: Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: CAM-Gerlach, ZackerySpytz, eryksun, izbyshev, lukasz.langa, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
Priority: normal Keywords: patch

Created on 2018-01-18 09:37 by vstinner, last changed 2020-03-23 20:39 by CAM-Gerlach.

Pull Requests
URL Status Linked Edit
PR 5231 closed vstinner, 2018-01-18 09:38
PR 11457 closed vstinner, 2019-01-07 14:59
PR 11457 closed vstinner, 2019-01-07 14:59
PR 11457 closed vstinner, 2019-01-07 14:59
PR 15951 merged steve.dower, 2019-09-11 13:52
Messages (31)
msg310227 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-01-18 09:37
https://docs.python.org/dev/using/windows.html#supported-versions

"As specified in PEP 11, a Python release only supports a Windows platform while Microsoft considers the platform under extended support. This means that Python 3.7 supports Windows Vista and newer. If you require Windows XP support then please install Python 3.4."

But Windows Vista extended supported already ended last year, in April 2017.

Attached PR removes code to support Windows Vista.
msg310233 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2018-01-18 11:01
The only changes necessary in the installer should be in PythonBootstrapperApplication.cpp to make it an error when run on pre-Win7 OS. The pattern is already there, and the string references are in Tools/msi/bundle/Default.wxl

If you don't get to it, reassign the bug to me once you've merged the first part and I'll look at the installer.
msg310234 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-01-18 11:02
> If you don't get to it, reassign the bug to me once you've merged the first part and I'll look at the installer.

I like that :-) Will me. Right now, my PR doesn't compile, I broke something and I don't understand the error.
msg310296 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-01-19 22:26
I believe that PEP 11 originally said, or should have said "3.6 supports Windows Vista and newer."  I believe 3.5 supports XP, so it should be "please install Python 3.5".
msg310297 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2018-01-19 22:29
3.4 was the last version to support XP.
msg310303 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-01-19 23:50
Terry: see my notes about platforms suported by Python.
http://vstinner.readthedocs.io/cpython.html#supported-platforms

The PEP 11 doesn't want to have an explicit list of supported Windows versions, but I'm unable to *guess* which Windows version is supported by which Python version, so I wrote my own doc...
msg310308 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-01-20 00:45
I personally think it was a mistake to stop being explicit about Windows support in PEP 11.  The rationale was to avoid having to update it.  But it is updated for other systems; an explicit list is needed somewhere (as illustrated by my memory lapse; and PEP 11 is the most obvious and discoverable place.
msg318103 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-05-29 21:50
I failed to fix failures on my PR. It's now too late for Python 3.7.

If someone is interested to drop Vista support from Python 3.8, I suggest to open a new issue instead.
msg333160 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-01-07 14:57
Hello 2018, I reopen the issue and change the version to Python 3.8.
msg333161 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-01-07 15:01
> I failed to fix failures on my PR. It's now too late for Python 3.7.

I will try to redo PR 5231 in small chunks to better control the risk. I extracted os.cpu_count() changed as a new PR: PR 11457.

I already updated time.monotonic() documentation in a previous change:

commit 3ab064e80a9be1e6e9c62437fffb92bde9c5e1fb
Author: Victor Stinner <vstinner@redhat.com>
Date:   Mon Dec 17 12:12:34 2018 +0100

    bpo-23451: Update time.monotonic() documentation (GH-11190)
    
    bpo-23451, bpo-22117: Python 3.5 requires Windows Vista or newer,
    time.monotonic() is now always system-wide.
msg333186 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2019-01-07 20:33
AFAIK, it was specifically Martin Loewis who did not want a specific list in PEP 11.  Since he is long inactive, I think you and Steve should feel free to change that.
msg333187 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-01-07 22:46
I'd rather leave it specified as it is in PEP 11, though perhaps specifying it explicitly in the release schedule PEPs would be helpful? Up to release managers.
msg341393 - (view) Author: Zackery Spytz (ZackerySpytz) * (Python triager) Date: 2019-05-04 17:12
See also #29075.
msg341534 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-05-06 15:34
I marked bpo-29075 as duplicate of this issue.

IMHO it's too late to remove code from Python 3.8. We are too close from the feature freeze: removing Vista code is a risk of introducing subtle issue. I prefer to now wait for Python 3.9. It's not like the "dead code" is causing any major issue. Or does someone see a good reason to remove Vista support *right now*?
msg341535 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-05-06 15:35
Before Vista, the code page 65001 behaved differently than official UTF-8 codec. Vista changed that. Maybe it's time to remove Lib/encodings/cp65001.py and make it an alias to utf_8 codec: see https://bugs.python.org/issue36778#msg341531
msg341612 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-05-06 19:18
> Maybe it's time to remove Lib/encodings/cp65001.py and make it an 
> alias to utf_8 codec

Note that Unicode console support already assumes they're equivalent. For stdin, we read UTF-16LE via ReadConsoleW and encode bytes to the UTF-8 BufferedReader via WideCharToMultiByte with CP_UTF8 (65001). For stdout/stderr, we decode bytes from the UTF-8 BufferedWriter via MultiByteToWideChar with CP_UTF8 and write UTF-16LE via WriteConsoleW.
msg342041 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-05-10 02:11
> Before Vista, the code page 65001 behaved differently than official UTF-8 codec. Vista changed that. Maybe it's time to remove Lib/encodings/cp65001.py and make it an alias to utf_8 codec: see https://bugs.python.org/issue36778#msg341531

FYI it's exactly what I did:

New changeset d267ac20c309e37d85a986b4417aa8ab4d05dabc by Victor Stinner in branch 'master':
bpo-36778: cp65001 encoding becomes an alias to utf_8 (GH-13230)
https://github.com/python/cpython/commit/d267ac20c309e37d85a986b4417aa8ab4d05dabc
msg351882 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-09-11 13:55
I'll at least make a start by updating the minimum API version.
msg351965 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2019-09-11 16:03
New changeset 0b72ccff56fb47e14f7b1f6590eafff8d104c229 by Zachary Ware (Steve Dower) in branch 'master':
bpo-32592: Set Windows 8 as the minimum required version for API support (GH-15951)
https://github.com/python/cpython/commit/0b72ccff56fb47e14f7b1f6590eafff8d104c229
msg352476 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-09-15 13:56
3.9 can drop support for console pseudohandles in set_inheritable in Python/fileutils.c and Popen._filter_handle_list in Lib/subprocess.py. 

Also, _Py_write_impl in Python/fileutils.c can remove the 32767 byte limit for console files (and other character devices such as NUL, since it over-generalizes via isatty). The same applies to _io__WindowsConsoleIO_write_impl in Modules/_io/winconsoleio.c.

---
Discussion

In Windows 8+, the console uses "\\Device\\ConDrv" with kernel file objects. The console host process opens a file object for the ConDrv device itself in order to handle IOCTLs from clients. A console client process opens virtual files on ConDrv such as Connect (for generic functions such as GetConsoleCP), Input (default StandardInput), Output (default StandardOutput, StandardError), Console (//./CON), CurrentIn (//./CONIN$), and CurrentOut (//./CONOUT$). There's no practical limit on the size of reads and writes via these files.

Prior to Windows 8, console API requests are instead sent over an LPC port. Large messages that don't fit in a LPC packet are passed in a 64 KiB window of shared memory that's overlayed by a heap. This is the heap referred to by claims in the console API docs such as "[i]f the total size of the specified number of characters exceeds the available heap, the function fails with ERROR_NOT_ENOUGH_MEMORY".

With the LPC implementation, file handles for the console input buffer and screen buffer(s) are not real handles for kernel File objects. Rather, the console host process maintains a private table of pseudohandles for console buffers. These console pseudohandles are tagged for routing in the Windows API by setting the lower 2 bits. They're also verified in functions such as GetFileType via the undocumented function VerifyConsoleIoHandle. These pseudohandles have to be identified in Python because they're not supported by SetHandleInformation or the PROC_THREAD_ATTRIBUTE_HANDLE_LIST of CreateProcess, both of which require real kernel handles.
msg352502 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-09-16 02:29
Here are a couple more:

* WSA_FLAG_NO_HANDLE_INHERIT is supported. Code related to `support_wsa_no_inherit` in Modules/socketmodule.c can be removed.

* AddDllDirectory and RemoveDllDirectory are supported. os__add_dll_directory_impl and os__remove_dll_directory_impl in Modules/posixmodule.c no longer need to manually link to them via GetModuleHandleW and GetProcAddress.
msg353307 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-09-26 14:21
Steve, in PR 15951 you updated Py_WINVER to 0x0602. I think it should be 0x0603 (_WIN32_WINNT_WINBLUE) and 
Py_NTDDI should be NTDDI_WINBLUE. Windows 8 hasn't been supported since 2016. Windows 8.1 is supported until 2023.
msg353308 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-09-26 14:25
> Steve, in PR 15951 you updated Py_WINVER to 0x0602. I think it should be 0x0603 (_WIN32_WINNT_WINBLUE) and Py_NTDDI should be NTDDI_WINBLUE. Windows 8 hasn't been supported since 2016. Windows 8.1 is supported until 2023.

Dropping Windows 7 support allows us to remove code to support Windows 7.

I'm not sure that there is a big benefit for us to drop Windows 8 support (only Windows 8 but continue to support Windows 8.1), compared to the annoyance for users.
msg353312 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-09-26 14:51
There shouldn't be any annoyance to users, as nobody should be using Windows 8 anymore (the update to 8.1 was free and difficult to avoid).

Updating to NTDDI_WINBLUE is fine, but not essential. Nothing about that flag has a real impact until we need or want to directly call functions that were only added in that version.
msg353328 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2019-09-26 16:31
> I'm not sure that there is a big benefit for us to drop Windows 8 
> support (only Windows 8 but continue to support Windows 8.1), 
> compared to the annoyance for users.

According to statcounter.com and netmarketshare.com, Windows 8 still has 1% or less of the desktop market (across all platforms), while Windows 8.1 has about 5%. In comparison, Windows 7 has about 25-30% share, and Windows 10 has about 45-50%. I expect to see complaints about dropping Windows 7 support in 3.9. It's still quite popular and may take longer to die off than even Windows XP. I don't expect much noise, if any at all, about dropping Windows 8. Microsoft hasn't supported it for over 3 years.

A minor benefit of requiring Windows 8.1 would be support for process snapshotting (*). We could re-implement win32_getppid based on PssCaptureSnapshot and PssQuerySnapshot. This would only snapshot basic information about the current process (a few NtQueryInformationProcess system calls), whereas a Toolhelp snapshot, as is currently used, captures information about every process and thread in every session. Like I said, it's a minor benefit -- especially if we make the parent pid a static variable, so it only has to be looked up once. But this also opens up other features provided by this facility, including walking the handle table and virtual memory, if someone finds a use for them.

(*) For some reason ProcessSnapshot.h requires NTDDI_WIN8 instead NTDDI_WINBLUE, so this isn't actually a case for changing the value of  Py_NTDDI, but it should be in principle. The docs for process snapshotting require Windows 8.1, and the Windows 8 version of kernel32.dll (6.2.9200.*) does not export any of the Pss* functions, so it really was/is not available in Windows 8 as far as I can tell.
msg363348 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2020-03-04 13:25
I'd be happy to submit a PR to resolve all the issues that I note here. Just say the word and I'll go right ahead.

I presume the Windows installer code [0a] should be updated to refuse to install on Windows <8 and given an informative warning instead letting the user know their system is not supported, as well as logging the appropriate messages in each case? Appropriate failure IDs would also be defined in the associated WXL [0b].

[0a] https://github.com/python/cpython/blob/master/Tools/msi/bundle/bootstrap/PythonBootstrapperApplication.cpp#L3041
[0b] https://github.com/python/cpython/blob/master/Tools/msi/bundle/Default.wxl

The relevant Using Python on Windows docs [1a] should be updated to reflect this, along with PCBuild/readme.txt [1b]. Also, given it is dropping 2 major Windows versions, including one seeing widespread use, it should probably be mentioned in What's New; I don't see it there as it stands now.

[1a] https://github.com/python/cpython/blob/master/Doc/using/windows.rst
[1b] https://github.com/python/cpython/blob/master/PCbuild/readme.txt

As a more trivial docs change, references to "Vista's" UAC ([2a], [2b], [2c]) could be updated to simply refer to "Windows'" UAC to avoid confusion since it presumably applies to all >=Vista versions which have said feature.

[2a] https://github.com/python/cpython/blob/master/Lib/distutils/command/bdist_wininst.py#L52
[2b] https://github.com/python/cpython/blob/master/PC/bdist_wininst/install.c#L2187
[2c] https://github.com/python/cpython/blob/master/Doc/distutils/builtdist.rst#vista-user-access-control-uac

Finally, maybe this is stretching the scope a bit, but the relevant part of [1a], namely [3a], should also be updated to state that Windows CE is not supported (it currently states the opposite), as this was removed in 3.6.0b1 [3ai], and additionally the Sourceforge (!) project it links to [3bii] is on an legacy archived CVS repo that hasn't been meaningfully updated since 2008 and the current versions of CE (5 and 6) at the time is long EoL now (in fact, 7 is coming up on its EoL in a year). Out of date references to Windows CE support could also be removed from the ctypes doc [3b] and the condavar code comments [3c], [3d].

[3a] https://github.com/python/cpython/blob/master/Doc/using/windows.rst#L1165
    [3ai] https://github.com/python/cpython/blob/master/Misc/NEWS.d/3.6.0b1.rst#L217
    [3aii] https://sourceforge.net/projects/pythonce/files/
[3b] https://github.com/python/cpython/blob/master/Doc/library/ctypes.rst 
[3c] https://github.com/python/cpython/blob/master/Include/internal/pycore_condvar.h#L30
[3d] https://github.com/python/cpython/blob/master/Python/condvar.h#L85
msg363352 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2020-03-04 14:48
Here's a further conservative list of low-hanging <Win8 bitrot in the  code itself not already mentioned that can be eliminated as a result of this change, focusing on the Python side of the code and tests; again, I can offer a PR if desired.

Python Code:
* ntpath.py | Win9x (!) | Check for pre-NT versions can be simplified along the lines of the check for darwin in posixpath.py: https://github.com/python/cpython/blob/master/Lib/ntpath.py#L675
* multiprocesing/connection.py | >=Win 8 | Branch can be inlined and outdated comments removed: https://github.com/python/cpython/blob/master/Lib/multiprocessing/connection.py#L866
* pathlib.py | >= Vista | Branch can be inlined and else block removed: https://github.com/python/cpython/blob/master/Lib/pathlib.py#L19


Tests:
* test_winreg.py | Vista | Multiple tests and constants (All the checks and tests requiring registry reflection/`HAS_REFLECTION`):  https://github.com/python/cpython/blob/master/Lib/test/test_winreg.py
* test_winreg.py | <Vista | No-reflection Test: https://github.com/python/cpython/blob/master/Lib/test/test_winreg.py#L309
* test/support/__init__ | <=Win 9x (!) | Test initialization branch can be inlined and out of date comments removed: https://github.com/python/cpython/blob/master/Lib/test/support/__init__.py#L987
* test_winconsoleio.py | <=Win7 | Test branch: https://github.com/python/cpython/blob/master/Lib/test/test_winconsoleio.py#L99
* test_winconsoleio.py | <=Vista | Skipif decorator : https://github.com/python/cpython/blob/master/Lib/test/test_winconsoleio.py#L99
* test_import/__init__.py | <Vista | Skipunless decorator in test initialization: https://github.com/python/cpython/blob/master/Lib/test/test_import/__init__.py#L1025


Other:
* "Since we limit WINVER to Windows 7 anyway, it doesn't really matter which WinSDK version we use." -> can be updated to 8? https://github.com/python/cpython/blob/master/PCbuild/python.props#L101
msg363356 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2020-03-04 15:37
What Eryk said wrt Windows 8 seems sound, looking at some additional data.

Per Statcounter [0], Windows 8 market share has dropped to 1.32% from 2.20% of all Windows users over the past 12 months, or 1.75% -> 1.01% of all desktop users. Extrapolating a constant linear decrease, this would imply a usage share of 0.55-0.60% at Python 3.9 release, or considering a more conservative (and realistic) constant-percent decrease, this would put the amount at 0.75%. For comparison, by Statcounter's same metrics, Windows XP which was EoL 5 versions ago is still at 1.13% of the Windows or 0.90% of the total desktop market today, WinVista is at 0.41%/0.33%, Win8.1 at 4.7%/3.8% (~4x Win8) and of course the EoL and also dropped Windows 7 is at no less than 23.2%/18.5%, nearly 20 times the amount of Win 8 today and dropping more slowly besides.

[0] https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide

Conducting a similar analysis with the NetMarketshare data [1], we see a 0.78% -> 0.66% year on year share for Win8, which extrapolates to a 0.57% share at Py2.9 release. Vista is much lower at only 0.15%, but XP is over 2x higher at 1.35%, and Win8.1 well over 5x as large at 3.5%. Windows 7 is, again, at no less than 25.2%, nearly 40x the Win 8 marketshare.

[1] https://netmarketshare.com/operating-system-market-share.aspx

Users likely to be most concerned with wanting or needing to use the latest and greatest version of Python are more than likely to be power users, enthusiasts and developers, a group that was particularly averse to adopting Windows 8 when it came out, was more likely to upgrade to 8.1 , and is more aware of EoL timeframes than the average consumer. This is empirically supported by the Steam survey [2], which samples a population substantially more similar to the profile of a developer than the average web user captured by the previous two surveys. Here, the numbers are much more stark: A mere 0.17% of their >96% Windows userbase runs Windows 8, vs. 2.10% (>10x) for Windows 8.1 and 12.4% for Windows 7 (~75x). Given an infinitesimal fraction of such remaining users are likely going to require upgrading to a bleeding-edge Python version but not their OS that would have been EoL for nearly 5 years, over a year longer than Vista itself  and 4 years longer than 7, I don't think supporting that EoL OS per PEP 11 for another >5+ years with another new Python version need be a priority.

[2] https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam
msg364793 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2020-03-22 09:53
Hey, any update on this? As I mentioned, I'm willing to implement everything I mention here in one or more PRs, but I wanted to wait for a go-ahead in case some of the changes were not desired. Let me know and I'll go ahead. Thanks!
msg364798 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2020-03-22 12:01
Go ahead. I think you should create three PRs (docs, tests and code), with only as many tests in the code PR as are needed to keep it passing.
msg364899 - (view) Author: C.A.M. Gerlach (CAM-Gerlach) * Date: 2020-03-23 20:39
Thanks, will do as requested. I was planning on knocking it out yesterday, but some unexpected things came up so I might have to push it all the way to next weekend, but I'll get it done.
History
Date User Action Args
2020-03-23 20:39:39CAM-Gerlachsetmessages: + msg364899
2020-03-22 12:01:48steve.dowersetmessages: + msg364798
2020-03-22 09:53:53CAM-Gerlachsetmessages: + msg364793
2020-03-04 22:23:11vstinnersetnosy: - vstinner
2020-03-04 15:37:42CAM-Gerlachsetmessages: + msg363356
2020-03-04 14:48:31CAM-Gerlachsetmessages: + msg363352
2020-03-04 13:25:28CAM-Gerlachsetnosy: + CAM-Gerlach
messages: + msg363348
2019-09-26 16:31:33eryksunsetmessages: + msg353328
2019-09-26 14:51:19steve.dowersetmessages: + msg353312
2019-09-26 14:25:22vstinnersetmessages: + msg353308
2019-09-26 14:21:01eryksunsetmessages: + msg353307
2019-09-16 02:29:31eryksunsetmessages: + msg352502
2019-09-15 13:56:19eryksunsetmessages: + msg352476
2019-09-11 16:03:39zach.waresetmessages: + msg351965
2019-09-11 15:20:09zach.wareunlinkissue33166 dependencies
2019-09-11 13:55:16steve.dowersettitle: Drop support of Windows Vista in Python 3.8 -> Drop support of Windows Vista and 7 in Python 3.9
messages: + msg351882
versions: + Python 3.9, - Python 3.8
2019-09-11 13:52:53steve.dowersetpull_requests: + pull_request15586
2019-05-10 17:25:51ned.deilysetnosy: + lukasz.langa
2019-05-10 02:11:35vstinnersetmessages: + msg342041
2019-05-06 19:18:53eryksunsetnosy: + eryksun
messages: + msg341612
2019-05-06 15:35:22vstinnersetmessages: + msg341535
2019-05-06 15:34:16vstinnersetmessages: + msg341534
2019-05-06 15:32:47vstinnerlinkissue29075 superseder
2019-05-04 20:55:22terry.reedysettitle: Drop support of Windows Vista in Python 3.7 -> Drop support of Windows Vista in Python 3.8
2019-05-04 17:12:30ZackerySpytzsetnosy: + ZackerySpytz
messages: + msg341393
2019-01-24 00:06:12cheryl.sabellalinkissue33166 dependencies
2019-01-07 22:46:25steve.dowersetmessages: + msg333187
2019-01-07 20:33:44terry.reedysetmessages: + msg333186
2019-01-07 15:01:31vstinnersetmessages: + msg333161
2019-01-07 15:00:07vstinnersetstage: resolved -> patch review
pull_requests: + pull_request10929
2019-01-07 14:59:58vstinnersetstage: resolved -> resolved
pull_requests: + pull_request10928
2019-01-07 14:59:46vstinnersetstage: resolved -> resolved
pull_requests: + pull_request10927
2019-01-07 14:57:44vstinnersetstatus: closed -> open
resolution: out of date ->
messages: + msg333160

versions: + Python 3.8, - Python 3.7
2018-05-29 21:50:12vstinnersetstatus: open -> closed
resolution: out of date
messages: + msg318103

stage: patch review -> resolved
2018-03-08 17:45:23izbyshevsetnosy: + izbyshev
2018-01-20 00:45:54terry.reedysetmessages: + msg310308
2018-01-19 23:50:30vstinnersetmessages: + msg310303
2018-01-19 22:29:19zach.waresetmessages: + msg310297
2018-01-19 22:26:28terry.reedysetmessages: + msg310296
2018-01-19 22:26:15terry.reedysetmessages: - msg310295
2018-01-19 22:25:49terry.reedysetnosy: + terry.reedy
messages: + msg310295
2018-01-18 11:02:12vstinnersetmessages: + msg310234
2018-01-18 11:01:27steve.dowersetmessages: + msg310233
2018-01-18 09:38:45vstinnersetkeywords: + patch
stage: patch review
pull_requests: + pull_request5078
2018-01-18 09:37:18vstinnercreate