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.