Third-party dep updates

[GaryElshaw]

Just keeping an up to date list of dependency updates.

1. libdeflate is now at 1.21 https://github.com/ebiggers/libdeflate/releases/tag/v1.21
2. fast_float is now at 6.1.5 https://github.com/fastfloat/fast_float/releases/tag/v6.1.5

[Coeur]

Charles is not participating anymore, and Mike is only doing one PR a day with his own priorities (that may catch things up, but that will take more than 1 month). I'll not do new PRs until I see my Mac build PR merged. Thanks nonetheless for pointing out at dependency updates.

[GaryElshaw]

I see him over on electron more often than not. Have they had any more discussion regarding tearfur having write access, it seems like an obvious solution.

I saw your Mac build pr, and i get holding off.

[Coeur]

PRs done as of today list.

[GaryElshaw]

Yes, to everything you said. https://github.com/transmission/transmission/issues/7058#issue-2460688555 There was a user a year or so back who got angry, and got banned after accusing Charles of running his own fiefdom. I couldn't really see that at the time, but do now. Open source projects live and die because of the leadership personalities involved. Mike is an equal part of the problem. If it takes someone to declare a project being dead, and the reaction is to pay attention for a day, it's lost.

Just my 2c. Unless they are willing to give tearfur write access, immediately, the project should be forked. Part of my thinking on this is one of my pain-points. Charles would constantly refactor everything, and bug fixes were always secondary. Nothing is more painful than making your contributors constantly rework a problem you have previously resolved. @Pentaphon

[Pentaphon]

I agree for the most part, @GaryElshaw but I would try to not upset the admins and I definitely would bring you back to the project if there was a way to get you and Charles to work more independently of one another. Giving Tearfur write access is all people really want at this point and if they don't budge on it then I am officially worried about the project. I still have hope that things can improve without anything drastic.

[GaryElshaw]

As i said above, 24 hours of merging, and stopping, is insufficient and insubstantial after weeks of inaction. Also, completely absent, the third maintainer of the project is not only silent, but wholly absent. The primary maintainer has been silent for weeks, and as Coeur and i have pointed out, regularly contributes to another project. My personal belief? Charles lost interest in the project when tearfur offered fixes to his code. Regardless of my feelings, he hasn't engaged with anything in the project for several weeks. And there were the several weeks of absence before that until pushing 4.0.6. It's why i raised the question of leadership personalities. The impediment to Transmission is the maintainers.

I have led small, and multi-million dollar projects. The key is presence. If there is no presence, there is no plan. If triage is left to contributors, there is no leadership presence. Zero engagement from leadership is a clear signal you're alone. Worse is doing the work, and nothing happens with it, so why bother.

A personal story. My partner had enough of my 70-hour work-week and gave me an ultimatum that i had to be home by nine. At five, one of the executives where i worked told me the CEO urgently required a detailed memo on something i had been working on in his business group. I finished writing it at 9:30, went home, and my partner announced she was leaving. She left. Fast-forward two weeks later, the CEO would walk past my desk every day. I asked her if she had any questions about it, because the silence was odd. She was direct in telling me not only she hadn't read it, but looked confused. I went down to the Executive i'd written the paper for. "David, Katrina hasn't read the paper you asked me to write, what's happening?". He shuffled papers on his desk. "This one?". Yeah, that one. I went upstairs and applied for a new job.

Just by the by, in the three or so years i was involved with Transmission(?), i've never heard of bcomnes. I don't remember this person filing an issue or creating a pr for the project. Adjudicating a project when you've never contributed to it should make your perspective irrelevant. @Pentaphon

[Pentaphon]

My personal belief? Charles lost interest in the project when tearfur offered fixes to his code. Regardless of my feelings, he hasn't engaged with anything in the project for several weeks. And there were the several weeks of absence before that until pushing 4.0.6. It's why i raised the question of leadership personalities. The impediment to Transmission is the maintainers.

@GaryElshaw I agree, This whole write access issue with Tearfur would mean nothing if one of the maintainers took an active leadership role and was actually around to address, at the very least, the top 50 out of the 100 PRs and then merge the most important ones but for some reason, yes, there is absolutely no presence in the majority of our PRs. They won't even pop their head in and say "I like/don't like this big change", which is bizarre to me. They don't use all the tools Github has to offer like topics, stickies, dependency automation, etc and worst of all they got rid of you, Gary at a time when Transmission needs contributors the most. I can't imagine doing that to a project. Even if I didn't get along with somebody 100%. I'd just say: "hey let's figure out how to get along for the sake of the project" and work at that to get over whatever bad blood we had before.

I really hope something changes soon.

[GaryElshaw]

@Coeur @tearfur Just fork it. I'm deadly serious, and would welcome and support it. If three out of three maintainers can't be bothered even engaging in the conversation, for a month, they don't care. Being a maintainer is a responsibility and obligation to make time. No one is demanding every day, we all have responsibilities. But if you can spend time in your work day to contribute to one open source project while you're at work, you can spend 5 minutes communicating with another. https://github.com/electron/electron/pulls

[Pentaphon]

Just fork it. I'm deadly serious, and would welcome and support it.

This is pretty risky, though. Do we even have at least 2 people who can commit to maintaining a fork of an active project? Would we risk fracturing the community by creating such a fork? Would today's contributors prefer to contribute to a longtime project or a brand new fork? I'm all for forking a project that has been officially abandoned, but the 3 current maintainers have yet to jump ship completely.

I think Coeur's idea to split the project into libtransmission and Transmission so as to compartmentalize write access and follow the model of projects like libtorrent-rasterbar and rakshasa is a more realistic first step and we should push for that first.

[Coeur]

I do not have the time in my life to maintain a fork all by myself. It could be tried and with multiple people involved, it could be sustainable, but I prefer to believe for now in Pentaphon's wisdom (https://github.com/transmission/transmission/issues/7058#issuecomment-2283755857):

I'm in favor of escalating efforts to get the Transmission admins to listen to reason and allow somebody to move the project along themselves when they are absent or uninterested.

[Pentaphon]

Thanks, @Coeur . I hope @GaryElshaw knows I mean no offense to him with my disagreement about forking the project right now, but I am cautious by nature and simply do not think forking can be considered until all other possible options have been exhausted. i think perhaps a good first step is to poll the users in discussions as to whether they want libtransmissjon split from the larger project.

[GaryElshaw]

I do not have the time in my life to maintain a fork all by myself.

This was not my suggestion for you to do this singularly and alone, it's why i said i would support the fork in any way i can. I'm offering to help out with project communication (wholly absent), bug triage, as well as UX support. These are my professional skills.

To @Pentaphon's point, i'm not offended in the slightest. I always appreciate your thoughts, because you always have a future for the project at heart. I do too. But i don't think it's realistic in its current configuration anymore.

There are three maintainers.

It took enormous pressure for Charles to get the latest 4.0 version of Transmission out the door after a significant absence. After that push, he has been wholly absent from reviewing or proposing pr's, let alone merging others.

Mitch has occasionally weighed in on MacOS changes, but in my time in the project, it's been infrequent, and the MacOS client code has been entirely changed without his input.

Mike is focussed on the Qt and GTK clients and infrastructure. #6642 is an easy fix, from February. #4376 was me picking up a change, Mike, himself proposed, that was stuck in limbo, and has now been further stuck in limbo since December 2022.

Neither Charles or Mike have publicly engaged with anyone following the project in conversation regarding write access to the project for months, or the divisions @Coeur recently proposed.

You have to remember that the maintainers are regularly asked for review, or to respond to reported issues. They receive the same notification of their name on GitHub as i see and respond to yours. They have chosen not to respond.

I will bet significant money that if @tearfur was to join a fork of Transmission, Charles will become available. You don't have to take my word. Look back. As tearfur became more engaged with the project, Charles became disengaged.

Three things kill projects, and none of them is money. One is resistance. To provide no accommodation for others who may know more, or to disengage because of ego-embarrassment that your work could be better. The second? Everyone falling over themselves to make excuses for the wasted time of poor leadership. Third, is a total absence of leadership. Everyone asks for some direction, and there is no response.

[GaryElshaw]

Just fork it. Right now is obvious after a weekend, of no sense of urgency for 4.0.7 or communication of change, should be clear. This screenshot is the present.

Where is the tipping point? Where is the realisation that a complete disengagement not only kills the project, but actually is killing it as an application where it's banned, and there is no 5 alarm fire to rectify it? @Pentaphon @Coeur

[Pentaphon]

@GaryElshaw the thing is that we can say "fork it" but there is no certainty that there's enough people who can work on a theoretical fork any faster than the current team can, plus we don't know if enough people out there will just trust a new fork for an active project. There's also the issue of whether trackers will whitelist a new fork as well. They need to make @Coeur a member and get 4.0.7 out the door ASAP. It is the end of Summer and people might not be focusing on work as much as usual to cut a release in such a short timespan though.

[GaryElshaw]

I'm going to delete my previous comments on this 'off topic' issue tomorrow. @Pentaphon

There were weeks of inactivity before @Coeur asked if the project is abandoned. In the three weeks since, none of the maintainers have even engaged with any question from the project community regarding its future. Zero. Zero comment from a single maintainer about concerns from contributors. Whether it be rights - or what should be alarming - to have a client being actively blacklisted, and have no sense of exigency to fix it.

It's a failure of leadership to have so much talent and ignore it.