Concern about ambigous rtorrent fork

[zawapete]

At https://github.com/jesec/rtorrent you can find a kind of fork, with no clear statement about its nature and relation with the original project, aiming on the paper to improve RPC interfaces and other optimistation.

I'm rather concerned since the maintainer proofed on other project to be uncaring about community and to be rather following its own development agenda.

He's also the maintainer of Flood, that started as a rtorrent web front-end (an alternative to rutorrent), and now is going to shift to support the JSON-RPC he added to his fork, loosing compatibility with original rtorrent.

What's the stance on the situation by rtorrent's original developer?

[jesec]

Maintainers are not compensated in any way, and we do not have any "agenda". It is you who claimed there is a "customer need", and try to force a technically deficient PR into my project.

I have already spent numerous voluntary time to review your PR (jesec/flood#70) , and made a bunch of code review comments. However, in the end, the code quality is far from satisfactory, and the use case is only limited to your (presumably, paying) "customer".

Your false allegations made me sick. I found it very unfortunate that you choose to do this.

As for my rTorrent distribution, my objective is clear: improve integration with modern RPC users (like Flood) and there is no consensus layer (BT protocol related) change. I would be happy to contribute the changes to the upstream, if they are deemed useful to a wider audience. Thank you rakshasa for this amazing project.

[zawapete]

@jesec I didn't make any allegations, contrary to you and I won't indulge in any personal discussion.

Here the discussion is different: we have two projects with the same name, the original one and another one that's not an explicit github fork and contains relevant and breaking changes while adressing itself as the original one.

this is a risk for the rtorrent community in my opinion: from trackers's clients whitelist to frontend compatibility

I would be more than glad if your improvement on the RPC part would be pushed upstream (you might be an awful maintainer in terms of community ecosystem but you're a good developer) since it would be the only way to avoid the above.

That's why I asked what's the stance of the original rtorrent developer

[rakshasa]

Looking at the amount of commits to the other repository, it should definitely not identify itself to trackers as an official rtorrent client, as that will cause issues.

This does not mean I disapprove of the effort.

As I've focused what time I have had the past couple years on developing a CI environment in an effort the tests necessary to fix various issues, the user-facing part and new features has been mostly ignored.

[sveinbjornpalsson]

The question I find to be missing from this conversation: @jesec is there a reason why the fork carries the exact same name? Could it have an amended name, like rfTorrent or something, so it'd allude to its origin but differentiate itself clearly for those who might be confused?
I concur that your rTorrent page doesn't present itself as anything else than rTorrent proper - until you start reading all the text, and even then it's a bit unclear.
Since flood is ever more popular (I'm slowly moving there myself from cursed ruTorrent), I'm sure that stream of users is enough to make it worthwhile. Otherwise you'd have to hold on to compatabillity for other solutions, and if I read this correctly, this is something you must make to serve Flood and its class of programs?
So it's a pretty clear decision, if you chose to make it.
I find that @zawapete opened the discussion on a needlessly agressive statement. Whatever your person may be is completely irrelevant. Us nerds much prefer rules over gossip and innuendo. But he does have a kernel of a point.

[aspacca]

since the project come back to development thanks to sponsorship (thanks to the sponsor and to @rakshasa and the other contributors), i guess the issue became relevant again

[rakshasa]

In what ways will that fork be relevant?

Asking for specific reasons as it seems to not have any development in 2+ years.

[aspacca]

In what ways will that fork be relevant?

Asking for specific reasons as it seems to not have any development in 2+ years.

https://github.com/jesec/flood is still active, and as fair as i know it has some "adoption traction" by the torrent community as alternative to rutorrent.

there's still confuction between @jesec 's rtorrent and @rakshasa 's rtorrent: https://github.com/jesec/flood?tab=readme-ov-file#rtorrent-notes

troubleshooting section doesn't clarify imho properly which one is the so-defined "vanilla rtorrent": https://github.com/jesec/flood?tab=readme-ov-file#troubleshooting, mixing installation instruction between the two "distro" in the same bulletpoint like if they are the same thing or interchangeble

i find this very confusing and misleading to the torrent community, and could lead to unintended consequences for users on trackers with a clients allow-list

[fffe]

I'm not sure what action you folks expect to be taken here.

If you don't feel the documentation for flood is accurate, submit a patch. As you note, it has a maintainer again.

[sveinbjornpalsson]

There is so much lore missing, I don't remember why I posted here, I think I was giving up on flood? One thing I don't love about these github apps is that it's often very time consuming trying to keep up with what's happening in them.
I ended up with qbittorrent, which is quite imperfect, because RUtorrent seemed stuck in the 00s and Flood wasn't a viable alternative due to all the being dead.

I'm not making a point here, I just lament the fact that nobody is documenting this in a simple fashion. It's either an endless changelog or you're out of the loop.

Food for thought. Not meaning any ingratitude for everyone's great work.