{"action":"created","issue":{"url":"https://api.github.com/repos/qbittorrent/qBittorrent/issues/6210","repository_url":"https://api.github.com/repos/qbittorrent/qBittorrent","labels_url":"https://api.github.com/repos/qbittorrent/qBittorrent/issues/6210/labels{/name}","comments_url":"https://api.github.com/repos/qbittorrent/qBittorrent/issues/6210/comments","events_url":"https://api.github.com/repos/qbittorrent/qBittorrent/issues/6210/events","html_url":"https://github.com/qbittorrent/qBittorrent/issues/6210","id":199383697,"number":6210,"title":"Development process improvements (A New Year Wish)","user":{"login":"evsh","id":394621,"avatar_url":"https://avatars3.githubusercontent.com/u/394621?v=3","gravatar_id":"","url":"https://api.github.com/users/evsh","html_url":"https://github.com/evsh","followers_url":"https://api.github.com/users/evsh/followers","following_url":"https://api.github.com/users/evsh/following{/other_user}","gists_url":"https://api.github.com/users/evsh/gists{/gist_id}","starred_url":"https://api.github.com/users/evsh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/evsh/subscriptions","organizations_url":"https://api.github.com/users/evsh/orgs","repos_url":"https://api.github.com/users/evsh/repos","events_url":"https://api.github.com/users/evsh/events{/privacy}","received_events_url":"https://api.github.com/users/evsh/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":72,"created_at":"2017-01-07T20:37:58Z","updated_at":"2017-05-04T23:55:36Z","closed_at":null,"body":"Hi @qbittorrent/qbittorrent-frequent-contributors,\r\n\r\nThere is one thing which I don't like in qBittorrent, only the single one: qBittorrent development is slow, and not only because the team is small. Our users expect from us more than we are able to deliver right now (just look how fast the number of open issues grows). And the contributors can obviously benefit from quicker advance too. I myself  find it easier to merge qBittorrent master into my own modified codebase then to merge my PRs into the qBt master branch. \r\n\r\nCan we speed it up a bit, without breaking anything? I think we can. Here is what I propose (some items were already mentioned here or there):\r\n\r\n1. Create a policy or a strategy for future development. In a minimal case list what can't be merged into the project and what can. For instance, simple things like \"no 3rd-party libraries except those used right now (explicit list follows)\",  \"no C++14\", \"no environment-specific code\", \"don't merge until there are open questions\", etc. Publish it and keep it up to date. This will help contributors and will be needed for the next item.\r\n2. Create an unstable development branch. Allow team members to merge PRs there after an approved review and absence of the policy violations (and GitHub can enforce the first condition). Cherry-pick or make pull request to transfer changes into the master branch. Merge master into development on a regular basis. \r\n3. Create a bugfixes-only (or LTS) branch. Drop Qt 4 support from master already and leave it in the bugfixes branch. Cherry-pick fixes there and build Ubuntu 14.04 packages from that branch. People who use 14.04 do not need fresh software, they manifested it clearly by using that distro version. Merge bugfixing PR into that branch to continue releasing versions 3.3.x with Qt 4 for Trusty.\r\n4. Keep dev branch (maybe master too)  compatible with libtorrent master branch, but not with released versions. This will give us a way to avoid or solve situations like the current one with libtorrent 1.1 because problems then can be found by the developers earlier than users encounter them.\r\n5. Protect master and bugfix branches and give those team members who want write permissions to manage issues (at least close old and those that are resolved already in one way or another). \r\n6. Perhaps we can create some special branches with dedicated maintainers. For example, I would be happy to maintain a branch with Plasma-specific modifications (and anything else given it is for Linux or OS-agnostic). Maybe there are other modifications in private repos, and their authors would be happy to push it closer to upstream.\r\n\r\nTo conclude, these modifications, I believe,  should make development process more dynamic and easier for maintainer(s). It is not hard to see that the project is already close to the limits of a single manpower and something has to be done to overcome this limit if we want to serve increasing demand from users and our expectations."},"comment":{"url":"https://api.github.com/repos/qbittorrent/qBittorrent/issues/comments/299340472","html_url":"https://github.com/qbittorrent/qBittorrent/issues/6210#issuecomment-299340472","issue_url":"https://api.github.com/repos/qbittorrent/qBittorrent/issues/6210","id":299340472,"user":{"login":"sledgehammer999","id":273315,"avatar_url":"https://avatars3.githubusercontent.com/u/273315?v=3","gravatar_id":"","url":"https://api.github.com/users/sledgehammer999","html_url":"https://github.com/sledgehammer999","followers_url":"https://api.github.com/users/sledgehammer999/followers","following_url":"https://api.github.com/users/sledgehammer999/following{/other_user}","gists_url":"https://api.github.com/users/sledgehammer999/gists{/gist_id}","starred_url":"https://api.github.com/users/sledgehammer999/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sledgehammer999/subscriptions","organizations_url":"https://api.github.com/users/sledgehammer999/orgs","repos_url":"https://api.github.com/users/sledgehammer999/repos","events_url":"https://api.github.com/users/sledgehammer999/events{/privacy}","received_events_url":"https://api.github.com/users/sledgehammer999/received_events","type":"User","site_admin":false},"created_at":"2017-05-04T23:55:36Z","updated_at":"2017-05-04T23:55:36Z","body":"FYI, I have enable the setting to require approvals again after new pushes to the a PR a few days ago.\r\nI haven't changed the team name because there is an autogenerated team from github that is contains the admins of the project. It is a \"legacy\" team, it lets me delete it, but first I wanted to make sure I don't break something in the admin rights. When I find time I'll do it."}}
{"actor":{"display_login":"sledgehammer999"}}