Le 17/09/16 à 10:02, Armin Rigo a écrit :
Hi Ronan, hi all,
Can we fix a date after which we stop needing to update pypy 3.3? It
is a (minor) mess that, whenever I find a bug or small missing feature
in pypy 3.5, I usually try first to see if it should be done in the
py3k (3.3) branch or directly in py3.5. In fact I would guess by now
that I have misplaced one or two such fixes. Sorry about that. It
would help reduce the overhead if we could all focus on py3.5.
The advantage of having py3k is that regressions are much more visible
there than on py3.5, but I agree that the overhead of having two py3
branches is too high. We can't go on like this for much longer.
At the start of August, Ronan mentioned the last pypy 3.3 release
being 1 or 2 months away. Ronan, can you say what you'd still like to
do and what you'd like fixed first for the release? I can help you
For all remaining linux64 test failures, we should either fix them or
explicitly decide not to bother (e.g. in cpyext). This mostly means
reviewing and stabilising the buffer interface. Some issues also need to
be fixed, like #2278 (os.stat()) and #2312 (venv).
Also, win32 doesn't seem too far from working, so we should try to fix
it as well. Finishing the posix module would be also be nice, though the
last missing bits seem obscure enough that we can live without.
I suggest that we tentatively fix the date of October the 8th for the
release (this is just after PyCon ZA). Then we can then focus our
South African sprint on py3.5.
8 October seems doable, so +1.
About the sprint: anyone around Cape Town for the two weeks after
PyCon ZA is welcome to join. We don't have exactly a plan so far; for
sure we will not be sprinting without some break days.
pypy-dev mailing list