Why has the project been forked as 'retransmission'?

[wally-crunk]

…

[ckerr]

There are several reasons, but the easiest one to explain quickly is it solves a longstanding disagreement between the Transmission maintainers on whether or not to add more maintainers.

It's still early days for the fork and we don't have signed binaries yet. Once we start doing actual releases we'll put out an announcement with more info.

[Pentaphon]

it solves a longstanding disagreement between the Transmission maintainers on whether or not to add more maintainers.

Is Transmission still the main project then? Is retransmission just a fork for other people to be added to it?

[ckerr]

it solves a longstanding disagreement between the Transmission maintainers on whether or not to add more maintainers.

Is Transmission still the main project then? Is retransmission just a fork for other people to be added to it?

@Pentaphon I can only speak for myself on this, it's not my place to tell people what to do.

I'm more excited about Retransmission and my goal is to make it a first-class torrent client.

I've contributed to Transmission for a long time and am hesitant to walk away from it. I'll stay here for awhile longer and try giving the project the same amount of contributions & energy that other people with write permissions give it.

[valcomm]

It's kind of weird situation. Let's split and then announce and discuss. I think discussion should happen first.
How changes would be applied from one project to another and back? Such synchronization is an additional job that didn't exists before.
Is one project will be doomed to be abandoned?
How bug reports will be synchronized?
All this is very alerting

[edc1512]

If this new fork can bring new life to the project, modernize the codebase, introduce new features, fix long-standing bugs, and allow contributions to move forward more quickly, then I think it could be a very positive development.

Transmission has been a great project for many years, and seeing renewed development and fresh energy around it can only be a good thing for its users.

I'm looking forward to seeing how Retransmission evolves. Good luck with the project!

[mocenigo]

I think that they have discussed already.

[valcomm]

If this new fork can bring new life to the project, modernize the codebase, introduce new features, fix long-standing bugs, and allow contributions to move forward more quickly, then I think it could be a very positive development.

You missed to mention the reason why all those great things can't happen to transmission.

[bergerjac]

If this new fork can bring new life to the project, modernize the codebase, introduce new features, fix long-standing bugs, and allow contributions to move forward more quickly, then I think it could be a very positive development.

You missed to mention the reason why all those great things can't happen to transmission.

because there's been

a longstanding disagreement between the Transmission maintainers on whether or not to add more maintainers

Few maintainers ⇒ backlog of 701 Issues and 145 Pull Requests

When there's internal conflict, never-ending discussions drain energy & morale.

Since both projects are open-source, they can swap & snag bug-fixes & features from each others codebase.

[Pentaphon]

Since both projects are open-source, they can swap & snag bug-fixes & features from each others codebase.

I'm hoping this "Retransmission" just acts as a codebase rather than a full project of its own because I'm not really keen on the idea of having a Transmission fork. I want the original project to remain the only project and for "Retransmission" to act as a proving ground of sorts where new features, fixes, and modernizations are shown to be effective, efficient and worthwhile (or not) to add to the main project and then the main project can simply cherry pick what is proven to improve the client.

[pipatron]

Since both projects are open-source, they can swap & snag bug-fixes & features from each others codebase.

I'm hoping this "Retransmission" just acts as a codebase rather than a full project of its own because I'm not really keen on the idea of having a Transmission fork. I want the original project to remain the only project and for "Retransmission" to act as a proving ground of sorts where new features, fixes, and modernizations are shown to be effective, efficient and worthwhile (or not) to add to the main project and then the main project can simply cherry pick what is proven to improve the client.

That won't happen, that's the problem. There are already billion pull requests to the project but apparently one of the maintainers won't merge them. That's the root cause of the fork. That maintainer won't magically start merging pull requests from the fork when they could have already done it in the main project.

[ckerr]

You missed to mention the reason why all those great things can't happen to transmission.

There has, for years, been a deadlock on whether or not to allow new maintainers onto the project.

The fork has picked up two new maintainers who were two of the most active contributors to Transmission.

[h1de0x]

This is phenomenal! Funnily enough, I was planning to create my own Transmission fork called ReTransmission in the near future. I’ve already developed several improvements aimed at high-load servers and seedboxes managing tens of thousands of torrents.

[ckerr]