Development process improvements (A New Year Wish) #6210

evsh opened this Issue Jan 7, 2017 · 15 comments


None yet

6 participants

evsh commented Jan 7, 2017 edited

Hi @qbittorrent/qbittorrent-frequent-contributors,

There 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.

Can 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):

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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.

To 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.


I can promise one thing. A serious problem is the ballooning of issues. Some are stale, some aren't really issues, some need reviewing, some tagging etc.

Tomorrow(or the day after), I'll give write permissions to some members in order to be able to close/open/tag issues. Some rules will apply on what can be closed or not.

PS: Write permission is required for managing issues. If you start messing with commits(pushing/rebasing/merging PRs) you will be clobbered to death with a 56k modem.
PS2: I'll try to find a way to make the other workflow a bit more streamlined.

evsh commented Jan 8, 2017

@sledgehammer999 take a look at branch protection provided by GitHub (i.e. you can leave commit rights for master to yourself only).


@evsh link?

Hrxn commented Jan 8, 2017

Another suggestion:
Enforce issue tracker discipline.


Enforce issue tracker discipline.

What is that?

Hrxn commented Jan 9, 2017 edited

Well, if you use the Submit new issue function on GitHub, you only see one unspectacular link to CONTRIBUTING.MD, which, apparently, no one bothers to read (slight exaggeration, but you know what I mean). Maybe because folks (mistakenly) believe that this is only intended for code contributions.

Until GitHub comes up with a more effective idea, one can use in the repo (or alternatively .github/ to display some important information in the new issue description text area. Useful for reminding new issue submitters of some necessary steps to reproduce in the description, for example, or to provide all required information before opening a new issue.

Failure to fulfill all mentioned requirements results in an immediate closing of the issue, and labeling it as "invalid" or something. And if necessary, locking the issue to prevent new comments.

okeatime commented Jan 9, 2017

one can use in the repo (or alternatively .github/ to display some important information in the new issue description text area.

We should mimic something like these:

sledgehammer999 commented Jan 10, 2017 edited

I added @evsh @ngosang and @GotDemBallsOfSteel in the new @qbittorrent/bug-handlers team. This team has write permissions. I (think) I have protected master + all v*_*_x branches from you.

Instructions for people involved with the code that know the internals of qbt pretty well:

  1. You can freely close bugs that are truly irrelevant/obsolete by current code
  2. Close bugs that have a description and you cannot reproduce AND are old. Take care to not close bugs that are affecting people but you yourself cannot reproduce due to something related to your setup. For example, if users are reporting network or performance issues it isn't nice to say "can't reproduce in mine so I'll close this". I hope I haven't confused you.
  3. Of course, try to triage the bugs before closing. Unless the bug is clearly fixed/obsoleted.
  4. Try not to tag me for attention unless absolutely necessary. I have too many emails from github notifications already.
  5. Tag bugs. Create new tags if necessary.

For non-developers:

  1. Read what I wrote above.
  2. Close bugs that you are sure are irrelevant/obsolete/fixed. Since you aren't a developer and you don't know qbt internals take extreme care before closing bugs that are a bit more involved.

PS: @GotDemBallsOfSteel is our forum overlord(and current site hoster), for anyone wondering.
PS2: If anyone else wants to be bug handler, leave a message. But if you don't have a previous presence here or aren't a dev I'll probably won't accept you. Also I'll try to not give to too many people bug rights, because it will create managing problems probably.


I forgot to mention that since something is very old doesn't mean it should be closed automatically.
Also the rules I outlined above aren't restrictive. I just give a general idea on how to behave on the bug tracker. You can do more things if you like, but try to not be overly strict.

evsh commented Jan 11, 2017

@sledgehammer999, thanks, I will try to be useful with issues management, of course. Did you have chance to think about the other 5 items?

ngosang commented Jan 11, 2017

Thank you!!!


About number 3:
Now that I merged the new icons, the next release will be 3.4.0.
I think 3.3.10 is very stable. So I'll stop packaging for Trusty. (vidid and wily seemed dropped from the repos too). So now, we can drop Qt4. AFAIK Windows + macOS qt5 is very stable.

For the other issues, I'll respond another time. I need time to think them.

evsh commented Jan 11, 2017


Seeker2 commented Jan 15, 2017

Is there a consolidated list of known problems in qBitTorrent v3.3.10 (or v3.3.7-9)?
If not, maybe we should start one like there is for qBitTorrent with libtorrent v1.1.x at: #6132

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment