@sledgehammer999 Anda harus membaca ini => https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions/5

Untungnya tidak terkena virus (dan saya harap saya tetap seperti itu).

Saya senang untuk Anda secara pribadi.

Tapi saya sangat sedih dengan keadaan proyek saat ini (dan saya bukan satu-satunya yang merasakan hal yang sama). Waktu untuk perubahan sangat penting. Jadi Anda harus merestrukturisasi manajemen/pemeliharaan proyek, atau secara eksplisit menyatakan bahwa itu hanya mainan pribadi Anda, sehingga tidak ada orang lain yang memiliki harapan palsu.

Apakah ada komitmen yang harus dikecualikan?

Saya tidak berpikir masuk akal untuk melewatkan perubahan apa pun sekarang.

Bagaimanapun, rilis baru sudah lama tertunda.

Terlalu banyak.

Haruskah saya, seperti biasa, mem-backport semua komit master baru ke cabang v4_2_x?

Mengapa v4.2.x? Ada lebih dari cukup perubahan untuk v4.3!
Selain itu, Anda cukup membuat cabang v4_3_x di atas master saat ini, alih-alih melakukan pekerjaan yang tidak perlu ini dengan "memilih ceri" dari komit satu per satu.

Saya baru saja selesai melihat komit dari rilis sebelumnya hingga master terbaru. (komit judul dan deskripsi PR sebagian besar)

Mengapa v4.2.x? Ada lebih dari cukup perubahan untuk v4.3!

Ya. Ada banyak sekali komitmen. Dan karena libtorrent 1.1.x dijatuhkan, itu pasti menjamin v4.3.x. (Dan v4.4.x untuk libtorrent 2.0.x dan c++17!!!)
Saya akan membuat PR baru untuk changelog yang akan datang, sesegera mungkin.

Tentang manajemen proyek: Kami akan membahas ini setelah rilis akhir pekan / mendatang.

@sledgehammer999

Senang Anda kembali dan semuanya baik-baik saja.

Haruskah saya, seperti biasa, mem-backport semua komit master baru ke cabang v4_2_x? Apakah ada komitmen yang harus dikecualikan?

Saya tidak peduli dengan usulan pelabelan versi baru 4.3.x. Terserah Anda dan orang lain untuk memutuskan.

Semua komit adalah AFAIK yang baik. Namun, banyak perbaikan yang sangat penting telah digabungkan ke libtorrent juga, jadi penting untuk menggunakan RC_1_2 terbaru yang mungkin untuk rilis baru ini.

Sudah ada beberapa komitmen terkait dukungan BitTorrent V2. Namun, saya berharap rilis ini dibuat dengan libtorrent RC_1_2 terbaru seperti yang disebutkan di atas, sehingga sebagian besar pengguna tidak akan melihatnya dalam praktik. Jadi, saya akan memberikan catatan di changelog yang menjelaskan hal ini, sehingga pengguna tidak mendapatkan harapan palsu ketika mereka membaca entri terkait BitTorrent V2.

Saya telah memperbarui rantai alat lokal saya. Pengujian backporting/changelog/minimal akan memakan waktu. Tapi saya pikir akhir pekan ini adalah target yang layak tergantung pada ukuran perubahan.

Bisakah Anda memberikan detail tentang ini? Saya berasumsi Anda memiliki MSVC 2019 terbaru dan saya _berharap_ Anda menggunakan vcpkg atau serupa untuk dependensi - lebih sedikit kemungkinan bug aneh karena sedikit perbedaan dalam cara semuanya dibangun dan lebih banyak reproduktifitas. Anda dapat memeriksa GitHub Actions CI baru untuk mendapatkan inspirasi. Harap ingat juga untuk menggunakan CMake untuk membangun kali ini, ini telah menjadi sistem pembangunan default baru.

Tentang manajemen proyek: Kami akan membahas ini setelah rilis akhir pekan / mendatang.

Oke, tapi tolong lebih cepat daripada nanti. Dan kita harus melanjutkan pembahasan tentang otomatisasi proses rilis lebih lanjut, sehingga pengemasan pun bisa dilakukan secara otomatis.

@sledgehammer999

Juga, harap bersihkan PPA dalam prosesnya. Rilis Ubuntu selain 18.04 , 20.04 dan 20.10 adalah EOL, jadi arsip untuk build yang menargetkan versi tersebut harus dihapus secepatnya.

jadi penting untuk menggunakan RC_1_2 terbaru yang mungkin untuk rilis baru ini.

Ini tidak perlu dikatakan.
Qt 15.1, membuka SL 1.1.1h, meningkatkan 1.74

RC_2_0 belum akan digunakan. Bukan tanpa beberapa rilis beta resmi.

Saya berasumsi Anda memiliki MSVC 2019 terbaru dan saya harap Anda menggunakan vcpkg

Tidak, saya masih menggunakan msvc2017 untuk rilis ini. Terakhir kali saya memeriksa msvc2019 itu menghasilkan file .pdb yang sangat besar untuk qbt. Saya akan memeriksanya lagi nanti tetapi tidak untuk rilis ini.
Ketergantungan lainnya dibangun dengan cara yang selalu saya lakukan. Kurang lebih dijelaskan di sini: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (static-linkage)

Harap ingat juga untuk menggunakan CMake untuk membangun kali ini, ini telah menjadi sistem bawaan yang baru .

Rupanya saya melewatkan ini di git log. Saya agak kecewa tetapi saya tidak bisa menolaknya karena semua orang lain merasa lebih nyaman menggunakan cmake daripada autotools/qmake.
Namun, untuk saat ini saya akan terus menggunakan autotools/qmake untuk rilis. Saya tidak punya waktu untuk membiasakan diri dengan cmake untuk rilis.

Saya akan melihat apa yang harus dilakukan tentang PPA, meskipun mereka tidak merugikan siapa pun.

@sledgehammer999 Saya tahu Anda tidak ingin pengguna normal berkomentar di sini, jadi maaf ...... Saya telah membuat windows build di sini untuk tujuan mengatasi masalah/bug dll.

Saya kompilasi dengan MSVC 2019 & executable qBittorrent biasanya sekitar 27 MB & .pdb adalah 180 MB

Pernahkah Anda berpikir untuk menggunakan /pdbstripped ?

Saya kompilasi dengan MSVC 2019 & executable qBittorrent biasanya sekitar 27 MB & .pdb adalah 180 MB

Bandingkan dengan msvc2017 dan master saat ini: 24.4MB exe dan 98.1MB pdb. Seperti yang saya katakan pdb sangat besar dibandingkan dengan msvc2017.

Saya juga tidak berpikir kita ingin /pdbstripped. Ini mungkin akan memberikan jejak balik yang kurang berguna ketika program macet.

Saya juga tidak berpikir kita ingin /pdbstripped. Ini mungkin akan memberikan jejak balik yang kurang berguna ketika program macet.

/PDBCompress ?

@sledgehammer999

Pembuatan CI otomatis, yang menggunakan CMake + MSVC 2019 + vcpkg terbaru (https://github.com/qbittorrent/qBittorrent/actions) berada di 57 MiB (dapat dieksekusi) + 122 MiB (pdb).

Tidak, saya masih menggunakan msvc2017 untuk rilis ini. Terakhir kali saya memeriksa msvc2019 itu menghasilkan file .pdb yang sangat besar untuk qbt. Saya akan memeriksanya lagi nanti tetapi tidak untuk rilis ini.

Ini bukan alasan yang baik IMO. MSVC 2019 berisi banyak perbaikan. Ini (akhir) 2020. Tidak ada yang peduli dengan ukuran instalasi ekstra \~50 MiB (dan jika ya, sayang sekali lol). Kita dapat mengetahuinya nanti jika ada sesuatu yang membuat pdb/executable membengkak, tetapi untuk saat ini semuanya berfungsi dan tambahan \~50 MiB adalah tradeoff yang akan saya lakukan setiap hari dalam seminggu untuk toolchain yang jauh lebih baru.

Saya juga tidak berpikir kita ingin /pdbstripped. Ini mungkin akan memberikan jejak balik yang kurang berguna ketika program macet.

:+1:, tetapi ini dapat diselidiki dengan baik di masa mendatang.

Ketergantungan lainnya dibangun dengan cara yang selalu saya lakukan. Kurang lebih dijelaskan di sini: https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (static-linkage)

Rupanya saya melewatkan ini di git log. Saya agak kecewa tetapi saya tidak bisa menolaknya karena semua orang lain merasa lebih nyaman menggunakan cmake daripada autotools/qmake.
Namun, untuk saat ini saya akan terus menggunakan autotools/qmake untuk rilis. Saya tidak punya waktu untuk membiasakan diri dengan cmake untuk rilis.

:-1:, ini bukan cara kebanyakan orang menguji qBittorrent selama beberapa bulan terakhir di Windows. Banyak orang menggunakan build dari cabang CI saya (CMake + vcpkg), dan sekarang bagian Tindakan repo itu sendiri. Saya akan mengatakan bahwa kemungkinan besar kita akan mengamati regresi yang tidak dapat dijelaskan hanya yang berasal dari perbedaan dalam proses pembuatan jika Anda melakukan ini.

@sledgehammer999 Saya tidak ingin menambahkan "pemblokir" lagi sebelum rilis, tetapi setidaknya saya akan menunggu ini mendarat, karena pada dasarnya sudah siap: https://github.com/qbittorrent/qBittorrent/pull/13499

Perubahan default untuk utas I/O asinkron akan bermanfaat bagi banyak pengguna.

Saya tidak ingin mengabaikan msvc2019 tetapi saya pikir Anda sedikit berlebihan dalam mempertimbangkan segala sesuatu yang baru sebagai lebih baik. Hal ini tidak selalu terjadi. Dan ya ekstra 50MB untuk klien bt adalah masalah besar. Itu tidak perlu mengasapi tanpa manfaat yang terukur (misalnya program tidak menjadi 1,5x lebih cepat).

Terakhir tentang sistem build: Jika kita melihat regresi hanya dari perubahan sistem build, maka ada yang salah dengan kodenya. Barang seharusnya tidak begitu rapuh.

13499 berada di luar cakupan karena ini tentang opsi libtorrent 2.0.x yang belum menjadi default. Terakhir, pemotongan akan dilakukan pada akhir pekan.

@sledgehammer999

Saya tidak ingin mengabaikan msvc2019 tetapi saya pikir Anda sedikit berlebihan dalam mempertimbangkan segala sesuatu yang baru sebagai lebih baik. Hal ini tidak selalu terjadi.
Dan ya ekstra 50MB untuk klien bt adalah masalah besar. Itu tidak perlu mengasapi tanpa manfaat yang terukur (misalnya program tidak menjadi 1,5x lebih cepat).

Tolong jangan hanya mengabaikan argumen saya sebagai "baru = lebih baik". Dan saya pikir Anda sedikit "berlebihan" dengan berpegang pada toolchain yang lebih buruk untuk 50 MiB. Tentu saja Anda tidak pernah (atau sangat jarang) melihat kecepatan "1,5x" dari memperbarui rantai alat Anda. Tapi itu adalah bar yang tidak realistis untuk ditetapkan. Dengan rantai alat yang lebih baru, mungkin tidak ada kecepatan "1,5x", tetapi selalu ada peningkatan kinerja kecil, dukungan bahasa yang lebih baik, gen kode yang lebih baik (terkadang menyebabkan lebih sedikit bug), ... Ada banyak sumber daya online yang mendokumentasikan perbaikan di MSVC 2019.

Sekali lagi, saya setuju bahwa kita harus mencukur ekstra 50 MiB jika memungkinkan, tetapi maksud saya adalah jika kita tidak dapat melakukannya tepat waktu untuk rilis berikutnya (atau selamanya!), _tidak apa-apa_. Juga, tidak ada implikasi bahwa ini akan terus terjadi dengan setiap rilis sekali lagi (saya juga akan kesal dalam kasus itu). Ini jelas merupakan masalah sekali saja. Sebagai pengguna, saya tidak ingin mendengar "ini biner kualitas buruk Anda, tapi setidaknya kami menyelamatkan Anda 50 MiB, bro". 50 MiB adalah kesalahan pembulatan saat ini (untuk program desktop, tentu saja di dunia tertanam dan ini tidak terjadi). Maaf, tapi Anda salah jika Anda berpikir sebaliknya.

Terakhir tentang sistem build: Jika kita melihat regresi hanya dari perubahan sistem build, maka ada yang salah dengan kodenya. Barang seharusnya tidak begitu rapuh.

Belum tentu. Ada yang salah dengan sistem build itu sendiri. Lihat status buildsystem CMake sebelumnya, sebelum saya merombak PR. Sebelum itu, membangun dengan CMake menyebabkan beberapa bug. Beberapa masalah (terkadang serius!) benar-benar berasal dari sistem build yang salah/buruk dan resep build. Tidak peduli seberapa kuat kode Anda, jika Anda salah membuatnya, kode itu akan rusak, terkadang dengan cara yang sangat spektakuler tetapi sulit didiagnosis.

13499 berada di luar cakupan karena ini tentang opsi libtorrent 2.0.x yang belum menjadi default. Terakhir, pemotongan akan dilakukan pada akhir pekan.

Silakan lihat sisa diskusi. PR itu juga sebenarnya mengubah jumlah default utas I/O asinkron, sehingga secara default, setidaknya 2 utas hashing digunakan saat membangun terhadap libtorrent 1.2.x juga. Ini menghasilkan peningkatan kinerja yang sangat signifikan bagi pengguna SSD (lebih dari 1,5x, sebenarnya, heh) sambil memberikan keuntungan yang sangat kecil bagi pengguna HDD juga.

@sledgehammer999

Berikut beberapa bantuan untuk Anda mulai:

• tutorial baru untuk membangun dengan CMake secara statis di Windows: https://github.com/qbittorrent/qBittorrent/wiki/Compilation :-Windows-(MSVC-2019,-64-bit,-static-linkage)
• daftar opsi + tutorial/intro CMake singkat: https://github.com/qbittorrent/qBittorrent/wiki/Compilation-with-CMake :-common-information

Jika Anda tidak menggunakan vcpkg, atau jika Anda menggunakan vcpkg untuk beberapa paket tetapi tidak yang lain, Anda hanya perlu memberikan petunjuk tambahan yang memberi tahu CMake di mana menemukan file konfigurasi untuk paket, seperti -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar . Jika ragu, Anda dapat menjalankan konfigurasi sampai berhasil, memperbaiki setiap pesan kesalahan tentang setiap paket satu per satu saat muncul, karena pesan kesalahan cukup membantu sehingga Anda selalu dapat memahami dan mencari tahu apa yang perlu Anda tambahkan Berikutnya.

Saya tidak akan berdebat lebih jauh tentang compiler. Saya tidak setuju dengan Anda secara khusus untuk qbt. msvc2019 akan menjadi jauh lebih relevan bagi kami setelah kami beralih ke c++17. Terakhir, untuk pengguna klien bt yang dia pedulikan adalah apakah klien dapat mencapai kecepatan top down/up. Itu adalah metrik untuk biner kualitas "lebih baik" atau "lebih buruk". msvc2017 mencapai itu tanpa mengasapi ekstra. --Saya memegang penilaian saya sampai saya mengulang bangunan saya dengan msvc2019--

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

Apakah ada bedanya bagaimana sebuah paket dibuat/diinstal? Saat ini saya tidak memiliki folder cmake di bawah lib untuk boost, libtorrent, openssl. Hanya untuk qt.
PS: boost dan libtorrent dibangun menggunakan b2. Openssl menggunakan skrip konfigurasi mereka.

@sledgehammer999

Satu-satunya persyaratan adalah Anda membangun libtorrent dengan CMake, IIRC. Semua paket lain menghasilkan file konfigurasi yang diperlukan secara default atau didukung oleh CMake dalam beberapa cara:

• libtorrent harus dibangun dengan CMake agar file yang sesuai dapat dihasilkan. Ini secara khusus tercakup dalam tutorial Wiki.
• CMake secara native mendukung OpenSSL melalui modul find yang dibundel: https://cmake.org/cmake/help/latest/module/FindOpenSSL.html#hints. Anda hanya perlu mengatur OPENSSL_ROOT_DIR . Contoh: -DOPENSSL_ROOT_DIR=C:\Qt\Tools\OpenSSL\Win_x64
• boost menghasilkan file yang diperlukan secara default. Anda hanya perlu mengatur Boost_DIR Contoh: -DBoost_DIR=C:\path\to\boost_1_73_0\stage\lib\cmake\Boost-1.73.0
• Untuk zlib Anda harus melewati beberapa jalur. Contoh: -DZLIB_INCLUDE_DIR=C:\path\to\zlib-1.2.11\build -DZLIB_LIBRARY=C:\path\to\zlib-1.2.11\build\libzlibstatic.a
• Qt menghasilkan file yang diperlukan, saya berasumsi Anda sudah menemukan flag waktu konfigurasi yang diperlukan untuk menunjuk ke sana.

Sekali lagi, jika Anda kehilangan salah satu dari ini, CMake akan memberi tahu Anda tentang hal itu di langkah konfigurasi, dan akan menyarankan apa yang ingin Anda tambahkan.

Saya setuju dengan palu godam999.
Biner yang lebih kecil selalu lebih baik. Khusus mengingat rekam jejak rilis sebelumnya.
Banyak yang masih memiliki internet yang lambat.. juga situs web yang melayani binari dapat menjadi lambat untuk beberapa pengguna berdasarkan lokasi.
Dalam kasus seperti itu, biner kecil memungkinkan pengunduhan lebih cepat. Orang mungkin berkecil hati untuk memperbarui jika mereka mencurigai bloatware yang tidak perlu.

itu telah menjadi sistem pembangunan default baru.

buildsystem default apa?

itu telah menjadi sistem pembangunan default baru.

buildsystem default apa?

dia bahkan menyatakan qmake/autotools tidak digunakan lagi https://github.com/qbittorrent/qBittorrent/wiki

dia bahkan menyatakan qmake/autotools tidak digunakan lagi https://github.com/qbittorrent/qBittorrent/wiki

Kesewenang-wenangan ini mulai benar-benar membuat marah!

itu telah menjadi sistem pembangunan default baru.
buildsystem default apa?

Kesewenang-wenangan ini mulai benar-benar membuat marah!

Oh wow! Jadi itu bukan keputusan yang sebenarnya! Lagipula aku tidak merasa kacau.

@FranciscoPombal
Tolong jangan mengalihkan perhatian @sledgehammer999 dengan percakapan tidak berguna tentang berbagai alat build, sistem build, dll. Biarkan rilis mendatang dilakukan dengan cara biasa - ini akan lebih cepat dan lebih andal. Kami perlu memiliki waktu untuk menyelesaikan masalah organisasi sehingga kami dapat menjaga proyek tetap berjalan, terlepas dari kenyataan bahwa salah satu anggotanya menghilang untuk waktu yang lama.
Juga tidak masuk akal untuk membahas libtorrent-2.0 dalam konteks rilis yang akan datang (dan seluruh cabang yang akan datang), karena kami tidak memiliki dukungan untuk itu, dan kami bahkan tidak dapat memprediksi kapan itu akan diimplementasikan sepenuhnya.

Ini (akhir) 2020. Tidak ada yang peduli dengan ukuran instalasi ekstra ~50 MiB (dan jika ya, sayang sekali lol).

Dua komputer utama saya berusia 9 dan 12 tahun (walaupun baru-baru ini saya meningkatkannya dengan menginstal SSD sebagai disk sistem). Banyak yang menggunakan perangkat keras yang lebih tua. Bukan karena kami menyukainya. Kami hanya tidak memiliki kapasitas keuangan/lainnya untuk memperbaruinya setiap 2-3 tahun. Jika Anda tidak dapat memahami kami, itu tetap tidak memberi Anda hak untuk mengolok-olok kami.

PS Namun, bahkan 10 tahun yang lalu saya tidak akan terlalu khawatir tentang 50 megabyte ini.

@an0n666 @sledgehammer999 @glassez

Saya setuju dengan palu godam999.
Biner yang lebih kecil selalu lebih baik. Khusus mengingat rekam jejak rilis sebelumnya.
Banyak yang masih memiliki internet yang lambat.. juga situs web yang melayani binari dapat menjadi lambat untuk beberapa pengguna berdasarkan lokasi.
Dalam kasus seperti itu, biner kecil memungkinkan pengunduhan lebih cepat. Orang mungkin berkecil hati untuk memperbarui jika mereka mencurigai bloatware yang tidak perlu.

Ayo sekarang, unduh aplikasi adalah biaya satu kali. Bahkan pada 10 Mb/s, tambahan 50 MiB hanyalah tambahan 50 detik. Jika orang-orang ini terganggu oleh itu, mereka lebih baik datang ke sini dan membantu memperbaiki masalahnya sendiri. Jangan biarkan diri Anda didorong oleh orang-orang obsesif kompulsif yang mengeluh tentang 50 MiB. Mereka ingin beralih kembali ke uT 2.2.1 karena itu? Bagus. Bahkan di Somalia Anda bisa mendapatkan rata-rata 10 Mb/s: https://www.speedtest.net/global-index , dan saya ragu klien BitTorrent adalah perhatian utama sebagian besar orang Somalia asli. Build dilayani dari Fosshub dan Sourceforge, yang sepertinya tidak akan pernah menjadi hambatan kecuali Kim Kardashian memberi tahu semua penggemarnya untuk mengunduh qBittorrent atau semacamnya.

Juga,

Biner yang lebih kecil selalu lebih baik. Khusus mengingat rekam jejak rilis sebelumnya.

Kutipan diperlukan. Di mana korelasi antara "rekam jejak yang lebih baik", dan "ukuran biner yang lebih kecil"? Rekam jejak yang lebih baik dari apa? Pertunjukan? Keandalan?

buildsystem default apa?

dia bahkan menyatakan qmake/autotools tidak digunakan lagi https://github.com/qbittorrent/qBittorrent/wiki

Kesewenang-wenangan ini mulai benar-benar membuat marah!

Oh wow! Jadi itu bukan keputusan yang sebenarnya! Lagipula aku tidak merasa kacau.

Kami setuju bahwa sistem build CMake adalah masa depan. Adalah suatu kesalahan untuk tetap mempertahankan dua sistem build, seperti yang telah saya nyatakan berkali-kali sebelumnya. Ini bahkan disebutkan dalam kontribusi baru-baru ini: https://github.com/qbittorrent/qBittorrent/pull/13509#issuecomment -708072078

Berbicara tentang bloatware: Lihatlah upaya duplikat yang kami miliki karena memelihara 2 sistem pembangunan. Lihatlah beberapa file autotools bloat yang kami miliki di repo.

Tolong jangan mengalihkan perhatian @sledgehammer999 dengan percakapan tidak berguna tentang berbagai alat build, sistem build, dll. Biarkan rilis mendatang dilakukan dengan cara biasa - ini akan lebih cepat dan lebih andal.

Namun serangan lain terhadap anggota yang mungkin paling aktif dalam repositori ini selama beberapa bulan terakhir, dan yang telah memberikan kontribusi penting, terutama di bidang sistem build, alat, dll. Build baru dan modifikasi sistem build _are_ lebih andal. Seingat saya, bahkan ada kasus masalah yang hilang hanya dengan membangun dengan metode baru. Berkat upaya saya, kami sekarang bisa mendapatkan build yang lebih andal dengan lebih cepat ke tangan pengguna. Hal ini tentu TIDAK berguna. Saya memiliki rencana untuk lebih meningkatkan ini, hingga rilis resmi, tetapi jangan mengandalkan saya jika Anda terus meremehkan partisipasi saya seperti itu.

Saya tidak mengganggunya, saya membawanya ke kecepatan dengan perkembangan penting dari beberapa bulan terakhir. Tanggung jawab ada padanya untuk mengejar ketinggalan.
Sekarang kereta luncur telah kembali, saya ingin membangun keluar pintu sebanyak siapa pun, tetapi saya ingin melakukannya _benar_. sledge kembali tidak berarti kita harus kembali ke cara lama kita (bahkan untuk rilis ini terasa seperti kompromi), itu berarti kita dapat berkembang _lebih cepat_ untuk mencapai tempat yang kita inginkan.

Kami perlu memiliki waktu untuk menyelesaikan masalah organisasi sehingga kami dapat menjaga proyek tetap berjalan, terlepas dari kenyataan bahwa salah satu anggotanya menghilang untuk waktu yang lama.

Sebagian dari masalah ini adalah mengandalkan satu orang untuk secara manual memproduksi build dengan sistem build yang sudah tua dan kurang dapat dirawat, melompati rintangan hanya karena 50 MiB (yang dapat diselesaikan nanti), dll. Pertimbangkan fakta bahwa kita menyimpang dari toolchain yang kami gunakan di CI kami hanya untuk ini. Bahkan jika itu sebenarnya bukan masalah besar sekarang, itu adalah prinsip dan preseden yang buruk.

Juga tidak masuk akal untuk membahas libtorrent-2.0 dalam konteks rilis yang akan datang (dan seluruh cabang yang akan datang), karena kami tidak memiliki dukungan untuk itu, dan kami bahkan tidak dapat memprediksi kapan itu akan diimplementasikan sepenuhnya.

Kita tidak perlu membicarakan libtorrent 2.0 sama sekali. Hanya sebuah catatan kecil yang menjelaskan bahwa dukungan untuk V2 masih belum ada meskipun fakta bahwa beberapa penyebutan dukungan V2 akan muncul di pesan komit di changelog. Misalnya, 19d77b0881dc777b7930106869854067e5b2faba. (kecuali tentu saja Anda tidak memilih komit tersebut untuk rilis 4.3.0, tetapi itu memperumit masalah IMO).

Dua komputer utama saya berusia 9 dan 12 tahun (walaupun baru-baru ini saya meningkatkannya dengan menginstal SSD sebagai disk sistem). Banyak yang menggunakan perangkat keras yang lebih tua. Bukan karena kami menyukainya. Kami hanya tidak memiliki kapasitas keuangan/lainnya untuk memperbaruinya setiap 2-3 tahun. Jika Anda tidak dapat memahami kami, itu tetap tidak memberi Anda hak untuk mengolok-olok kami.

PS Namun, bahkan 10 tahun yang lalu saya tidak akan terlalu khawatir tentang 50 megabyte ini.

Tolong tunjukkan di mana saya "mengolok-olok" pengguna dengan spesifikasi rendah. Saya juga memiliki laptop C2D berusia 12 tahun yang saya pasang SSD (koneksinya hanya SATA II!) yang masih sering saya gunakan. Saya juga tidak memiliki mesin dengan prosesor yang dibuat dalam 3 tahun terakhir, dan saya berharap saya bisa mendapatkan AMD Ryzen di masa depan. Saya tentu saja tidak "meningkatkan setiap 2-3 tahun". Saya mengerti dan setuju dengan Anda. Saya baru saja mengolok-olok orang yang mengeluh tentang 50 MiB di desktop/laptop saat ini (baca: 15+ tahun terakhir), karena orang-orang itu memang pantas untuk diolok-olok.

Namun serangan lain mungkin terhadap anggota paling aktif dalam repositori ini selama beberapa bulan terakhir

Tolong berhenti mencari beberapa subteks tersembunyi di komentar saya. Saya hanya mengatakan apa yang saya katakan. Saya harap reaksi Anda tidak membingungkan siapa pun.

Saya tidak mengganggunya, saya membawanya ke kecepatan dengan perkembangan penting dari beberapa bulan terakhir. Tanggung jawab ada padanya untuk mengejar ketinggalan.

Semua ada waktu dan tempatnya.
Mengapa menekan @sledgehammer999 di sini dan sekarang, jika itu hanya dapat mengarah pada fakta bahwa dia tidak akan punya waktu untuk membuat rilis berikutnya, atau untuk merestrukturisasi manajemen/pemeliharaan proyek sebelum dia menghilang lagi, sehingga kita tidak akan dapat melanjutkan pekerjaan penuh dalam ketidakhadirannya.

Kita tidak perlu membicarakan libtorrent 2.0 sama sekali. Hanya sebuah catatan kecil yang menjelaskan bahwa dukungan untuk V2 masih belum ada meskipun fakta bahwa beberapa penyebutan dukungan V2 akan muncul di pesan komit di changelog.

Saya telah berulang kali menyebutkan bahwa log perubahan tidak boleh secara membabi buta menyalin riwayat git. Anda harus ingat bahwa:

1. beberapa komit adalah bagian dari satu perbaikan/peningkatan/fitur, jadi masuk akal untuk menyebutkannya secara keseluruhan;
2. beberapa komit memperbaiki kesalahan perantara yang tidak ada di rilis sebelumnya, jadi tidak masuk akal untuk menyebutkannya;
3. beberapa komit adalah bagian dari beberapa pekerjaan yang belum selesai, jadi tidak masuk akal untuk menyebutkannya.

@sledgehammer999
Harap diberitahu untuk masalah #13519.

EDIT: alarm palsu: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710744534
EDIT (FranciscoPombal) bukan alarm palsu: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710911209

@sledgehammer999 @Chocobo1 @glassez

Maaf untuk ping massal, tetapi yang ini tampaknya cukup kritis juga, dan sayangnya sedikit berantakan sekarang (saya juga bingung pada saat ini tentang apa masalahnya sebenarnya): https://github.com/ qbittorrent/qBittorrent/issues/13389. Mungkin salah satu dari Anda dapat menjelaskan beberapa hal baru?

Satu hal yang pasti; Saya tidak ingin mengambil risiko melanggar pengaturan *arr semua orang dengan rilis 4.3.x pertama.

yang ini tampaknya cukup kritis juga, dan sayangnya sedikit berantakan sekarang (saya juga bingung pada saat ini tentang apa masalahnya sebenarnya): #13389. Mungkin salah satu dari Anda dapat menjelaskan beberapa hal baru?

Satu hal yang pasti; Saya tidak ingin mengambil risiko melanggar pengaturan *arr semua orang dengan rilis 4.3.x pertama.

Tolong jangan mulai panik di akhir. Apa masalahnya? (Selain masalah dalam memahami logika aplikasi.) Kami tidak mengubah kode terkait, bukan? Saya tentu saja tidak membaca seluruh utas. Jika ada bukti yang jelas dari bug di aplikasi, tolong arahkan saya ke komentar tertentu.

@glassez

Tolong jangan mulai panik di akhir. Apa masalahnya? (Selain masalah dalam memahami logika aplikasi.) Kami tidak mengubah kode terkait, bukan? Saya tentu saja tidak membaca seluruh utas. Jika ada bukti yang jelas dari bug di aplikasi, tolong arahkan saya ke komentar tertentu.

Tidak ada yang panik, kita hanya perlu menyadari konsekuensi potensial. Intinya adalah agar orang lain membaca utas dengan hati-hati dan dengan kepala jernih. Kembali ketika saya mencoba mengatasinya, saya tidak yakin apakah itu regresi yang sah atau representasi yang salah dari perubahan baru-baru ini, atau jika perubahan kata-kata baru-baru ini memperlihatkan cacat yang tidak terduga atau apa. Ini diperparah oleh fakta bahwa saya tidak pernah benar-benar menggunakan perangkat lunak *arr , tetapi saya tahu bahwa banyak orang melakukannya. Terlepas dari itu, berikut adalah laporan asli di *arr repo: https://github.com/Radarr/Radarr/issues/5032 https://github.com/Sonarr/Sonarr/issues/3968 , jika Anda ingin melihat-lihat.

Hallo teman-teman,

Saya baru menyadari bahwa seseorang menyebutkan FOSSHUB di komentar sebelumnya. Saya sudah membaca utas dan ingin mengatakan ini. Dengan asumsi qBittorrent akan memiliki sekitar 50 MB, itu tidak ada bedanya bagi kami. Sama dengan lonjakan lalu lintas, seseorang menyebut Kim Kardashian. Tolong minta dia merekomendasikan qBittorrent; Saya yakin kami tidak akan turun. Kita bisa menyerap lalu lintas itu. Misalnya, setiap kali qBittorrent baru dirilis, kami telah melihat ribuan permintaan pembaruan per detik.

Apa yang saya coba katakan adalah bahwa Anda tidak perlu khawatir tentang hal ini.

Terima kasih!

1,5 sen saya itu membangun dan berjalan lebih baik di msvc2019 untuk alasan apa pun
50mb ruang disk sama sekali bukan apa-apa pada tahun 2020, jika sistem Anda BAHWA dibatasi maka Anda tetap menjalankan klien yang lebih ringan atau qbt-cli

jangan pernah menunda untuk mendapatkan proyek Anda yang terbaru dan terhebat ketika itu dapat dilakukan tanpa menyebabkan bug semakin lama Anda menunggu semakin Anda berisiko tertinggal dan terjebak pada kompiler mati yang tidak didukung tidak pernah menyenangkan bagi siapa pun

Saya pikir kereta luncur mengacu pada masalah seperti ini yang dibuka bahkan setelah hanya 12 MiB peningkatan ukuran penginstal.
https://github.com/qbittorrent/qBittorrent/issues/12247

Jadi bahkan bukan 50 MiB tetapi hanya 12 MiB yang akan dibuat orang untuk membuat tiket masalah.

@sledgehammer999 "JIKA" Anda akan menggunakan Qt 5.15.0/5.15.1 di rilis berikutnya, perhatikan (menu konteks ditutup setelah memilih satu tag) #13492

Sederhananya saya pikir jika itu akan diberi label 4.3 tidak ada yang akan mengeluh tentang penginstal yang lebih besar, itu pasti diharapkan! Menjaga dengan rantai alat kuno benar-benar terasa seperti representasi yang pas dari proses rilis qBittorrent.

Senang akhirnya melihat ini terjadi, saya hampir putus asa untuk melihat sesuatu tahun ini.

Saya pikir kereta luncur mengacu pada masalah seperti ini yang dibuka bahkan setelah hanya 12 MiB peningkatan ukuran penginstal.

12247

>

Jadi bahkan bukan 50 MiB tetapi hanya 12 MiB yang akan dibuat orang untuk membuat tiket masalah.

Jadi? Satu-satunya tanggapan yang tepat untuk tiket tersebut adalah "terserah, man.". Saya tidak mengerti obsesi membungkuk ke belakang untuk orang-orang ini. Seperti yang saya katakan di https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708436739 , tentu saja kami akan selalu melakukan yang terbaik untuk mencegah peningkatan ukuran seperti itu, tetapi kami tidak boleh mengorbankan apa pun hanya untuk 50 MiB, dan jika beberapa orang terganggu dengan itu, mereka bisa datang ke sini dan memperbaikinya sendiri.

kita tidak harus mengorbankan hal lain

Saya minta maaf, tetapi saya benar-benar tidak melihat apa yang kami korbankan dengan tidak menggunakan kompiler terbaru dan terbesar (diragukan). Tidak ada yang nyata untuk pergi ke kompiler terbaru. Ini bukan seolah-olah msvc2017 adalah kompiler kuno.

@sledgehammer999

Saya minta maaf, tetapi saya benar-benar tidak melihat apa yang kami korbankan dengan tidak menggunakan kompiler terbaru dan terbesar (diragukan). Tidak ada yang nyata untuk pergi ke kompiler terbaru. Ini bukan seolah-olah msvc2017 adalah kompiler kuno.

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

1,5 sen saya itu membangun dan berjalan lebih baik di msvc2019 untuk alasan apa pun

Seperti yang disebutkan sebelumnya, saya mengingat akun lain seperti ini di pelacak masalah atau saluran komunikasi lainnya. Saya tidak mengada-ada.

Terlepas dari itu, seseorang harus selalu mencoba menggunakan rantai alat terbaru (dengan alasan tertentu, tetapi MSVC 2019 sudah matang pada saat ini), kecuali jika ada alasan yang sangat bagus untuk tidak melakukannya. Selain itu, build MSVC 2019 telah diuji secara ekstensif selama beberapa bulan terakhir, baik yang disediakan oleh saya, xavier2k6, atau lainnya, atau sekarang, baru-baru ini, dengan alur kerja GitHub Actions resmi. 50 MiB bukan alasan yang baik, karena banyak orang mencoba memberi tahu Anda. Jangan biarkan diri Anda diganggu oleh mereka yang terobsesi lebih dari 50 MiB!! Saya pribadi akan mengurus laporan itu, Anda bahkan tidak perlu melihatnya.

Apakah memutakhirkan ke MSVC2019 sesuatu yang membutuhkan banyak waktu untuk dilakukan? Ini hanya kasus ketika tidak jika bukan? Jadi jika bukan rilis ini maka pasti rilis berikutnya, mengingat rilis umumnya hampir berbulan-bulan.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -711123971 hanya satu laporan subjektif yang kemungkinan besar terpengaruh dengan menggunakan lib terbaru dan kode qbt. Bukan karena kompiler.

Apakah memutakhirkan ke MSVC2019 sesuatu yang membutuhkan banyak waktu untuk dilakukan? Ini hanya kasus ketika tidak jika bukan? Jadi jika bukan rilis ini maka pasti rilis berikutnya, mengingat rilis umumnya hampir berbulan-bulan.

alasan diberikan di sini https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708055242

Jangan biarkan diri Anda diganggu oleh mereka yang terobsesi lebih dari 50 MiB!!

Saya tidak akan membiarkan diri saya diganggu oleh mereka yang terobsesi dengan "terbaru dan terhebat". Dan perbedaannya sebenarnya adalah 68MB penyimpanan ekstra (saya melakukan build statis lokal). msvc2017 hanya berfungsi! dan tidak membutuhkan ruang ekstra.

13505 (komentar) hanya satu laporan subjektif yang kemungkinan besar terpengaruh dengan menggunakan libs dan kode qbt terbaru. Bukan karena kompiler.

Dan komentar Anda tentang MSVC 2019 yang tidak memberikan manfaat sama sekali juga merupakan klaim yang tidak berdasar.

Saya tidak akan membiarkan diri saya diganggu oleh mereka yang terobsesi dengan "terbaru dan terhebat". Dan perbedaannya sebenarnya adalah 68MB penyimpanan ekstra (saya melakukan build statis lokal). msvc2017 hanya berfungsi! dan tidak membutuhkan ruang ekstra.

Kembalinya buruk. Tidak ada yang menganjurkan toolchain terbaru yang "menindas" Anda. Berpegang pada toolchain terbaru (sekali lagi, dengan alasan) secara objektif adalah kebijakan yang lebih baik, terutama ketika satu-satunya argumen yang menentangnya adalah bahwa ia menghasilkan binari yang sedikit lebih besar (kami tidak mengembangkan untuk beberapa platform yang disematkan). Selain itu, bukanlah kebijakan yang baik untuk membuat rilis dengan rantai alat yang berbeda dari satu CI dan yang telah digunakan sebagian besar pengguna dan kontributor selama _bulan_ terakhir. Dan untuk melengkapi semua ini, kemungkinan ada perbaikan yang relatif sederhana untuk pengasapan biner - mintalah teman 50 MiB Anda untuk menginvestasikan energi mereka dalam menemukan masalah daripada hanya mengeluh tentang 50 MiB jika itu sangat mengganggu mereka.

(msvc2017 =>msvc2019) dapat didiskusikan/diperdebatkan/diperdebatkan dll dalam masalah lain _KAPAN_ menjadi perlu

msvc2019 akan menjadi jauh lebih relevan bagi kami setelah kami beralih ke c++17.

Ini juga akan menjadi lebih relevan dalam perpindahan ke Qt 6.0/6.1/6.2 ketika Qt membutuhkan msvc2019 & drop (dukungan windows 7/8/8.1 & 32 bit) (yang masih jauh dari implementasi, saya tahu)

Host pengembangan dan target di Qt 6.0

Host pengembangan Qt 6.0

Target pengembangan Qt 6.0

Qt 6.1 host pengembangan

Qt 6.1 target pengembangan

Saya tidak akan berdebat lebih jauh tentang compiler. Saya tidak setuju dengan Anda secara khusus untuk qbt. msvc2019 akan menjadi jauh lebih relevan bagi kami setelah kami beralih ke c++17.

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

UNTUK SEKARANG!, BISAKAH KITA SEMUA SEKALI & UNTUK SEMUA PARKIR DI SINI UNTUK LAIN WAKTU?

Ayo keluarkan 4.2.x/4.3.x!

(msvc2017 =>msvc2019) dapat didiskusikan/diperdebatkan/diperdebatkan dll di edisi lain KETIKA diperlukan

UNTUK SEKARANG!, BISAKAH KITA SEMUA SEKALI & UNTUK SEMUA PARKIR DI SINI UNTUK LAIN WAKTU?

Ayo keluarkan 4.2.x/4.3.x!

Dengar, saya ingin ini berakhir seperti orang lain, tetapi jika tidak ada yang lain, terus terang tidak bertanggung jawab untuk mengubah rantai alat pada menit terakhir untuk rilis ketika semua orang, termasuk Anda, telah menggunakan dan menguji dengan MSVC 2019 untuk _bulan_ terakhir. Jika dilihat dari lensa ini, saya yakin sangat "perlu" menggunakan MSVC 2019 untuk rilis ini.

Secara pribadi, saya memiliki banyak skin dalam game ini: jika ada yang tidak beres, saya akan berurusan dengan sebagian besar laporan bug dari jenis "build nightly/CI bekerja dengan baik tetapi rilis tidak" dll. Dan ya, saya tahu saya tidak "harus" menghadapinya. Tapi saya tidak ingin proyek dibanjiri dengan masalah baru setelah rilis karena alasan yang bisa dihindari. Sudah cukup buruk bahwa rilis tidak akan dilakukan dengan perpustakaan yang dikompilasi dengan cara yang sama atau mirip dengan CI.

Saya bingung bagaimana semua ini, termasuk waktu dan upaya yang saya lakukan untuk proyek dan mengelola pelacak masalah tidak lebih penting daripada seseorang yang terobsesi lebih dari 50 MiB. Siapa orang-orang ini, bahkan? Apa yang telah mereka lakukan untuk proyek tersebut?

@FranciscoPombal Saya tidak akan memiliki diskusi kompiler lebih lanjut di sini. Kata-kata saya sudah final. Rilis akan dilakukan dengan msvc2017.

jika saya ingat dengan benar hanya Qt 5.15 "resmi" yang mendukung msvc2019. mereka tidak mulai berjalan di sana ci di msvc2019 hingga Qt 5.15
dan dia tidak dapat merilis dengan qt 5.15 karena bug yang disebutkan sebelumnya.

Dengar, saya ingin ini berakhir seperti orang lain, tetapi jika tidak ada yang lain, terus terang tidak bertanggung jawab untuk mengubah rantai alat pada menit terakhir untuk rilis ketika semua orang, termasuk Anda, telah menggunakan dan menguji dengan MSVC 2019 untuk bulan terakhir. Jika dilihat dari lensa ini, saya yakin sangat "perlu" menggunakan MSVC 2019 untuk rilis ini.

Build MSVC 2017 telah diuji dalam pertempuran dengan seluruh siklus rilis 4.2.x dan tidak ada banyak hal baru di msvc 2019 dan msvc 2017 masih memiliki siklus rilis mainstream, saya tidak mengerti mengapa Anda begitu terobsesi dengan "terbaru dan terhebat" .

@xavier2k6

Selain itu, misalkan kita tidak memperbaiki "masalah" ekstra 50 MiB sebelum rilis "besar" berikutnya. Apakah kita semua akan memiliki diskusi yang sama? Apakah kita akan menunda upgrade ke Qt 6 karena itu? Apa yang/tidak lebih penting dari 50 MiB? Kami hanya menyapu masalah di bawah karpet, itu adalah preseden buruk.

Petunjuk, saya hampir dapat menjamin bahwa, dari pendapat yang saya lihat dari orang lain dari waktu ke waktu, peningkatan ke Qt6 akan ditunda lebih lama dari yang wajar, untuk semua 3 alasan ini, dan mungkin lebih, tanpa urutan tertentu: ekstra Ukuran penginstal 50 MiB, menjaga dukungan untuk Windows 7 tetap hidup, menjaga dukungan untuk build 32-bit tetap hidup.

@jagannatharjun Qt 5.15.1 dibangun dengan baik dengan msvc2017. Satu-satunya masalah yang terkait adalah tentang penutupan menu konteks saat memilih tag. IMO, itu bukan pemblokir. Qt 5.15 membawa dukungan HiDPI yang jauh lebih baik.

@FranciscoPombal Saya bisa mengerti dari mana Anda berasal & pekerjaan Anda di sini sangat dihargai!

Poin yang Anda buat memiliki relevansi tetapi sayangnya, saya tidak berpikir kerangka waktu saat ini untuk mengeluarkan "rilis baru" memungkinkan untuk diskusi ini .... (saat ini)

Saya tidak mengerti mengapa Anda begitu terobsesi dengan "terbaru dan terhebat".

Kebijakan yang lebih unggul secara objektif bukanlah "obsesi". Saya kira Anda bisa mengatakan bahwa saya terobsesi untuk tidak memenuhi obsesi bodoh lainnya. Tapi tolong saya dan berhenti memproyeksikan ini pada saya, ya? Itu tidak memperkuat poin Anda.

Kalian secara serius mempertimbangkan untuk menjaga kecepatan peningkatan/modernisasi yang wajar sebagai "obsesi" dan tidak lebih penting dari 50 MiB di penginstal. Astaga.

@jagannatharjun Qt 5.15.1 dibangun dengan baik dengan msvc2017. Satu-satunya masalah yang terkait adalah tentang penutupan menu konteks saat memilih tag. IMO, itu bukan pemblokir. Qt 5.15 membawa dukungan HiDPI yang jauh lebih baik.

Saya setuju, bug tag menu konteks sangat disayangkan, tetapi bug HiDPI jauh lebih serius dan menghasilkan lebih banyak laporan dari waktu ke waktu.

@FranciscoPombal Saya bisa mengerti dari mana Anda berasal & pekerjaan Anda di sini sangat dihargai!

Lelucon yang bagus.

Poin yang Anda buat memiliki relevansi tetapi sayangnya, saya tidak berpikir kerangka waktu saat ini untuk mengeluarkan "rilis baru" memungkinkan untuk diskusi ini .... (saat ini)

Saya melihat saya tidak bisa melakukan apa-apa lagi. Baiklah.

@FranciscoPombal Saya bisa mengerti dari mana Anda berasal & pekerjaan Anda di sini sangat dihargai!

Lelucon yang bagus.

@FranciscoPombal Serius?? - Ini bukan lelucon & saya secara pribadi tulus!!!

Poin yang Anda buat memiliki relevansi tetapi sayangnya, saya tidak berpikir kerangka waktu saat ini untuk mengeluarkan "rilis baru" memungkinkan untuk diskusi ini .... (saat ini)

Saya melihat saya tidak bisa melakukan apa-apa lagi. Baiklah.

Jangan mengambil situasi ini secara pribadi / ke hati ...... ok
........tarik nafas
biarkan bagian dari kerja keras Anda dalam proyek setidaknya bisa melihat "publik utama" melalui rilis baru. (seperti saat ini hanya dapat dilihat oleh orang-orang seperti saya yang datang ke sini & berpartisipasi/berkontribusi/membangun dll

Saya baru saja mendorong cabang staging_v4_3_x . Ini pada dasarnya master dengan changelog yang diperbarui.
Silakan lihat Changelog dan beri tahu saya jika ada yang salah atau saya melewatkan sesuatu.
@glassez

1. Apakah #13234 memiliki atribut yang dihadapi pengguna? Sesuatu yang harus ada di changelog? misalnya "meningkatkan kecepatan pemuatan sesi dengan ratusan torrent".
2. Apa tujuan dari #13395. Apa fungsinya? Haruskah saya memasukkan sesuatu ke dalam changelog?

Sedikit saya akan melihat masalah yang disebutkan di utas ini yang mungkin membuat beberapa komit tidak disertakan untuk rilis. Saya akan tetap mengiformasikan ke anda.

@sledgehammer999

Juga, harap bersihkan PPA dalam prosesnya. Rilis Ubuntu selain 18.04 , 20.04 dan 20.10 adalah EOL, jadi arsip untuk build yang menargetkan versi tersebut harus dihapus secepatnya.

Ubuntu 14.04 dan 16.04 bukan EOL. Dari mana Anda mendapatkan daftar itu?
https://wiki.ubuntu.com/Releases

@sledgehammer999 Sepertinya Anda melewatkan https://github.com/qbittorrent/qBittorrent/pull/13188 untuk changelog

juga, dapatkah Anda menambahkan catatan di changelog itu?
Bundel tema sebelumnya tidak akan berfungsi dengan baik dengan rilis ini karena perubahan format file bundel, Silakan hubungi penyedia tema untuk perbaikan. Anda dapat membaca lebih lanjut tentang format baru di sini https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes " atau semacamnya.
Sebenarnya, ini karena https://github.com/qbittorrent/qBittorrent/pull/12755/files

Saya pikir harus disebutkan bahwa dukungan untuk RC1_1 libtorrent telah dihentikan.

Juga jika seseorang menginginkan tingkat pengumuman pelacak yang lebih cepat atau memiliki klien keluar yang lebih lambat (dibandingkan dengan 4.2.x) dengan versi ini, maka mereka dapat mencoba meningkatkan batas "Pengumuman HTTP Serentak Maks" dari pengaturan lanjutan.

Apakah #13234 memiliki atribut yang dihadapi pengguna? Sesuatu yang harus ada di changelog? misalnya "meningkatkan kecepatan pemuatan sesi dengan ratusan torrent".

Maaf, saya tidak ingat semuanya... kebanyakan perbaikan internal. Mungkin bagian selanjutnya dari deskripsi PR cocok dengan "atribut yang dihadapi pengguna":

Hal ini memungkinkan untuk menyimpan data resume dengan benar dalam beberapa keadaan, misalnya dalam status "file yang hilang" (walaupun kami mencoba untuk mencegah hal ini dilakukan sebelumnya, pengguna sebenarnya dapat melakukannya ketika, misalnya, mengubah beberapa properti dari torrent semacam itu).

Apa tujuan dari #13395. Apa fungsinya? Haruskah saya memasukkan sesuatu ke dalam changelog?

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

Saya pikir harus disebutkan bahwa dukungan untuk RC1_1 libtorrent telah dihentikan

👍

FITUR: Tambahkan dukungan untuk membuat torrent v2 (memerlukan libtorrent 2.0.x) (Chocobo1)

Sial! Apakah qBittorrent sudah mendukung libtorrent-2.0? Mengapa menyebutkan seperti itu? Kami memang sudah membicarakannya.

juga, dapatkah Anda menambahkan catatan di changelog itu?
Bundel tema sebelumnya tidak akan berfungsi dengan baik dengan rilis ini karena perubahan format file bundel, Silakan hubungi penyedia tema untuk perbaikan. Anda dapat membaca lebih lanjut tentang format baru di sini https://github.com/qbittorrent/ qBittorrent/wiki/How-to-use-custom-UI-themes " atau semacamnya.
Sebenarnya, ini karena https://github.com/qbittorrent/qBittorrent/pull/12755/files

Saya pikir saya akan menambahkan ini ke bagian "berita" di situs web. Di luar perubahan, di teks pengantar.

Saya pikir harus disebutkan bahwa dukungan untuk RC1_1 libtorrent telah dihentikan.

OKE.

Juga jika seseorang menginginkan tingkat pengumuman pelacak yang lebih cepat atau memiliki klien keluar yang lebih lambat (dibandingkan dengan 4.2.x) dengan versi ini, maka mereka dapat mencoba meningkatkan batas "Pengumuman HTTP Serentak Maks" dari pengaturan lanjutan.

Haruskah ini disebutkan dalam changelog sebagai item?

Sial! Apakah qBittorrent sudah mendukung libtorrent-2.0? Mengapa menyebutkan seperti itu? Kami memang sudah membicarakannya.

Kemudian saya akan memindahkan item ini di bawah entri rilis v4.4.0 (bukan bagian dari changelog v4.3.0). Kecuali jika dukungan libtorrent-2.0 resmi diperkenalkan sebelumnya. Apakah itu memuaskan?

Berikut adalah changelog yang diperbarui: https://github.com/qbittorrent/qBittorrent/commit/0302e8abbc545d13b7be51e011d2795a9bb3ea73

Haruskah ini disebutkan dalam changelog sebagai item?

Saya pikir lebih baik jika diposting sebagai berita. Karena pengguna dengan ribuan torrent/banyak pelacak per torrent mungkin memperhatikan perilaku pengumuman yang lambat.

Diperbarui lagi: https://github.com/qbittorrent/qBittorrent/commit/727dec97540091f891991113299fa38468e13885

Pengumuman: Penundaan yang sangat kecil harus diharapkan. Saya harus melakukan kompilasi ulang rantai alat parsial karena masalah keamanan yang saya informasikan melalui email. Detailnya akan tersedia beberapa hari setelah rilis. IMO, tingkat keparahannya mungkin kecil karena eksploitasi memerlukan seseorang yang jahat memiliki akses lokal atau sudah menjalankan aplikasi jahat di sistem Anda. Dalam kedua kasus Anda sudah kacau bahkan tanpa masalah keamanan qbt.

Ubuntu 14.04 dan 16.04 bukan EOL. Dari mana Anda mendapatkan daftar itu?

Mungkin salah kata. Ini adalah EOL bagi kami karena versi Qt mereka kurang dari persyaratan minimum kami.

OKE. Saya pikir semuanya sudah diatur sekarang, dan saya sedang mempersiapkan build. Cabang v4_3_x akan didorong bersama dengan build.

@sledgehammer999 Maaf atas komentar yang terlambat, tetapi harap ingat untuk menyebutkan (di bagian berita situs web) bahwa ada banyak perbaikan libtorrent sejak rilis terakhir yang hadir dalam yang satu ini, termasuk untuk kebocoran memori yang diketahui, masalah kecepatan karena logika pengaturan cache yang salah pada Windows, dll. Anda dapat melihat libtorrent's 1.2.6-1.2.11 (1.2.11 masih belum dirilis secara resmi tetapi sudah memiliki beberapa entri changelog) untuk inspirasi dan memilih entri yang paling relevan.

Karena penasaran, komit libtorrent mana yang akan digunakan?

OK, dan git commit terbaru seperti biasa.

@rrrevin

Ubuntu 14.04 dan 16.04 bukan EOL. Dari mana Anda mendapatkan daftar itu?
https://wiki.ubuntu.com/Releases

Mungkin salah kata. Ini adalah EOL bagi kami karena versi Qt mereka kurang dari persyaratan minimum kami.

Yah, saya benar-benar bermaksud "Akhir Dukungan Standar" saya kira, yang sebenarnya penting. Di luar itu, hanya perusahaan yang membayar yang mendapatkan dukungan. 16.04 secara teknis bahkan belum mencapai "Akhir Dukungan Standar", tetapi sangat dekat. Dan terlepas dari itu, dukungan OOTB untuk itu dijatuhkan seperti 2 tahun yang lalu atau lebih karena qBittorrent menabrak versi Qt minimum yang diperlukan menjadi 5,9.

@sledgehammer999 Satu hal kecil lagi: pertimbangkan untuk menyebutkan regresi kecil menu konteks tag yang dikenal dalam berita: https://github.com/qbittorrent/qBittorrent/issues/13492.

@sledgehammer999 Anda tidak mencantumkan banyak PR saya di changelog... https://github.com/qbittorrent/qBittorrent/pulls?q=is%3Apr+author%3AFranciscoPombal+is%3Aclosed+milestone%3A4.3.0

@FranciscoPombal Saya menggabungkan semua PR CMake Anda menjadi satu entri. PR pembersihan kode internal Anda tidak dapat disebutkan di Changelog. Itu harus berisi perbaikan yang dihadapi pengguna. Sama dengan banyak PR dari @Chocobo1
Jika saya melewatkan sesuatu yang spesifik, sebutkan di bawah ini. Saya akan menunggu beberapa saat, karena saya masih melakukan tugas administrasi di belakang layar.

@sledgehammer999

Itu harus berisi perbaikan yang dihadapi pengguna.

Oke, jadi:

• -> https://github.com/qbittorrent/qBittorrent/pull/13042 adalah yang dihadapi pengguna, karena memperbaiki bug yang diumumkan di pelacak yang disematkan. <--

• https://github.com/qbittorrent/qBittorrent/pull/12086 , https://github.com/qbittorrent/qBittorrent/pull/13109 , dan https://github.com/qbittorrent/qBittorrent/pull/13439 bukan pembersihan yang dihadapi pengguna, jadi saya rasa tidak apa-apa.

• https://github.com/qbittorrent/qBittorrent/pull/13288 adalah jenis yang menghadap pengguna, saya kira? Sekarang pengguna dapat mengunduh build eksperimental dari CI, apakah itu dianggap menghadap pengguna?

• Sisanya sudah dikreditkan, terkait dengan peningkatan CMake (sudah dikreditkan juga) atau terkait dengan https://github.com/qbittorrent/qBittorrent/pull/13288.

/ di luar topik (untuk lain waktu) - mungkin pembersihan yang dihadapi non-pengguna harus dimasukkan dalam "LAINNYA" atau mungkin bagian "KODE KESEHATAN" baru? Pengguna suka melihat hal semacam itu di changelog.

-> #13042 menghadap pengguna, karena memperbaiki bug yang diumumkan di pelacak yang disematkan. <--

Oke, maaf. Tidak jelas dari judul komit. Bisakah Anda menyarankan entri changelog yang sesuai (untuk pengguna yang membacanya)?

Perubahan CI biasanya tidak relevan dengan rilis.

/ di luar topik (untuk lain waktu) - mungkin pembersihan yang dihadapi non-pengguna harus dimasukkan dalam "LAINNYA" atau mungkin bagian "KODE KESEHATAN" baru? Pengguna suka melihat hal semacam itu di changelog.

Hmm, saya akan menambahkan entri OTHER untuk pembersihan kode yang mengkredit Anda dan @Chocobo1

13288 adalah jenis yang menghadap pengguna, saya kira? Sekarang pengguna dapat mengunduh build eksperimental dari CI, apakah itu dianggap menghadap pengguna?

IMO, hal seperti itu dapat disebutkan di News sebagai gantinya (di luar Change log).

IMO, hal seperti itu dapat disebutkan di News sebagai gantinya (di luar Change log).

Saya entah bagaimana bisa menjejalkan tautan "nightlies" di halaman unduhan ...

~@glassez~ @sledgehammer999

IMO, hal seperti itu dapat disebutkan di News sebagai gantinya (di luar Change log).

Saya entah bagaimana bisa menjejalkan tautan "nightlies" di halaman unduhan ...

Sebutkan saja hal-hal CI di berita, saya akan ragu untuk menautkan halaman unduhan "malam" ke audiens yang lebih luas sebelum kami memiliki versi berbasis git di executable. Jika tidak, semua pengguna akan melaporkan semua versi malam yang berbeda sebagai "4.x.xalpha1", yang menyebabkan kebingungan.

versi berbasis git di executable. Jika tidak, semua pengguna akan melaporkan semua versi malam yang berbeda sebagai "4.x.xalpha1", yang menyebabkan kebingungan.

Ya, itu komentar yang benar.

@sledgehammer999

Bisakah Anda menyarankan entri changelog yang sesuai (untuk pengguna yang membacanya)?

"Memperbaiki logika pengumuman yang rusak di pelacak tertanam yang menyebabkan kegagalan dalam beberapa kasus."

CI build dapat digunakan untuk tujuan jahat juga. Dengan membuat PR jahat dan kemudian mendistribusikan tautan.
Saya akan merekomendasikan untuk tidak menautkan hal seperti itu di situs web.

@an0n666

CI build dapat digunakan untuk tujuan jahat juga. Dengan membuat PR jahat dan kemudian mendistribusikan tautan.
Saya akan merekomendasikan untuk tidak menautkan hal seperti itu di situs web.

Ini juga poin yang bagus. Saya kira saya lebih baik mulai mengerjakan alur kerja khusus untuk build malam yang hanya dibangun dari master yang telah saya bicarakan sebelumnya. Kemudian kita akan dapat menautkan ke bangunan malam tanpa takut hal seperti itu terjadi.

Rilis dibuat.
PPA akan dibersihkan besok.
Detail masalah keamanan dalam beberapa hari.
Rencana perubahan organisasi dalam beberapa hari.

Dan seperti biasa, terima kasih kepada semua orang atas kontribusi mereka dalam siklus rilis ini.