Future of icalendar, looking for maintainer

[mauritsvanrees]

I have created a post on the Plone community forum about the future of this package, and needing a maintainer for it. If you want to add your thoughts, please create an account and comment there. But since icalendar seems to have users outside of the Plone community, where it originated, we can try out Discussions in this repository. I don't think I have used GitHub Discussions yet anywhere, but let's see. Let me copy the entire post below.

The icalendar package in the Plone collective has been designated as a "critical" project on PyPI, meaning it is in the top 1 percent of downloaded packages. It was started by Martijn Faassen in 2005, saw lots of commits by Johannes Raggam and Rok Garbas around 2011/2012, during the time plone.app.event was created and added to Plone. You can see all contributors.

Apparently I am the number four contributor, but that is only because I occasionally make a release. I hardly know anything about the inner workings of this package. As Plone Release Manager I am interested in having stable releases of this.

It would help if we get some fresh developer/maintainer blood in here. Is anyone capable and interested?

I have some ideas for the near future, to hopefully get things unstuck:

• We should no longer test this on the Plone Jenkins server. That would be something to arrange in mr.roboto. I can have a look at that.
• The package can use Github Actions instead.
• According to setup.py the package supports Python 2.7 and 3.4-3.10. We should get GitHub actions to work with those versions. I expect that this is not really doable for at least Python 3.4 and 3.5, so we would need a new major release in which we drop support for some Python versions.
• Ideally there should be a branch that keeps working on all Python versions that are supported for Plone 5.2, which means: Python 2.7, 3.6, 3.7, 3.8. Maybe that just needs to be the current branch, which we then would copy to 4.x. If we fail to get Github Actions to work for this, Jenkins for Plone 5.2 should still keep testing the package.
• Increase master branch version to 5 (or 6 if needed). This should keep working on Plone 6.0 (which is near beta), which means Python 3.7-3.10.

So the first action item is really: try to get Github Actions (and locally tox) running on as much Python versions as possible, with a reasonable amount of effort.

Some links:

• PyPI: https://pypi.org/project/icalendar/
• Documentation: https://icalendar.readthedocs.io/en/latest/
• Code: https://github.com/collective/icalendar, where you can see it has 138 forks and 783 stars.
• Issue tracker: https://github.com/collective/icalendar/issues
• 18 open pull requests: https://github.com/collective/icalendar/pulls, including:
  • My failed attempt at adding GitHub actions, from November 2021.
  • Document Setup process for development.

[mauritsvanrees]

I have managed to revive my gh-actions PR, and it is now green and merged. I have disabled Jenkins tests in the settings in this repo. Something more might be needed, but for now I think on new PRs these checks should no longer pop up.

I have released 4.1.0 and 5.0.0a1. The only current difference is that 4.1.0 (new branch 4.x) only drops some Python versions from the tests, and on 5.0.0a1 (master) they are really officially not supported anymore. We could drop more versions there if we want. Now at least both branches have a reasonable tox and gh-actions. So for clarity:

• Branch 4.x is for Python 2.7, 3.6-3.10, and PyPy3. Those are tested. Technically it should still work on 3.4, 3.5 and PyPy2 and let's try not to break this.
• The master branch is tested and officially supported on Python 2.7, 3.6-3.10, and PyPy3. I would be in favour of dropping 2.7 and 3.6 here.

[geier]

All for dropping old version of python

[niccokunzmann]

@mauritsvanrees I am maintaining recurring-ical-events and others that build on top of icalendar in my free time. I will give it a go for a bit but I am unsure about the amount of time that I can put in and how the trust hand-over works. This is a really critical project. That should be made clear also in the distribution of the new versions.

Is it alright to raise a Warning in the latest version that a maintainer is needed? I mean - this should concern people using it really! I am a bit more concerned as this did not receive any comment until now..

After adding #365, I see that recurring-ical-events accounts for about a bit less than 1/3 of the installation reasons for this package.

While I am not in the depth of the code of this, I have long-term Python experience and read Python-libraries for fun. Also, I can keep the discussion going forward while keeping the quality of the code. Like this is a no-brainer: #330 and it just needs some attention - for a year now...
If I get write access, I will ping you for checking my PRs (mostly docs/tests) while keeping some of the other ones going forward...
What are your thoughts on that?

[geier]

Please don't emit a Warning at least not during run time (while installing, e.g. in setup.py is fine for me), end user applications only will need to suppress that.

Recurring-ical-events looks interesting, I'll give it a go and see if it can replace a lot of ugly code for us.

[niccokunzmann]

Recurring-ical-events looks interesting, I'll give it a go and see if it can replace a lot of ugly code for us.

Maybe you will find some edge cases.

[geier]

Thank you for inviting me @mauritsvanrees to become a maintainer. I'd love to contribute more to icalendar, but I rarely have the time, but I'm happy to review some PRs and contribute occasionally (but mostly if it concerns khal).

Also, I think somebody more understanding of the needs of the Plone community would probably make sense.

I'd like to not only drop python 3.6 but also 3.7 (because python 3.8 makes type hinting really a lot easier IMHO), make icalendar always return strs not bytes, make sure we always return valid icalendar objects, migrate from pytz to tzinfo. All of which would break with the long-term stability that -- if I understand it correctly -- plone needs.

[mauritsvanrees]

Thank you @niccokunzmann and @geier for stepping up, and be willing to do what you can. Let's see how it goes.

For me it is okay to drop Python 2.7 and 3.7 from the master branch. I have changed Plone 5.2 to use branch 4.x. And on latest Plone 6.0 I have added a pin for Python 3.7 to use the latest 4.x version as well. I have created #366 to drop older versions. Can you review.

I have merged several PRs today.
Ping me if you have questions related to Plone, or need to get things unstuck.

Christian already has PyPI rights. Nicco not yet. I see two accounts on https://pypi.org/project/recurring-ical-events/. Which account can I add for you?

[niccokunzmann]

I do not much mind not having access to PyPI at the moment. I could probably contribute more if I had write access to this repository.

[mauritsvanrees]

Ah, I did not realise you do not have write access yet. Everyone can get write access to the Plone Collective where this package lives. I can give you an account there. Or if you you prefer I can add you to this repository only.

[niccokunzmann]

Nicco not yet. I see two accounts on https://pypi.org/project/recurring-ical-events/. Which account can I add for you?

@mauritsvanrees, The account to add would be niccokunzmann - the other one is an old account for automatic deployments before API tokens.

[niccokunzmann]

Thanks. I see that some people do not have 2 factor authentication enabled. Would it be alright to contact them and ask if they like to do that or be removed from the project? There are many people who do have it enabled. That might be low priority, though, for now.

[mauritsvanrees]

One of these users is plone, which is a shared account of the Plone release managers (including me). Enabling 2FA there sounds tricky.

Another is maxm, who I do not know.

I do know the two remaining others, who I will ping here.

[mauritsvanrees]

@garbas @rnixx You are among the owners of icalendar. It turns out that this package is so popular that it has been tagged as critical by PyPI. This means PyPI wants all contributors to use two-factor authentication. Some info here. You do not have 2FA enabled on PyPI. Would you like to do that? If you are no longer interested in PyPI ownership I could also remove you there.

[garbas]

Hi @mauritsvanrees! Feel free to remove me from the owners list. I'm not doing much of python development these days. Happy coding to all!

[mauritsvanrees]

Hi Rok. I have removed you. Happy coding to you too. And you know: there is always a place in the Python and Plone communities for you!

[niccokunzmann]

@geier, I went through all the pull requests and updated people there about the status of the repo and asked them to rebase/merge of possible.

[WhyNotHugo]

Happy to see this under active maintenance again! I'm using this library for todoman, and currently support Python 3.10. I'd like to switch to moving ZoneInfo in future, which is part of Python's stdlib but has a backport for 3.8 and 3.9. Any thoughts on this?

In the meantime, I've rebased my old PR which removes a lot of leftovers from older python versions: #327

And also this other one just auto-generated with pyupgrade --py38-plus: #376

[niccokunzmann]

Thanks for that!

(1) I see your PRs and I think I would want to wait until 3.7 or not 3.7 is decided to merge 3.8 upgrades - I commented there as you can see.
(2) Personally: I test pytz and zoneinfo for python-recurring-ical-events and pytest allows to run all tests on both implementations after another. BUT: moving forward is dropping pytz probably as it is much better to use zoneinfo and people use pytz in the wrong way so many times. Python3.7 EOL is in 10 months - good question. What do you think? I think, we discuss it in #368 at the moment.

[stevepiercy]

@niccokunzmann, @thet and I have started the planning phase of work to update the Plone Event content type, which primarily uses plone.app.event which in turn has icalendar as one of its dependencies. We also decided to transition from pytz to zoneinfo, and our work is targeted for Plone 6.2 or 7.0, whichever version drops support for Python 3.8 first. You can read our Plone Improvement Proposal (PLIP) at plone/volto#5629.

I lead the Plone Documentation Team, and developed a timezone converter application about 15 years ago in an obscure web programming language before I started using Python. I started watching this repo. I hope to contribute to this project, especially documentation. I also helped @mauritsvanrees revise the Plone release policy for 2024.

[niccokunzmann]

@stevepiercy,
I acquired funding from NLNet #595 and zoneinfo for icalendar is on the list #609. Cool that you are also going this way!

I would discuss how to go about moving to zoneinfo in #609 instead of here. Please leave a comment on what you see needs doing. Thanks for linking plone/volto#5629.

Over a year ago, we started refactoring the tests so that we could potentially allow to use pytz, zoneinfo and other timezone implementations in icalendar - make it flexible. Moving to zoneinfo, nobody has objected to drop pytz. So, being flexible might not be needed. Thanks for your note here in this project and I look forward to seeing how we can join forces!

[niccokunzmann]

Let's continue this conversation here: #609.

[niccokunzmann]

For those who do not want to read the full discussion, a summary (I will edit it here), please leave a comment.

SUMMARY

A list of the maintainers of the package with their abilities/focuses

• @geier - likes to contribute code and evolve the package?
  Abilities:
  • review
  • merge
  • deploy new versions
  • GitHub admin
• @niccokunzmann - likes to involve people, document, test.
  Abilities:
  • review
  • merge
  • deploy new versions
  • GitHub admin
• @mauritsvanrees - likes to make sure this project is maintained and progressing.
  Abilities:
  • review
  • merge
  • deploy new versions
  • GitHub admin

Does this sound true? Did I forget someone?

[niccokunzmann]

@geier - there are branches that are very old...

The latest ones (5 years) are your branches - I would hope the others can safely be deleted. What do you think since you are more involved in these branches?

[geier]

yes, we can delete those.

[WhyNotHugo]

Is buildout still actively used for this project? If not, buildout.cfg and bootstrap.py can be deleted.

[niccokunzmann]

Hm. Email may not work on discussions...
So, I do not know what these are, never used these. I think, you can remove them - if we need them, we can revert the PR. Also, it removes clutter that does not add to functionality. There is nothing in the documentation, only in setup.cfg.

[mauritsvanrees]

buildout.cfg and bootstrap.py can be removed indeed.

[niccokunzmann]

I allowed the actions to run as they do not contain any secrets and it is nice to get the result and not wait for a maintainer...

[niccokunzmann]

@geier @mauritsvanrees, I have this proposal:

The intention of this is to smooth out the way to become a maintainer & contributor in this project.

The strategy:

• We create two teams:
  • maintainers (admin access)
  • contributors (write access, should not merge their own PR)
• When people create a successful pull request, we ask them if they would like write access to the repository. If they agree, we add them to the contributors group.

Hoped Result:

• people are more engaged as they can review and merge other PRs
• we clarify the process and documentation when we see something happening that we do not like
• when people see that they can review/merge - after a while they might like helping out more
• we get workload off our shoulders, more reviews, more discussion, more engaged community.

What do you think, should we try it out?

[mauritsvanrees]

Sounds fine to me.

[niccokunzmann]

@mauritsvanrees I am not allowed to create the icalendar-admin and the icalendar-contributor teams in this organization.

I would like to add @jacadzaca to the contributor team because of the interest in maintenance as shown in #392.
Can you or who could

• create the two teams
• make @geier and @niccokunzmann admin of the two teams?

thanks for your support!

[mauritsvanrees]

I have added the two teams. Sorry it took a while.
I wondered why you could not do this, since you already have admin rights. But they had to be added on the organisation level.
icalendar-admin has admin rights, icalendar-contributor has write rights. I have invited you and @geier to the admin group.

[niccokunzmann]

Thank you very much, no problem!

[niccokunzmann]

I invited @angatha to be come a contributor as I saw the contributions in the last days reviewing PRs.
Invitation: #413 (comment)

[niccokunzmann]

I would like to give @jacadzaca equal maintainer status to myself. The work is nice together, committed and thoughtful. @jacadzaca published version 5.0.1. Thanks! @jacadzaca do you accept? Does anyone have any comments?

Here is a blog post that inspires me: http://hintjens.com/blog:95

[niccokunzmann]

• Repository Admin
• Maintainer on PyPI
• Maintainer on readthedocs
• PyPI env access

see https://icalendar.readthedocs.io/en/latest/maintenance.html#maintainers

@jacadzaca
What is your PyPI username? Do you have 2 factor authentication enabled?
What is your readthedocs username?

[jacadzaca]

@niccokunzmann My pypi username is jacadzaca and I have 2FA enabled.

[niccokunzmann]

PyPI invite is pending. Could you create an account on readthedocs? I would like one more person there to improve the bus factor.

[jacadzaca]

I created an account on readthedocs, my username is jacadzaca.

[niccokunzmann]

Thanks, I sent an invitation there. You are 100% set up with authority and responsibility! 🥳

[niccokunzmann]

That is documented above the release process. I will do it one-by-one when I take the time.

[niccokunzmann]

I do not really know where to post this but here is the usage statistics from readthedocs. I think, this is nice to keep in mind when it comes to making the documentation nicer.

[niccokunzmann]

I am adding @ennamarie19 as a contributor with write access so we can be taught about the fuzzing tests and also have more people to look after the project who are more committed.
See also: #574 (comment)

[niccokunzmann]

@ennamarie19, welcome!

[ennamarie19]

Thanks so much! Looking forward to what comes of this!