-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggested order of merging ready-to-merge PRs + Transmission 4.0.6 release #6813
Comments
@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! |
I normally don't nag much, because more than enough people are doing it, but... @transmission/core-devs Any word for a new 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. |
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 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 |
Thank you @tearfur for all the work. 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. |
@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. |
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 😸 |
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. |
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? |
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.
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 ;) |
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. |
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. |
@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. |
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.
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. |
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? |
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. |
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. |
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. |
Please do. Thanks for keeping the project organized and your work overall, Coeur. |
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 |
Seems to have been merged but is not in the 4.0.6 changelog... |
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)
4.0.x (production fixes that could be addressed and released without delay)
Kindly come to a quick agreement for the last two, and then:
pipelines testing and warnings (benefits all the other pull requests)
docs and safe changes
fixes
fixes pending review
Only a subset of them, but which I believe are mature enough for merging, pending a little approval?
have
key and other cleanup #6747 - @ckerr ?features (oldest ready-to-merge PR first)
features pending review
Only a subset of them, but which I believe are mature enough for merging, pending a little approval?
refactor (best done last, to avoid potential conflicts with higher importance ready-to-merge pull requests)
tr_variant
API intransmission-remote
and other cleanup #6798 (not reviewed yet)The text was updated successfully, but these errors were encountered: