Suggested order of merging ready-to-merge PRs + Transmission 4.0.6 release

[Coeur]

What is the issue?

To avoid the Transmission project stalling too much like it did a few years back (between Transmission 3.0.0 and 4.0.0 ?), I'm attempting to drive focus on merging what matters for next release.
https://github.com/transmission/transmission/pulls?q=is%3Aopen+is%3Apr+draft%3Afalse+assignee%3Amikedld

So here is a personal suggestion order of merges to be performed, by my perceived priority/low-risk, and hopefully they all get merged quickly before other refactors.

blockers (build failures or broken app that should be addressed before anything else)

• none at the moment

4.0.x (production fixes that could be addressed and released without delay)

• fix: escape single file torrent name #6846 - Fixes encoding (needs a second PR for 4.0.x branch)
• [4.0.x] fix building with mbedtls 3.x #6823 - Fixes building with mbedtls 2.0-2.6 or 3.x
• chore: add Add <launchable> tag to GTK client metainfo (#6720) #6779 - Fixes GTK launchable
• fix: store seconds downloading/seeding when stopping torrent #6844 - Fixes Sonarr (needs cube review)
• chore: improved filterbar for narrowed viewports in web client #6761 - Fixes web UI
• feat: save queue order between sessions #6753 - Fixes queue order between sessions (needs a second PR for 4.0.x branch)

Kindly come to a quick agreement for the last two, and then:

• Release Transmission 4.0.6

pipelines testing and warnings (benefits all the other pull requests)

• removing temporary workaround for sanitizer crashes #6802 - Improves sanitizer pipeline
• Fix incorrect value for SortIncludes in .clang-format #6784 - Fixes clang-format

docs and safe changes

• Update outdated Doxygen params refs for tr_recentHistory #6791 - Fixes Doxygen
• fir scripts, document usage of systemd overrides rather than changing… #6800 - Improves Security with systemd
• Building the QT app with CMake #6814 - Building QT app
• Avoiding "sec" as abbreviation #6828 - International System of Units

fixes

• build error fix: #6842 #6843 - Fixes building with gcc 8.2
• fix building with mbedtls 3.X #6822 - Fixes building with mbedtls 2.0-2.6 or 3.x
• Add virtual destructor to the polymorphic Settings class #6786 - Follow rule of 5
• Fix potential Null pointer dereference in rpc-server.cc #6780 - Minor warning fix
• fix: possible heap-use-after-free with magnet links #6815 - Crash fix
• refactor: store peer info objects in shared pointers #6614 - Crash fix
• feat: allow port forwarding state to recover from error #6718 - Recover from error
• Default initialize sleep callback duration in tr_verify_worker #6789 - Initialization fix
• Recommended Project Settings #6591 - MacOS Project warning fix
• rename "UpdateQueue" to "UpdateTorrentsState" #6613 - MacOS Project warning fix

fixes pending review

Only a subset of them, but which I believe are mature enough for merging, pending a little approval?

• chore: resume file remove redundant have key and other cleanup #6747 - @ckerr ?

features (oldest ready-to-merge PR first)

• feat: torrentVerify on completion #4178 - macOS prevents corrupted downloads
• feat: dual stack udp tracker support #6687 - bep 15 compliance
• feat: ipv6 lpd #6700 - bep 14 compliance

features pending review

Only a subset of them, but which I believe are mature enough for merging, pending a little approval?

• Support dual stack by manually creating and binding socket on Windows platform #6548 - Windows dual stack support - @mikedld ?

refactor (best done last, to avoid potential conflicts with higher importance ready-to-merge pull requests)

• refactor: new tr_variant API in transmission-remote and other cleanup #6798 (not reviewed yet)
• refactor: sorting torrents for display in qt client #6729 (not reviewed yet)

[Coeur]

@mikedld @ckerr @livings124 there are strictly no one else with write access to this project than you three. Could you give a weekly look to the pull requests, or grant write access to some of the Members (tearfur, nevack, ...)? Thanks!

[tearfur]

I normally don't nag much, because more than enough people are doing it, but...

@transmission/core-devs Any word for a new 4.0.x release? Fixes for the speed limit are waiting in line to be released for 5 months by now. People are getting upset because the bug is quite disruptive #6361 #6736.

The recent months has been frustrating. I'm starting to lose interest because I'm not so confident that any core devs (which is essential for this project to move at all) are also interested anymore.

[Pentaphon]

or grant write access to some of the Members (tearfur, nevack, ...)? Thanks!

I very much support this. Tearfur especially is very active. We need just 1 more point release and then 4.1.0 should become first priority.

I'm starting to lose interest because I'm not so confident that any core devs (which is essential for this project to move at all) are also interested anymore.

I hope this isn't the case as I very much appreciate the work you've done on the project so far. Hopefully the Summer will allow people more time to devote to the project.

We also need somebody to make the Github project page more discoverable to hopefully attract more contributors as I brought up in #6150 and figure out the license situation as brought up in #6836

[Coeur]

Thank you @tearfur for all the work.
I decided to stop contributing and reviewing until @mikedld @ckerr or @livings124 would come with a sustainable maintainability plan (for instance, granting write access to Tearfur) or show a commitment to reach a really faster release pace (for instance, 4.0.6 in less than 1 week, 4.1.0 beta in less then 6 weeks). Certainly, the project can survive without any of those conditions fulfilled, but there is no joy to attempt to contribute to /dev/null. I do recognize some of the devs here have more talent than I do (my mastery of C++ hasn't reached perfection yet, and I wouldn't try building a TeamCity CI), but missing admins aren't preserving the integrity of a project, it just makes it a dead shell.

I do get that a personal life event can disrupt calendars, but that's why you're 3 admins? Or that's why renewing the team should be considered when the development cycle reaches a stall. Thank you.

[Pentaphon]

@ckerr thank you for your work in getting these PRs merged. I hope @Coeur is satisfied as I'd hate for the project to lose any existing contributors. Thoughts on changes proposed by Coeur, like write access to Tearfur or a faster release pace strategy? I think they are worth discussing. I'd really like the path to be cleared for 4.1.0 to get released this year, especially in terms of BEP compliance and features long overdue like IPV6 and saving queue order between session support.

[ckerr]

I agree that something need to happen to make contributions land more smoothly & releases happen more often, but it's not clear to me that there's an obvious easy fix.

It's complicated. Write permissions would be one thing, but it looks like on GitHub this would also give release permissions, which is something that more than one maintainer's got concerns about. (To be clear: not concerns about @tearfur; just concerns about giving out release permissions to anyone.)

Of the three people with write access, I'm probably the one with the most availability to the project. So when I get really busy with my day job, as I have been recently, it shows here. I may not have time for much coding right now, but I'll try at least to make time for PR review and discussion. And BTW I really appreciate @Coeur's effort in doing prep work on the PR train 😸

[Pentaphon]

It's complicated. Write permissions would be one thing, but it looks like on GitHub this would also give release permissions, which is something that more than one maintainer's got concerns about.

Ah, that sucks. Github should have something more granular to allow write access but not release permissions to give enthusiastic contributors like Tearfur more to do. I understand the apprehension.

[tearfur]

Given the recent the recent XZ backdoor incident, it's very understandable that you are wary of adding new maintainers. Still, the only way to better the situation is to have more people with write access.

Is there ways someone can gain existing's maintainers's trust? How about conducting interviews or background checks on willing individuals?

[robd003]

I'd vote for tearful getting write access. I see no threat and wouldn't worry about him having release privileges.

[mikedld]

@robd003,

I'd vote for tearful getting write access. I see no threat and wouldn't worry about him having release privileges.

Do you know him well and personally IRL? That's the only way it could've been that easy for me as it seems to be for you.

@tearfur,

... Still, the only way to better the situation is to have more people with write access.

Is there ways someone can gain existing's maintainers's trust? How about conducting interviews or background checks on willing individuals?

Are you requesting write access right now? I think that's the closest that I could remember you coming to that (could be wrong), and even now it's not at all clearly expressed. Still, there's a handful of people who do that on your behalf. This all looks a bit suspicious, hopefully you agree, even if there's in fact no collusion of any sort.

---

There're options (at least one or two) we want to explore when it comes to release rights, and it might be we'll find a way to restrict that while still giving people write access, so not all hope is lost ;)

[Pentaphon]

This all looks a bit suspicious, hopefully you agree, even if there's in fact no collusion of any sort.

I don't think anybody here is doing anything nefarious and I don't think anybody here knows Tearfur in person. I think Tearfur is being recommended for write access simply because he is an enthusiastic and active new contributor and people who follow the project want to see people like that be able to push the project forward when other members do not have the time to do so. I'm sure we'd all like to see Transmission have as many regular contributors as other projects like qBittorrent so anybody as promising as Tearfur has been so far will instantly be thought by the public as somebody who should have write access, even if they have no authority over the project itself. I wouldn't read much into this public opinion other than use it as feedback for any decisions you and the other 2 people in charge make in the future.

[mikedld]

Until @tearfur (or anyone else really) explicitly and directly requests the access, any such discussions are pointless, more or less. No matter how much you nominate someone, if they don't want it then I see no point in talking about it. You're basically supporting a candidate who's not even running, isn't that weird?

[Pentaphon]

Until @tearfur (or anyone else really) explicitly and directly requests the access, any such discussions are pointless, more or less. No matter how much you nominate someone, if they don't want it then I see no point in talking about it. You're basically supporting a candidate who's not even running, isn't that weird?

That's what I'm trying to explain. There's no concerted effort or anything other than just wishful thinking on the part of the public. There's lot of cases where the public will propose new leadership without any formal process and I think that is typically done when there is unease about the future of a project, which I do see in this thread.

I do think one way to start moving things forward is by finally having some kind of contributor chat room (or whatever communication platform you prefer) so that people who actually contribute code to this project can talk privately to coordinate releases and build trust rather than having to open project management issues like this one.

[robd003]

@mikedld I'm suggesting granting motivated contributors the ability to move the project forward after they've proved themselves as valuable contributors.

As long as granting good contributors write access doesn't jeopardize the project by letting them remove all existing users with write access I don't see a problem. I assume you can just as easily revoke write permissions if code quality suffers, but both @Coeur and @tearfur are talented programmers who are just trying to improve Transmission.

If the current admins are too busy with life or work it just makes sense to bring more people on board to help share the load. Nobody wishes ill on the project, we just want to see bugs get resolved and new features released at a faster pace.

[tearfur]

@mikedld:

Are you requesting write access right now? I think that's the closest that I could remember you coming to that (could be wrong), and even now it's not at all clearly expressed.

OK, let me make it clear now. I hereby request write access to the Transmission repository, and hopefully the forks of Transmission's dependencies as well.

If you want to set some rules, I'll be glad to discuss with the current mainteiners about it.

Still, there's a handful of people who do that on your behalf. This all looks a bit suspicious, hopefully you agree, even if there's in fact no collusion of any sort.

To my best knowledge, I am not part of any campaign striving to get myself granted write access to Transmission's repositories, or any other sort of elevated acesss.

[Pentaphon]

Glad you guys got 4.0.6 out in a short timeframe after this thread.

I'd like to know though, what about this decide-after-4.0.0 milestone? https://github.com/transmission/transmission/milestone/10

Perhaps its time to put those on a 4.1.0 or 5.0.0 beta milestone?

I assume 4.1.0 is coming up next?

[Coeur]

Until @tearfur (or anyone else really) explicitly and directly requests the access, any such discussions are pointless, more or less.

I believe I made an explicit request by email to you @mikedld and Charles on the 23rd of March 2024. Including some engagements like "only merge to the main branch (not released branches)".

Thank you @ckerr for the recent updates.

[Pentaphon]

Since this issue is still up, what does everybody here think of stickying certain issues to the top of the issues page? I think it will help some longstanding bugs get more eyes on them instead of having them languish under nearly 600 other issues.

[Coeur]

Most of the PRs listed were merged, and 4.0.6 was released. The scope of this issue has been done, so I'll close it.
If needed, I'll create a new updated list for the 4.1.0 beta Milestone.
Regarding write accesses, I'll leave the admins to communicate about this one way or another, or we can open a dedicated issue/discussion.

[Pentaphon]

If needed, I'll create a new updated list for the 4.1.0 beta Milestone.

Please do. Thanks for keeping the project organized and your work overall, Coeur.

[bbsixzz]

#6844

Was this regression fixed in 4.0.6? It says it needs cube review here. I'm just a lowly sonarr user waiting to upgrade from Transmission 3.0

[Coeur]

#6844

Was this regression fixed in 4.0.6?

Charles wrote it was done in bb19ef7.

[Pentaphon]

Was this regression fixed in 4.0.6?

Seems to have been merged but is not in the 4.0.6 changelog...