Rotonen (Joni Orponen) 2018-09-20 13:38:31 UTC #41
I am not sure where I got this settings from.
Actually, can you still double check you're not staticly assigning those cores to anything else? Would be silly if Plone CI builds step on the toes of your production VMs.
jensens (Jens W. Klein) 2018-09-20 13:47:06 UTC #42
Actually, can you still double check you're not staticly assigning those cores to anything else?
No, those are used by 2 VMs, the CI and one with very low CPU usage (most of the time idle).
Rotonen (Joni Orponen) 2018-09-20 13:49:22 UTC #43
Or, alternatively, do one container per server, and just let it use all the resources and only use the container for software isolation.
gforcada (gforcada) 2018-09-24 21:11:25 UTC #44
Running lxc exec CONTAINER_NAME lscpu before and after lxc config set CONTAINER_NAME limits.cpu 1 yields the exact same value either it is ignored, or lscpu is not the right tool to check this. getconf _NPROCESSORS_ONLN also returns the total amount rather than the restricted amount
gforcada (gforcada) 2018-09-24 21:13:31 UTC #45
Thanks to @pbauer and @polyester (so the Foundation board in general) we have a new server available with 12 cores:
Model name:          Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
CPU MHz:             1197.448
BogoMIPS:            6984.36
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti intel_ppin ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts flush_l1d
I created two nodes on it (Node5 and Node6) with 6 executors each.
Have fun trying to make them busy
gforcada (gforcada) 2018-09-25 08:32:11 UTC #46
Sorry for the spam... Python 3.7 was readily installed on nodes for quite a while, but I forgot to enable it on Jenkins, well not anymore
If one wants to play with it, create a virtualenv build step and on the dropdown you will see Python 3.7 as an option.
I wouldn't expect any regression from 3.6, but anyhow, we can eventually test on both 3.6 as well as 3.7.
icemac (Michael Howitz) 2018-09-25 09:12:29 UTC #47
I expect regressions when using Python 3.7 instead of 3.6. (Zope does not yet support Python 3.7, too.)
Each supported Python version should be tested individually.
Rotonen (Joni Orponen) 2018-09-25 09:18:33 UTC #48
6 cores, not 12. We run the same hardware for our CI. This can run the non-robot tests in 10minutes.
We cannot containers. Let's do bare metal. Please. That'd also greatly simplify the executor queue design and the test splitting design.
I'd like to see 2.6 .. 2.7 and 3.4 .. 3.7 on the CI.
Rotonen (Joni Orponen) 2018-09-25 09:22:39 UTC #49
Ran some benchmarking as to how the most trivial parallelisation of the tests would work. Used Python 3.7.0 compiled with --enable-optimisations. The tests actually run on 3.7.0, which is a decent starting point.
lscpu | tee parallel.log && echo "" | tee -a parallel.log && git log -1 --format="%ai %d %H" | tee -a parallel.log && for n in $(seq 1 "$(getconf _NPROCESSORS_ONLN)"); do echo "" && echo "n = $n" && ROBOTSUITE_PREFIX=ROBOT bin/test --all -j "$n" -t '!ROBOT' 2>/dev/null | tail -n 1; done | tee -a parallel.log
Model name:            Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz
CPU MHz:               1231.323
BogoMIPS:              6999.57
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts spec_ctrl intel_stibp flush_l1d
2018-09-24 14:24:32 +0200  (HEAD -> 5.2, origin/5.2) 018ba5dc02f6ca7dd3e03f327fc4ff373e28c311
Total: 9228 tests, 58 failures, 40 errors and 275 skipped in 29 minutes 3.867 seconds.
Total: 9520 tests, 68 failures, 41 errors and 0 skipped in 28 minutes 1.659 seconds.
Total: 9520 tests, 67 failures, 41 errors and 0 skipped in 19 minutes 15.774 seconds.
Total: 9300 tests, 53 failures, 36 errors and 0 skipped in 14 minutes 25.575 seconds.
Total: 9300 tests, 53 failures, 36 errors and 0 skipped in 11 minutes 51.595 seconds.
Total: 9271 tests, 52 failures, 47 errors and 0 skipped in 10 minutes 27.564 seconds.
Total: 9271 tests, 53 failures, 47 errors and 0 skipped in 10 minutes 58.729 seconds.
Total: 9271 tests, 52 failures, 47 errors and 0 skipped in 10 minutes 52.678 seconds.
Total: 9230 tests, 54 failures, 38 errors and 0 skipped in 10 minutes 33.451 seconds.
Total: 9271 tests, 51 failures, 47 errors and 0 skipped in 10 minutes 24.175 seconds.
Total: 9230 tests, 52 failures, 38 errors and 0 skipped in 10 minutes 1.881 seconds.
Total: 9291 tests, 54 failures, 37 errors and 0 skipped in 9 minutes 56.034 seconds.
Splitting the non-Robot Python 3 runs into running 6 layers in parallel seems sane. The rest is then a bit of a puzzle as we'll have a mix of 4 core and 6 core machines.
What worries me the most is the varying test count across the runs, but I'll chalk that up to using 3.7.0 at this point.
pbauer (Philip Bauer) 2018-09-25 10:04:59 UTC #50
With https://jenkins.plone.org/view/PLIPs/job/plip-py3.7 I created a copy of the Py3-Job that uses Python 3.7.
After that is done we can compare the results to https://jenkins.plone.org/view/PLIPs/job/plip-py3.
I had already fixed one issue with 3.7 (https://github.com/plone/borg.localrole/commit/26514d0) but there probably will be some more.
icemac (Michael Howitz) 2018-09-25 11:34:06 UTC #51
3.4 is not supported by Zope, so I see no need to test against this Python version.
3.5 will go end of live in 2020. I'd expect nobody to migrate his/her Plone project to this version.
Rotonen (Joni Orponen) 2018-09-25 11:54:19 UTC #52
Excellent, thank you. only doing 3.6 and 3.7 simplify the juggling act for making builds quicker a lot.
This also means f-strings and type annotations are something Plone could actually go for.
icemac (Michael Howitz) 2018-09-26 06:53:48 UTC #53
This will be possible after dropping Python 2 support. Zope will do so in Zope 5 but I do not think that this will happen before 2020.
Rotonen (Joni Orponen) 2018-09-28 18:12:31 UTC #54
Ha, caught it.
There are other (multiples of) zServer layers than just the Robot tests.
@sunew did you take a look at dynamically picking a free port for zServer test layers?
There's three ways around to parallelising that too:
Have it automatically pick ports
Isolate all such layers into a separate sequential test run
Use a wrapper to run the tests, which allocates the ports for the runs (this has unsolved aspects in regards to how to negotiate this between two test runs happening in parallel)
pbauer (Philip Bauer) 2018-10-01 06:17:14 UTC #55
The sprint in Halle is starting today. We'll do a initial standup on Monday at 2pm CEST (12pm UTC) where where we create teams and distribute tasks. If you want to contribute from remote please join us in a hangout at https://hangouts.google.com/hangouts/_/event/ct8e35vjvc59n01sk5ckugfqto0
Sprint Planning Standup - Google+
Standup for Saltlabs sprint – Zope and Plone together
pbauer (Philip Bauer) 2018-10-11 21:48:25 UTC #56
We just had the first green builds for Python 3.6 and Python 3.7 \o/
The py3_on_py2 job still has some remaining failing robot tests. That runs the whole py3-branches plus Archetypes in Python 2.7. https://jenkins.plone.org/view/PLIPs/job/py3_on_py2
Zope 4.0b6 has been released. Updating our versions leads to some more issues that need to be fixed (see https://github.com/plone/Products.CMFPlone/issues/2590).
Once 4.0b6 is used and all three jobs are green we will need to merge a lot of branches at the same time.
tisto (Tisto) 2018-10-12 04:46:24 UTC #57
Fantastic work Philip et. al!!! Thank you!
pbauer (Philip Bauer) 2018-10-12 17:16:17 UTC #58
And now finally all builds are green. We plan the task necessary before a release of Plone 5.2a1 in:
pbauer (Philip Bauer) 2018-10-19 17:31:01 UTC #59
I finally published a sprint report on the Saltlabs Sprint:
I'll cross-post it here so that any discussions do not have to go through our websites disqus:
Archetypes will not be ported to Python 3 but still has to work when running Plone 5.2 in Python 2.7. Since all tests that used PloneTestCase were still using Archetypes Philip changed that to use Dexterity now and created a new testlayer (plone.app.testing.bbb_at.PloneTestCase) that is now used by all the packages using the Archetypes-stack. See https://github.com/plone/plone.app.testing/pull/51. You could use this layer in your archetypes-based addon-packages that you want to port to Plone 5.2.
plone.reload: https://github.com/plone/plone.reload/pull/9
Products.PDBDebugMode: https://github.com/collective/Products.PDBDebugMode/pull/8
plone.app.debugtoolbar: https://github.com/plone/plone.app.debugtoolbar/pull/20
Products.PrintingMailHost: https://github.com/collective/Products.PrintingMailHost/pull/6
mr.developer: https://github.com/fschulze/mr.developer/pull/193
Being able to run tests against Plone in Python 3, and with these development-tools now available also, it is now viable to start porting other addons to Python 3. To find out how hard that is I started porting collective.easyform: https://github.com/collective/collective.easyform/pull/129. The work is only 97% finished since some tests need more work but it is now useable in Python 3!
Harald Friesenegger and Robert Buchholz worked on defining a default migration-story for existing databases using `zodbupdate (https://github.com/zopefoundation/zodbupdate). To discuss the details of this approach we had a hangout with Jim Fulton, David Glick and Sylvain Viollon. They solved a couple of tricky issues and wrote enough documentation. This approach seems to work well enough and the documentation points out some caveats but the ZODB migration will require some more work.
Johannes Raggam finished work on his PLIP to restructure static resources.
With this we no longer carry 60MB of static resources in the CMFPlone repository, it allows to use different versions of mockup in Plone, enable us to release our libraries on npm and will make it easier to switch to a different framework.
Skin scripts removal
Katja Süss, Thomas Lotze, Maurits van Rees and Manuel Reinhardt worked hard at removing the remaining python_scripts. The work is still ongoing and it would be great to get rid of the last of these before a final Plone 5.2 release. See https://github.com/plone/Products.CMFPlone/issues/1801 for details. Katja also worked on finally removing the old resource registry (for js and css).
Joni Orponen made a lot of progress on speeding up our test-runs by running different test-layers in parallel. The plan is to get them from 30-60 minutes (depending on server and test-setup) to less than 10 minutes. For a regularly updated status of this work see CI run speedups for buildout.coredev
Better late than never: We now have a method safe_nativestring in Products.CMFPlone.utils besides our all-time favorites safe_unicode and safe_encode. It transforms to string (which is bytes in Python 2 and text in Python 3). By the way: There is also zope.schema.NativeString and zope.schema.NativeStringLine.
pbauer (Philip Bauer) 2018-12-01 08:36:52 UTC #60
I guess most people know already but: Plone 5.2a1 was released in Tokyo. That means Plone now supports Python 3
I wrote a blogpost with a update:
Our favourite Open Source CMS has landed on Python 3. Here is what you need to know about migrating projects.
The super-short version of that blogpost:
A final release is scheduled for February
You should start planning your migration now
Many developer-tools and some important addons already support Python 3
There is more work to be done regarding migration, documentation and testing
Rotonen (Joni Orponen) 2018-09-20 13:38:31 UTC #41
I am not sure where I got this settings from.
Actually, can you still double check you're not staticly assigning those cores to anything else? Would be silly if Plone CI builds step on the toes of your production VMs.
jensens (Jens W. Klein) 2018-09-20 13:47:06 UTC #42
Actually, can you still double check you're not staticly assigning those cores to anything else?
No, those are used by 2 VMs, the CI and one with very low CPU usage (most of the time idle).
Rotonen (Joni Orponen) 2018-09-20 13:49:22 UTC #43
Or, alternatively, do one container per server, and just let it use all the resources and only use the container for software isolation.
gforcada (gforcada) 2018-09-24 21:11:25 UTC #44
Running lxc exec CONTAINER_NAME lscpu before and after lxc config set CONTAINER_NAME limits.cpu 1 yields the exact same value either it is ignored, or lscpu is not the right tool to check this. getconf _NPROCESSORS_ONLN also returns the total amount rather than the restricted amount
gforcada (gforcada) 2018-09-24 21:13:31 UTC #45
Thanks to @pbauer and @polyester (so the Foundation board in general) we have a new server available with 12 cores:
Model name:          Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
CPU MHz:             1197.448
BogoMIPS:            6984.36
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti intel_ppin ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc dtherm ida arat pln pts flush_l1d
I created two nodes on it (Node5 and Node6) with 6 executors each.
Have fun trying to make them busy
gforcada (gforcada) 2018-09-25 08:32:11 UTC #46
Sorry for the spam... Python 3.7 was readily installed on nodes for quite a while, but I forgot to enable it on Jenkins, well not anymore
If one wants to play with it, create a virtualenv build step and on the dropdown you will see Python 3.7 as an option.
I wouldn't expect any regression from 3.6, but anyhow, we can eventually test on both 3.6 as well as 3.7.
icemac (Michael Howitz) 2018-09-25 09:12:29 UTC #47
I expect regressions when using Python 3.7 instead of 3.6. (Zope does not yet support Python 3.7, too.)
Each supported Python version should be tested individually.
Rotonen (Joni Orponen) 2018-09-25 09:18:33 UTC #48
6 cores, not 12. We run the same hardware for our CI. This can run the non-robot tests in 10minutes.
We cannot containers. Let's do bare metal. Please. That'd also greatly simplify the executor queue design and the test splitting design.
I'd like to see 2.6 .. 2.7 and 3.4 .. 3.7 on the CI.
Rotonen (Joni Orponen) 2018-09-25 09:22:39 UTC #49
Ran some benchmarking as to how the most trivial parallelisation of the tests would work. Used Python 3.7.0 compiled with --enable-optimisations. The tests actually run on 3.7.0, which is a decent starting point.
lscpu | tee parallel.log && echo "" | tee -a parallel.log && git log -1 --format="%ai %d %H" | tee -a parallel.log && for n in $(seq 1 "$(getconf _NPROCESSORS_ONLN)"); do echo "" && echo "n = $n" && ROBOTSUITE_PREFIX=ROBOT bin/test --all -j "$n" -t '!ROBOT' 2>/dev/null | tail -n 1; done | tee -a parallel.log
Model name:            Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz
CPU MHz:               1231.323
BogoMIPS:              6999.57
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm epb ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt dtherm ida arat pln pts spec_ctrl intel_stibp flush_l1d
2018-09-24 14:24:32 +0200  (HEAD -> 5.2, origin/5.2) 018ba5dc02f6ca7dd3e03f327fc4ff373e28c311
Total: 9228 tests, 58 failures, 40 errors and 275 skipped in 29 minutes 3.867 seconds.
Total: 9520 tests, 68 failures, 41 errors and 0 skipped in 28 minutes 1.659 seconds.
Total: 9520 tests, 67 failures, 41 errors and 0 skipped in 19 minutes 15.774 seconds.
Total: 9300 tests, 53 failures, 36 errors and 0 skipped in 14 minutes 25.575 seconds.
Total: 9300 tests, 53 failures, 36 errors and 0 skipped in 11 minutes 51.595 seconds.
Total: 9271 tests, 52 failures, 47 errors and 0 skipped in 10 minutes 27.564 seconds.
Total: 9271 tests, 53 failures, 47 errors and 0 skipped in 10 minutes 58.729 seconds.
Total: 9271 tests, 52 failures, 47 errors and 0 skipped in 10 minutes 52.678 seconds.
Total: 9230 tests, 54 failures, 38 errors and 0 skipped in 10 minutes 33.451 seconds.
Total: 9271 tests, 51 failures, 47 errors and 0 skipped in 10 minutes 24.175 seconds.
Total: 9230 tests, 52 failures, 38 errors and 0 skipped in 10 minutes 1.881 seconds.
Total: 9291 tests, 54 failures, 37 errors and 0 skipped in 9 minutes 56.034 seconds.
Splitting the non-Robot Python 3 runs into running 6 layers in parallel seems sane. The rest is then a bit of a puzzle as we'll have a mix of 4 core and 6 core machines.
What worries me the most is the varying test count across the runs, but I'll chalk that up to using 3.7.0 at this point.
pbauer (Philip Bauer) 2018-09-25 10:04:59 UTC #50
With https://jenkins.plone.org/view/PLIPs/job/plip-py3.7 I created a copy of the Py3-Job that uses Python 3.7.
After that is done we can compare the results to https://jenkins.plone.org/view/PLIPs/job/plip-py3.
I had already fixed one issue with 3.7 (https://github.com/plone/borg.localrole/commit/26514d0) but there probably will be some more.
icemac (Michael Howitz) 2018-09-25 11:34:06 UTC #51
3.4 is not supported by Zope, so I see no n
eed to test against this Python version.
3.5 will go end of live in 2020. I'd expect nobody to migrate his/her Plone project to this version.
Rotonen (Joni Orponen) 2018-09-25 11:54:19 UTC #52
Excellent, thank you. only doing 3.6 and 3.7 simplify the juggling act for making builds quicker a lot.
This also means f-strings and type annotations are something Plone could actually go for.
icemac (Michael Howitz) 2018-09-26 06:53:48 UTC #53
This will be possible after dropping Python 2 support. Zope will do so in Zope 5 but I do not think that this will happen before 2020.
Rotonen (Joni Orponen) 2018-09-28 18:12:31 UTC #54
Ha, caught it.
There are other (multiples of) zServer layers than just the Robot tests.
@sunew did you take a look at dynamically picking a free port for zServer test layers?
There's three ways around to parallelising that too:
Have it automatically pick ports
Isolate all such layers into a separate sequential test run
Use a wrapper to run the tests, which allocates the ports for the runs (this has unsolved aspects in regards to how to negotiate this between two test runs happening in parallel)
pbauer (Philip Bauer) 2018-10-01 06:17:14 UTC #55
The sprint in Halle is starting today. We'll do a initial standup on Monday at 2pm CEST (12pm UTC) where where we create teams and distribute tasks. If you want to contribute from remote please join us in a hangout at https://hangouts.google.com/hangouts/_/event/ct8e35vjvc59n01sk5ckugfqto0
Sprint Planning Standup - Google+
Standup for Saltlabs sprint – Zope and Plone together
pbauer (Philip Bauer) 2018-10-11 21:48:25 UTC #56
We just had the first green builds for Python 3.6 and Python 3.7 \o/
The py3_on_py2 job still has some remaining failing robot tests. That runs the whole py3-branches plus Archetypes in Python 2.7. https://jenkins.plone.org/view/PLIPs/job/py3_on_py2
Zope 4.0b6 has been released. Updating our versions leads to some more issues that need to be fixed (see https://github.com/plone/Products.CMFPlone/issues/2590).
Once 4.0b6 is used and all three jobs are green we will need to merge a lot of branches at the same time.
tisto (Tisto) 2018-10-12 04:46:24 UTC #57
Fantastic work Philip et. al!!! Thank you!
pbauer (Philip Bauer) 2018-10-12 17:16:17 UTC #58
And now finally all builds are green. We plan the task necessary before a release of Plone 5.2a1 in:
pbauer (Philip Bauer) 2018-10-19 17:31:01 UTC #59
I finally published a sprint report on the Saltlabs Sprint:
I'll cross-post it here so that any discussions do not have to go through our websites disqus:
Archetypes will not be ported to Python 3 but still has to work when running Plone 5.2 in Python 2.7. Since all tests that used PloneTestCase were still using Archetypes Philip changed that to use Dexterity now and created a new testlayer (plone.app.testing.bbb_at.PloneTestCase) that is now used by all the packages using the Archetypes-stack. See https://github.com/plone/plone.app.testing/pull/51. You could use this layer in your archetypes-based addon-packages that you want to port to Plone 5.2.
plone.reload: https://github.com/plone/plone.reload/pull/9
Products.PDBDebugMode: https://github.com/collective/Products.PDBDebugMode/pull/8
plone.app.debugtoolbar: https://github.com/plone/plone.app.debugtoolbar/pull/20
Products.PrintingMailHost: https://github.com/collective/Products.PrintingMailHost/pull/6
mr.developer: https://github.com/fschulze/mr.developer/pull/193
Being able to run tests against Plone in Python 3, and with these development-tools now available also, it is now viable to start porting other addons to Python 3. To find out how hard that is I started porting collective.easyform: https://github.com/collective/collective.easyform/pull/129. The work is only 97% finished since some tests need more work but it is now useable in Python 3!
Harald Friesenegger and Robert Buchholz worked on defining a default migration-story for existing databases using `zodbupdate (https://github.com/zopefoundation/zodbupdate). To discuss the details of this approach we had a hangout with Jim Fulton, David Glick and Sylvain Viollon. They solved a couple of tricky issues and wrote enough documentation. This approach seems to work well enough and the documentation points out some caveats but the ZODB migration will require some more work.
Johannes Raggam finished work on his PLIP to restructure static resources.
With this we no longer carry 60MB of static resources in the CMFPlone repository, it allows to use different versions of mockup in Plone, enable us to release our libraries on npm and will make it easier to switch to a different framework.
Skin scripts removal
Katja Süss, Thomas Lotze, Maurits van Rees and Manuel Reinhardt worked hard at removing the remaining python_scripts. The work is still ongoing and it would be great to get rid of the last of these before a final Plone 5.2 release. See https://github.com/plone/Products.CMFPlone/issues/1801 for details. Katja also worked on finally removing the old resource registry (for js and css).
Joni Orponen made a lot of progress on speeding up our test-runs by running different test-layers in parallel. The plan is to get them from 30-60 minutes (depending on server and test-setup) to less than 10 minutes. For a regularly updated status of this work see CI run speedups for buildout.coredev
Better late than never: We now have a method safe_nativestring in Products.CMFPlone.utils besides our all-time favorites safe_unicode and safe_encode. It transforms to string (which is bytes in Python 2 and text in Python 3). By the way: There is also zope.schema.NativeString and zope.schema.NativeStringLine.
pbauer (Philip Bauer) 2018-12-01 08:36:52 UTC #60
I guess most people know already but: Plone 5.2a1 was released in Tokyo. That means Plone now supports Python 3
I wrote a blogpost with a update:
Our favourite Open Source CMS has landed on Python 3. Here is what you need to know about migrating projects.
The super-short version of that blogpost:
A final release is scheduled for February
You should start planning your migration now
Many developer-tools and some important addons already support Python 3
There is more work to be done regarding migration, documentation and testing