Selecting maintainers and continuing the usual maintenance work

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

Hello Ease Devs,

In case you are not subscribed to py4j github, I want to make you aware of the below message from them. 

Thanks, 

Jonah 

---------- Forwarded message ---------
From: Barthelemy Dagenais <notifications@xxxxxxxxxx>
Date: Sat., Feb. 6, 2021, 06:03
Subject: [bartdag/py4j] Maintainers needed (#426)
To: bartdag/py4j <py4j@xxxxxxxxxxxxxxxxxx>
Cc: Subscribed <subscribed@xxxxxxxxxxxxxxxxxx>

Hi everyone,

It is becoming difficult to maintain Py4J alone and I would like to invite contributors to become Py4J maintainers.

The landscape has changed remarkably since Py4J was first created and as a dad, CTO of a growing company and mostly python programmer, I just cannot keep up with the support requests, new Java & Eclipse versions, and the constantly changing build ecosystem.

For example Java 11 is a fundamentally different beast than Java 8, bintray (where I host Py4J eclipse artifacts) is closing, and Travis-ci.org is moving to Travis-ci.com.

I see this transition phase as a three-step process:

1. Selecting maintainers and continuing the usual maintenance work
2. Moving to a GitHub organization
3. Publishing a Py4J 1.0 or 2.0

If you are interested, please reply to this issue or contact me at barthelemy at inforbart dot com

Selecting maintainers and continuing the usual maintenance work

I am looking for contributors who will help maintain Py4J by:

1. Submitting pull requests to contribute code, documentation or infrastructure changes
2. Helping merge pull requests submitted by other contributors
3. Answering support requests on GitHub issues and the mailing list
4. Striving to preserve good test coverage
5. Striving to preserve backward compatibility at all cost as long as Py4J is on the 0.x version path.

After 10 successful actions involving code or documentation, I would give commit access to the contributor and publicly recognize them on the Py4J readme file and website.

After we have our first maintainer, code contribution from maintainers (myself included) should always be performed through pull requests before being merged into master.

Moving to a GitHub organization

When we have enough maintainers (e.g., a super active maintainer or a few active maintainers), we would move all Py4J-related projects to a GitHub organization.

Ideally we would also find a way to give access to the various release platforms to at least one other key maintainer. This would allow a maintainer to perform release engineering and I would no longer be the bottleneck when releasing a new Py4J version.

Publishing Py4J 1.0 or 2.0

I would like the Py4J team to publish a 1.0 version of Py4J that is backward compatible with 0.x.

But if we want to support Java 11 and generate interest for more contributions, I don't think it is realistic to preserve backward compatibility. I would probably suggest to start fresh with Py4J 2 and remove a lot of the accumulated cruft (the net.sf package name, support for Python 2.x).

Maintainers would be the ones providing the direction for Py4J 2.

A word about backward compatibility

I very much agree with Linus Torvalds when he says "If a change results in user programs breaking, it's a bug in the kernel."

The value of a piece of software that you can upgrade with full confidence that you have nothing to change in your own software is incredible. It means extra work for the maintainers and it means crystalizing as features bad design decisions and long-standing bugs. But it also means that your users trust you because they know that you have their back, that you are not always chasing the latest fad, and that you are not constantly forcing them to spend their valuable time upgrading their code instead of developing new useful or cool features.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.