pypi / support

Issue tracker for support requests related to using https://pypi.org
94 stars 48 forks source link

PEP 541 Request: scikit-optimize #4554

Open fkiraly opened 1 month ago

fkiraly commented 1 month ago

Project to be claimed

scikit-optimize: https://pypi.org/project/scikit-optimize

Your PyPI username

fkiraly: https://pypi.org/user/fkiraly

Reasons for the request

scikit-optimize has been archived by one of its maintainers, and is no longer maintained.

I wish to continue maintenance, in close collaboration with the sktime ecosystem, in which important tuning routines depend on scikit-optimize.

Maintenance or replacement?

Maintenance

Source code repositories URLs

https://github.com/scikit-optimize/scikit-optimize

Contact and additional research

The scikit-optimize repo was archived in February 2024, without any further announcements accompanying this.

I contacted the main admin, Tim Head (@betatim), on June 3, 2024, and received a cautiously positive reply on June 4. He confirmed that the project is no longer maintained.

The conversation then developed a little, but then stalled, and finally no more replies were forthcoming (after mid-June).

I was also able to reach another maintainer, @holgern, who claims that Tim Head simply shut down the project without discussing it with other maintainers. @holgern has created a fork, on which he continued maintenance (including updates to newer python versions etc). In an issue there, our discussion of the very odd situation: https://github.com/holgern/scikit-optimize/issues/6

@holgern may be willing to further contribute to maintenance if the governance/ownership question is sorted, though from our communications I gathered that he does not want to get involved in the admin side (e.g., the PEP 541 request, transferring repos, setting up release pipelines, etc), and prefers to focus on technical matters.

From my perspective, the simplest would be just ot hand the project to me, I will then immediately move it back to maintained status under the sktime umbrella, and integrate it into release and maintenance processes, which should simplify accompanying processes. Remaining active maintainers can then contribute, under a guarantee that the project remains open, openly governed, and professionally maintained.

Code of Conduct

betatim commented 1 month ago

We (@glouppe and I, the remaining original creators of the project) decided to archive the project on GitHub after years of inactivity. Even before we officially marked the project as archived it was clear to many that it was no longer maintained. They created forks and made releases of those forks on PyPI under new names. I think this is a natural way for a project to continue.

When we archived the project I did not realise that Holger could upload releases to PyPI under the original project name. I only realised after he made a new release. My preference here would have also been to create a release under a new name.

The main reason that I think creating a fork under a new name is that none of the original creators and long term maintainers of the project are involved in any of the forks. As topics like supply chain attacks and software security become more important I think it makes sense for users to notice that the project is under "new management" and re-evaluate their level of trust in the new maintainers.

If there is a (or several) successor(s) that gains adoption and a track record of maintenance we'd be happy to endorse that/those projects on the GitHub project website and on PyPI as a way to point people to where they can find continuing support and development. (technically I am not sure how best to do this on PyPI)

fkiraly commented 1 month ago

@betatim, I am quite unhappy about the implicit allegations related to supply chain security in connection to me speficially, here:

As topics like supply chain attacks and software security become more important I think it makes sense for users to notice that the project is under "new management" and re-evaluate their level of trust in the new maintainers.

I would even go so far and consider this at least borderline, possibly a blatant violation, with respect to the code of conduct relevant here. You are, between the lines, alleging that my involvement, or that of sktime's governance, would introduce an element of supply chain risk.

I am not part of your direct network or scikit-learn/probabl decision makers, and my name does not match the general pattern in it where most people have English or French names. But pointing to supply chain risk directly in this conversation, and as the main concern you have with regares to my request (in which you are posting), makes my detector for racism, xenophobic and other exclusionary dogwhistle patterns tingle.

It's like, your neighbor - a minority/immigrant person - wants to move in, and you suddenly start talking being concerned about knife crime and theft in the area, and talk to your landlord, maybe we should work out a crime/theft concept or just leave the flat unoccupied.

Also, responding to the accusation directly: why is the current situation, with you the only person holding the keys, a lesser risk for a supply chain attack?

One could even say, you directly attacked the supply chain - of a package that still gets about a million downloads a month - by pulling it off the grid without any clear public messaging. You still hold the keys to the pypi account and can, at any time, reactivate it, and upload a malicious version - noting that it still gets about a million downloads a month.

Further, you have a proven history of pushing maintainers off the project who intended to continue maintaining it, for no clear reason, and you even say you are annoyed by the fact that they continued to maintain the package, keep it usable by its current, large user base, which is pretty pretty strange in my book.

In summary, I think the current situation constitutes a higher supply chain risk than many of the alternatives I can imagine.

Regarding track record of maintenance, have you even looked at sktime? It has a comparable footprint, and the professionalism and continuity of maintenance has been orders of magnitude above scikit-optimize over the last years.

fkiraly commented 1 month ago

PS, @betatim, it probably does not help your case in reply to this that the last commit on scikit-optimize before its shutdown has a swastika on it (retrieved February 28, 2024, the date of repo shutdown).

skopt-swastika-2024-02-28