Zope-4-Welcome-Sprint in Halle, Germany; May 16th to 18th, 2018

Announcements
, ,
1

Zope 4 is already in beta, time to move applications running on Zope to Zope 4.
Zope 4 supports Python 3, time to move application running on Zope to Python 3.

The Zope-4-Welcome-Sprint is a chance to move forward with Plone and other applications built on Zope.

gocept hosts this sprint in Halle (Saale), Germany from May, 16th to 18th.

You are heartily invited to welcome Zope 4 in the Python 3 wonderland and help his friends to also start to live there.

Find more information at https://blog.gocept.com/2018/04/03/
Register at https://www.meetup.com/de-DE/Zope-Sprint/events/248187180/

Will you join us?

4 Likes
2

:+1: We could really use more Plonistas working on on https://github.com/plone/Products.CMFPlone/projects/4 and https://github.com/plone/Products.CMFPlone/issues/2368
There are plenty of fun tasks that can best be solved in small teams at a sprint.

3

I think Jan confirmed last week that he's coming to Halle for the Zope-4-Welcome-Sprint. If there's anything he should prepare in advance just let me know :slight_smile:

2 Likes
4

That's nice. To effectively contribute to Zope resp. Plone a signed contributor agreement for each of the organisations is required. If he already have them, no worry about further preparation.

5

@icemac thanks for your quick reply. Do you know where he can get the contributor agreement?

6

@JohannaKookie

The Zope Foundation contributor agreement is here: https://docs.zope.org/developer/becoming-a-committer.html
The one for Plone is there: https://plone.org/foundation/contributors-agreement

7

Here are some things every developer who wants to help porting Plone to Python 3 should do before the sprint:

  1. Sign and submit the contributor agreements for Plone and Zope: https://docs.zope.org/developer/becoming-a-committer.html and https://plone.org/foundation/contributors-agreement

  2. Create two coredev-buildouts for Plone 5.2 on your laptop. One for Python 2 and one for Python 3.
    Why? Because the py3-config uses a lot of custom branches and you would waste a lot of time switching python-versions and running buildout when you do not separate these to simply try some feature in python2. They can share the same buildout-cache.

    Python 3:

     $ git clone https://github.com/plone/buildout.coredev coredev_py3
 $ cd coredev_py3
 $ git checkout 5.2
 $ python3 -m venv .
 $ ./bin/pip install -r requirements.txt
 $ ./bin/buildout -c py3.cfg

    Python 2:

     $ git clone https://github.com/plone/buildout.coredev coredev_py2
 $ cd coredev_py2
 $ git checkout 5.2
 $ virtualenv .
 $ ./bin/pip install -r requirements.txt
 $ ./bin/buildout

    I use a custom local.cfg (one for each coredev) that has some tools that I like during developing:

    The py2-coredev should basically work without issues.

    In the py3-coredev you should be able to start a instance like this:

     $ ./bin/wsgi.py etc/waitress.ini

    It should start Plone on http://0.0.0.0:6543. You can now create a instance.

  3. Read https://github.com/plone/Products.CMFPlone/issues/2368

At the beginning of the sprint we will split into teams that work on different tasks. There are a lot of things that need to be done and here are some issues that we'd love to work on during the sprint:

  • Finish porting plone.testing (i.e. modify test-layers to use wsgi instead of ZServer) and start porting plone.app.testing. Currently we cannot even run a single test because we have no test-layer in py3 that provides a plone-instance
  • Port resolveuid_and_caption to python3 using lxml/BS4 instead of sgmllib (https://github.com/plone/plone.outputfilters/issues/27)
  • Deprecate Archetypes (https://github.com/plone/Products.CMFPlone/issues/2390)
  • Start a instance and fix a feature that does not work yet in py3. There are plenty of these and it is fun to hunt and fix these issues. I will bring a list of broken features to the sprint :smiley:

As a small motivation-token here is a screenshot of the Plonesite I just created in Python 3. Today I finally found the time to fix a issue that broke creating a new site.

py3shot
py3shot.png2688×1898 156 KB

3 Likes
8

I am experimenting the tox way:

So I can have one coredev checkout, one shared src and I can run the tests for both Python versions, i.e.:

.tox/py27/bin/test -s package.name
.tox/py36/bin/test -s package.name
1 Like
9

@alert, is the idea there to also map all the (sub)packages across a test matrix and parallelize via Travis and/or AppVeyor for buildout.coredev?

10

@Rotonen actually I have no plan :slight_smile:
Whenever I have some time I try to pick a package and make the test run for both Pythons and the current tox configuration (even if it is not perfect) is something that makes this quite convenient.

11

One to solve before the sprint if possible, is this one:

This is the problem causing our jenkins builds to hang some times.
See:

and

It can also be reproduced outside of running tests. Sometimes when stopping Zope, it will end with a keyerror instead of closing down nicely. This can probably cause issues with proper reporting of shutdown (docker etc.)

12

pbauer have pinned ZODB to 5.3.0 to avoid jenkins hanging, until the issue in ZODB is solved. See