@sledgehammer999 Sie sollten dies lesen => https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions/5

Zum Glück habe ich den Virus nicht (und ich hoffe, ich bleibe es auch).

Ich freue mich für Sie persönlich.

Aber ich bin wirklich traurig über den aktuellen Stand der Dinge im Projekt (und ich bin nicht der Einzige, dem es genauso geht). Die Zeit für Veränderungen ist kritisch. Sie müssen also entweder die Leitung/Wartung des Projekts umstrukturieren oder ausdrücklich erklären, dass es nur Ihr persönliches Spielzeug ist, damit sich niemand falsche Hoffnungen macht.

Gibt es Commits, die ausgenommen werden müssen?

Ich halte es nicht für sinnvoll, jetzt Änderungen zu überspringen.

Eine Neuauflage ist jedenfalls längst überfällig.

Zu viel.

Soll ich wie üblich alle neuen Master-Commits in den v4_2_x-Zweig zurückportieren?

Warum v4.2.x? Es gibt mehr als genug Änderungen für v4.3!
Außerdem können Sie einfach einen v4_3_x-Zweig über dem aktuellen Master erstellen, anstatt diese unnötige Arbeit zu erledigen, indem Sie Commits einzeln "herauspicken".

Ich habe mir gerade die Commits von der vorherigen Version bis zum neuesten Master angesehen. (meistens Titel und PR-Beschreibungen übernehmen)

Warum v4.2.x? Es gibt mehr als genug Änderungen für v4.3!

Ja. Es gibt eine Menge Commits. Und da libtorrent 1.1.x fallengelassen wurde, rechtfertigt es sicherlich v4.3.x. (Und v4.4.x für libtorrent 2.0.x und c++17!!!)
Ich werde so schnell wie möglich eine neue PR für das kommende Changelog erstellen.

Über das Projektmanagement: Wir werden dies nach dem Wochenende / der bevorstehenden Veröffentlichung besprechen.

@ Vorschlaghammer999

Schön, dass du wieder da bist und alles in Ordnung ist.

Soll ich wie üblich alle neuen Master-Commits in den v4_2_x-Zweig zurückportieren? Gibt es Commits, die ausgenommen werden müssen?

Der Vorschlag, die neue Version als 4.3.x zu bezeichnen, ist mir gleichgültig. Es liegt an Ihnen und anderen zu entscheiden.

Alle Commits sind AFAIK gut. Viele sehr wichtige Korrekturen wurden jedoch auch in libtorrent integriert, daher ist es wichtig, für diese neue Version das neuste mögliche RC_1_2 zu verwenden.

Es gab bereits einige Commits bezüglich der Unterstützung von BitTorrent V2. Ich würde jedoch erwarten, dass diese Version wie oben erwähnt mit dem neuesten libtorrent RC_1_2 erstellt wird, sodass die meisten Benutzer in der Praxis nichts davon sehen werden. Daher würde ich einen Hinweis in das Changelog setzen, der dies erklärt, damit die Benutzer keine falschen Hoffnungen bekommen, wenn sie die BitTorrent V2-bezogenen Einträge lesen.

Ich habe meine lokale Toolchain auf den neuesten Stand gebracht. Die Rückportierung/das Änderungsprotokoll/das minimale Testen wird einige Zeit in Anspruch nehmen. Aber ich denke, dass dieses Wochenende ein machbares Ziel ist, abhängig von der Größe der Änderungen.

Können Sie bitte Einzelheiten dazu angeben? Ich nehme an, Sie haben das allerneueste MSVC 2019 und ich _hoffe_, dass Sie vcpkg oder ähnliches für die Abhängigkeiten verwenden - weniger Wahrscheinlichkeit von seltsamen Fehlern aufgrund geringfügiger Abweichungen in der Art und Weise, wie alles aufgebaut ist, und mehr Reproduzierbarkeit. Zur Inspiration können Sie sich das neue GitHub Actions CI ansehen. Bitte denken Sie auch daran, dieses Mal CMake zum Erstellen zu verwenden, es ist das neue Standard-Buildsystem geworden.

Über das Projektmanagement: Wir werden dies nach dem Wochenende / der bevorstehenden Veröffentlichung besprechen.

OK, aber bitte lieber früher als später. Und wir müssen die Diskussion über die Automatisierung des Freigabeprozesses weiterführen, damit sogar das Paketieren automatisch erfolgen kann.

@ Vorschlaghammer999

Bitte bereinigen Sie dabei auch die PPA. Andere Ubuntu-Releases als 18.04 , 20.04 und 20.10 sind EOL, daher sollten Archive für Builds, die auf diese Versionen abzielen, so schnell wie möglich entfernt werden.

Daher ist es wichtig, für diese neue Version den letztmöglichen RC_1_2 zu verwenden.

Das versteht sich von selbst.
Qt 15.1, openssl 1.1.1h, Boost 1.74

RC_2_0 wird noch nicht verwendet. Nicht ohne ein paar offizielle Beta-Versionen.

Ich nehme an, Sie haben das neueste MSVC 2019 und ich hoffe, Sie verwenden vcpkg

Nein, ich bleibe für diese Version immer noch bei msvc2017. Als ich das letzte Mal msvc2019 überprüft habe, wurde eine sehr große .pdb-Datei für qbt erstellt. Ich werde es später noch einmal überprüfen, aber nicht für diese Version.
Der Rest der Abhängigkeiten ist so aufgebaut, wie ich es immer gemacht habe. Hier mehr oder weniger beschrieben: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (statische Verknüpfung)

Bitte denken Sie auch daran, dieses Mal CMake zum Erstellen zu verwenden, es ist das neue Standard-Buildsystem geworden .

Anscheinend habe ich das im Git-Log übersehen. Ich bin etwas verblüfft, aber ich kann nicht wirklich Einwände erheben, da sich alle anderen mit der Verwendung von cmake wohler fühlen als mit autotools/qmake.
Vorerst werde ich jedoch weiterhin autotools/qmake für die Veröffentlichung verwenden. Ich habe keine Zeit, mich für die Veröffentlichung mit cmake vertraut zu machen.

Ich werde sehen, was ich gegen die PPA tun kann, obwohl sie niemandem schaden.

@sledgehammer999 Ich weiß, dass Sie nicht möchten, dass normale Benutzer hier Kommentare abgeben, also entschuldigen Sie sich ... Ich habe hier Windows-Builds erstellt, um Probleme / Fehler usw. zu beseitigen.

Ich kompiliere mit MSVC 2019 und ausführbare qBittorrent-Dateien sind normalerweise etwa 27 MB groß und .pdb sind 180 MB groß

Haben Sie daran gedacht, /pdbstripped zu verwenden?

Ich kompiliere mit MSVC 2019 und ausführbare qBittorrent-Dateien sind normalerweise etwa 27 MB groß und .pdb sind 180 MB groß

Vergleichen Sie mit msvc2017 und dem aktuellen Master: 24,4 MB exe und 98,1 MB pdb. Wie gesagt, die pdb ist im Vergleich zu msvc2017 sehr groß.

Ich glaube auch nicht, dass wir /pdbstripped wollen. Es wird wahrscheinlich weniger nützliche Rückverfolgungen geben, wenn das Programm abstürzt.

Ich glaube auch nicht, dass wir /pdbstripped wollen. Es wird wahrscheinlich weniger nützliche Rückverfolgungen geben, wenn das Programm abstürzt.

/PDBCompress ?

@ Vorschlaghammer999

Die automatisierten CI-Builds, die CMake + das neueste MSVC 2019 + vcpkg (https://github.com/qbittorrent/qBittorrent/actions) verwenden, liegen bei 57 MiB (ausführbar) + 122 MiB (pdb).

Nein, ich bleibe für diese Version immer noch bei msvc2017. Als ich das letzte Mal msvc2019 überprüft habe, wurde eine sehr große .pdb-Datei für qbt erstellt. Ich werde es später noch einmal überprüfen, aber nicht für diese Version.

Das ist IMO kein guter Grund. MSVC 2019 enthält viele Korrekturen. Es ist (das Ende von) 2020. Niemand kümmert sich um eine zusätzliche Installationsgröße von ~50 MiB (und wenn doch, schade, lol). Wir können später herausfinden, ob etwas die pdb/ausführbare Datei aufbläht, aber im Moment funktioniert alles und zusätzliche \~50 MiB sind ein Kompromiss, den ich an jedem Tag der Woche für eine viel neuere Toolchain eingehen würde.

Ich glaube auch nicht, dass wir /pdbstripped wollen. Es wird wahrscheinlich weniger nützliche Rückverfolgungen geben, wenn das Programm abstürzt.

:+1:, aber das kann in Zukunft richtig untersucht werden.

Der Rest der Abhängigkeiten ist so aufgebaut, wie ich es immer gemacht habe. Hier mehr oder weniger beschrieben: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (statische Verknüpfung)

Anscheinend habe ich das im Git-Log übersehen. Ich bin etwas verblüfft, aber ich kann nicht wirklich Einwände erheben, da sich alle anderen mit der Verwendung von cmake wohler fühlen als mit autotools/qmake.
Vorerst werde ich jedoch weiterhin autotools/qmake für die Veröffentlichung verwenden. Ich habe keine Zeit, mich für die Veröffentlichung mit cmake vertraut zu machen.

:-1:, dies ist nicht die Art und Weise, wie die meisten Leute qBittorrent in den letzten Monaten unter Windows getestet haben. Viele Leute haben Builds aus meinem CI-Zweig (CMake + vcpkg) und jetzt den eigenen Actions-Abschnitt des Repos verwendet. Ich würde sagen, es ist sehr wahrscheinlich, dass wir unerklärliche Regressionen beobachten, die sich nur aus den Unterschieden im Build-Prozess ergeben, wenn Sie dies tun.

@sledgehammer999 Ich möchte vor der Veröffentlichung keine weiteren "Blocker" hinzufügen, aber zumindest würde ich warten, bis dies landet, da es im Grunde fertig ist: https://github.com/qbittorrent/qBittorrent/pull/13499

Die Änderung der Voreinstellung für asynchrone I/O-Threads wird für viele Benutzer von Vorteil sein.

Ich möchte msvc2019 nicht dissen, aber ich denke, Sie sind ein bisschen übertrieben, wenn Sie alles brandneu als besser betrachten. Es ist nicht immer der Fall. Und ja, 50 MB extra für einen BT-Client sind eine große Sache. Es ist eine unnötige Aufblähung ohne messbaren Nutzen (zB wird das Programm nicht 1,5x schneller).

Zuletzt zu Build-Systemen: Wenn wir Regressionen nur aufgrund der Änderung des Build-Systems sehen, dann stimmt etwas ernsthaft mit dem Code nicht. Sachen sollten nicht so zerbrechlich sein.

13499 ist außerhalb des Gültigkeitsbereichs, da es sich um eine libtorrent 2.0.x-Option handelt, die noch nicht die Standardeinstellung ist. Letztendlich wird am Wochenende der Schnitt gemacht.

@ Vorschlaghammer999

Ich möchte msvc2019 nicht dissen, aber ich denke, Sie sind ein bisschen übertrieben, wenn Sie alles brandneu als besser betrachten. Es ist nicht immer der Fall.
Und ja, 50 MB extra für einen BT-Client sind eine große Sache. Es ist eine unnötige Aufblähung ohne messbaren Nutzen (zB wird das Programm nicht 1,5x schneller).

Bitte lehnen Sie meine Argumente nicht einfach als "neu = besser" ab. Und ich denke, Sie sind ein bisschen "übertrieben", wenn Sie für 50 MiB an einer schlechteren Toolchain festhalten. Natürlich sehen Sie nie (oder sehr selten) eine „1,5-fache“ Geschwindigkeitssteigerung durch die Aktualisierung Ihrer Toolchain. Aber das ist eine unrealistische Messlatte. Mit einer neueren Toolchain gibt es vielleicht keine "1,5-fache" Geschwindigkeitssteigerung, aber es gibt immer kleine Leistungsverbesserungen, bessere Sprachunterstützung, bessere Code-Generierung (was manchmal zu weniger Fehlern führt), ... Es gibt viele Online-Ressourcen, die das dokumentieren Verbesserungen in MSVC 2019.

Auch hier stimme ich zu, dass wir diese zusätzlichen 50 MiB nach Möglichkeit abbauen sollten, aber mein Punkt ist, dass, wenn wir das nicht rechtzeitig für die nächste Veröffentlichung (oder überhaupt!) schaffen, _das in Ordnung ist_. Es ist auch nicht impliziert, dass dies bei jedem Release aufs Neue passiert (da würde ich mich auch ärgern). Dies ist ganz klar ein einmaliges Problem. Als Benutzer würde ich nicht hören wollen "hier ist deine Binärdatei von schlechterer Qualität, aber wir haben dir wenigstens 50 MiB gespart, Bruder". 50 MiB sind heutzutage ein Rundungsfehler (für Desktop-Programme sowieso; natürlich in der Embedded-Welt und dergleichen ist dies nicht der Fall). Tut mir leid, aber du liegst einfach falsch, wenn du anders denkst.

Zuletzt zu Build-Systemen: Wenn wir Regressionen nur aufgrund der Änderung des Build-Systems sehen, dann stimmt etwas ernsthaft mit dem Code nicht. Sachen sollten nicht so zerbrechlich sein.

Nicht unbedingt. Mit dem Build-System selbst kann etwas ernsthaft falsch sein. Sehen Sie sich den vorherigen Stand des CMake-Buildsystems vor meiner Überholungs-PR an. Davor verursachte das Erstellen mit CMake einige Fehler. Einige (manchmal ernste!) Probleme stammen wirklich von falschen/schlechten Build-Systemen und Build-Rezepten. Egal wie robust Ihr Code ist, wenn Sie ihn falsch erstellen, wird er kaputt gehen, manchmal auf sehr spektakuläre, aber schwer zu diagnostizierende Weise.

13499 ist außerhalb des Gültigkeitsbereichs, da es sich um eine libtorrent 2.0.x-Option handelt, die noch nicht die Standardeinstellung ist. Letztendlich wird am Wochenende der Schnitt gemacht.

Bitte sehen Sie sich den Rest der Diskussion an. Dieser PR ändert auch tatsächlich die Standardanzahl von asynchronen E/A-Threads, sodass standardmäßig mindestens 2 Hash-Threads verwendet werden, wenn auch gegen libtorrent 1.2.x gebaut wird. Dies führt zu einem sehr deutlichen Leistungsschub für SSD-Benutzer (mehr als 1,5x, heh), während es auch für HDD-Benutzer einen sehr geringen Gewinn bringt.

@ Vorschlaghammer999

Hier ist etwas Hilfe für den Einstieg:

• das neue Tutorial zum statischen Erstellen mit CMake unter Windows: https://github.com/qbittorrent/qBittorrent/wiki/Compilation :-Windows-(MSVC-2019,-64-bit,-static-linkage)
• Liste der Optionen + kurzes CMake-Tutorial/Intro: https://github.com/qbittorrent/qBittorrent/wiki/Compilation-with-CMake :-common-information

Falls Sie vcpkg nicht verwenden oder wenn Sie vcpkg für einige Pakete verwenden, aber nicht für andere, müssen Sie nur zusätzlich die entsprechenden Hinweise übergeben, die CMake mitteilen, wo die Konfigurationsdateien für die Pakete zu finden sind, z. B. -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar . Im Zweifelsfall können Sie einfach die Konfiguration ausführen, bis sie erfolgreich ist, und jede Fehlermeldung zu jedem Paket nacheinander beheben, wenn sie auftauchen, da die Fehlermeldungen so hilfreich sind, dass Sie immer verstehen und herausfinden können, was Sie hinzufügen müssen nächste.

Ich werde nicht weiter über Compiler streiten. Ich stimme Ihnen nicht speziell für qbt zu. msvc2019 wird für uns viel relevanter, wenn wir auf c++17 umsteigen. Schließlich interessiert sich ein BT-Client-Benutzer nur dafür, ob der Client Top-Down/Up-Geschwindigkeit erreichen kann. Das ist die Metrik für "bessere" oder "schlechtere" Binärdateien. msvc2017 erreicht dies ohne zusätzliches Aufblähen. --Ich behalte mein Urteil, bis ich meine Builds mit msvc2019 neu mache--

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

Macht es einen Unterschied, wie ein Paket erstellt/installiert wird? Derzeit habe ich keinen Ordner cmake unter lib für Boost, libtorrent, openssl. Nur für Quart.
PS: boost und libtorrent werden mit b2 erstellt. Openssl mit ihrem Konfigurationsskript.

@ Vorschlaghammer999

Die einzige Voraussetzung ist, dass Sie libtorrent mit CMake, IIRC erstellen. Alle anderen Pakete generieren entweder standardmäßig die erforderlichen Konfigurationsdateien oder werden von CMake in irgendeiner Weise unterstützt:

• libtorrent muss mit CMake erstellt werden, damit die entsprechenden Dateien generiert werden können. Dies wird speziell im Wiki-Tutorial behandelt.
• CMake unterstützt OpenSSL nativ über ein gebündeltes Suchmodul: https://cmake.org/cmake/help/latest/module/FindOpenSSL.html#hints. Sie müssen nur OPENSSL_ROOT_DIR einstellen. Beispiel: -DOPENSSL_ROOT_DIR=C:\Qt\Tools\OpenSSL\Win_x64
• boost generiert standardmäßig die erforderlichen Dateien. Sie müssen nur Boost_DIR einstellen. Beispiel: -DBoost_DIR=C:\path\to\boost_1_73_0\stage\lib\cmake\Boost-1.73.0
• Für zlib müssen Sie einige Pfade passieren. Beispiel: -DZLIB_INCLUDE_DIR=C:\path\to\zlib-1.2.11\build -DZLIB_LIBRARY=C:\path\to\zlib-1.2.11\build\libzlibstatic.a
• Qt generiert die erforderlichen Dateien, ich nehme an, Sie haben bereits das erforderliche Konfigurationszeit-Flag herausgefunden, das erforderlich ist, um auf sie zu verweisen.

Auch hier, wenn Sie eines davon vermissen, wird CMake Sie im Konfigurationsschritt darüber informieren und genau vorschlagen, was Sie hinzufügen möchten.

Ich stimme Vorschlaghammer999 zu.
Kleinere Binärdateien sind immer besser. Besonders angesichts der Erfolgsbilanz vergangener Veröffentlichungen.
Viele haben immer noch ein langsames Internet. Auch die Website, die die Binärdateien bereitstellt, könnte für einige Benutzer je nach Standort langsam sein.
In solchen Fällen ermöglicht eine kleine Binärdatei einen schnelleren Download. Menschen werden möglicherweise von einem Update entmutigt, wenn sie unnötige Bloatware vermuten.

es ist das neue Standard-Buildsystem geworden.

Standard-Buildsystem von was?

es ist das neue Standard-Buildsystem geworden.

Standard-Buildsystem von was?

er hat sogar qmake/autotools für veraltet erklärt https://github.com/qbittorrent/qBittorrent/wiki

er hat sogar qmake/autotools für veraltet erklärt https://github.com/qbittorrent/qBittorrent/wiki

Diese Willkür macht langsam richtig wütend!

es ist das neue Standard-Buildsystem geworden.
Standard-Buildsystem von was?

Diese Willkür macht langsam richtig wütend!

Oh wow! Es ist also keine wirkliche Entscheidung! Ich fühle mich schließlich nicht verarscht.

@FranciscoPombal
Bitte lenken Sie @sledgehammer999 nicht mit nutzlosen Gesprächen über verschiedene Build-Tools, Build-Systeme usw. ab. Lassen Sie die kommende Veröffentlichung auf die übliche Weise erfolgen – sie wird schneller und zuverlässiger. Wir brauchen Zeit, um organisatorische Probleme zu lösen, damit wir das Projekt am Laufen halten können, ungeachtet der Tatsache, dass eines seiner Mitglieder für längere Zeit verschwindet.
Es macht auch keinen Sinn, libtorrent-2.0 im Zusammenhang mit dem kommenden Release (und dem gesamten kommenden Zweig) zu diskutieren, da wir dafür keine Unterstützung haben und wir nicht einmal vorhersagen können, wann es vollständig implementiert sein wird.

Es ist (das Ende von) 2020. Niemand kümmert sich um eine zusätzliche Installationsgröße von ~50 MiB (und wenn doch, schade, lol).

Meine beiden Hauptcomputer sind 9 und 12 Jahre alt (obwohl ich sie kürzlich verbessert habe, indem ich SSD als Systemfestplatten installiert habe). Viele verwenden noch ältere Hardware. Nicht, weil es uns gefällt. Wir haben einfach nicht die finanziellen/sonstigen Kapazitäten, um es alle 2-3 Jahre zu aktualisieren. Wenn Sie uns nicht verstehen können, gibt Ihnen das noch lange nicht das Recht, sich über uns lustig zu machen.

PS Aber selbst vor 10 Jahren hätte ich mich nicht so sehr um diese 50 Megabyte gekümmert.

@an0n666 @ sledgehammer999 @glassez

Ich stimme Vorschlaghammer999 zu.
Kleinere Binärdateien sind immer besser. Besonders angesichts der Erfolgsbilanz vergangener Veröffentlichungen.
Viele haben immer noch ein langsames Internet. Auch die Website, die die Binärdateien bereitstellt, könnte für einige Benutzer je nach Standort langsam sein.
In solchen Fällen ermöglicht eine kleine Binärdatei einen schnelleren Download. Menschen werden möglicherweise von einem Update entmutigt, wenn sie unnötige Bloatware vermuten.

Kommen Sie jetzt, der Download der Anwendung ist einmalig. Selbst bei 10 Mb/s sind zusätzliche 50 MiB nur zusätzliche 50 Sekunden. Wenn diese Leute das so stört, kommen sie verdammt noch mal besser hierher und helfen, das Problem selbst zu lösen. Lassen Sie sich nicht von Zwangsmenschen herumschubsen, die sich über 50 MiB beschweren. Sie wollen deswegen zurück zu uT 2.2.1 wechseln? Bußgeld. Selbst in Somalia können Sie durchschnittlich 10 Mb/s erreichen: https://www.speedtest.net/global-index , und ich bezweifle, dass ein BitTorrent-Client die Hauptbeschäftigung der meisten einheimischen Somalier ist. Die Builds werden sowohl von Fosshub als auch von Sourceforge bereitgestellt, die wahrscheinlich nie zum Engpass werden, es sei denn, Kim Kardashian forderte alle ihre Fans auf, qBittorrent oder so etwas herunterzuladen.

Ebenfalls,

Kleinere Binärdateien sind immer besser. Besonders angesichts der Erfolgsbilanz vergangener Veröffentlichungen.

Zitat benötigt. Wo ist die Korrelation zwischen "besserer Erfolgsbilanz" und "kleinerer Binärgröße"? Bessere Erfolgsbilanz von was? Leistung? Verlässlichkeit?

Standard-Buildsystem von was?

er hat sogar qmake/autotools für veraltet erklärt https://github.com/qbittorrent/qBittorrent/wiki

Diese Willkür macht langsam richtig wütend!

Oh wow! Es ist also keine wirkliche Entscheidung! Ich fühle mich schließlich nicht verarscht.

Wir waren uns einig, dass das CMake-Build-System die Zukunft war. Es ist ein Fehler, weiterhin zwei Build-Systeme zu pflegen, wie ich schon oft gesagt habe. Dies wird sogar in aktuellen Beiträgen erwähnt: https://github.com/qbittorrent/qBittorrent/pull/13509#issuecomment -708072078

Apropos Bloatware: Schauen Sie sich den doppelten Aufwand an, den wir durch die Wartung von 2 Build-Systemen haben. Schauen Sie sich die verschiedenen Dateien von Autotools Bloat an, die wir im Repo haben.

Bitte lenken Sie @sledgehammer999 nicht mit nutzlosen Gesprächen über verschiedene Build-Tools, Build-Systeme usw. ab. Lassen Sie die kommende Veröffentlichung auf die übliche Weise erfolgen – sie wird schneller und zuverlässiger.

Ein weiterer Angriff auf das wahrscheinlich aktivste Mitglied in diesem Repository in den letzten Monaten, das entscheidende Beiträge geleistet hat, insbesondere im Bereich der Build-Systeme, Tools usw. Die neuen Builds und Änderungen am Build-System _sind_ zuverlässiger. Soweit ich mich erinnere, gab es sogar Fälle von Problemen, die einfach durch das Bauen mit der neuen Methode verschwanden. Dank meiner Bemühungen können wir jetzt zuverlässigere Builds viel schneller in die Hände der Benutzer bringen. Es ist sicherlich NICHT nutzlos. Ich habe vor, dies bis zur offiziellen Veröffentlichung weiter zu verbessern, aber zählen Sie nicht auf mich, wenn Sie meine Teilnahme weiterhin so herabsetzen.

Ich lenke ihn nicht ab, ich informiere ihn über wichtige Entwicklungen der letzten Monate. Es liegt an ihm, aufzuholen.
Jetzt, wo der Schlitten zurückgekehrt ist, möchte ich den Build so gerne wie jeder andere aus der Tür holen, aber ich möchte es _richtig_ machen. Die Rückkehr von sledge sollte nicht bedeuten, dass wir zu unseren alten Gewohnheiten zurückkehren müssen (auch wenn sich diese Veröffentlichung wie ein Kompromiss anfühlt), es sollte bedeuten, dass wir uns _schneller_ weiterentwickeln können, um den Ort zu erreichen, an dem wir sein möchten.

Wir brauchen Zeit, um organisatorische Probleme zu lösen, damit wir das Projekt am Laufen halten können, ungeachtet der Tatsache, dass eines seiner Mitglieder für längere Zeit verschwindet.

Ein Teil des Problems besteht darin, sich auf eine einzelne Person zu verlassen, um Builds mit einem alternden und weniger wartbaren Build-System manuell zu erstellen, nur wegen 50 MiB (die später gelöst werden können) durch Reifen zu springen usw. Bedenken Sie die Tatsache, dass wir von der abweichen Toolchain, die wir in unserem CI nur dafür verwenden. Auch wenn es jetzt eigentlich kein großes Thema ist, ist es ein schlechtes Prinzip und Präzedenzfall.

Es macht auch keinen Sinn, libtorrent-2.0 im Zusammenhang mit dem kommenden Release (und dem gesamten kommenden Zweig) zu diskutieren, da wir dafür keine Unterstützung haben und wir nicht einmal vorhersagen können, wann es vollständig implementiert sein wird.

Über libtorrent 2.0 brauchen wir überhaupt nicht zu reden. Nur eine kleine Anmerkung, die erklärt, dass die Unterstützung für V2 immer noch nicht vorhanden ist, obwohl einige Erwähnungen der V2-Unterstützung in den Commit-Meldungen im Änderungsprotokoll erscheinen werden. Zum Beispiel 19d77b0881dc777b7930106869854067e5b2faba. (es sei denn natürlich, Sie wählen diese Commits nicht für die Version 4.3.0 aus, aber das verkompliziert die Dinge meiner Meinung nach).

Meine beiden Hauptcomputer sind 9 und 12 Jahre alt (obwohl ich sie kürzlich verbessert habe, indem ich SSD als Systemfestplatten installiert habe). Viele verwenden noch ältere Hardware. Nicht, weil es uns gefällt. Wir haben einfach nicht die finanziellen/sonstigen Kapazitäten, um es alle 2-3 Jahre zu aktualisieren. Wenn Sie uns nicht verstehen können, gibt Ihnen das noch lange nicht das Recht, sich über uns lustig zu machen.

PS Aber selbst vor 10 Jahren hätte ich mich nicht so sehr um diese 50 Megabyte gekümmert.

Bitte zeigen Sie, wo ich mich über Benutzer mit niedrigen Spezifikationen "verspottet" habe. Ich habe auch einen 12 Jahre alten C2D-Laptop, auf dem ich eine SSD installiert habe (der Anschluss ist jedoch nur SATA II!), Den ich immer noch häufig benutze. Ich besitze auch keine Maschine mit einem Prozessor, der in den letzten 3 Jahren hergestellt wurde, und ich wünschte, ich könnte in Zukunft einen AMD Ryzen bekommen. Ich rüste sicher nicht alle 2-3 Jahre auf. Ich verstehe und stimme dir zu. Ich habe mich nur über Leute lustig gemacht, die sich heutzutage über 50 MiB auf einem Desktop/Laptop beschweren (sprich: letzten 15+ Jahre), weil diese Leute es verdienen, sich über sie lustig zu machen.

Ein weiterer Angriff auf das wahrscheinlich aktivste Mitglied in diesem Repository in den letzten Monaten

Bitte hören Sie auf, in meinen Kommentaren nach verstecktem Subtext zu suchen. Ich habe nur gesagt, was ich gesagt habe. Ich hoffe, Ihre Reaktion verwirrt niemanden.

Ich lenke ihn nicht ab, ich informiere ihn über wichtige Entwicklungen der letzten Monate. Es liegt an ihm, aufzuholen.

Alles hat seine Zeit und seinen Ort.
Warum hier und jetzt @sledgehammer999 drücken, wenn es nur dazu führen kann, dass er keine Zeit hat, weder das nächste Release zu machen, noch die Verwaltung/Wartung des Projekts umzustrukturieren, bevor er wieder verschwindet, damit wir es nicht sein werden in seiner Abwesenheit vollumfänglich weiterarbeiten kann.

Über libtorrent 2.0 brauchen wir überhaupt nicht zu reden. Nur eine kleine Anmerkung, die erklärt, dass die Unterstützung für V2 immer noch nicht vorhanden ist, obwohl einige Erwähnungen der V2-Unterstützung in den Commit-Meldungen im Änderungsprotokoll erscheinen werden.

Ich habe wiederholt erwähnt, dass das Änderungsprotokoll die Git-Historie nicht blind kopieren sollte. Das sollten Sie bedenken:

1. Einige Commits sind Teil einer einzigen Fehlerbehebung/Verbesserung/Funktion, daher ist es sinnvoll, sie in ihrer Gesamtheit zu erwähnen;
2. Einige Commits beheben Zwischenfehler, die in der vorherigen Version nicht vorhanden waren, daher macht es keinen Sinn, sie zu erwähnen.
3. Einige Commits sind Teil einer unvollendeten Arbeit, daher macht es keinen Sinn, sie zu erwähnen.

@ Vorschlaghammer999
Bitte benachrichtigen Sie uns für Ausgabe Nr. 13519.

BEARBEITEN: Fehlalarm: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710744534
EDIT (FranciscoPombal) kein Fehlalarm: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710911209

@ sledgehammer999 @Chocobo1 @glassez

Entschuldigung für das Massen-Ping, aber dieses scheint auch ziemlich kritisch zu sein und leider im Moment ein bisschen chaotisch (ich bin an dieser Stelle auch verwirrt, was das Problem eigentlich ist): https://github.com/ qbittorrent/qBittorrent/issues/13389. Vielleicht kann einer von euch etwas neues Licht ins Dunkel bringen?

Eines ist sicher; Ich möchte nicht riskieren, mit der ersten 4.3.x-Version alle *arr -Setups zu zerstören.

dieses hier scheint auch ziemlich kritisch zu sein und leider im Moment ein bisschen chaotisch (ich bin an dieser Stelle auch verwirrt, was das Problem eigentlich ist): #13389. Vielleicht kann einer von euch etwas neues Licht ins Dunkel bringen?

Eines ist sicher; Ich möchte nicht riskieren, mit der ersten 4.3.x-Version alle *arr -Setups zu zerstören.

Bitte nicht erst am Ende ausflippen. Was ist das Problem? (Zusätzlich zu Problemen mit dem Verständnis der Anwendungslogik.) Wir haben den zugehörigen Code nicht geändert, oder? Ich habe sicher nicht den ganzen Thread gelesen. Wenn es eindeutige Hinweise auf einen Fehler in der App gibt, verweise mich bitte auf einen bestimmten Kommentar.

@glasez

Bitte nicht erst am Ende ausflippen. Was ist das Problem? (Zusätzlich zu Problemen mit dem Verständnis der Anwendungslogik.) Wir haben den zugehörigen Code nicht geändert, oder? Ich habe sicher nicht den ganzen Thread gelesen. Wenn es eindeutige Hinweise auf einen Fehler in der App gibt, verweise mich bitte auf einen bestimmten Kommentar.

Niemand flippt aus, wir müssen uns nur der möglichen Folgen bewusst sein. Der Punkt ist, dass jemand anderes den Thread sorgfältig und mit klarem Kopf liest. Als ich damals versuchte, es anzugehen, konnte ich nicht sicher sein, ob es sich um eine legitime Regression oder eine falsche Darstellung einer kürzlich vorgenommenen Änderung durch den Benutzer handelte oder ob die kürzlich erfolgte Änderung des Wortlauts einen unerwarteten Fehler aufdeckte oder was auch immer. Hinzu kommt die Tatsache, dass ich noch nie eine *arr -Software verwendet habe, aber ich weiß, dass viele Leute dies tun. Ungeachtet dessen sind hier die Originalberichte in den *arr Repos: https://github.com/Radarr/Radarr/issues/5032 https://github.com/Sonarr/Sonarr/issues/3968 , falls Sie mal schauen möchte.

Hallo Leute,

Ich habe gerade bemerkt, dass jemand FOSSHUB in einem früheren Kommentar erwähnt hat. Ich habe den Thread gelesen und möchte dies sagen. Angenommen, qBittorrent wird etwa 50 MB haben, macht das für uns keinen Unterschied. Dasselbe gilt für jede Verkehrsspitze, jemand erwähnte Kim Kardashian. Bitte lassen Sie sie qBittorrent empfehlen; Ich bin sicher, wir werden nicht untergehen. Wir können diesen Verkehr absorbieren. Wenn beispielsweise ein neuer qBittorrent veröffentlicht wird, haben wir Tausende von Aktualisierungsanfragen pro Sekunde gesehen.

Was ich versuche zu sagen ist, dass Sie sich darüber keine Sorgen machen sollten.

Danke!

Für meine 1,5 Cent baut und läuft es auf msvc2019 aus irgendeinem Grund besser
50 MB Speicherplatz sind im Jahr 2020 absolut nichts, wenn Ihr System SO eingeschränkt ist, führen Sie sowieso einen leichteren Client oder qbt-cli aus

Schieben Sie es niemals auf, Ihr Projekt auf den neuesten und besten Stand zu bringen, wenn es möglich ist, ohne Fehler zu verursachen. Je länger Sie warten, desto mehr riskieren Sie, ins Hintertreffen zu geraten, und an einem toten, nicht unterstützten Compiler hängen zu bleiben, macht niemandem Spaß

Ich denke, Sledge bezog sich auf Probleme wie diese, die auch nach einer Erhöhung der Größe des Installationsprogramms um nur 12 MiB geöffnet wurden.
https://github.com/qbittorrent/qBittorrent/issues/12247

Es sind also nicht einmal 50 MiB, sondern nur 12 MiB, mit denen die Leute sich die Mühe machen, ein Ausstellungsticket zu erstellen.

@sledgehammer999 "WENN" Sie Qt 5.15.0/5.15.1 in der nächsten Version verwenden werden, beachten Sie (Kontextmenü schließt sich nach Auswahl eines Tags) #13492

Einfach ausgedrückt denke ich, wenn es als 4.3 bezeichnet wird, wird sich niemand darüber beschweren, dass das Installationsprogramm größer ist, es wäre sicherlich zu erwarten! Das Beibehalten antiquierter Toolchains fühlt sich ehrlich gesagt wie eine passende Darstellung des Veröffentlichungsprozesses von qBittorrent an.

Aufgeregt, dies endlich zu sehen, hatte ich die Hoffnung fast aufgegeben, dieses Jahr etwas zu sehen.

Ich denke, Sledge bezog sich auf Probleme wie diese, die auch nach einer Erhöhung der Größe des Installationsprogramms um nur 12 MiB geöffnet wurden.

12247

>

Es sind also nicht einmal 50 MiB, sondern nur 12 MiB, mit denen die Leute sich die Mühe machen, ein Ausstellungsticket zu erstellen.

Damit? Die einzig angemessene Antwort für solche Tickets ist "was auch immer, Mann.". Ich verstehe die Besessenheit nicht, sich für diese Leute nach hinten zu beugen. Wie ich in https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708436739 sagte, werden wir natürlich immer unser Bestes tun, um solche Größenzunahmen zu verhindern, aber wir sollten nichts anderes opfern, nur für 50 MiB, und wenn einige Leute das so stören, können sie hierher kommen und es selbst reparieren.

wir sollten nichts anderes opfern

Es tut mir leid, aber ich sehe wirklich nicht, was wir opfern, wenn wir nicht zum neuesten und besten (zweifelhaften) Compiler gehen. Es ist nichts Greifbares daran, zum neuesten Compiler zu gehen. Es ist nicht so, als ob msvc2017 ein alter Compiler wäre.

@ Vorschlaghammer999

Es tut mir leid, aber ich sehe wirklich nicht, was wir opfern, wenn wir nicht zum neuesten und besten (zweifelhaften) Compiler gehen. Es ist nichts Greifbares daran, zum neuesten Compiler zu gehen. Es ist nicht so, als ob msvc2017 ein alter Compiler wäre.

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

Für meine 1,5 Cent baut und läuft es auf msvc2019 aus irgendeinem Grund besser

Wie bereits erwähnt, erinnere ich mich an andere derartige Berichte im Issue Tracker oder anderen Kommunikationskanälen. Ich erfinde das nicht.

Unabhängig davon sollte man immer versuchen, die neueste Toolchain zu verwenden (im Rahmen des Zumutbaren, aber MSVC 2019 ist zu diesem Zeitpunkt ausgereift), es sei denn, es gibt einen sehr guten Grund, dies nicht zu tun. Darüber hinaus wurden die MSVC 2019-Builds in den letzten Monaten ausgiebig getestet, entweder von mir, xavier2k6 oder anderen bereitgestellt, oder jetzt, in jüngerer Zeit, mit dem offiziellen GitHub Actions-Workflow. 50 MiB sind kein guter Grund, wie viele Leute versuchen, Ihnen zu sagen. Lassen Sie sich nicht von denen schikanieren, die über 50 MiB besessen sind!! Ich kümmere mich persönlich um diese Berichte, Sie brauchen sie nicht einmal zu sehen.

Ist das Upgrade auf MSVC2019 etwas, das viel Zeit in Anspruch nimmt? Es geht nur darum, wann nicht, wenn nicht? Also, wenn nicht diese Veröffentlichung, dann sicherlich die nächsten, gegebenen Veröffentlichungen liegen im Allgemeinen fast Monate auseinander.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -711123971 ist nur ein subjektiver Bericht, der höchstwahrscheinlich von der Verwendung der neuesten Bibliotheken und des qbt-Codes betroffen ist. Nicht wegen Compiler.

Ist das Upgrade auf MSVC2019 etwas, das viel Zeit in Anspruch nimmt? Es geht nur darum, wann nicht, wenn nicht? Also, wenn nicht diese Veröffentlichung, dann sicherlich die nächsten, gegebenen Veröffentlichungen liegen im Allgemeinen fast Monate auseinander.

Grund ist hier angegeben https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708055242

Lassen Sie sich nicht von denen schikanieren, die über 50 MiB besessen sind!!

Ich lasse mich auch nicht von denen einschüchtern, die vom „Neuesten und Größten“ besessen sind. Und der Unterschied sind tatsächlich 68 MB zusätzlicher Speicher (ich habe lokale statische Builds erstellt). msvc2017 funktioniert einfach! und benötigt keinen zusätzlichen Platz.

13505 (Kommentar) ist nur ein subjektiver Bericht, der höchstwahrscheinlich von der Verwendung der neuesten Bibliotheken und des neuesten qbt-Codes betroffen ist. Nicht wegen Compiler.

Und Ihre Kommentare darüber, dass MSVC 2019 überhaupt keine Vorteile bietet, sind ebenfalls unbegründete Behauptungen.

Ich lasse mich auch nicht von denen einschüchtern, die vom „Neuesten und Größten“ besessen sind. Und der Unterschied sind tatsächlich 68 MB zusätzlicher Speicher (ich habe lokale statische Builds erstellt). msvc2017 funktioniert einfach! und benötigt keinen zusätzlichen Platz.

Schlechtes Comeback. Niemand, der sich für die neueste Toolchain einsetzt, „schikaniert“ Sie. Das Festhalten an der neuesten Toolchain (wiederum aus gutem Grund) ist objektiv die bessere Richtlinie, insbesondere wenn das einzige Argument dagegen ist, dass sie etwas größere Binärdateien erzeugt (wir entwickeln nicht für irgendeine eingebettete Plattform). Darüber hinaus ist es keine gute Richtlinie, eine Veröffentlichung mit einer Toolchain zu erstellen, die sich von der einen CI unterscheidet, die die meisten Benutzer und Mitwirkenden in den letzten _Monaten_ verwendet haben. Und um das Ganze abzurunden, gibt es wahrscheinlich eine relativ einfache Lösung für das binäre Aufblähen - bitten Sie Ihre 50-MiB-Freunde, ihre Energie in die Suche nach dem Problem zu investieren, anstatt sich nur über 50 MiB zu beschweren, wenn es sie so sehr stört.

(msvc2017 => msvc2019) kann in einem anderen Thema diskutiert/argumentiert/debattiert werden etc. _WENN_ es notwendig wird

msvc2019 wird für uns viel relevanter, wenn wir auf c++17 umsteigen.

Es wird auch relevanter bei der Umstellung auf Qt 6.0/6.1/6.2, wenn Qt msvc2019 & drop (Windows 7/8/8.1 & 32-Bit-Unterstützung) benötigt (was noch lange nicht implementiert ist, ich weiß).

Entwicklungshosts und -ziele in Qt 6.0

Qt 6.0-Entwicklungshosts

Entwicklungsziele für Qt 6.0

Qt 6.1-Entwicklungshosts

Entwicklungsziele für Qt 6.1

Ich werde nicht weiter über Compiler streiten. Ich stimme Ihnen nicht speziell für qbt zu. msvc2019 wird für uns viel relevanter, wenn wir auf c++17 umsteigen.

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

KÖNNEN WIR ALLE EINMAL DAS HIER EINMAL EINMAL FÜR EIN WEITERES MAL PARKEN?

Lassen Sie uns 4.2.x/4.3.x aus der Tür bringen!

(msvc2017 => msvc2019) kann in einem anderen Thema diskutiert/argumentiert/debattiert werden usw., WENN es notwendig wird

KÖNNEN WIR ALLE EINMAL DAS HIER EINMAL EINMAL FÜR EIN WEITERES MAL PARKEN?

Lassen Sie uns 4.2.x/4.3.x aus der Tür bringen!

Sehen Sie, ich möchte das genauso gerne hinter uns bringen wie alle anderen, aber zumindest ist es offen gesagt unverantwortlich, die Toolchain in letzter Minute für die Veröffentlichung zu ändern, wenn alle anderen, einschließlich Ihnen, MSVC 2019 für die verwendet und getestet haben letzte Monate_. Aus dieser Sicht betrachtet ist es meiner Meinung nach sehr „notwendig“, MSVC 2019 für diese Version zu verwenden.

Persönlich habe ich viel Haut in diesem Spiel: Wenn irgendetwas schief geht, werde ich es sein, der sich mit den meisten Fehlerberichten des Typs „Der Nightly/CI-Build hat gut funktioniert, aber die Veröffentlichung nicht“ usw. Und ja, ich weiß, dass ich mich damit nicht auseinandersetzen „muss“. Aber ich möchte nicht, dass das Projekt nach einer Veröffentlichung aus einem vermeidbaren Grund mit neuen Problemen überschwemmt wird. Es ist schon schlimm genug, dass die Veröffentlichung nicht mit Bibliotheken erfolgen wird, die auf die gleiche oder ähnliche Weise wie das CI kompiliert wurden.

Es verblüfft mich, wie all dies, einschließlich der Zeit und Mühe, die ich in das Projekt stecke, und die Verwaltung des Issue-Trackers nicht wichtiger ist als jemand, der über 50 MiB besessen ist. Wer sind diese Leute überhaupt? Was haben sie für das Projekt getan?

@FranciscoPombal Ich werde hier keine weitere Compiler-Diskussion führen. Mein Wort ist endgültig. Die Freigaben erfolgen mit msvc2017.

Wenn ich mich richtig erinnere, unterstützt nur Qt 5.15 "offiziell" msvc2019. Sie haben dort ci auf msvc2019 erst mit Qt 5.15 ausgeführt
und er kann sowieso nicht mit qt 5.15 veröffentlichen wegen der zuvor erwähnten Fehler.

Sehen Sie, ich möchte das genauso gerne hinter uns bringen wie alle anderen, aber zumindest ist es offen gesagt unverantwortlich, die Toolchain in letzter Minute für die Veröffentlichung zu ändern, wenn alle anderen, einschließlich Ihnen, MSVC 2019 für die verwendet und getestet haben letzte Monate. Aus dieser Sicht betrachtet ist es meiner Meinung nach sehr „notwendig“, MSVC 2019 für diese Version zu verwenden.

MSVC 2017-Builds sind im gesamten 4.2.x-Release-Zyklus kampferprobt und es gibt sowieso nicht viel Neues in msvc 2019 und msvc 2017 hat immer noch den Mainstream-Release-Zyklus. Ich kann nicht verstehen, warum Sie so besessen von "Neuesten und Besten" sind. .

@ xavier2k6

Nehmen wir außerdem an, wir lösen das zusätzliche 50-MiB-„Problem“ nicht vor der nächsten „großen“ Veröffentlichung. Werden wir dann alle dieselbe Diskussion führen? Werden wir deswegen das Upgrade auf Qt 6 aufschieben? Was ist/ist wichtiger als 50 MiB? Wir kehren das Problem nur unter den Teppich, es ist ein schlechter Präzedenzfall.

Hinweis: Ich kann fast garantieren, dass das Upgrade auf Qt6 aufgrund der Meinungen, die ich im Laufe der Zeit von anderen gesehen habe, viel länger als angemessen verschoben wird, aus all diesen 3 Gründen und möglicherweise mehr, in keiner bestimmten Reihenfolge: extra 50 MiBs Installer-Größe, um die Unterstützung für Windows 7 aufrechtzuerhalten und die Unterstützung für 32-Bit-Builds aufrechtzuerhalten.

@jagannatharjun Qt 5.15.1 lässt sich problemlos mit msvc2017 erstellen. Die einzigen verknüpften Probleme beziehen sich auf das Schließen des Kontextmenüs bei der Auswahl von Tags. IMO, das ist kein Blocker. Qt 5.15 bringt jedoch eine viel bessere HiDPI-Unterstützung.

@FranciscoPombal Ich kann verstehen, woher du kommst und deine Arbeit hier wird sehr geschätzt!

Die Punkte, die Sie machen, sind relevant, aber leider glaube ich nicht, dass der aktuelle Zeitrahmen für die Veröffentlichung der "neuen Version" diese Diskussion zulässt ... (zu diesem Zeitpunkt)

Ich kann nicht verstehen, warum Sie so besessen von "Neuesten und Größten" sind.

Objektiv überlegene Politiken sind keine „Obsessionen“. Ich schätze, man könnte sagen, dass ich besessen davon bin, anderen dummen Obsessionen nicht nachzugeben. Aber tu mir einen Gefallen und hör auf, das auf mich zu projizieren, ja? Es stärkt Ihren Standpunkt nicht.

Sie denken ernsthaft darüber nach, ein angemessenes Tempo bei Upgrades/Modernisierungen als "Besessenheit" einzuhalten und nicht wichtiger als 50 MiB im Installationsprogramm zu sein. Jesus scheiße.

@jagannatharjun Qt 5.15.1 lässt sich problemlos mit msvc2017 erstellen. Die einzigen verknüpften Probleme beziehen sich auf das Schließen des Kontextmenüs bei der Auswahl von Tags. IMO, das ist kein Blocker. Qt 5.15 bringt jedoch eine viel bessere HiDPI-Unterstützung.

Ich stimme zu, der Fehler mit den Kontextmenü-Tags ist unglücklich, aber die HiDPI-Fehler sind viel schwerwiegender und produzieren im Laufe der Zeit viel mehr Berichte.

@FranciscoPombal Ich kann verstehen, woher du kommst und deine Arbeit hier wird sehr geschätzt!

Guter Witz.

Die Punkte, die Sie machen, sind relevant, aber leider glaube ich nicht, dass der aktuelle Zeitrahmen für die Veröffentlichung der "neuen Version" diese Diskussion zulässt ... (zu diesem Zeitpunkt)

Ich sehe, ich kann nicht anders. Nun ja.

@FranciscoPombal Ich kann verstehen, woher du kommst und deine Arbeit hier wird sehr geschätzt!

Guter Witz.

@FranciscoPombal Im Ernst?? - Das war kein Scherz & ich war/bin persönlich aufrichtig!!!

Die Punkte, die Sie machen, sind relevant, aber leider glaube ich nicht, dass der aktuelle Zeitrahmen für die Veröffentlichung der "neuen Version" diese Diskussion zulässt ... (zu diesem Zeitpunkt)

Ich sehe, ich kann nicht anders. Nun ja.

Nimm dir diese Situation nicht persönlich/zu Herzen......ok
........atme durch
lassen Sie einen Teil Ihrer harten Arbeit im Projekt über das neue Release zumindest der "Mainstrem-Öffentlichkeit" zukommen. (da es derzeit nur von Leuten wie mir gesehen werden kann, die hierher kommen und teilnehmen / beitragen / bauen usw

Ich habe gerade einen staging_v4_3_x -Zweig geschoben. Es ist im Grunde ein Meister mit einem aktualisierten Änderungsprotokoll.
Bitte werfen Sie einen Blick auf das Änderungsprotokoll und sagen Sie mir, wenn etwas nicht stimmt oder ich etwas übersehen habe.
@glasez

1. Verfügt #13234 über benutzerorientierte Attribute? Etwas, das im Changelog stehen sollte? zB "Ladegeschwindigkeit von Sessions mit Hunderten von Torrents verbessern".
2. Was ist der Zweck von #13395. Was tut es? Soll ich etwas in das Changelog aufnehmen?

In Kürze werde ich auf Probleme eingehen, die in diesem Thread erwähnt werden und dazu führen können, dass einige Commits nicht für die Veröffentlichung enthalten sind. Ich werde dich auf dem Laufenden halten.

@ Vorschlaghammer999

Bitte bereinigen Sie dabei auch die PPA. Andere Ubuntu-Releases als 18.04 , 20.04 und 20.10 sind EOL, daher sollten Archive für Builds, die auf diese Versionen abzielen, so schnell wie möglich entfernt werden.

Ubuntu 14.04 und 16.04 sind kein EOL. Woher hast du diese Liste?
https://wiki.ubuntu.com/Releases

@sledgehammer999 Anscheinend hast du https://github.com/qbittorrent/qBittorrent/pull/13188 für das Änderungsprotokoll verpasst

Können Sie auch eine Notiz im Änderungsprotokoll hinzufügen, dass
„Die vorherigen Theme-Bundles funktionieren mit dieser Version aufgrund von Änderungen im Format der Bundle-Dateien nicht richtig. Bitte wenden Sie sich an den Theme-Anbieter, um eine Lösung zu erhalten. Mehr über das neue Format können Sie hier lesen https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes " oder so ähnlich.
Eigentlich liegt das an https://github.com/qbittorrent/qBittorrent/pull/12755/files

Ich denke, es sollte erwähnt werden, dass die Unterstützung für RC1_1 libtorrent eingestellt wurde.

Auch wenn jemand eine schnellere Tracker-Ankündigungsrate wünscht oder einen langsameren Client-Exit (im Vergleich zu 4.2.x) mit dieser Version hat, kann er versuchen, das Limit „Max. gleichzeitige HTTP-Ankündigung“ in den erweiterten Einstellungen zu erhöhen.

Verfügt #13234 über benutzerorientierte Attribute? Etwas, das im Changelog stehen sollte? zB "Ladegeschwindigkeit von Sessions mit Hunderten von Torrents verbessern".

Es tut mir leid, ich erinnere mich nicht an alles ... es war hauptsächlich eine interne Verbesserung. Vielleicht passt der nächste Teil der PR-Beschreibung zu "benutzerorientierten Attributen":

Es ermöglicht unter bestimmten Umständen das korrekte Speichern von Lebenslaufdaten, z. B. im Status „Fehlende Dateien“ (obwohl wir versucht haben, dies früher zu verhindern, könnte der Benutzer dies tatsächlich tun, wenn er z. B. eine Eigenschaft eines solchen Torrents ändert).

Was ist der Zweck von #13395. Was tut es? Soll ich etwas in das Changelog aufnehmen?

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

Ich denke, es sollte erwähnt werden, dass die Unterstützung für RC1_1 libtorrent eingestellt wurde

👍

FUNKTION: Unterstützung für das Erstellen von v2-Torrents hinzugefügt (erfordert libtorrent 2.0.x) (Chocobo1)

Verdammt! Unterstützt qBittorrent bereits libtorrent-2.0? Warum es so erwähnen, wie es ist? Wir haben bereits darüber gesprochen.

Können Sie auch eine Notiz im Änderungsprotokoll hinzufügen, dass
„Die vorherigen Theme-Bundles funktionieren mit dieser Version aufgrund von Änderungen im Format der Bundle-Dateien nicht richtig. Bitte wenden Sie sich an den Theme-Anbieter, um eine Lösung zu erhalten. Mehr über das neue Format können Sie hier lesen https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes " oder so ähnlich.
Eigentlich liegt das an https://github.com/qbittorrent/qBittorrent/pull/12755/files

Ich denke, ich werde dies zum Abschnitt "Neuigkeiten" der Website hinzufügen. Außerhalb der Änderungen, im Einführungstext.

Ich denke, es sollte erwähnt werden, dass die Unterstützung für RC1_1 libtorrent eingestellt wurde.

OK.

Auch wenn jemand eine schnellere Tracker-Ankündigungsrate wünscht oder einen langsameren Client-Exit (im Vergleich zu 4.2.x) mit dieser Version hat, kann er versuchen, das Limit „Max. gleichzeitige HTTP-Ankündigung“ in den erweiterten Einstellungen zu erhöhen.

Sollte dies im Changelog als Item erwähnt werden?

Verdammt! Unterstützt qBittorrent bereits libtorrent-2.0? Warum es so erwähnen, wie es ist? Wir haben bereits darüber gesprochen.

Dann werde ich dieses Element unter v4.4.0 Release-Eintrag verschieben (nicht Teil des v4.3.0-Änderungsprotokolls). Es sei denn, die offizielle libtorrent-2.0-Unterstützung wird früher eingeführt. Ist das zufriedenstellend?

Hier ist das aktualisierte Änderungsprotokoll: https://github.com/qbittorrent/qBittorrent/commit/0302e8abbc545d13b7be51e011d2795a9bb3ea73

Sollte dies im Changelog als Item erwähnt werden?

Ich denke, es ist besser, wenn es als News gepostet wird. Da Benutzer mit Tausenden von Torrents/vielen Trackern pro Torrent das langsame Ankündigungsverhalten bemerken können.

Erneut aktualisiert: https://github.com/qbittorrent/qBittorrent/commit/727dec97540091f891991113299fa38468e13885

Ankündigung: Es ist mit einer sehr geringen Verzögerung zu rechnen. Ich muss wegen eines Sicherheitsproblems, das mir per E-Mail mitgeteilt wurde, eine teilweise Neukompilierung der Toolchain durchführen. Die Details werden einige Tage nach der Veröffentlichung zur Verfügung gestellt. IMO, der Schweregrad ist wahrscheinlich gering, da der Exploit erfordert, dass jemand böswillig lokalen Zugriff hat oder bereits eine bösartige Anwendung auf Ihrem System ausführt. In beiden Fällen ist man auch ohne das Sicherheitsproblem von qbt bereits aufgeschmissen.

Ubuntu 14.04 und 16.04 sind kein EOL. Woher hast du diese Liste?

Wahrscheinlich falsche Formulierung. Es ist EOL für uns, weil ihre Qt-Version weniger als unsere Mindestanforderung ist.

OK. Ich denke, jetzt ist alles eingestellt, und ich bereite Builds vor. Der Zweig v4_3_x wird zusammen mit den Builds gepusht.

@sledgehammer999 Entschuldigung für den späten Kommentar, aber denken Sie bitte daran, (im News-Bereich der Website) zu erwähnen, dass es seit der letzten Version viele libtorrent-Korrekturen gab, die in dieser vorhanden sind, einschließlich bekannter Speicherlecks, Geschwindigkeitsprobleme aufgrund von fehlerhafte Cache-Einstellungslogik unter Windows usw. Sie können einen Blick auf libtorrents 1.2.6-1.2.11 werfen (1.2.11 ist immer noch nicht offiziell veröffentlicht, hat aber bereits einige Changelog-Einträge), um sich inspirieren zu lassen und die relevantesten Einträge herauszusuchen.

Aus Neugier, welches libtorrent-Commit wird verwendet?

OK, und neuster Git-Commit wie immer.

@rrrevin

Ubuntu 14.04 und 16.04 sind kein EOL. Woher hast du diese Liste?
https://wiki.ubuntu.com/Releases

Wahrscheinlich falsche Formulierung. Es ist EOL für uns, weil ihre Qt-Version weniger als unsere Mindestanforderung ist.

Nun, ich meinte wirklich "End of Standard Support", denke ich, was sowieso wirklich zählt. Darüber hinaus erhalten nur zahlende Unternehmen Unterstützung. 16.04 ist technisch gesehen noch nicht einmal am "Ende des Standard-Supports", aber es ist sehr nah dran. Und unabhängig davon wurde die OOTB-Unterstützung dafür vor ungefähr 2 Jahren eingestellt, weil qBittorrent die mindestens erforderliche Qt-Version auf 5.9 erhöht hat.

@sledgehammer999 Noch eine Kleinigkeit: Erwägen Sie, die kleinere Regression des bekannten Tag-Kontextmenüs in den Nachrichten zu erwähnen: https://github.com/qbittorrent/qBittorrent/issues/13492.

@sledgehammer999 Sie haben viele meiner PRs im Änderungsprotokoll nicht gutgeschrieben ... https://github.com/qbittorrent/qBittorrent/pulls?q=is%3Apr+author%3AFranciscoPombal+is%3Aclosed+milestone%3A4.3.0

@FranciscoPombal Ich habe alle Ihre CMake-PRs in einem Eintrag zusammengefasst. Ihre internen Code-Bereinigungs-PRs können nicht im Änderungsprotokoll erwähnt werden. Es sollte benutzerseitige Korrekturen enthalten. Dasselbe gilt für die vielen PRs von @Chocobo1
Wenn ich etwas Bestimmtes übersehen habe, erwähne es bitte unten. Ich werde einen Moment warten, da ich immer noch administrative Aufgaben hinter den Kulissen erledige.

@ Vorschlaghammer999

Es sollte benutzerseitige Korrekturen enthalten.

OK, also:

• --> https://github.com/qbittorrent/qBittorrent/pull/13042 ist benutzerorientiert, da es einen Ankündigungsfehler im eingebetteten Tracker behebt. <--

• https://github.com/qbittorrent/qBittorrent/pull/12086 , https://github.com/qbittorrent/qBittorrent/pull/13109 und https://github.com/qbittorrent/qBittorrent/pull/13439 sind keine benutzerseitige Bereinigungen, also denke ich, dass das in Ordnung ist.

• https://github.com/qbittorrent/qBittorrent/pull/13288 ist irgendwie benutzerorientiert, denke ich? Jetzt können Benutzer experimentelle Builds von CI herunterladen, gilt das als benutzerorientiert?

• Die restlichen sind entweder bereits gutgeschrieben, beziehen sich auf die CMake-Verbesserungen (auch bereits gutgeschrieben) oder beziehen sich auf https://github.com/qbittorrent/qBittorrent/pull/13288.

/offtopic (für ein anderes Mal) - Vielleicht sollten die nicht benutzerorientierten Bereinigungen in "OTHER" oder vielleicht in einen neuen Abschnitt "CODE HEALTH" aufgenommen werden? Benutzer sehen solche Dinge gerne im Änderungsprotokoll.

--> #13042 ist benutzerorientiert, da es einen Ankündigungsfehler im eingebetteten Tracker behebt. <--

Ok, tut mir Leid. Aus dem Commit-Titel ging das nicht hervor. Können Sie einen geeigneten Changelog-Eintrag vorschlagen (für Benutzer, die ihn lesen)?

Die CI-Änderungen sind normalerweise für Releases irrelevant.

/offtopic (für ein anderes Mal) - Vielleicht sollten die nicht benutzerorientierten Bereinigungen in "OTHER" oder vielleicht in einen neuen Abschnitt "CODE HEALTH" aufgenommen werden? Benutzer sehen solche Dinge gerne im Änderungsprotokoll.

Hmm, ich füge einen OTHER -Eintrag für Code-Bereinigungen hinzu, der sowohl dir als auch @Chocobo1 gutschreibt

13288 ist irgendwie benutzerorientiert, denke ich? Jetzt können Benutzer experimentelle Builds von CI herunterladen, gilt das als benutzerorientiert?

IMO, so etwas kann stattdessen in News erwähnt werden (außerhalb des Änderungsprotokolls).

IMO, so etwas kann stattdessen in News erwähnt werden (außerhalb des Änderungsprotokolls).

Ich könnte irgendwie einen "Nightlies"-Link in die Download-Seite stopfen ...

~@glassez~ @sledgehammer999

IMO, so etwas kann stattdessen in News erwähnt werden (außerhalb des Änderungsprotokolls).

Ich könnte irgendwie einen "Nightlies"-Link in die Download-Seite stopfen ...

Erwähnen Sie einfach das CI-Zeug in den Nachrichten, ich würde zögern, die "nächtliche" Download-Seite einem breiteren Publikum zu verlinken, bevor wir eine Git-basierte Versionierung in den ausführbaren Dateien haben. Andernfalls melden alle Benutzer alle verschiedenen Nightly-Versionen als "4.x.xalpha1", was zu Verwirrung führt.

git-basierte Versionierung in den ausführbaren Dateien. Andernfalls melden alle Benutzer alle verschiedenen Nightly-Versionen als "4.x.xalpha1", was zu Verwirrung führt.

Ja, das ist eine richtige Bemerkung.

@ Vorschlaghammer999

Können Sie einen geeigneten Changelog-Eintrag vorschlagen (für Benutzer, die ihn lesen)?

"Fehlerhafte Ankündigungslogik im eingebetteten Tracker behoben, die in einigen Fällen zu Fehlern führte."

CI-Builds könnten auch für böswillige Zwecke verwendet werden. Durch das Erstellen von böswilliger PR und das spätere Verteilen von Links.
Ich würde empfehlen, so etwas nicht auf der Website zu verlinken.

@an0n666

CI-Builds könnten auch für böswillige Zwecke verwendet werden. Durch das Erstellen von böswilliger PR und das spätere Verteilen von Links.
Ich würde empfehlen, so etwas nicht auf der Website zu verlinken.

Das ist auch ein guter Punkt. Ich schätze, ich sollte besser anfangen, an dem Workflow zu arbeiten, der speziell für nächtliche Builds entwickelt wird, die nur aus dem Master erstellt werden, über den ich zuvor gesprochen habe. Dann werden wir in der Lage sein, uns mit nächtlichen Builds zu verlinken, ohne befürchten zu müssen, dass so etwas passiert.

Die Freigabe erfolgt.
PPA wird morgen aufgeräumt.
Details zu Sicherheitsproblemen in ein paar Tagen.
Organisatorische Veränderungen planen in wenigen Tagen.

Und wie immer ein Dankeschön an alle für ihre Beiträge in diesem Veröffentlichungszyklus.