Call for Maintainers & Support

[SebastianWolf-SAP]

Update Dec 13, 2024 We need to archive this repository. Please see the latest comment for details.

---

We regret to inform you that we can no longer maintain this project due to changing priorities. As you might have seen, the latest version of this project is built with an older RFC SDK, which is no longer supported by SAP. Therefore, the processing of issues and pull requests is on hold for now.

However, we would like to avoid having to archive the project in Q4/2024 and would like to hand it over to new maintainers. We are therefore looking forward to potential volunteers who would be willing to take over this project. In this case, please contact [email protected]. We will then get in touch with you as soon as possible.

Thank you for your understanding,
SAP Open Source Program Office

[sean-freeman]

@SebastianWolf-SAP The polite course of action in the open-source community and should be in accordance with best practice by the SAP Open Source Program Office, is to release a final version of the main branch and the last tested version (in this case, tested against NWRFC SDK Patch ?) prior to the core/sole developer stepping down from the project.

Can you please trigger another release of PyRFC, with the above last tested version, and note the call for maintainers in the release notes? The PyRFC Package can then be yanked from the Python Package Index (pypi) thereafter.

At the moment - the last version of PyRFC is version 3.3.1 released in Jan-2024, compatible with NWRFC SDK Patch 12 released in Aug-2023.

[SebastianWolf-SAP]

@sean-freeman Thanks for your comment! We will check internally what we can do here.

[fvenegasn]

Hi, I'm having some trouble with this library. As it has been disabled from PyPI, I'm not being able to get it from the command line pip install pyrfc. I also tried other alternatives and can't understand if I'm doing things wrong or it isn't possible neither.

Are we going to know what happens with the project? Is it going to still be available for use without support and/or previous SDK version? Which "official" alternatives are there going to be in the future (for example for scripts that download tables massively)?

Thanks in advance

[SebastianWolf-SAP]

@fvenegasn We've received several positive replies to our call for maintainers and will start discussions with potential new maintainers shortly. However, until these talks are completed, we don't know how things will continue here and can't give any commitments.

[fvenegasn]

@SebastianWolf-SAP thanks for the answer and hope to hear some news soon!

[leginee]

@SebastianWolf-SAP Is there an update?

[maikxmh]

@SebastianWolf-SAP are there any updates about the future of this project? Would be great if the project keeps maintained 👍

[trymzet]

I'm also curious, what is the logic behind removing already released versions from PyPI? This essentially breaks all existing code depending on the library, doesn't it?

[bsrdjan]

I'm also curious, what is the logic behind removing already released versions from PyPI? This essentially breaks all existing code depending on the library, doesn't it?

After PyRFC releases stopped following new SAP NW RFC SDK releases, the pip install pyrfc would install the PyRFC version built and tested with older and not supported SAP NW RFC SDK.

To prevent that, already released pyrfc versions are not completely removed from PyPI but yanked. They can still be installed with explicit version specifier, like pip install pyrfc==3.3.1. The pip install pyrfc is reserved for supported PyRFC version, which is not available.

[trymzet]

@bsrdjan Wow, I never realized this is how yanking worked, probably because I've only encountered only specific faulty releases being yanked before, not all of them, and I usually don't pin my dependencies to specific versions but use >=. Thank you for the explanation.

[SebastianWolf-SAP]

Dear community,

I regret to inform you that we will archive the project by the end of 2024 as we haven’t been able to properly transfer the ownership to new maintainers. The reasons for that are mainly resource constraints on our side as well as the fact that we currently cannot provide the necessary prerequisites for a successful restart (e.g. access to the RFC SDK under an open-source license, backend test systems etc.).

Of course, we will keep working on these topics in the background, but there is currently no guarantee that we can resolve them. Consequently, we recommend starting a fork or a completely new project to address the use cases that have previously been covered by this project. We know that this is challenging especially with respect to the boundary conditions mentioned. However, it is probably better than keeping the question of a transfer to new maintainers open for a longer time.

Though we move the repository to our archive, we will keep the issues open to enable you a central point for coordination between the different stakeholders in case you need it.

In case of any questions or feedback, please reach out directly to us at [email protected]. Thank you in advance for your understanding and again apologies for this step that we need to take now unfortunately.

SAP Open Source Program Office

[sean-freeman]

@SebastianWolf-SAP Test systems could have been made available/donated by the SAP LinuxLab Open-Source Initaitive team (as we are provisioning systems all the time) to a willing developer.

Overall, I am extremely disappointed at the SAP Open Source Program Office's course of action and the handling of this situation.

[SebastianWolf-SAP]

@sean-freeman Indeed, the test system issue is probably more easily resolvable than the others that I mentioned. However, the others are very tricky for several reasons - which led to the disappointing outcome.

We've started a few work items that aim to overcome some of the root causes for the situation so that they don't happen for other open source projects, Of course, this won't help us with the RFC connector projects and some tricky questions will remain, especially in times of scarce budgets and resources, but you can be sure that this decision wasn't and will never be an easy one for us.