search

torproject / stem

Python controller library for Tor
https://stem.torproject.org/
GNU Lesser General Public License v3.0
257 stars 75 forks source link

Stem is unmaintained! #154

Open kkarhan opened 4 months ago

kkarhan commented 4 months ago

As hinted by me in this issue re: nyx and confirmed by @atagar as per his comment both stem and nyx are unmaintained.

I hope @torproject-git will select either a new maintainer, set them as archived or otherwise take care of them.

gk-tpo commented 4 months ago

So, here is what ideally happens from a Tor Project side: Both nyx and stem should be archived on Github. Then we'd take patches against stem via our maintenance branch on Gitlab: https://gitlab.torproject.org/tpo/network-health/stem/-/tree/maint?ref_type=heads. The flow for stem right now (which is okay for us) is explained on https://stem.torproject.org/.

For nyx we don't plan doing any releases and for stem we do bugfix/maintenance releases until we transitioned away from it our tools and the new world with arti (https://gitlab.torproject.org/tpo/core/arti) is a reality.

However, the call what to do with both projects, nyx and stem, on Github is something @atagar has to make.

emdee-is commented 4 months ago

@gk-tpo Who has write privs on this repo besides @atagar ?

Instead of archiving it you can mirror it on github. This is where it's known to be.

Do you have commit privs on that repo?

I don't see an issue tracker on https://gitlab.torproject.org/tpo/network-health/stem/-/tree/maint?ref_type=heads

It says 1.8.3 released last week: was the test run_tests.py --integ --target RUN_ALL run before it was releaed?

test/network.py should not use 9050 as a port as tor may be running on it.

The tests should check the existence of /proc/sys/net/ipv6 before doing anything with ipv6 as you may be on an ipv6 disabled system.

atagar commented 4 months ago

I don't interact with Tor's Gitlab. Moving Stem's canonical home there would remove the only person who replies to tickets or merges patches so that's probably not a good idea. ;P

emdee-is commented 4 months ago

The project should migrate away from setup.py

You can use these as starting points for both master and maint: setup.cfg.txt pyproject.toml.txt

@atagar are you the only one who has write privs on this github repo?

atagar commented 4 months ago

@atagar are you the only one who has write privs on this github repo?

No. GK, Juga, Silvia, Alex (ahf), Nick, George (asn), Mike, and David Goulet do too.

emdee-is commented 4 months ago

Thanks; I looked at the 1.8.3 gitlab code and there are some small changes relative to master from cryprtography renames and some data updates but the unit tests do not run cleanly for me. There's no issue tracker there. And I'm concerned for the coding style: I see no attempt at backwards compatability, the usage of == in requirements.txt and no double imports to deal with namechanges in imported packages. The project should never use == in requirements.txt given how many distros it's in.

The differences to the maint branch of this repo however are very substantial. What's the plan for that branch? Could you tell us in the README? If GK has commit privs here, maybe the best thing is for GK to mirror this repo into gitlab and help with the issues here...

Now we have 3 stems: now what?

Personally I'd like to see GK merge his patches into master here, and he can mirror master to gitlab, and then work on merging maint into master and dealing with any issues here. @atagar : your thoughts?

hendursaga commented 1 week ago

Just a suggestion, but perhaps pin this issue?