@ sledgehammer999 vous devriez lire ceci => https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions/5

Heureusement, je n'ai pas le virus (et j'espère que je le resterai).

Je suis content pour toi personnellement.

Mais je suis vraiment triste de l'état actuel du projet (et je ne suis pas le seul à ressentir la même chose). Le moment du changement est critique. Vous devez donc soit restructurer la gestion/maintenance du projet, soit déclarer explicitement qu'il ne s'agit que de votre jouet personnel, afin que personne d'autre n'ait de faux espoirs.

Y a-t-il des commits qui doivent être exemptés ?

Je ne pense pas qu'il soit logique d'ignorer les modifications maintenant.

En tout cas, une nouvelle version se fait attendre depuis longtemps.

Trop.

Dois-je, comme d'habitude, rétroporter tous les nouveaux commits principaux dans la branche v4_2_x ?

Pourquoi v4.2.x ? Il y a plus qu'assez de changements pour la v4.3 !
En outre, vous pouvez simplement créer une branche v4_3_x au-dessus du maître actuel, au lieu de faire ce travail inutile en « sélectionnant » les commits un par un.

Je viens de finir de regarder les commits de la version précédente jusqu'au dernier master. (commettez les titres et les descriptions de relations publiques principalement)

Pourquoi v4.2.x ? Il y a plus qu'assez de changements pour la v4.3 !

Ouais. Il y a une tonne de commits. Et depuis que libtorrent 1.1.x a été abandonné, cela justifie sûrement la v4.3.x. (Et v4.4.x pour libtorrent 2.0.x et c++17 !!!)
Je vais créer un nouveau PR pour le changelog à venir, dès que possible.

À propos de la gestion de projet : nous en discuterons après le week-end / la prochaine version.

@ sledgehammer999

Content que tu sois de retour et que tout aille bien.

Dois-je, comme d'habitude, rétroporter tous les nouveaux commits principaux dans la branche v4_2_x ? Y a-t-il des commits qui doivent être exemptés ?

Je suis indifférent à la proposition d'étiqueter la nouvelle version 4.3.x. C'est à vous et aux autres de décider.

Tous les commits sont bons AFAIK. Cependant, de nombreux correctifs très importants ont également été fusionnés avec libtorrent, il est donc important d'utiliser le dernier RC_1_2 possible pour cette nouvelle version.

Il y a déjà eu quelques commits concernant la prise en charge de BitTorrent V2. Cependant, je m'attendrais à ce que cette version soit construite avec le dernier libtorrent RC_1_2 comme mentionné ci-dessus, donc la plupart des utilisateurs n'en verront rien dans la pratique. Ainsi, je mettrais une note dans le journal des modifications expliquant cela, afin que les utilisateurs n'aient pas de faux espoirs lorsqu'ils lisent les entrées liées à BitTorrent V2.

J'ai mis à jour ma chaîne d'outils locale. Le rétroportage/le journal des modifications/les tests minimaux prendront un certain temps. Mais je pense que ce week-end est un objectif réalisable en fonction de l'ampleur des changements.

Pouvez-vous s'il vous plaît fournir des détails à ce sujet? Je suppose que vous avez le tout dernier MSVC 2019 et j'espère que vous utilisez vcpkg ou similaire pour les dépendances - moins de risques de bogues étranges dus à de légères différences dans la façon dont tout est construit et plus de reproductibilité. Vous pouvez consulter le nouveau GitHub Actions CI pour vous inspirer. N'oubliez pas également d'utiliser CMake pour la construction cette fois-ci, il est devenu le nouveau système de construction par défaut.

À propos de la gestion de projet : nous en discuterons après le week-end / la prochaine version.

OK, mais le plus tôt possible s'il vous plaît. Et nous devons poursuivre la discussion sur l'automatisation du processus de publication, afin que même l'emballage puisse être fait automatiquement.

@ sledgehammer999

Veuillez également nettoyer le PPA dans le processus. Les versions d'Ubuntu autres que 18.04 , 20.04 et 20.10 sont EOL, donc les archives des versions ciblant ces versions doivent être supprimées dès que possible.

il est donc important d'utiliser le dernier RC_1_2 possible pour cette nouvelle version.

Cela va sans dire.
Qt 15.1, openssl 1.1.1h, boost 1.74

RC_2_0 ne sera pas encore utilisé. Pas sans quelques versions bêta officielles.

Je suppose que vous avez le tout dernier MSVC 2019 et j'espère que vous utilisez vcpkg

Non, je reste toujours avec msvc2017 pour cette version. La dernière fois que j'ai vérifié msvc2019, il a produit un très gros fichier .pdb pour qbt. Je revérifierai plus tard mais pas pour cette version.
Le reste des dépendances est construit comme j'ai toujours fait les choses. Plus ou moins décrit ici : https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (static-linkage)

N'oubliez pas également d'utiliser CMake pour la construction cette fois-ci, il est devenu le nouveau système de construction par défaut .

Apparemment, j'ai raté cela dans le journal git. Je suis un peu déçu mais je ne peux pas vraiment m'y opposer puisque tous les autres se sentent plus à l'aise avec l'utilisation de cmake que d'autotools/qmake.
Cependant, pour le moment, je continuerai à utiliser autotools/qmake pour la version. Je n'ai pas le temps de me familiariser avec cmake pour la sortie.

Je verrai quoi faire à propos du PPA, même s'ils ne font de mal à personne.

@ sledgehammer999 Je sais que vous ne voulez pas que les utilisateurs normaux commentent ici, alors excusez-moi ...... J'ai créé des versions de Windows ici dans le but d'éliminer les problèmes / bogues, etc.

Je compile avec MSVC 2019 & les exécutables qBittorrent font généralement environ 27 Mo & .pdb font 180 Mo

Avez-vous pensé à utiliser /pdbstripped ?

Je compile avec MSVC 2019 & les exécutables qBittorrent font généralement environ 27 Mo & .pdb font 180 Mo

Comparez avec msvc2017 et le maître actuel : 24,4 Mo d'exe et 98,1 Mo de pdb. Comme je l'ai dit, le pdb est très gros par rapport à msvc2017.

De plus, je ne pense pas que nous voulions /pdbstripped. Cela donnera probablement des backtraces moins utiles lorsque le programme plantera.

De plus, je ne pense pas que nous voulions /pdbstripped. Cela donnera probablement des backtraces moins utiles lorsque le programme plantera.

/PDBCompress ?

@ sledgehammer999

Les builds CI automatisés, qui utilisent CMake + le dernier MSVC 2019 + vcpkg (https://github.com/qbittorrent/qBittorrent/actions) sont à 57 MiB (exécutable) + 122 MiB (pdb).

Non, je reste toujours avec msvc2017 pour cette version. La dernière fois que j'ai vérifié msvc2019, il a produit un très gros fichier .pdb pour qbt. Je revérifierai plus tard mais pas pour cette version.

Ce n'est pas une bonne raison OMI. MSVC 2019 contient de nombreux correctifs. C'est (la fin de) 2020. Personne ne se soucie d'une taille d'installation supplémentaire de \ ~ 50 MiB (et s'ils le font, tant pis lol). Nous pouvons le découvrir plus tard si quelque chose gonfle le pdb/exécutable, mais pour l'instant tout fonctionne et un \~50 MiB supplémentaire est un compromis que je ferais n'importe quel jour de la semaine pour une chaîne d'outils beaucoup plus récente.

De plus, je ne pense pas que nous voulions /pdbstripped. Cela donnera probablement des backtraces moins utiles lorsque le programme plantera.

:+1:, mais cela peut être correctement étudié à l'avenir.

Le reste des dépendances est construit comme j'ai toujours fait les choses. Plus ou moins décrit ici : https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (static-linkage)

Apparemment, j'ai raté cela dans le journal git. Je suis un peu déçu mais je ne peux pas vraiment m'y opposer puisque tous les autres se sentent plus à l'aise avec l'utilisation de cmake que d'autotools/qmake.
Cependant, pour le moment, je continuerai à utiliser autotools/qmake pour la version. Je n'ai pas le temps de me familiariser avec cmake pour la sortie.

:-1:, ce n'est pas ainsi que la plupart des gens ont testé qBittorrent ces derniers mois sur Windows. De nombreuses personnes utilisaient des builds de ma branche CI (CMake + vcpkg), et maintenant la propre section Actions du dépôt. Je dirais qu'il est fort probable que nous observions des régressions inexpliquées résultant simplement des différences dans le processus de construction si vous faites cela.

@ sledgehammer999 Je ne veux plus ajouter de "bloquants" avant la sortie, mais au moins j'attendrais que cela atterrisse, car il est pratiquement prêt : https://github.com/qbittorrent/qBittorrent/pull/13499

La modification de la valeur par défaut pour les threads d'E/S asynchrones sera bénéfique pour de nombreux utilisateurs.

Je ne veux pas dissoudre msvc2019 mais je pense que vous êtes un peu exagéré en considérant que tout est nouveau comme meilleur. Ce n'est pas toujours le cas. Et oui, 50 Mo supplémentaires pour un client bt, c'est un gros problème. C'est un ballonnement inutile sans aucun avantage mesurable (par exemple, le programme ne devient pas 1,5 fois plus rapide).

Enfin à propos des systèmes de construction : si nous voyons des régressions uniquement à partir du changement de système de construction, il y a quelque chose qui ne va vraiment pas avec le code. Les choses ne devraient pas être si fragiles.

13499 est hors de portée car il s'agit d'une option libtorrent 2.0.x qui n'est pas encore la valeur par défaut. Enfin la coupe se fera dans le week-end.

@ sledgehammer999

Je ne veux pas dissoudre msvc2019 mais je pense que vous êtes un peu exagéré en considérant que tout est nouveau comme meilleur. Ce n'est pas toujours le cas.
Et oui, 50 Mo supplémentaires pour un client bt, c'est un gros problème. C'est un ballonnement inutile sans aucun avantage mesurable (par exemple, le programme ne devient pas 1,5 fois plus rapide).

S'il vous plaît, ne rejetez pas simplement mes arguments comme "nouveau = meilleur". Et je pense que vous êtes un peu "exagéré" en vous en tenant à une chaîne d'outils pire pour 50 MiB. Bien sûr, vous ne voyez jamais (ou très rarement) une accélération "1,5x" de la mise à jour de votre chaîne d'outils. Mais c'est une barre irréaliste à fixer. Avec une chaîne d'outils plus récente, il se peut qu'il n'y ait pas d'accélération "1,5x", mais il y a toujours de petites améliorations de performances, un meilleur support de langage, une meilleure génération de code (conduisant parfois à moins de bogues), ... Il existe de nombreuses ressources en ligne documentant le améliorations dans MSVC 2019.

Encore une fois, je suis d'accord que nous devrions réduire ces 50 MiB supplémentaires si possible, mais ce que je veux dire, c'est que si nous ne pouvons pas le faire à temps pour la prochaine version (ou jamais !), _c'est OK_. De plus, rien n'implique que cela se reproduise à chaque version (je serais également ennuyé dans ce cas). Il s'agit très clairement d'un problème ponctuel. En tant qu'utilisateur, je ne voudrais pas entendre "voici votre binaire de pire qualité, mais au moins nous vous avons économisé 50 MiB, bro". 50 MiB est une erreur d'arrondi de nos jours (pour les programmes de bureau, de toute façon ; bien sûr dans le monde embarqué et ce n'est pas le cas). Je suis désolé, mais vous vous trompez si vous pensez le contraire.

Enfin à propos des systèmes de construction : si nous voyons des régressions uniquement à partir du changement de système de construction, il y a quelque chose qui ne va vraiment pas avec le code. Les choses ne devraient pas être si fragiles.

Pas nécessairement. Quelque chose peut être sérieusement mal avec le système de construction lui-même. Voir l'état précédent du système de construction de CMake, avant mon PR de révision. Avant cela, la construction avec CMake causait pas mal de bugs. Certains problèmes (parfois graves !) proviennent vraiment de systèmes de construction incorrects/mauvais et de recettes de construction. Quelle que soit la robustesse de votre code, si vous le construisez mal, il se cassera, parfois de manière très spectaculaire mais difficile à diagnostiquer.

13499 est hors de portée car il s'agit d'une option libtorrent 2.0.x qui n'est pas encore la valeur par défaut. Enfin la coupe se fera dans le week-end.

S'il vous plaît voir le reste de la discussion. Ce PR modifie également le nombre par défaut de threads d'E/S asynchrones, de sorte que par défaut, au moins 2 threads de hachage sont également utilisés lors de la construction avec libtorrent 1.2.x. Cela se traduit par une amélioration très significative des performances pour les utilisateurs de SSD (plus de 1,5x, en fait, heh) tout en offrant un gain très marginal pour les utilisateurs de HDD également.

@ sledgehammer999

Voici quelques conseils pour vous aider à démarrer :

• le nouveau tutoriel pour construire avec CMake de manière statique sur Windows : https://github.com/qbittorrent/qBittorrent/wiki/Compilation :-Windows-(MSVC-2019,-64-bit,-static-linkage)
• liste des options + court tutoriel/intro CMake : https://github.com/qbittorrent/qBittorrent/wiki/Compilation-with-CMake :-common-information

Si vous n'utilisez pas vcpkg, ou si vous utilisez vcpkg pour certains packages mais pas pour d'autres, il vous suffit de transmettre en plus les indications appropriées qui indiquent à CMake où trouver les fichiers de configuration pour les packages, comme -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar . En cas de doute, vous pouvez simplement exécuter la configuration jusqu'à ce qu'elle réussisse, en corrigeant chaque message d'erreur concernant chaque paquet un par un au fur et à mesure qu'ils apparaissent, car les messages d'erreur sont suffisamment utiles pour que vous puissiez toujours comprendre et comprendre ce que vous devez ajouter. suivant.

Je ne vais pas discuter davantage des compilateurs. Je ne suis pas d'accord avec vous spécifiquement pour qbt. msvc2019 deviendra beaucoup plus pertinent pour nous une fois que nous passerons à c++17. Enfin, pour un utilisateur de client bt, tout ce qui lui importe, c'est si le client peut atteindre une vitesse descendante/montante. C'est la métrique pour un binaire de qualité "meilleure" ou "pire". msvc2017 y parvient sans surcharge supplémentaire. --Je retiens mon jugement jusqu'à ce que je refasse mes constructions avec msvc2019--

comme -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar

La manière dont un paquet est construit/installé fait-elle une différence ? Actuellement, je n'ai pas de dossier cmake sous lib pour boost, libtorrent, openssl. Uniquement pour qt.
PS : boost et libtorrent sont construits avec b2. Openssl en utilisant leur script de configuration.

@ sledgehammer999

La seule exigence est que vous construisiez libtorrent avec CMake, IIRC. Tous les autres packages génèrent les fichiers de configuration requis par défaut ou sont pris en charge par CMake d'une manière ou d'une autre :

• libtorrent doit être construit avec CMake pour que les fichiers appropriés soient générés. Ceci est spécifiquement couvert dans le didacticiel Wiki.
• CMake prend nativement en charge OpenSSL via un module de recherche intégré : https://cmake.org/cmake/help/latest/module/FindOpenSSL.html#hints. Il vous suffit de définir OPENSSL_ROOT_DIR . Exemple : -DOPENSSL_ROOT_DIR=C:\Qt\Tools\OpenSSL\Win_x64
• boost génère les fichiers requis par défaut. Il vous suffit de définir Boost_DIR Exemple : -DBoost_DIR=C:\path\to\boost_1_73_0\stage\lib\cmake\Boost-1.73.0
• Pour zlib, vous devez passer quelques chemins. Exemple : -DZLIB_INCLUDE_DIR=C:\path\to\zlib-1.2.11\build -DZLIB_LIBRARY=C:\path\to\zlib-1.2.11\build\libzlibstatic.a
• Qt génère les fichiers requis, je suppose que vous avez déjà compris l'indicateur de temps de configuration requis pour pointer vers eux.

Encore une fois, s'il vous manque l'un de ces éléments, CMake vous en parlera lors de l'étape de configuration et vous suggérera exactement ce qu'il souhaite que vous ajoutiez.

Je suis d'accord avec sledgehammer999.
Un binaire plus petit est toujours meilleur. Surtout compte tenu des antécédents des versions précédentes.
Beaucoup ont encore un Internet lent. De plus, le site Web desservant les fichiers binaires peut être lent pour certains utilisateurs en fonction de leur emplacement.
Dans de tels cas, un petit binaire permet un téléchargement plus rapide. Les gens peuvent être découragés de mettre à jour s'ils soupçonnent un bloatware inutile.

il est devenu le nouveau système de construction par défaut.

système de construction par défaut de quoi ?

il est devenu le nouveau système de construction par défaut.

système de construction par défaut de quoi ?

il a même déclaré qmake/autotools obsolète https://github.com/qbittorrent/qBittorrent/wiki

il a même déclaré qmake/autotools obsolète https://github.com/qbittorrent/qBittorrent/wiki

Cet arbitraire commence à vraiment exaspérer !

il est devenu le nouveau système de construction par défaut.
système de construction par défaut de quoi ?

Cet arbitraire commence à vraiment exaspérer !

Oh wow! Ce n'est donc pas une vraie décision ! Je ne me sens pas dégoûté après tout.

@FranciscoPombal
S'il vous plaît, ne distrayez pas @ sledgehammer999 avec des conversations inutiles sur différents outils de construction, systèmes de construction, etc. Laissez la prochaine version se faire de manière habituelle - ce sera plus rapide et plus fiable. Nous avons besoin de temps pour résoudre les problèmes d'organisation afin de pouvoir maintenir le projet à flot, même si l'un de ses membres disparaît depuis longtemps.
Cela n'a également aucun sens de discuter de libtorrent-2.0 dans le contexte de la prochaine version (et de toute la branche à venir), car nous n'avons pas de support pour cela, et nous ne pouvons même pas prédire quand il sera entièrement implémenté.

C'est (la fin de) 2020. Personne ne se soucie d'une taille d'installation supplémentaire d'environ 50 MiB (et s'ils le font, tant pis lol).

Mes deux ordinateurs principaux ont 9 et 12 ans (même si je les ai récemment améliorés en installant des SSD comme disques système). Beaucoup utilisent du matériel encore plus ancien. Ce n'est pas parce qu'on aime ça. Nous n'avons tout simplement pas la capacité financière/autre de le mettre à jour tous les 2-3 ans. Si vous n'êtes pas capable de nous comprendre, cela ne vous donne pas pour autant le droit de vous moquer de nous.

PS Cependant, même il y a 10 ans, je ne me serais pas autant inquiété de ces 50 mégaoctets.

@an0n666 @sledgehammer999 @glassez

Je suis d'accord avec sledgehammer999.
Un binaire plus petit est toujours meilleur. Surtout compte tenu des antécédents des versions précédentes.
Beaucoup ont encore un Internet lent. De plus, le site Web desservant les fichiers binaires peut être lent pour certains utilisateurs en fonction de leur emplacement.
Dans de tels cas, un petit binaire permet un téléchargement plus rapide. Les gens peuvent être découragés de mettre à jour s'ils soupçonnent un bloatware inutile.

Allez maintenant, le téléchargement de l'application est un coût unique. Même à 10 Mb/s, 50 Mio supplémentaires ne représentent que 50 secondes supplémentaires. Si ces gens sont si gênés par ça, ils feraient mieux de venir ici et d'aider à résoudre le problème eux-mêmes. Ne vous laissez pas bousculer par des personnes obsessionnelles compulsives qui se plaignent de 50 MiB. Ils veulent revenir à uT 2.2.1 à cause de ça ? Amende. Même en Somalie, vous pouvez obtenir 10 Mb/s en moyenne : https://www.speedtest.net/global-index , et je doute qu'un client BitTorrent soit la principale préoccupation de la plupart des Somaliens de souche. Les versions sont servies à la fois par Fosshub et Sourceforge, qui ne deviendront probablement jamais le goulot d'étranglement à moins que Kim Kardashian ne dise à tous ses fans de télécharger qBittorrent ou quelque chose du genre.

Aussi,

Un binaire plus petit est toujours meilleur. Surtout compte tenu des antécédents des versions précédentes.

Citation requise. Où est la corrélation entre "meilleur bilan" et "taille binaire plus petite" ? Meilleur bilan de quoi ? Performance? Fiabilité?

système de construction par défaut de quoi ?

il a même déclaré qmake/autotools obsolète https://github.com/qbittorrent/qBittorrent/wiki

Cet arbitraire commence à vraiment exaspérer !

Oh wow! Ce n'est donc pas une vraie décision ! Je ne me sens pas dégoûté après tout.

Nous avons convenu que le système de construction CMake était l'avenir. C'est une erreur de continuer à maintenir deux systèmes de construction, comme je l'ai déjà dit à plusieurs reprises. Ceci est même mentionné dans des contributions récentes : https://github.com/qbittorrent/qBittorrent/pull/13509#issuecomment -708072078

En parlant de bloatware : regardez l'effort en double que nous avons en raison de la maintenance de 2 systèmes de construction. Regardez les différents fichiers d'autotools que nous avons dans le référentiel.

S'il vous plaît, ne distrayez pas @ sledgehammer999 avec des conversations inutiles sur différents outils de construction, systèmes de construction, etc. Laissez la prochaine version se faire de manière habituelle - ce sera plus rapide et plus fiable.

Encore une autre attaque contre probablement le membre le plus actif de ce référentiel au cours des derniers mois, et qui a apporté des contributions cruciales, notamment dans le domaine des systèmes de construction, des outils, etc. Les nouvelles versions et modifications du système de construction _sont_ plus fiables. Si je me souviens bien, il y a même eu des cas de problèmes qui ont disparu simplement en construisant avec la nouvelle méthode. Grâce à mes efforts, nous pouvons maintenant obtenir des versions plus fiables beaucoup plus rapidement entre les mains des utilisateurs. Ce n'est certainement PAS inutile. J'ai l'intention d'améliorer encore cela, jusqu'au moment de la sortie officielle, mais ne comptez pas sur moi si vous continuez à dénigrer ma participation comme ça.

Je ne le distrait pas, je le mets au courant des développements importants des derniers mois. C'est à lui de se rattraper.
Maintenant que le traîneau est de retour, je veux sortir la construction autant que n'importe qui, mais je veux le faire _correct_. Le retour de luge ne devrait pas signifier que nous devons revenir à nos anciennes habitudes (même si cette version ressemble à un compromis), cela devrait signifier que nous pouvons évoluer _plus vite_ pour atteindre l'endroit où nous voulons être.

Nous avons besoin de temps pour résoudre les problèmes d'organisation afin de pouvoir maintenir le projet à flot, même si l'un de ses membres disparaît depuis longtemps.

Une partie du problème consiste à compter sur une seule personne pour produire manuellement des builds avec un système de build vieillissant et moins maintenable, sauter à travers des cerceaux juste à cause de 50 MiB (qui peut être résolu plus tard), etc. Considérez le fait que nous nous écartons du la chaîne d'outils que nous utilisons dans notre CI juste pour cela. Même si ce n'est pas réellement un gros problème maintenant, c'est un mauvais principe et un précédent.

Cela n'a également aucun sens de discuter de libtorrent-2.0 dans le contexte de la prochaine version (et de toute la branche à venir), car nous n'avons pas de support pour cela, et nous ne pouvons même pas prédire quand il sera entièrement implémenté.

Nous n'avons pas du tout besoin de parler de libtorrent 2.0. Juste une petite note expliquant que le support de la V2 n'est toujours pas présent malgré le fait que certaines mentions du support de la V2 apparaîtront dans les messages de commit du changelog. Par exemple, 19d77b0881dc777b7930106869854067e5b2faba. (à moins bien sûr que vous ne sélectionniez pas ces commits pour la version 4.3.0, mais cela complique les choses à mon avis).

Mes deux ordinateurs principaux ont 9 et 12 ans (même si je les ai récemment améliorés en installant des SSD comme disques système). Beaucoup utilisent du matériel encore plus ancien. Ce n'est pas parce qu'on aime ça. Nous n'avons tout simplement pas la capacité financière/autre de le mettre à jour tous les 2-3 ans. Si vous n'êtes pas capable de nous comprendre, cela ne vous donne pas pour autant le droit de vous moquer de nous.

PS Cependant, même il y a 10 ans, je ne me serais pas autant inquiété de ces 50 mégaoctets.

Veuillez indiquer où je me suis "moqué" des utilisateurs à faible spécification. J'ai aussi un ordinateur portable C2D de 12 ans sur lequel j'ai installé un SSD (la connexion n'est que SATA II cependant !) que j'utilise encore fréquemment. Je ne possède pas non plus de machine avec un processeur fabriqué au cours des 3 dernières années, et j'aimerais pouvoir obtenir un AMD Ryzen à l'avenir. Je ne fais certainement pas de "mise à niveau tous les 2-3 ans". Je te comprends et suis d'accord avec toi. Je viens de me moquer des gens qui se plaignent de 50 MiB sur un ordinateur de bureau/portable de nos jours (lire : 15+ dernières années), parce que ces gens méritent qu'on se moque de eux.

Encore une autre attaque contre probablement le membre le plus actif de ce référentiel au cours des derniers mois

S'il vous plaît, arrêtez de chercher des sous-textes cachés dans mes commentaires. J'ai juste dit ce que j'ai dit. J'espère que votre réaction ne confondra personne.

Je ne le distrait pas, je le mets au courant des développements importants des derniers mois. C'est à lui de se rattraper.

Chaque chose a son heure et sa place.
Pourquoi appuyer sur @sledgehammer999 ici et maintenant, si cela ne peut que conduire au fait qu'il n'aura pas le temps ni de faire la prochaine version, ni de restructurer la gestion/maintenance du projet avant qu'il ne disparaisse à nouveau, afin que nous ne soyons pas en mesure de poursuivre un travail à part entière en son absence.

Nous n'avons pas du tout besoin de parler de libtorrent 2.0. Juste une petite note expliquant que le support de la V2 n'est toujours pas présent malgré le fait que certaines mentions du support de la V2 apparaîtront dans les messages de commit du changelog.

J'ai mentionné à plusieurs reprises que le journal des modifications ne devrait pas copier aveuglément l'historique de git. Vous devez garder à l'esprit que :

1. certains commits font partie d'un seul correctif/amélioration/fonctionnalité, il est donc logique de le mentionner dans son intégralité ;
2. certains commits corrigent des erreurs intermédiaires qui n'étaient pas présentes dans la version précédente, il est donc inutile de les mentionner ;
3. certains commits font partie d'un travail inachevé, il n'est donc pas logique de les mentionner.

@ sledgehammer999
Veuillez être informé du numéro 13519.

EDIT : fausse alarme : https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710744534
EDIT(FranciscoPombal) pas une fausse alerte : https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710911209

@ sledgehammer999 @ Chocobo1 @ glassez

Désolé pour le ping de masse, mais celui-ci semble également assez critique, et malheureusement un peu en désordre en ce moment (je suis également confus à ce stade quant à la nature réelle du problème): https://github.com/ qbittorrent/qBittorrent/issues/13389. Peut-être que l'un d'entre vous pourra nous éclairer d'un jour nouveau ?

Une chose est sûre; Je ne voudrais pas risquer de casser les configurations *arr de tout le monde avec la première version 4.3.x.

celui-ci semble également assez critique, et malheureusement un peu en désordre en ce moment (je suis également confus à ce stade quant à la nature réelle du problème): # 13389. Peut-être que l'un d'entre vous pourra nous éclairer d'un jour nouveau ?

Une chose est sûre; Je ne voudrais pas risquer de casser les configurations *arr de tout le monde avec la première version 4.3.x.

S'il vous plaît, ne commencez pas à paniquer à la toute fin. Quel est le problème? (En plus des problèmes de compréhension de la logique de l'application.) Nous n'avons pas modifié le code associé, n'est-ce pas ? Je n'ai certainement pas lu tout le fil. S'il existe des preuves évidentes d'un bogue dans l'application, veuillez m'indiquer un commentaire spécifique.

@glassez

S'il vous plaît, ne commencez pas à paniquer à la toute fin. Quel est le problème? (En plus des problèmes de compréhension de la logique de l'application.) Nous n'avons pas modifié le code associé, n'est-ce pas ? Je n'ai certainement pas lu tout le fil. S'il existe des preuves évidentes d'un bogue dans l'application, veuillez m'indiquer un commentaire spécifique.

Personne ne panique, nous devons juste être conscients des conséquences potentielles. Le but est que quelqu'un d'autre lise le fil attentivement et avec une tête claire. À l'époque où j'essayais de m'y attaquer, je ne pouvais pas être sûr s'il s'agissait d'une régression légitime ou d'une fausse représentation par l'utilisateur d'un changement récent, ou si le changement de formulation récent exposait un défaut inattendu ou quoi. Cela est aggravé par le fait que je n'ai jamais utilisé de logiciel *arr , mais je sais que beaucoup de gens le font. Quoi qu'il en soit, voici les rapports originaux dans les *arr : https://github.com/Radarr/Radarr/issues/5032 https://github.com/Sonarr/Sonarr/issues/3968 , si vous veux jeter un oeil.

Bonjour gars,

Je viens de remarquer que quelqu'un a mentionné FOSSHUB dans un commentaire précédent. J'ai lu le fil et je veux dire ceci. En supposant que qBittorrent aura environ 50 Mo, cela ne fait aucune différence pour nous. La même chose avec n'importe quel pic de trafic, quelqu'un a mentionné Kim Kardashian. S'il vous plaît, demandez-lui de recommander qBittorrent ; Je suis sûr que nous ne descendrons pas. Nous pouvons absorber ce trafic. Par exemple, chaque fois qu'un nouveau qBittorrent est publié, nous avons vu des milliers de demandes de mise à jour par seconde.

Ce que j'essaie de dire, c'est que vous ne devriez pas vous inquiéter à ce sujet.

Merci!

mon 1,5 cents, il se construit et fonctionne mieux sur msvc2019 pour une raison quelconque
50 Mo d'espace disque ne sont absolument rien en 2020, si votre système est CELA contraint, vous exécutez de toute façon un client plus léger ou qbt-cli

ne remettez jamais votre projet sur le dernier et le meilleur quand il peut être fait sans causer de bogues plus vous attendez plus vous risquez de prendre du retard et d'être bloqué sur un compilateur mort non pris en charge n'est jamais amusant pour personne

Je pense que sledge faisait référence à des problèmes comme ceux-ci ouverts même après une augmentation de seulement 12 MiB de la taille du programme d'installation.
https://github.com/qbittorrent/qBittorrent/issues/12247

Ce n'est donc même pas 50 MiB mais seulement 12 MiB que les gens vont jusqu'à créer un ticket de problème.

@ sledgehammer999 "SI" vous allez utiliser Qt 5.15.0/5.15.1 dans la prochaine version, prenez note de (le menu contextuel se ferme après avoir choisi une balise) # 13492

En termes simples, je pense que si ça va être étiqueté 4.3, personne ne va se plaindre du fait que l'installateur soit plus grand, on s'y attendrait sûrement ! Garder des chaînes d'outils obsolètes ressemble honnêtement à une représentation appropriée du processus de publication de qBittorrent.

Excité de voir enfin cela se produire, j'avais presque abandonné l'espoir de voir quelque chose cette année.

Je pense que sledge faisait référence à des problèmes comme ceux-ci ouverts même après une augmentation de seulement 12 MiB de la taille du programme d'installation.

12247

>

Ce n'est donc même pas 50 MiB mais seulement 12 MiB que les gens vont jusqu'à créer un ticket de problème.

Alors? La seule réponse appropriée pour de tels tickets est "peu importe, mec.". Je ne comprends pas l'obsession de se plier en quatre pour ces gens. Comme je l'ai dit dans https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708436739, nous ferons bien sûr toujours de notre mieux pour empêcher de telles augmentations de taille, mais nous ne devrions rien sacrifier d'autre juste pour 50 MiB, et si certaines personnes sont si gênées par cela, elles peuvent venir ici et réparer elles-mêmes.

nous ne devrions rien sacrifier d'autre

Je suis désolé, mais je ne vois vraiment pas ce que nous sacrifions en n'utilisant pas le dernier et le plus grand compilateur (doute). Il n'y a rien de tangible à passer au dernier compilateur. Ce n'est pas comme si msvc2017 était un ancien compilateur.

@ sledgehammer999

Je suis désolé, mais je ne vois vraiment pas ce que nous sacrifions en n'utilisant pas le dernier et le plus grand compilateur (doute). Il n'y a rien de tangible à passer au dernier compilateur. Ce n'est pas comme si msvc2017 était un ancien compilateur.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -711123971

mon 1,5 cents, il se construit et fonctionne mieux sur msvc2019 pour une raison quelconque

Comme mentionné précédemment, je me souviens d'autres récits de ce type dans le suivi des problèmes ou d'autres canaux de communication. Je ne l'invente pas.

Quoi qu'il en soit, il faut toujours essayer d'utiliser la dernière chaîne d'outils (dans des limites raisonnables, mais MSVC 2019 est mature à ce stade), à ​​moins qu'il n'y ait une très bonne raison de ne pas le faire. De plus, les versions de MSVC 2019 ont été largement testées au cours des derniers mois, soit par moi, xavier2k6 ou d'autres, soit maintenant, plus récemment, avec le flux de travail officiel GitHub Actions. 50 MiB n'est pas une bonne raison, comme beaucoup de gens essaient de vous le dire. Ne vous laissez pas intimider par ceux qui obsèdent plus de 50 MiB !! Je m'occuperai personnellement de ces rapports, vous n'aurez même pas à les voir.

La mise à niveau vers MSVC2019 prend-elle beaucoup de temps ? C'est juste un cas de quand pas si n'est-ce pas? Donc, si ce n'est pas cette version, alors sûrement la suivante, étant donné que les versions sont généralement à des mois d'intervalle.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -711123971 n'est qu'un seul rapport subjectif qui est très probablement affecté par l'utilisation des dernières bibliothèques et du code qbt. Pas à cause du compilateur.

La mise à niveau vers MSVC2019 prend-elle beaucoup de temps ? C'est juste un cas de quand pas si n'est-ce pas? Donc, si ce n'est pas cette version, alors sûrement la suivante, étant donné que les versions sont généralement à des mois d'intervalle.

la raison est donnée ici https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708055242

Ne vous laissez pas intimider par ceux qui obsèdent plus de 50 MiB !!

Je ne me laisserai pas non plus intimider par ceux qui sont obsédés par le "dernier et le plus grand". Et la différence est en fait de 68 Mo de stockage supplémentaire (j'ai fait des builds statiques locaux). msvc2017 fonctionne tout simplement ! et ne nécessite pas d'espace supplémentaire.

13505 (commentaire) n'est qu'un rapport subjectif qui est très probablement affecté par l'utilisation des dernières bibliothèques et du code qbt. Pas à cause du compilateur.

Et vos commentaires sur le fait que MSVC 2019 ne fournit aucun avantage sont également des affirmations non fondées.

Je ne me laisserai pas non plus intimider par ceux qui sont obsédés par le "dernier et le plus grand". Et la différence est en fait de 68 Mo de stockage supplémentaire (j'ai fait des builds statiques locaux). msvc2017 fonctionne tout simplement ! et ne nécessite pas d'espace supplémentaire.

Mauvaise rentrée. Personne ne défend la dernière chaîne d'outils ne vous "intimide". S'en tenir à la dernière chaîne d'outils (encore une fois, avec raison) est objectivement la meilleure politique, surtout lorsque le seul argument contre elle est qu'elle produit des binaires un peu plus volumineux (nous ne développons pas pour une plate-forme embarquée). De plus, ce n'est pas une bonne politique de faire une version avec une chaîne d'outils différente de celle que la plupart des utilisateurs et contributeurs utilisent depuis les _mois_ derniers. Et pour couronner le tout, il est probable qu'il existe une solution relativement simple au gonflement binaire - demandez à vos amis de 50 MiB d'investir leur énergie pour trouver le problème plutôt que de se plaindre de 50 MiB si cela les dérange tellement.

(msvc2017 => msvc2019) peut être discuté/argumenté/débattu, etc. dans un autre numéro _QUAND_ cela devient nécessaire

msvc2019 deviendra beaucoup plus pertinent pour nous une fois que nous passerons à c++17.

Cela deviendra également plus pertinent lors du passage à Qt 6.0/6.1/6.2 lorsque Qt nécessitera msvc2019 & drop (prise en charge de Windows 7/8/8.1 & 32 bits) (ce qui est encore loin d'être implémenté, je sais)

Hôtes et cibles de développement dans Qt 6.0

Hôtes de développement Qt 6.0

Objectifs de développement de Qt 6.0

Hôtes de développement Qt 6.1

Objectifs de développement de Qt 6.1

Je ne vais pas discuter davantage des compilateurs. Je ne suis pas d'accord avec vous spécifiquement pour qbt. msvc2019 deviendra beaucoup plus pertinent pour nous une fois que nous passerons à c++17.

référence : https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708094578

POUR L'INSTANT ! POUVONS-NOUS TOUS GARER ICI POUR UNE AUTRE FOIS ?

Sortons 4.2.x/4.3.x !

(msvc2017 =>msvc2019) peut être discuté/argumenté/débattu, etc. dans un autre numéro QUAND cela devient nécessaire

POUR L'INSTANT ! POUVONS-NOUS TOUS GARER ICI POUR UNE AUTRE FOIS ?

Sortons 4.2.x/4.3.x !

Écoutez, je veux que cela se termine autant que n'importe qui d'autre, mais si rien d'autre, il est franchement irresponsable de changer la chaîne d'outils à la dernière minute pour la version alors que tout le monde, y compris vous, a utilisé et testé avec MSVC 2019 pour le _mois_ derniers. Vu de cet objectif, je pense qu'il est tout à fait "nécessaire" d'utiliser MSVC 2019 pour cette version.

Personnellement, j'ai beaucoup de peau dans ce jeu : si quelque chose ne va pas, ce sera moi qui traiterai la majorité des rapports de bugs de type "la version nocturne/CI a bien fonctionné mais la version ne fonctionne pas" etc etc. Et oui, je sais que je n'ai pas "" à m'en occuper. Mais je ne veux pas que le projet soit submergé de nouveaux problèmes après une publication pour une raison qui peut être évitée. Il est déjà assez grave que la publication ne se fasse pas avec des bibliothèques compilées de la même manière ou de manière similaire à la CI.

Cela me déconcerte de voir que tout cela, y compris le temps et les efforts que j'ai consacrés au projet et la gestion du suivi des problèmes, n'est pas plus important que quelqu'un qui est obsédé par plus de 50 MiB. Qui sont ces gens, même ? Qu'ont-ils fait pour le projet ?

@FranciscoPombal Je n'aurai plus de discussion sur le compilateur ici. Ma parole est définitive. Les versions seront faites avec msvc2017.

si je me souviens bien, seul Qt 5.15 prend "officiellement" en charge msvc2019. ils n'ont pas commencé à fonctionner ci sur msvc2019 jusqu'à Qt 5.15
et il ne peut pas publier avec qt 5.15 de toute façon à cause des bogues mentionnés précédemment.

Écoutez, je veux que cela se termine autant que n'importe qui d'autre, mais si rien d'autre, il est franchement irresponsable de changer la chaîne d'outils à la dernière minute pour la version alors que tout le monde, y compris vous, a utilisé et testé avec MSVC 2019 pour le derniers mois. Vu de cet objectif, je pense qu'il est tout à fait "nécessaire" d'utiliser MSVC 2019 pour cette version.

Les versions de MSVC 2017 sont testées au combat avec tout le cycle de publication 4.2.x et il n'y a pas grand-chose de nouveau dans msvc 2019 de toute façon et msvc 2017 a toujours un cycle de publication grand public, je ne comprends pas pourquoi vous êtes si obsédé par "le plus récent et le plus grand" .

@xavier2k6

De plus, supposons que nous ne résolvions pas le "problème" supplémentaire de 50 MiB avant la prochaine "grosse" version. Allons-nous tous avoir cette même discussion alors? Allons-nous repousser la mise à jour vers Qt 6 à cause de cela ? Qu'est-ce qui est/n'est pas plus important que 50 Mio ? Nous ne faisons que balayer le problème sous le tapis, c'est un mauvais précédent.

Indice, je peux presque garantir que, d'après les opinions que j'ai vues des autres au fil du temps, la mise à niveau vers Qt6 sera reportée beaucoup plus longtemps que raisonnable, pour toutes ces 3 raisons, et peut-être plus, sans ordre particulier : extra Taille du programme d'installation de 50 Mio, maintien de la prise en charge de Windows 7, maintien de la prise en charge des versions 32 bits.

@jagannatharjun Qt 5.15.1 se construit bien avec msvc2017. Les seuls problèmes liés concernent la fermeture du menu contextuel lors de la sélection des balises. OMI, ce n'est pas un bloqueur. Qt 5.15 apporte cependant un bien meilleur support HiDPI.

@FranciscoPombal Je peux comprendre d'où vous venez et votre travail ici est très apprécié !

Les points que vous soulevez sont pertinents, mais malheureusement, je ne pense pas que le délai actuel pour la sortie de la "nouvelle version" permette cette discussion... (pour le moment)

Je ne comprends pas pourquoi tu es si obsédé par "le plus récent et le meilleur".

Les politiques objectivement supérieures ne sont pas des "obsessions". Je suppose que vous pourriez dire que je suis obsédé par le fait de ne pas répondre à d'autres obsessions stupides. Mais rends-moi service et arrête de projeter ça sur moi, oui ? Cela ne renforce pas votre propos.

Vous envisagez sérieusement de maintenir un rythme raisonnable de mises à niveau/modernisation comme une "obsession" et de ne pas être plus important que 50 MiB dans le programme d'installation. putain de Jésus.

@jagannatharjun Qt 5.15.1 se construit bien avec msvc2017. Les seuls problèmes liés concernent la fermeture du menu contextuel lors de la sélection des balises. OMI, ce n'est pas un bloqueur. Qt 5.15 apporte cependant un bien meilleur support HiDPI.

Je suis d'accord, le bogue des balises du menu contextuel est malheureux, mais les bogues HiDPI sont beaucoup plus graves et produisent beaucoup plus de rapports au fil du temps.

@FranciscoPombal Je peux comprendre d'où vous venez et votre travail ici est très apprécié !

Bonne blague.

Les points que vous soulevez sont pertinents, mais malheureusement, je ne pense pas que le délai actuel pour la sortie de la "nouvelle version" permette cette discussion... (pour le moment)

Je vois que je ne peux rien faire d'autre. Tant pis.

@FranciscoPombal Je peux comprendre d'où vous venez et votre travail ici est très apprécié !

Bonne blague.

@FranciscoPombal Sérieusement ?? - Ce n'était pas une blague et j'étais/suis personnellement sincère !!!

Les points que vous soulevez sont pertinents, mais malheureusement, je ne pense pas que le délai actuel pour la sortie de la "nouvelle version" permette cette discussion... (pour le moment)

Je vois que je ne peux rien faire d'autre. Tant pis.

Ne prenez pas cette situation personnellement/à cœur ...... ok
........prendre une pause
laissez une partie de votre travail acharné dans le projet au moins voir le "public principal" via la nouvelle version. (comme actuellement, il ne peut être vu que par des gens comme moi qui viennent ici et participent/contribuent/construisent, etc.

Je viens de pousser une branche staging_v4_3_x . Il est essentiellement maître avec un journal des modifications mis à jour.
S'il vous plaît jeter un oeil à Changelog et dites-moi si quelque chose ne va pas ou si j'ai raté quelque chose.
@glassez

1. #13234 a-t-il des attributs destinés aux utilisateurs ? Quelque chose qui devrait être dans le journal des modifications ? par exemple "améliorer la vitesse de chargement des sessions avec des centaines de torrents".
2. Quel est le but de #13395. Qu'est ce que ça fait? Dois-je inclure quelque chose dans le journal des modifications ?

Dans quelques instants, j'examinerai les problèmes mentionnés dans ce fil qui pourraient faire en sorte que certains commits ne soient pas inclus pour la publication. Je vous tiendrai au courant.

@ sledgehammer999

Veuillez également nettoyer le PPA dans le processus. Les versions d'Ubuntu autres que 18.04 , 20.04 et 20.10 sont EOL, donc les archives des versions ciblant ces versions doivent être supprimées dès que possible.

Ubuntu 14.04 et 16.04 ne sont pas EOL. D'où avez-vous obtenu cette liste?
https://wiki.ubuntu.com/Releases

@ sledgehammer999 Il semble que vous ayez manqué https://github.com/qbittorrent/qBittorrent/pull/13188 pour le changelog

aussi, pouvez-vous ajouter une note dans le changelog qui
"Les bundles de thèmes précédents ne fonctionneront pas correctement avec cette version en raison de changements dans le format des fichiers de bundle, veuillez contacter le fournisseur de thèmes pour un correctif. Vous pouvez en savoir plus sur le nouveau format ici https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes " ou quelque chose comme ça.
En fait, c'est à cause de https://github.com/qbittorrent/qBittorrent/pull/12755/files

Je pense qu'il convient de mentionner que le support de RC1_1 libtorrent a été abandonné.

De plus, si quelqu'un veut un taux d'annonce de suivi plus rapide ou a une sortie de client plus lente (par rapport à 4.2.x) avec cette version, il peut essayer d'augmenter la limite "Annonce HTTP simultanée maximale" à partir des paramètres avancés.

#13234 a-t-il des attributs destinés aux utilisateurs ? Quelque chose qui devrait être dans le journal des modifications ? par exemple "améliorer la vitesse de chargement des sessions avec des centaines de torrents".

Je suis désolé, je ne me souviens pas de tout... c'était surtout une amélioration interne. Peut-être que la partie suivante de la description du PR correspond aux "attributs destinés à l'utilisateur":

Il permet de sauvegarder correctement les données de reprise dans certaines circonstances, par exemple dans l'état "fichiers manquants" (bien que nous ayons essayé d'empêcher que cela ne se fasse plus tôt, l'utilisateur pourrait en fait le faire lorsque, par exemple, il modifie certaines propriétés d'un tel torrent).

Quel est le but de #13395. Qu'est ce que ça fait? Dois-je inclure quelque chose dans le journal des modifications ?

https://github.com/qbittorrent/qBittorrent/pull/13395#issuecomment -710787904

Je pense qu'il convient de mentionner que le support de RC1_1 libtorrent a été abandonné

👍

FONCTIONNALITÉ : Ajout de la prise en charge de la création de torrents v2 (nécessite libtorrent 2.0.x) (Chocobo1)

Bon sang! QBittorrent prend-il déjà en charge libtorrent-2.0 ? Pourquoi le mentionner tel quel ? Nous en avons déjà parlé.

aussi, pouvez-vous ajouter une note dans le changelog qui
"Les bundles de thèmes précédents ne fonctionneront pas correctement avec cette version en raison de changements dans le format des fichiers de bundle, veuillez contacter le fournisseur de thèmes pour un correctif. Vous pouvez en savoir plus sur le nouveau format ici https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes " ou quelque chose comme ça.
En fait, c'est à cause de https://github.com/qbittorrent/qBittorrent/pull/12755/files

Je pense que je vais l'ajouter à la section "actualités" du site. En dehors des changements, dans le texte d'introduction.

Je pense qu'il convient de mentionner que le support de RC1_1 libtorrent a été abandonné.

D'ACCORD.

De plus, si quelqu'un veut un taux d'annonce de suivi plus rapide ou a une sortie de client plus lente (par rapport à 4.2.x) avec cette version, il peut essayer d'augmenter la limite "Annonce HTTP simultanée maximale" à partir des paramètres avancés.

Cela devrait-il être mentionné dans le journal des modifications en tant qu'élément ?

Bon sang! QBittorrent prend-il déjà en charge libtorrent-2.0 ? Pourquoi le mentionner tel quel ? Nous en avons déjà parlé.

Ensuite, je déplacerai cet élément sous l'entrée de version v4.4.0 (ne faisant pas partie du journal des modifications v4.3.0). À moins que le support officiel de libtorrent-2.0 ne soit introduit plus tôt. Est-ce satisfaisant ?

Voici le changelog mis à jour : https://github.com/qbittorrent/qBittorrent/commit/0302e8abbc545d13b7be51e011d2795a9bb3ea73

Cela devrait-il être mentionné dans le journal des modifications en tant qu'élément ?

Je pense mieux s'il est publié en tant que news. Comme les utilisateurs avec des milliers de torrents/beaucoup de trackers par torrent peuvent remarquer le comportement d'annonce lent.

Mis à jour à nouveau : https://github.com/qbittorrent/qBittorrent/commit/727dec97540091f891991113299fa38468e13885

Annonce : Un très léger retard est à prévoir. Je dois faire une recompilation partielle de la chaîne d'outils en raison d'un problème de sécurité dont j'ai été informé par e-mail. Les détails seront rendus disponibles quelques jours après la publication. Selon l'OMI, la gravité est probablement mineure car l'exploit nécessite qu'une personne malveillante ait un accès local ou exécute déjà une application malveillante sur votre système. Dans les deux cas vous êtes déjà foutu même sans le problème de sécurité de qbt.

Ubuntu 14.04 et 16.04 ne sont pas EOL. D'où avez-vous obtenu cette liste?

Formulation probablement erronée. C'est EOL pour nous car leur version Qt est inférieure à nos exigences minimales.

D'ACCORD. Je pense que tout est réglé maintenant, et je prépare des builds. La branche v4_3_x sera poussée avec les builds.

@ sledgehammer999 Désolé pour le commentaire tardif, mais n'oubliez pas de mentionner (dans la section des nouvelles du site Web) qu'il y a eu de nombreux correctifs libtorrent depuis la dernière version qui sont présents dans celle-ci, y compris pour les fuites de mémoire connues, les problèmes de vitesse dus à logique de paramètres de cache défectueuse sous Windows, etc. Vous pouvez jeter un œil à la version 1.2.6-1.2.11 de libtorrent (la version 1.2.11 n'est toujours pas officiellement publiée mais contient déjà quelques entrées du journal des modifications) pour vous inspirer et choisir les entrées les plus pertinentes.

Par curiosité, quel commit libtorrent sera utilisé ?

OK, et le dernier commit git comme toujours.

@rrrevin

Ubuntu 14.04 et 16.04 ne sont pas EOL. D'où avez-vous obtenu cette liste?
https://wiki.ubuntu.com/Releases

Formulation probablement erronée. C'est EOL pour nous car leur version Qt est inférieure à nos exigences minimales.

Eh bien, je voulais vraiment dire "Fin du support standard", je suppose, ce qui compte vraiment de toute façon. Au-delà, seules les entreprises payantes bénéficient d'un soutien. 16.04 n'est techniquement même pas encore à la "fin du support standard", mais c'est très proche. Et quoi qu'il en soit, le support OOTB a été abandonné il y a environ 2 ans en raison du fait que qBittorrent a fait passer la version minimale requise de Qt à 5.9.

@ sledgehammer999 Encore une petite chose : pensez à mentionner la régression mineure connue du menu contextuel des balises dans les actualités : https://github.com/qbittorrent/qBittorrent/issues/13492.

@ sledgehammer999 Vous n'avez pas crédité beaucoup de mes relations publiques dans le changelog... https://github.com/qbittorrent/qBittorrent/pulls?q=is%3Apr+author%3AFranciscoPombal+is%3Aclosed+milestone%3A4.3.0

@FranciscoPombal J'ai combiné toutes vos relations publiques CMake en une seule entrée. Vos PR de nettoyage de code interne ne peuvent pas être mentionnés dans le Changelog. Il devrait contenir des correctifs destinés aux utilisateurs. Idem avec les nombreux PR de @Chocobo1
Si j'ai raté quelque chose de spécifique, veuillez le mentionner ci-dessous. Je vais attendre quelques instants, car je fais encore des tâches administratives en coulisses.

@ sledgehammer999

Il devrait contenir des correctifs destinés aux utilisateurs.

D'accord alors:

• --> https://github.com/qbittorrent/qBittorrent/pull/13042 est orienté utilisateur, car il corrige un bogue d'annonce dans le tracker intégré. <--

• https://github.com/qbittorrent/qBittorrent/pull/12086 , https://github.com/qbittorrent/qBittorrent/pull/13109 et https://github.com/qbittorrent/qBittorrent/pull/13439 ne sont pas nettoyages face à l'utilisateur, donc je suppose que c'est bien.

• https://github.com/qbittorrent/qBittorrent/pull/13288 est une sorte d'utilisateur, je suppose ? Désormais, les utilisateurs peuvent télécharger des versions expérimentales à partir de CI, est-ce considéré comme accessible aux utilisateurs ?

• Les autres sont soit déjà crédités, liés aux améliorations de CMake (déjà également crédités) ou liés à https://github.com/qbittorrent/qBittorrent/pull/13288.

/offtopic (pour une autre fois) - peut-être que les nettoyages non destinés aux utilisateurs devraient être inclus dans "OTHER" ou peut-être une nouvelle section "CODE HEALTH" ? Les utilisateurs aiment voir ce genre de choses dans le changelog.

--> #13042 est destiné à l'utilisateur, car il corrige un bogue d'annonce dans le tracker intégré. <--

D'accord désolé. Ce n'était pas clair dans le titre du commit. Pouvez-vous suggérer une entrée de journal des modifications appropriée (pour les utilisateurs qui la lisent) ?

Les changements de CI ne sont généralement pas pertinents pour les versions.

/offtopic (pour une autre fois) - peut-être que les nettoyages non destinés aux utilisateurs devraient être inclus dans "OTHER" ou peut-être une nouvelle section "CODE HEALTH" ? Les utilisateurs aiment voir ce genre de choses dans le changelog.

Hmm, je vais ajouter une entrée OTHER pour les nettoyages de code vous créditant ainsi que @Chocobo1

13288 est une sorte de face à l'utilisateur, je suppose? Désormais, les utilisateurs peuvent télécharger des versions expérimentales à partir de CI, est-ce considéré comme accessible aux utilisateurs ?

IMO, une telle chose peut être mentionnée dans News à la place (en dehors du journal des modifications).

IMO, une telle chose peut être mentionnée dans News à la place (en dehors du journal des modifications).

Je pourrais en quelque sorte fourrer un lien "nightlies" dans la page de téléchargements...

~@glassez~ @ sledgehammer999

IMO, une telle chose peut être mentionnée dans News à la place (en dehors du journal des modifications).

Je pourrais en quelque sorte fourrer un lien "nightlies" dans la page de téléchargements...

Mentionnez simplement les trucs CI dans les nouvelles, j'hésiterais à lier la page de téléchargements "nocturne" à un public plus large avant que nous ayons une version basée sur git dans les exécutables. Sinon, tous les utilisateurs signaleront toutes les différentes versions nocturnes comme "4.x.xalpha1", ce qui prête à confusion.

versioning basé sur git dans les exécutables. Sinon, tous les utilisateurs signaleront toutes les différentes versions nocturnes comme "4.x.xalpha1", ce qui prête à confusion.

Oui, c'est une remarque correcte.

@ sledgehammer999

Pouvez-vous suggérer une entrée de journal des modifications appropriée (pour les utilisateurs qui la lisent) ?

"Correction de la logique d'annonce cassée dans le tracker intégré provoquant des échecs dans certains cas."

Les builds CI peuvent également être utilisées à des fins malveillantes. En créant des relations publiques malveillantes et en distribuant plus tard des liens.
Je recommanderais de ne pas lier une telle chose sur le site Web.

@an0n666

Les builds CI peuvent également être utilisées à des fins malveillantes. En créant des relations publiques malveillantes et en distribuant plus tard des liens.
Je recommanderais de ne pas lier une telle chose sur le site Web.

C'est aussi un bon point. Je suppose que je ferais mieux de commencer à travailler sur le flux de travail spécifiquement pour les versions nocturnes qui ne sont construites qu'à partir du maître dont j'ai déjà parlé. Ensuite, nous pourrons nous connecter à des versions nocturnes sans craindre qu'une telle chose ne se produise.

La libération est faite.
Le PPA sera nettoyé demain.
Détails du problème de sécurité dans quelques jours.
Plan de changements organisationnels dans quelques jours.

Et comme toujours, merci à tous pour leurs contributions à ce cycle de publication.