I made a quick calculation of the emails that were sent to the project organization list of the LibreOffice germanophone project (de-discuss-list). I looked at the number of mailing addresses which were subscribed to the list and the number of postings during one year from 2015 to 2020. I started with the numbers from 2015-06-14 and my calculation endet with the numbers from 2020-06-21.
The number of mailing addresses subscribed to the list: – June 2015: 198 addresses – June 2016: 208 addresses – June 2017: 204 addresses – June 2018: 208 addresses – June 2019: 210 addresses – June 2020: 221 addresses
I calculated the number of mails during one year since June 2015: – June 2015 to June 2016: 1208 new mails – June 2016 to June 2017: 1281 new mails – June 2017 to June 2018: 1087 new mails – June 2018 to June 2019: 865 new mails – June 2019 to June 2020: 699 new mails
Although the number of mail addresses subscribed to the list increased during the period (with one exception) the number of new mails declined dramatically to approximately 54 percent. Thus the communication inside the open source project went alarming down.
I worked on a Plone add-on to manage conferences. I already created such an add-on to run the LibreOffice conferences in Berlin (2012) and Milano (2013). But this add-on was build against a former version of Plone and Python 2. It used the Grok style which could have some side effects. Thus I decided to move away from Grok style for an upgrade / a new setup of the add-on.
I already moved all modules and active functions away from Grok and reordered the structure of the add-on. I added a new configuration panel to the administration page. I could also fix relations and the indexing. You could get the code from Github at: https://github.com/collective/collective.conferences.
I worked further on a Plone add-on to manage conferences and had to work with the navigation root of a Plone site. I moved this navigation root to the container object of the conference add-on. The navigation worked as expected yet (the objects in top container made it to the main navigation menubar), but the login and register links at the top of the site didn’t work anymore. Thus I had to edit the links of this actions / portal_actions inside the ‘Site Setup’ or the Plone ‘Management Interface’. I added a short howto about this.
I created a Plone conference add-on a longer time ago, which was used to run two LibreOffice conferences. I published the code of this add-on on the Plone collective Github account.
This add-on was created and used within Plone 4 and the Grok method. This is not the usal way to develop on Plone anymore thus I decided to first drop all grok ties and replace them with other Plone methods, especially make better use of configure.zcml. I’ll finish this work during the next days.
The goal of my work is the migration of the conference add-on to Plone 5.2.x and Python 3 and add new features afterwards to support the work of organizers of analog and online conferences.
I added a feature to choose if the name and / or the contact e-mail address of an addon project should be published on the projects page during the last days. Today I created a release from this changes and published it on the Cheeseshop (https://pypi.org): https://pypi.org/project/collective.addons/
I worked further on the source code of the Plone add-on collective.templates and added a feature to display the username and the e-mail address of a project owner on his/her choice. The new release contains also an improved user documentation.
I worked with the Plone add-on for virus scanning yesterday and evaluated an issue with a new feature in the Plone add-on plone.formwidget.namedfile. If a file field was not changed (no replacing upload) the return is ‘NOT_CHANGED’ and validator module of collective.clamav was not able to get any data to scan. But there was no need to run a scan in such a situation and thus I added a appropriate check to the validator module. There will be no virus scanning for unchanged file fields anymore.
I worked on the complete migration of the LibreOffice extensions and templates website repository to Python 3 and Plone 5.2.x during the last days. I was able to upgrade the staging (development / single instance) buildout first. I worked on some Plone add-ons to reach this goal in my spare time during the last weeks.
But for the success of the migration to Python 3 and Plone 5.2.x is necessary a working production buildout. Thus I worked on the live.cfg buildout script for the site and created a new version of it: live2.cfg. I used this new script for the setup of a pure zeoserver with four instances. I could also add the supervisor controller to start and stop the zeoserver and its instances.
Then I worked on adding the support of Varnish to it. I used the add-on plone.recipe.varnish from the Github repository for that and changed Varnish to the a current LTS version 6.0.6. I could start varnishd with supervisor although I got an error message with supervisorctl status for it. The Varnish log stated that it could not get the socket of the port, it is configured to run on.
I looked with netstat -pln into the processes running on my PC and found varnishd running and listening. Thus Varnish had been started, but supervisor lost control over it. I was not able to stop Varnish with a supervisorctl command.
I worked further on the migration of HAProxy to the new Python 3 setup. I got a hint from a member of the Plone community that he already created a working branch of plone.recipe.haproxy for Python 3. I changed my buildout scripts to use this branch and I could build and run HAProxy too. But HAProxy didn’t get in contact with Varnish and the zeoserver instances in my setting. It stated that this instances were not running / available, although they are.
I got another hint from this community member and changed my buildout further. I changed the ‘bind’ Varnish configuration line to point to the Haproxy port of my buildout setting. The error message from Varnish disappeared. I was under control of supervisor yet.
Then I read in a blog about an issue of the HAProxy configuration, if it checks via http for the availability of Plone instances. I removed this option (httpchk) from the haproxy.conf file and everything went green. I could finish the migration to Python 3 and Plone 5.2.x.
The next step would be a test with a copy of the database and content of the current LibreOffice extensions website. I asked for this some days ago, but got no answer yet.
The Python version 2.x is soon reaching the end of it’s lifecycle. The last release of this Python version will be published Mid of April 2020 (https://www.python.org/dev/peps/pep-0373/), thus in less than three weeks. After this date Python 2 will not get any updates, not even for security reasons.
If a software is using Python 2 and not using only a Python 2 supported by a Linux distribution, it’s time to move forward to Python 3 and publish a new release for this switch. If a software project especially targeted to enduser is not able to do this switch at least to the end of April 2020 (or short after this date), the software should not delivered anymore and the user of the software should be informed accordingly. If there is an suitable alternative to the software the user should be pointed to that alternative.
Today I looked into the source code repository of a well known open source software for office worker and it seemed this software (Apache OpenOffice) is using only Python 2.7.x (see http://openoffice-vm1-he-de.apache.org/xref/aoo418/main/python/) and has not been upgraded to Python 3. In contrast the other succesor of OpenOffice.org , LibreOffice, has been ported to Python 3 for some time. Thus the Python bindings of this open source software is more up-to-date and the use of LibreOffice secure and forward-looking. If the open source project Apache OpenOffice will not be able to publish a new release with Python 3 bindings at least at the beginning of May 2020, the software should not be delivered anymore and the current user should be informed accordingly with a link to the successful and vibrant successor.