@sledgehammer999 이것을 읽어야 합니다 => https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions/5

고맙게도 바이러스가 없기를 바랍니다.

나는 당신을 개인적으로 기쁘게 생각합니다.

그러나 나는 프로젝트의 현재 상황에 대해 정말 슬픕니다(저만 같은 느낌이 아닙니다). 변화의 시기가 중요합니다. 따라서 프로젝트의 관리/유지를 재구성하거나, 다른 사람이 잘못된 희망을 갖지 않도록 개인 장난감임을 명시적으로 선언해야 합니다.

면제되어야 하는 커밋이 있습니까?

지금 변경 사항을 건너뛰는 것은 의미가 없다고 생각합니다.

어쨌든 새 릴리스는 오래 전에 출시되었습니다.

너무 많은.

평소와 같이 모든 새 마스터 커밋을 v4_2_x 분기로 백포트해야 합니까?

왜 v4.2.x인가? v4.3에 대한 변경 사항이 충분합니다!
게다가 커밋을 하나씩 "체리-피킹"하여 불필요한 작업을 수행하는 대신 현재 마스터 위에 단순히 v4_3_x 분기를 만들 수 있습니다.

방금 이전 릴리스에서 최신 마스터까지 커밋 보기를 마쳤습니다. (대부분 제목과 PR 설명을 커밋)

왜 v4.2.x인가? v4.3에 대한 변경 사항이 충분합니다!

응. 커밋이 많이 있습니다. 그리고 libtorrent 1.1.x가 삭제되었으므로 v4.3.x를 확실히 보증합니다. (그리고 libtorrent 2.0.x 및 C++17용 v4.4.x!!!)
가능한 한 빨리 다가오는 변경 로그에 대한 새 PR을 작성하겠습니다.

프로젝트 관리 정보: 주말/출시 이후에 이에 대해 논의할 것입니다.

@sledgehammer999

돌아와서 다행이고 모든 것이 정상입니다.

평소와 같이 모든 새 마스터 커밋을 v4_2_x 분기로 백포트해야 합니까? 면제되어야 하는 커밋이 있습니까?

나는 새 버전 4.3.x에 레이블을 지정하는 제안에 무관심합니다. 결정하는 것은 귀하와 다른 사람들의 몫입니다.

모든 커밋은 좋은 AFAIK입니다. 그러나 많은 중요한 수정 사항이 libtorrent에도 병합되었으므로 이 새 릴리스에는 가능한 최신 RC_1_2 를 사용하는 것이 중요합니다.

BitTorrent V2 지원과 관련된 몇 가지 커밋이 이미 있습니다. 그러나 나는 이 릴리스가 위에서 언급한 것처럼 최신 libtorrent RC_1_2 로 빌드될 것으로 예상하므로 대부분의 사용자는 실제로 이를 보지 못할 것입니다. 따라서 사용자가 BitTorrent V2 관련 항목을 읽을 때 잘못된 희망을 갖지 않도록 변경 로그에 이를 설명하는 메모를 작성했습니다.

로컬 도구 모음을 최신 상태로 만들었습니다. 백포팅/변경 로그/최소한의 테스트는 시간이 걸립니다. 하지만 이번 주말은 변화의 규모에 따라 가능한 목표라고 생각한다.

이에 대한 세부정보를 제공해 주시겠습니까? 나는 당신이 최신 MSVC 2019를 가지고 있다고 가정하고 나는 당신이 의존성에 대해 vcpkg 또는 이와 유사한 것을 사용하고 있다고 _희망_ 합니다. 새로운 GitHub Actions CI에서 영감을 얻을 수 있습니다. 또한 이번에 빌드할 때 CMake를 사용하는 것을 기억하십시오. CMake는 새로운 기본 빌드 시스템이 되었습니다.

프로젝트 관리 정보: 주말/출시 이후에 이에 대해 논의할 것입니다.

알겠습니다. 하지만 하루라도 빨리 부탁드립니다. 그리고 패키징도 자동으로 완료될 수 있도록 릴리스 프로세스 자동화에 대한 논의를 계속해야 합니다.

@sledgehammer999

또한 그 과정에서 PPA를 정리하십시오. 18.04 , 20.04 및 20.10 이외의 Ubuntu 릴리스는 EOL이므로 해당 버전을 대상으로 하는 빌드의 아카이브는 최대한 빨리 제거해야 합니다.

따라서 이 새 릴리스에는 가능한 최신 RC_1_2를 사용하는 것이 중요합니다.

이것은 말할 필요도 없습니다.
Qt 15.1, openssl 1.1.1h, 부스트 1.74

RC_2_0은(는) 아직 사용되지 않습니다. 몇 가지 공식 베타 릴리스 없이는 아닙니다.

최신 MSVC 2019가 있다고 가정하고 vcpkg를 사용하고 있기를 바랍니다.

아니요, 저는 이 릴리스에 대해 여전히 msvc2017을 사용하고 있습니다. 마지막으로 msvc2019를 확인했을 때 qbt에 대해 매우 큰 .pdb 파일이 생성되었습니다. 나중에 다시 확인하겠지만 이번 릴리스에서는 그렇지 않습니다.
나머지 종속성은 내가 항상 해오던 방식으로 구축됩니다. https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (정적 연결)에 다소 설명되어 있습니다.

또한 이번에 빌드할 때 CMake를 사용하는 것을 기억하십시오. CMake 는 새로운 기본 빌드 시스템이 되었습니다 .

분명히 나는 ​​git 로그에서 이것을 놓쳤습니다. 나는 다소 부끄럽지만 다른 모든 사람들이 autotools/qmake보다 cmake를 사용하는 것이 더 편안하다고 느끼기 때문에 실제로 반대할 수 없습니다.
그러나 당분간은 릴리스를 위해 autotools/qmake를 계속 사용할 것입니다. 릴리스를 위해 cmake에 익숙해질 시간이 없습니다.

PPA가 누구에게도 피해를 주지는 않지만 PPA에 대해 어떻게 해야 하는지 알아보겠습니다.

@sledgehammer999 일반 사용자가 여기에 댓글을 남기는 것을 원하지 않는다는 것을 알고 있습니다. 그래서 죄송합니다......저는 문제/버그 등을 없애기 위해 여기에서 Windows 빌드를 만들고 있습니다.

MSVC 2019로 컴파일하고 qBittorrent 실행 파일은 일반적으로 약 27MB이고 .pdb는 180MB입니다.

/pdbstripped 를 사용할 생각을 해본 적이 있습니까?

MSVC 2019로 컴파일하고 qBittorrent 실행 파일은 일반적으로 약 27MB이고 .pdb는 180MB입니다.

msvc2017 및 현재 마스터와 비교: 24.4MB exe 및 98.1MB pdb. 내가 말했듯이 pdb는 msvc2017에 비해 매우 큽니다.

또한 나는 우리가 /pdbstripped를 원하지 않는다고 생각합니다. 프로그램이 충돌할 때 덜 유용한 역추적을 제공할 것입니다.

또한 나는 우리가 /pdbstripped를 원하지 않는다고 생각합니다. 프로그램이 충돌할 때 덜 유용한 역추적을 제공할 것입니다.

/PDBCompress ?

@sledgehammer999

CMake + 최신 MSVC 2019 + vcpkg(https://github.com/qbittorrent/qBittorrent/actions)를 사용하는 자동화된 CI 빌드는 57MiB(실행 파일) + 122MiB(pdb)입니다.

아니요, 저는 이 릴리스에 대해 여전히 msvc2017을 사용하고 있습니다. 마지막으로 msvc2019를 확인했을 때 qbt에 대해 매우 큰 .pdb 파일이 생성되었습니다. 나중에 다시 확인하겠지만 이번 릴리스에서는 그렇지 않습니다.

이것은 IMO가 좋은 이유가 아닙니다. MSVC 2019에는 많은 수정 사항이 포함되어 있습니다. 2020년 (말)입니다. 아무도 \~50 MiB 추가 설치 크기에 대해 신경 쓰지 않습니다. 무언가가 pdb/실행 파일을 부풀리는 경우 나중에 알아낼 수 있지만, 지금은 모든 것이 작동하고 추가 \~50 MiB는 훨씬 더 최근의 도구 모음에 대해 요일에 만들 수 있는 절충안입니다.

또한 나는 우리가 /pdbstripped를 원하지 않는다고 생각합니다. 프로그램이 충돌할 때 덜 유용한 역추적을 제공할 것입니다.

:+1:, 하지만 이것은 앞으로 적절하게 조사될 수 있습니다.

나머지 종속성은 내가 항상 해오던 방식으로 구축됩니다. https://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019- (정적 연결)에 다소 설명되어 있습니다.

분명히 나는 ​​git 로그에서 이것을 놓쳤습니다. 나는 다소 부끄럽지만 다른 모든 사람들이 autotools/qmake보다 cmake를 사용하는 것이 더 편안하다고 느끼기 때문에 실제로 반대할 수 없습니다.
그러나 당분간은 릴리스를 위해 autotools/qmake를 계속 사용할 것입니다. 릴리스를 위해 cmake에 익숙해질 시간이 없습니다.

:-1:, 이것은 대부분의 사람들이 지난 몇 달 동안 Windows에서 qBittorrent를 테스트한 방식이 아닙니다. 많은 사람들이 내 CI 브랜치(CMake + vcpkg)의 빌드를 사용하고 있었고 이제는 리포지토리의 자체 작업 섹션을 사용하고 있습니다. 이렇게 하면 빌드 프로세스의 차이로 인해 설명할 수 없는 회귀가 관찰될 가능성이 매우 높습니다.

@sledgehammer999 릴리스 전에 더 이상 "차단기"를 추가하고 싶지 않지만 기본적으로 준비가 되었기 때문에 적어도 이것이 착륙할 때까지 기다릴 것입니다. https://github.com/qbittorrent/qBittorrent/pull/13499

비동기 I/O 스레드의 기본값을 변경하면 많은 사용자에게 도움이 됩니다.

msvc2019를 폄하하고 싶지는 않지만 모든 것이 새롭다고 생각하는 면에서 당신은 약간 과도하다고 생각합니다. 항상 그런 것은 아닙니다. 그리고 예, bt 클라이언트를 위한 50MB 추가는 큰 문제입니다. 측정 가능한 이점이 없는 불필요한 팽창입니다(예: 프로그램이 1.5배 빨라지지 않음).

마지막으로 빌드 시스템에 대해: 빌드 시스템 변경에서 회귀가 보인다면 코드에 심각한 문제가 있는 것입니다. 물건이 너무 연약해서는 안됩니다.

13499는 아직 기본값이 아닌 libtorrent 2.0.x 옵션에 관한 것이기 때문에 범위를 벗어납니다. 마지막으로 컷은 주말에 만들어집니다.

@sledgehammer999

msvc2019를 폄하하고 싶지는 않지만 모든 것이 새롭다고 생각하는 면에서 당신은 약간 과도하다고 생각합니다. 항상 그런 것은 아닙니다.
그리고 예, bt 클라이언트를 위한 50MB 추가는 큰 문제입니다. 측정 가능한 이점이 없는 불필요한 팽창입니다(예: 프로그램이 1.5배 빨라지지 않음).

제 주장을 "new = better"라고 그냥 무시하지 마세요. 그리고 나는 당신이 50 MiB에 대해 더 나쁜 도구 체인을 고수하는 데 약간 "최상위"라고 생각합니다. 물론 도구 체인 업데이트로 인해 "1.5x" 속도가 향상되는 것은 전혀(또는 매우 드물게) 볼 수 없습니다. 그러나 그것은 설정하기에 비현실적인 기준입니다. 최신 도구 모음을 사용하면 "1.5x" 속도 향상이 없을 수 있지만 항상 약간의 성능 개선, 더 나은 언어 지원, 더 나은 코드 생성(때로는 버그가 적음), ... 문서화하는 온라인 리소스가 많이 있습니다. MSVC 2019의 개선 사항.

다시 말하지만, 가능하면 추가로 50MiB를 줄여야 한다는 데 동의하지만, 제 요점은 다음 릴리스(또는 그 이후)에 제시간에 그렇게 할 수 없다면 _괜찮습니다_. 또한 모든 릴리스에서 이러한 일이 계속 반복된다는 의미는 없습니다(저도 그런 경우 짜증이 납니다). 이것은 분명히 일회성 문제입니다. 사용자로서 "여기 품질이 더 나쁜 바이너리가 있지만 최소한 50MiB를 절약했습니다."라는 말을 듣고 싶지 않습니다. 50 MiB는 요즘 반올림 오류입니다(어쨌든 데스크탑 프로그램의 경우, 물론 임베디드 세계에서는 그렇지 않습니다). 죄송합니다만 다른 생각을 하시면 오산입니다.

마지막으로 빌드 시스템에 대해: 빌드 시스템 변경에서 회귀가 보인다면 코드에 심각한 문제가 있는 것입니다. 물건이 너무 연약해서는 안됩니다.

반드시는 아닙니다. 빌드 시스템 자체에 심각한 문제가 있을 수 있습니다. 정밀 검사 PR 전에 CMake 빌드 시스템의 이전 상태를 참조하십시오. 그 전에는 CMake로 빌드하면 꽤 많은 버그가 발생했습니다. 일부(때로는 심각합니다!) 문제는 실제로 올바르지 않거나 잘못된 빌드 시스템과 빌드 레시피에서 비롯됩니다. 코드가 아무리 강력하더라도 잘못 빌드하면 매우 훌륭하지만 진단하기 어려운 방식으로 코드가 손상될 수 있습니다.

13499는 아직 기본값이 아닌 libtorrent 2.0.x 옵션에 관한 것이기 때문에 범위를 벗어납니다. 마지막으로 컷은 주말에 만들어집니다.

나머지 토론을 참조하십시오. 해당 PR은 실제로 비동기 I/O 스레드의 기본 수를 변경하므로 libtorrent 1.2.x에 대해서도 빌드할 때 기본적으로 최소 2개의 해싱 스레드가 사용됩니다. 결과적으로 SSD 사용자에게는 성능이 크게 향상되지만(실제로는 1.5배 이상) HDD 사용자에게도 매우 미미한 이득을 제공합니다.

@sledgehammer999

다음은 시작하는 데 도움이 되는 몇 가지 도움말입니다.

• Windows에서 CMake를 사용하여 정적으로 빌드하기 위한 새 자습서: https://github.com/qbittorrent/qBittorrent/wiki/Compilation :-Windows-(MSVC-2019,-64-bit,-static-linkage)
• 옵션 목록 + 짧은 CMake 튜토리얼/소개: https://github.com/qbittorrent/qBittorrent/wiki/Compilation-with-CMake :-common-information

vcpkg를 사용하지 않거나 일부 패키지에는 vcpkg를 사용하지만 다른 패키지에는 사용하지 않는 경우 -DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar 와 같이 패키지에 대한 구성 파일을 찾을 위치를 CMake에 알려주는 적절한 힌트를 추가로 전달하면 됩니다. . 확실하지 않은 경우 구성이 성공할 때까지 간단히 실행할 수 있습니다. 오류 메시지는 추가해야 할 항목을 항상 이해하고 파악할 수 있을 만큼 충분히 유용하기 때문에 팝업되는 각 패키지에 대한 각 오류 메시지를 한 번에 하나씩 수정합니다. 다음.

나는 컴파일러에 대해 더 이상 논쟁하지 않을 것입니다. qbt에 대해 특별히 동의하지 않습니다. msvc2019는 C++17로 전환하면 훨씬 더 관련성이 높아집니다. 마지막으로, bt 클라이언트 사용자의 경우 그가 걱정하는 것은 클라이언트가 하향식/상향식 속도를 달성할 수 있는지 여부입니다. 이것이 "더 나은" 또는 "나쁜" 품질 바이너리에 대한 메트릭입니다. msvc2017은 추가 팽창 없이 이를 달성합니다. -- msvc2019로 빌드를 다시 실행할 때까지 판단을 보류합니다--

-DLibtorrentRasterbar_DIR=C:\path\to\libtorrent-install-dir\lib\cmake\LibtorrentRasterbar와 같이

패키지가 빌드/설치되는 방식에 차이가 있습니까? 현재 boost, libtorrent, openssl에 대해 lib 아래에 $ cmake 폴더가 없습니다. qt 전용입니다.
추신: boost 및 libtorrent는 b2를 사용하여 빌드됩니다. 구성 스크립트를 사용하여 Openssl.

@sledgehammer999

유일한 요구 사항은 CMake, IIRC로 libtorrent를 빌드하는 것입니다. 다른 모든 패키지는 기본적으로 필요한 구성 파일을 생성하거나 어떤 방식으로든 CMake에서 지원합니다.

• 적절한 파일을 생성하려면 libtorrent를 CMake로 빌드해야 합니다. 이것은 Wiki 튜토리얼에서 구체적으로 다룹니다.
• CMake는 기본적으로 번들 찾기 모듈( https://cmake.org/cmake/help/latest/module/FindOpenSSL.html#hints)을 통해 OpenSSL을 지원합니다. OPENSSL_ROOT_DIR 설정하면 됩니다. 예: -DOPENSSL_ROOT_DIR=C:\Qt\Tools\OpenSSL\Win_x64
• boost는 기본적으로 필요한 파일을 생성합니다. Boost_DIR 를 설정하면 됩니다. 예: -DBoost_DIR=C:\path\to\boost_1_73_0\stage\lib\cmake\Boost-1.73.0
• zlib의 경우 몇 가지 경로를 전달해야 합니다. 예: -DZLIB_INCLUDE_DIR=C:\path\to\zlib-1.2.11\build -DZLIB_LIBRARY=C:\path\to\zlib-1.2.11\build\libzlibstatic.a
• Qt는 필요한 파일을 생성합니다. 나는 당신이 그것들을 가리키는 데 필요한 필수 구성 시간 플래그를 이미 파악했다고 가정합니다.

다시 말하지만, 이 중 하나라도 누락된 경우 CMake는 구성 단계에서 이에 대해 알려주고 추가하려는 항목을 정확히 제안합니다.

나는 sledgehammer999에 동의합니다.
더 작은 바이너리가 항상 더 좋습니다. 특히 과거 릴리스의 트랙 레코드가 제공됩니다.
많은 사람들이 여전히 느린 인터넷을 가지고 있습니다. 또한 바이너리를 제공하는 웹 사이트는 위치에 따라 일부 사용자에게 느릴 수 있습니다.
이러한 경우 작은 바이너리가 더 빠른 다운로드를 허용합니다. 사람들은 불필요한 블로트웨어가 의심되는 경우 업데이트를 꺼릴 수 있습니다.

새로운 기본 빌드 시스템이 되었습니다.

무엇의 기본 빌드 시스템?

새로운 기본 빌드 시스템이 되었습니다.

무엇의 기본 빌드 시스템?

그는 심지어 qmake/autotools가 더 이상 사용되지 않는다고 선언했습니다. https://github.com/qbittorrent/qBittorrent/wiki

그는 심지어 qmake/autotools가 더 이상 사용되지 않는다고 선언했습니다. https://github.com/qbittorrent/qBittorrent/wiki

이 임의성이 정말로 화를 내기 시작했습니다!

새로운 기본 빌드 시스템이 되었습니다.
무엇의 기본 빌드 시스템?

이 임의성이 정말로 화를 내기 시작했습니다!

오 와우! 따라서 실제 결정이 아닙니다! 나는 결국 부끄러움을 느끼지 않는다.

@FranciscoPombal
다른 빌드 도구, 빌드 시스템 등에 대한 쓸데없는 대화로 @sledgehammer999 의 주의를 산만하게 하지 마십시오. 다음 릴리스가 일반적인 방식으로 완료되도록 하십시오. 더 빠르고 안정적입니다. 구성원 중 한 명이 오랫동안 사라지더라도 프로젝트를 계속 진행할 수 있도록 조직 문제를 해결할 시간이 필요합니다.
또한 libtorrent-2.0에 대한 지원이 없고 언제 완전히 구현될지 예측할 수 없기 때문에 향후 릴리스(및 전체 향후 분기)와 관련하여 libtorrent-2.0을 논의하는 것도 의미가 없습니다.

2020년 (말)입니다. 아무도 ~50MiB의 추가 설치 크기에 대해 신경 쓰지 않습니다(그렇다면 너무 나쁩니다).

제 두 대의 주요 컴퓨터는 9년과 12년입니다(최근에 SSD를 시스템 디스크로 설치하여 개선했지만). 많은 사람들이 더 오래된 하드웨어를 사용합니다. 우리가 좋아해서가 아닙니다. 2-3년마다 업데이트할 재정적/기타적 역량이 없습니다. 우리를 이해할 수 없다면 여전히 우리를 놀릴 권리가 없습니다.

PS 그러나 10년 전만 해도 이 50MB에 대해 그렇게 많이 걱정하지 않았을 것입니다.

@an0n666 @sledgehammer999 @glassez

나는 sledgehammer999에 동의합니다.
더 작은 바이너리가 항상 더 좋습니다. 특히 과거 릴리스의 트랙 레코드가 제공됩니다.
많은 사람들이 여전히 느린 인터넷을 가지고 있습니다. 또한 바이너리를 제공하는 웹 사이트는 위치에 따라 일부 사용자에게 느릴 수 있습니다.
이러한 경우 작은 바이너리가 더 빠른 다운로드를 허용합니다. 사람들은 불필요한 블로트웨어가 의심되는 경우 업데이트를 꺼릴 수 있습니다.

자, 응용 프로그램 다운로드는 일회성 비용입니다. 10Mb/s에서도 추가 50MiB는 추가 50초에 불과합니다. 이 사람들이 그것에 대해 귀찮게한다면 차라리 여기 와서 문제를 스스로 해결하는 것이 좋습니다. 50MiB에 대해 불평하는 강박적이고 강박적인 사람들에게 휘둘리지 않도록 하십시오. 그 때문에 uT 2.2.1로 다시 전환하고 싶습니까? 괜찮은. 소말리아에서도 평균 10Mb/s를 얻을 수 있습니다. https://www.speedtest.net/global-index , BitTorrent 클라이언트가 대부분의 소말리아 원주민의 주요 관심사인지 의심스럽습니다. 빌드는 Fosshub와 Sourceforge 모두에서 제공되며 Kim Kardashian이 모든 팬에게 qBittorrent 또는 기타를 다운로드하도록 지시하지 않는 한 병목 현상이 발생하지 않을 것입니다.

또한,

더 작은 바이너리가 항상 더 좋습니다. 특히 과거 릴리스의 트랙 레코드가 제공됩니다.

인용이 필요합니다. "더 나은 트랙 레코드"와 "더 작은 바이너리 크기" 사이의 상관관계는 어디에 있습니까? 무엇에 대한 더 나은 기록? 성능? 신뢰할 수 있음?

무엇의 기본 빌드 시스템?

그는 심지어 qmake/autotools가 더 이상 사용되지 않는다고 선언했습니다. https://github.com/qbittorrent/qBittorrent/wiki

이 임의성이 정말로 화를 내기 시작했습니다!

오 와우! 따라서 실제 결정이 아닙니다! 나는 결국 부끄러움을 느끼지 않는다.

우리는 CMake 빌드 시스템이 미래라는 데 동의했습니다. 이전에 여러 번 언급했듯이 두 개의 빌드 시스템을 계속 유지하는 것은 실수입니다. 이것은 최근 기여에서도 언급되었습니다: https://github.com/qbittorrent/qBittorrent/pull/13509#issuecomment -708072078

블로트웨어에 대해 말하자면: 2개의 빌드 시스템을 유지 관리하는 데 따른 중복 작업을 보십시오. 저장소에 있는 autotools bloat의 여러 파일을 보십시오.

다른 빌드 도구, 빌드 시스템 등에 대한 쓸데없는 대화로 @sledgehammer999 의 주의를 산만하게 하지 마십시오. 다음 릴리스가 일반적인 방식으로 완료되도록 하십시오. 더 빠르고 안정적입니다.

지난 몇 달 동안 이 저장소에서 아마도 가장 활동적인 구성원에 대한 또 다른 공격, 특히 빌드 시스템, 도구 등의 분야에서 중요한 공헌을 한 구성원에 대한 또 다른 공격이 있습니다. 빌드 시스템에 대한 새로운 빌드와 수정은 더 안정적입니다. 제 기억으로는 단순히 새로운 방식으로 빌드하면 문제가 사라진 경우도 있었습니다. 제 노력 덕분에 이제 사용자에게 훨씬 더 빠르게 안정적인 빌드를 제공할 수 있습니다. 확실히 쓸모가 없습니다. 정식 발매 전까지는 이를 더욱 개선할 계획이 있는데, 계속 그렇게 제 참여를 폄하하신다면 저를 믿지 마세요.

나는 그의 주의를 산만하게 하는 것이 아니라 지난 몇 달 동안의 중요한 발전에 대해 그에게 알리고 있습니다. 따라잡을 책임은 그에게 있습니다.
이제 그 썰매가 돌아왔으니 누구보다 건물 밖으로 나가게 하고 싶지만 _맞아_ 하고 싶어요. 썰매가 돌아온다는 것은 우리가 예전 방식으로 돌아가야 한다는 것을 의미해서는 안 되며(이 릴리스가 타협처럼 느껴지더라도), 우리가 원하는 위치에 도달하기 위해 _더 빠르게_ 진화할 수 있음을 의미해야 합니다.

구성원 중 한 명이 오랫동안 사라지더라도 프로젝트를 계속 진행할 수 있도록 조직 문제를 해결할 시간이 필요합니다.

문제의 일부는 50MiB(나중에 해결할 수 있음) 때문에 골치 아픈 일을 건너뛰고 노후화되고 유지 관리가 덜 쉬운 빌드 시스템으로 빌드를 수동으로 한 사람에게 의존하는 것입니다. 이를 위해 CI에서 사용하는 툴체인. 지금은 실제로 큰 문제가 아니더라도 잘못된 원칙이자 선례입니다.

또한 libtorrent-2.0에 대한 지원이 없고 언제 완전히 구현될지 예측할 수 없기 때문에 향후 릴리스(및 전체 향후 분기)와 관련하여 libtorrent-2.0을 논의하는 것도 의미가 없습니다.

libtorrent 2.0에 대해 이야기할 필요가 전혀 없습니다. V2 지원에 대한 일부 언급이 변경 로그의 커밋 메시지에 나타날 것이라는 사실에도 불구하고 V2에 대한 지원이 여전히 존재하지 않는다는 것을 설명하는 작은 메모입니다. 예: 19d77b0881dc777b7930106869854067e5b2faba. (물론 4.3.0 릴리스에 대한 커밋을 선택하지 않는 한 IMO가 복잡해집니다.)

제 두 대의 주요 컴퓨터는 9년과 12년입니다(최근에 SSD를 시스템 디스크로 설치하여 개선했지만). 많은 사람들이 더 오래된 하드웨어를 사용합니다. 우리가 좋아해서가 아닙니다. 2-3년마다 업데이트할 재정적/기타적 역량이 없습니다. 우리를 이해할 수 없다면 여전히 우리를 놀릴 권리가 없습니다.

PS 그러나 10년 전만 해도 이 50MB에 대해 그렇게 많이 걱정하지 않았을 것입니다.

저사양 사용자를 "조롱한" 부분을 지적해 주십시오. 나도 12년 된 C2D 랩톱에 SSD를 설치했는데(연결은 SATA II만 가능합니다!) 여전히 자주 사용합니다. 나는 또한 지난 3년 동안 만들어진 프로세서가 있는 기계를 소유하고 있지 않으며 앞으로 AMD Ryzen을 얻을 수 있기를 바랍니다. 나는 확실히 "2-3년마다 업그레이드"하지 않습니다. 나는 당신을 이해하고 동의합니다. 나는 단지 요즘 데스크탑/노트북에서 50MiB에 대해 불평하는 사람들을 조롱했습니다(읽기: 지난 15년 이상).

지난 몇 달 동안 이 저장소에서 아마도 가장 활동적인 구성원에 대한 또 다른 공격

내 의견에서 숨겨진 하위 텍스트를 찾는 것을 중단하십시오. 나는 내가 말한 것을 말했다. 나는 당신의 반응이 누군가를 혼란스럽게하지 않기를 바랍니다.

나는 그의 주의를 산만하게 하는 것이 아니라 지난 몇 달 동안의 중요한 발전에 대해 그에게 알리고 있습니다. 따라잡을 책임은 그에게 있습니다.

모든 것에는 시간과 장소가 있습니다.
그가 다음 릴리스를 할 시간도 없고 그가 다시 사라지기 전에 프로젝트의 관리/유지 보수를 재구성할 시간도 없다는 사실로 이어질 수 있다면 왜 지금 여기에서 @sledgehammer999 를 누르십시오. 그의 부재 중에 본격적인 작업을 계속할 수 있습니다.

libtorrent 2.0에 대해 이야기할 필요가 전혀 없습니다. V2 지원에 대한 일부 언급이 변경 로그의 커밋 메시지에 나타날 것이라는 사실에도 불구하고 V2에 대한 지원이 여전히 존재하지 않는다는 것을 설명하는 작은 메모입니다.

변경 로그가 git history를 맹목적으로 복사해서는 안 된다고 반복해서 언급했습니다. 다음 사항을 염두에 두어야 합니다.

1. 일부 커밋은 단일 수정/개선/기능의 일부이므로 전체를 언급하는 것이 좋습니다.
2. 일부 커밋은 이전 릴리스에 없었던 중간 오류를 수정하므로 언급하는 것은 의미가 없습니다.
3. 일부 커밋은 완료되지 않은 작업의 일부이므로 언급하는 것은 의미가 없습니다.

@sledgehammer999
문제 #13519에 대해 알림을 받으십시오.

편집: 잘못된 경보: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710744534
EDIT(FranciscoPombal) 잘못된 경보가 아님: https://github.com/qbittorrent/qBittorrent/issues/13519#issuecomment -710911209

@sledgehammer999 @Chocobo1 @glassez

대량 핑에 대해 유감스럽게 생각합니다. 하지만 이것도 상당히 중요하고 불행하게도 지금은 약간 엉망입니다(이 시점에서 문제가 실제로 무엇인지 혼란스럽기도 합니다): https://github.com/ qbittorrent/qBittorrent/issues/13389. 어쩌면 당신 중 한 명이 그것에 대해 새로운 빛을 비출 수 있습니까?

한 가지는 확실합니다. 첫 번째 4.3.x 릴리스로 모든 사람의 *arr 설정을 깨는 위험을 감수하고 싶지 않습니다.

이것도 상당히 중요해 보입니다. 불행히도 지금 당장은 약간 엉망입니다(이 시점에서 문제가 실제로 무엇인지 혼란스럽기도 합니다): #13389. 어쩌면 당신 중 한 명이 그것에 대해 새로운 빛을 비출 수 있습니까?

한 가지는 확실합니다. 첫 번째 4.3.x 릴리스로 모든 사람의 *arr 설정을 깨는 위험을 감수하고 싶지 않습니다.

마지막에 겁먹지 마시기 바랍니다. 뭐가 문제 야? (애플리케이션 로직을 이해하는 데 문제가 있는 것 외에도.) 관련 코드를 변경하지 않았습니까? 나는 확실히 전체 스레드를 읽지 않았습니다. 앱에 버그가 있다는 명백한 증거가 있으면 특정 의견을 알려주십시오.

@glassez

마지막에 겁먹지 마시기 바랍니다. 뭐가 문제 야? (애플리케이션 로직을 이해하는 데 문제가 있는 것 외에도.) 관련 코드를 변경하지 않았습니까? 나는 확실히 전체 스레드를 읽지 않았습니다. 앱에 버그가 있다는 명백한 증거가 있으면 특정 의견을 알려주십시오.

아무도 놀라지 않습니다. 우리는 잠재적인 결과를 인식하기만 하면 됩니다. 요점은 다른 사람이 명확한 머리로 스레드를주의 깊게 읽는 것입니다. 문제를 해결하려고 할 때 최근 변경 사항에 대한 정당한 회귀인지 사용자가 잘못 표시했는지, 또는 최근 문구 변경으로 인해 예상치 못한 결함이 노출되었는지 등을 확신할 수 없었습니다. 이것은 내가 실제로 *arr 소프트웨어를 사용한 적이 없다는 사실에 의해 복잡해졌지만 많은 사람들이 사용한다는 것을 알고 있습니다. 그럼에도 불구하고 *arr 저장소의 원본 보고서는 다음과 같습니다. https://github.com/Radarr/Radarr/issues/5032 https://github.com/Sonarr/Sonarr/issues/3968 살펴보고 싶습니다.

안녕하세요 여러분,

누군가가 이전 댓글에서 FOSHUB에 대해 언급한 것을 보았습니다. 스레드를 읽고 이 말을 하고 싶습니다. qBittorrent에 약 50MB가 있다고 가정하면 이는 우리에게 아무런 차이가 없습니다. 트래픽 급증과 마찬가지로 누군가 Kim Kardashian을 언급했습니다. 그녀가 qBittorrent를 추천하도록 하십시오. 나는 우리가 내려가지 않을 것이라고 확신합니다. 우리는 그 트래픽을 흡수할 수 있습니다. 예를 들어, 새로운 qBittorrent가 출시될 때마다 초당 수천 건의 업데이트 요청을 보았습니다.

내가 말하려는 것은 당신이 이것에 대해 걱정할 필요가 없다는 것입니다.

감사합니다!

내 1.5cents는 어떤 이유로 든 msvc2019에서 더 멋지게 빌드하고 실행합니다.
50MB의 디스크 공간은 2020년에 전혀 의미가 없습니다. 시스템이 그렇게 제한되어 있다면 어쨌든 더 가벼운 클라이언트 또는 qbt-cli를 실행하고 있는 것입니다.

버그를 일으키지 않고 완료할 수 있을 때 프로젝트를 가장 최신의 가장 좋은 것으로 미루지 마십시오. 더 오래 기다릴수록 뒤쳐지고 지원되지 않는 죽은 컴파일러에 갇힐 위험이 있습니다. 누구에게도 재미가 없습니다

썰매는 설치 프로그램 크기가 12MiB 증가한 후에도 열리는 이와 같은 문제를 언급한 것 같습니다.
https://github.com/qbittorrent/qBittorrent/issues/12247

따라서 사람들이 발행 티켓을 생성하는 길이는 50MiB가 아니라 12MiB에 불과합니다.

@sledgehammer999 "IF" 다음 릴리스에서 Qt 5.15.0/5.15.1 을 사용할 예정입니다. (태그 하나를 선택하면 컨텍스트 메뉴가 닫힙니다) #13492에 유의하십시오.

간단히 말해서 4.3으로 레이블이 지정되면 설치 프로그램이 더 크다고 아무도 불평하지 않을 것이라고 생각합니다. 당연히 예상할 수 있을 것입니다! 구식 도구 체인을 유지하는 것은 솔직히 qBittorrent의 릴리스 프로세스를 적절하게 표현하는 것처럼 느껴집니다.

마침내 이런 일이 일어나는 것을 보고 흥분해서 올해에 무언가를 볼 수 있다는 희망을 거의 포기했습니다.

썰매는 설치 프로그램 크기가 12MiB 증가한 후에도 열리는 이와 같은 문제를 언급한 것 같습니다.

12247

>

따라서 사람들이 발행 티켓을 생성하는 길이는 50MiB가 아니라 12MiB에 불과합니다.

그래서? 그러한 티켓에 대한 유일한 적절한 응답은 "무엇이든 간에."입니다. 나는 이 사람들을 위해 몸을 뒤로 구부리는 강박관념을 이해하지 못합니다. https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708436739에서 말했듯이, 우리는 물론 이러한 크기 증가를 방지하기 위해 항상 최선을 다할 것이지만 50을 위해 다른 것을 희생해서는 안됩니다. MiB, 그게 귀찮다면 여기 와서 스스로 고칠 수 있습니다.

우리는 다른 것을 희생해서는 안됩니다

죄송합니다. 하지만 가장 최신의(의심스러운) 컴파일러를 사용하지 않음으로써 우리가 무엇을 희생하는지 정말 모르겠습니다. 최신 컴파일러로 가는 것은 아무 것도 없습니다. msvc2017이 고대 컴파일러인 것은 아닙니다.

@sledgehammer999

죄송합니다. 하지만 가장 최신의(의심스러운) 컴파일러를 사용하지 않음으로써 우리가 무엇을 희생하는지 정말 모르겠습니다. 최신 컴파일러로 가는 것은 아무 것도 없습니다. msvc2017이 고대 컴파일러인 것은 아닙니다.

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

내 1.5cents는 어떤 이유로 든 msvc2019에서 더 멋지게 빌드하고 실행합니다.

앞서 언급했듯이 나는 이슈 트래커나 다른 커뮤니케이션 채널에서 이와 같은 다른 계정을 기억합니다. 나는 이것을 꾸미고 있지 않다.

그럼에도 불구하고, 사용하지 않는 아주 좋은 이유가 없는 한 항상 최신 도구 모음을 사용하려고 시도해야 합니다(이유 내에서, 그러나 MSVC 2019는 이 시점에서 성숙함). 또한 MSVC 2019 빌드는 저, xavier2k6 또는 다른 사람이 제공하거나 더 최근에는 공식 GitHub Actions 워크플로를 통해 지난 몇 달 동안 광범위하게 전투 테스트를 거쳤습니다. 많은 사람들이 말하려고 하는 것처럼 50MiB는 좋은 이유가 아닙니다. 50MiB 이상에 집착하는 사람들에게 자신을 괴롭히지 마십시오!! 내가 개인적으로 그 보고서를 처리할 것입니다, 당신은 그것들을 볼 필요조차 없을 것입니다.

MSVC2019로 업그레이드하는 데 시간이 많이 걸리나요? 그렇지 않은 경우의 경우 일 뿐입니다. 따라서 이 릴리스가 아니라면 다음 릴리스는 일반적으로 거의 몇 달 간격입니다.

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -711123971은 최신 라이브러리 및 qbt 코드를 사용하여 영향을 받을 가능성이 가장 높은 하나의 주관적인 보고서입니다. 컴파일러 때문이 아닙니다.

MSVC2019로 업그레이드하는 데 시간이 많이 걸리나요? 그렇지 않은 경우의 경우일 뿐입니다. 따라서 이 릴리스가 아니라면 다음 릴리스는 일반적으로 거의 몇 달 간격입니다.

이유는 https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -708055242에 나와 있습니다.

50MiB 이상에 집착하는 사람들에게 자신을 괴롭히지 마십시오!!

'최신'과 '위대함'에 집착하는 이들에게도 괴롭힘을 당하지 않겠습니다. 그리고 차이점은 실제로 68MB의 추가 스토리지입니다(로컬 정적 빌드를 수행했습니다). msvc2017이 작동합니다! 추가 공간이 필요하지 않습니다.

13505(코멘트)는 최신 libs 및 qbt 코드를 사용하여 영향을 받을 가능성이 가장 높은 주관적인 보고서 중 하나일 뿐입니다. 컴파일러 때문이 아닙니다.

그리고 MSVC 2019가 혜택을 전혀 제공하지 않는다는 귀하의 의견도 근거 없는 주장입니다.

'최신'과 '위대함'에 집착하는 이들에게도 괴롭힘을 당하지 않겠습니다. 그리고 차이점은 실제로 68MB의 추가 스토리지입니다(로컬 정적 빌드를 수행했습니다). msvc2017이 작동합니다! 추가 공간이 필요하지 않습니다.

나쁜 컴백. 최신 도구 모음을 옹호하는 사람은 아무도 당신을 "왕따"시키지 않습니다. 최신 툴체인을 고수하는 것이 객관적으로 더 나은 정책입니다. 특히 그것에 반대하는 유일한 주장이 조금 더 큰 바이너리를 생성한다는 것(일부 임베디드 플랫폼용으로 개발하지 않음)인 경우 더욱 그렇습니다. 게다가 지난 _개월_ 동안 대부분의 사용자와 기여자가 사용한 CI와 다른 도구 체인으로 릴리스를 만드는 것은 좋은 정책이 아닙니다. 그리고 무엇보다도 이진 팽창에 대한 비교적 간단한 수정 사항이 있을 수 있습니다. 50MiB 친구에게 문제를 찾는 데 에너지를 투자하도록 요청하십시오. 문제가 너무 귀찮다면 50MiB에 대해 불평하는 것보다.

(msvc2017 =>msvc2019)는 다른 문제 _WHEN_에서 논의/논쟁/토론할 수 있습니다. 필요하게 됩니다.

msvc2019는 C++17로 전환하면 훨씬 더 관련성이 높아집니다.

또한 Qt가 msvc2019 & drop(windows 7/8/8.1 및 32비트 지원) 을 요구할 때 Qt 6.0/6.1/6.2로의 이동과 관련성이 높아집니다(아직 구현하려면 멀었습니다)

Qt 6.0의 개발 호스트 및 대상

Qt 6.0 개발 호스트

Qt 6.0 개발 목표

Qt 6.1 개발 호스트

Qt 6.1 개발 목표

나는 컴파일러에 대해 더 이상 논쟁하지 않을 것입니다. qbt에 대해 특별히 동의하지 않습니다. msvc2019는 C++17로 전환하면 훨씬 더 관련성이 높아집니다.

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

지금은 여기를 한 번만 다시 주차할 수 있나요?

4.2.x/4.3.x를 출시합시다!

(msvc2017 =>msvc2019)는 필요할 때 다른 문제에서 논의/논쟁/토론할 수 있습니다.

지금은 여기를 한 번만 다시 주차할 수 있나요?

4.2.x/4.3.x를 출시합시다!

이봐, 나는 다른 누구와 함께 이것을 끝내고 싶지만, 당신을 포함하여 다른 모든 사람들이 MSVC 2019를 사용하고 테스트한 릴리스의 마지막 순간에 도구 체인을 변경하는 것은 솔직히 무책임합니다. 지난 _개월_. 이 렌즈에서 볼 때 이번 릴리스에 MSVC 2019를 사용하는 것이 매우 "필수적"이라고 생각합니다.

개인적으로 저는 이 게임에 많은 스킨을 가지고 있습니다. 문제가 발생하면 "야간/CI 빌드가 제대로 작동했지만 릴리스가 작동하지 않는" 등의 대부분의 버그 보고서를 처리하게 됩니다. 그리고 예, 나는 그것을 다룰 "필요가 없습니다"라는 것을 압니다. 하지만 피할 수 있는 이유로 출시 후 프로젝트가 새로운 문제로 가득 차기를 원하지 않습니다. CI와 동일하거나 유사한 방식으로 컴파일된 라이브러리로 릴리스가 완료되지 않을 정도로 이미 나쁩니다.

내가 프로젝트에 들인 시간과 노력과 이슈 트래커를 관리하는 것을 포함하여 이 모든 것이 50MiB 이상에 집착하는 사람보다 더 중요하지 않다는 것이 나를 당황하게 합니다. 이 사람들은 누구입니까? 그들은 프로젝트를 위해 무엇을 했는가?

@FranciscoPombal 여기서 더 이상의 컴파일러 논의는 하지 않겠습니다. 내 말은 최종적이다. 릴리스는 msvc2017로 만들어집니다.

내가 올바르게 기억한다면 Qt 5.15만이 "공식적으로" msvc2019를 지원합니다. 그들은 Qt 5.15까지 msvc2019에서 ci 실행을 시작하지 않았습니다.
그리고 그는 앞에서 언급한 버그 때문에 어쨌든 qt 5.15로 출시할 수 없습니다.

이봐, 나는 다른 누구와 함께 이것을 끝내고 싶지만, 당신을 포함하여 다른 모든 사람들이 MSVC 2019를 사용하고 테스트한 릴리스의 마지막 순간에 도구 체인을 변경하는 것은 솔직히 무책임합니다. 지난 달. 이 렌즈에서 볼 때 이번 릴리스에 MSVC 2019를 사용하는 것이 매우 "필수적"이라고 생각합니다.

MSVC 2017 빌드는 전체 4.2.x 릴리스 주기로 테스트되었으며 어쨌든 msvc 2019에는 새로운 것이 많지 않으며 msvc 2017에는 여전히 주류 릴리스 주기가 있습니다. 왜 "최신 및 최고"에 집착하는지 이해할 수 없습니다. .

@xavier2k6

게다가 다음 "큰" 릴리스 전에 추가 50MiB "문제"를 수정하지 않는다고 가정합니다. 그러면 우리 모두가 같은 토론을 하게 될까요? 그것 때문에 Qt 6으로의 업그레이드를 연기할 것인가? 50MiB보다 중요하거나 중요하지 않은 것은 무엇입니까? 우리는 단지 카펫 아래서 문제를 휩쓸고 있을 뿐입니다. 그것은 나쁜 선례입니다.

힌트, 나는 시간이 지남에 따라 다른 사람들로부터 본 의견에 따르면 Qt6으로의 업그레이드가 이 3가지 이유 모두로 인해 합리적인 것보다 훨씬 더 오래 연기될 것이라고 거의 보장할 수 있습니다. 50MiBs 설치 프로그램 크기, Windows 7 지원 유지, 32비트 빌드 지원 유지.

@jagannatharjun Qt 5.15.1은 msvc2017에서 잘 빌드됩니다. 연결된 유일한 문제는 태그를 선택할 때 컨텍스트 메뉴가 닫히는 것에 관한 것입니다. IMO, 차단기가 아닙니다. Qt 5.15는 훨씬 더 나은 HiDPI 지원을 제공합니다.

@FranciscoPombal 나는 당신이 어디에서 왔는지 이해할 수 있으며 여기에서 당신의 작업은 매우 감사합니다!

귀하가 지적한 사항은 관련이 있지만 불행히도 "새 릴리스"를 출시하는 현재 시간 프레임이 이 논의를 허용하지 않는다고 생각합니다....(현재)

나는 당신이 "최신"과 "최고"에 집착하는 이유를 이해할 수 없습니다.

객관적으로 우월한 정책은 "집착"이 아닙니다. 당신은 내가 다른 어리석은 집착에 집착하지 않는 것에 집착한다고 말할 수 있을 것 같습니다. 그러나 나에게 호의를 베풀고 나에게 이것을 투영하지 마십시오. 예? 그것은 당신의 요점을 강화하지 않습니다.

여러분은 합리적인 속도의 업그레이드/현대화를 "집착"으로 유지하고 설치 프로그램에서 50MiB보다 더 중요하지 않도록 진지하게 고려하고 있습니다. 젠장.

@jagannatharjun Qt 5.15.1은 msvc2017에서 잘 빌드됩니다. 연결된 유일한 문제는 태그를 선택할 때 컨텍스트 메뉴가 닫히는 것에 관한 것입니다. IMO, 차단기가 아닙니다. Qt 5.15는 훨씬 더 나은 HiDPI 지원을 제공합니다.

동의합니다. 컨텍스트 메뉴 태그 버그는 불행하지만 HiDPI 버그는 훨씬 더 심각하며 시간이 지남에 따라 더 많은 보고서를 생성합니다.

@FranciscoPombal 나는 당신이 어디에서 왔는지 이해할 수 있으며 여기에서 당신의 작업은 매우 감사합니다!

좋은 농담.

귀하가 지적한 사항은 관련이 있지만 불행히도 "새 릴리스"를 출시하는 현재 시간 프레임이 이 논의를 허용하지 않는다고 생각합니다....(현재)

나는 다른 것을 할 수 없다고 본다. 오 글쎄.

@FranciscoPombal 나는 당신이 어디에서 왔는지 이해할 수 있으며 여기에서 당신의 작업은 매우 감사합니다!

좋은 농담.

@FranciscoPombal 진심으로?? - 농담 이 아니라 개인적으로 진심이었습니다!!!

귀하가 지적한 사항은 관련이 있지만 불행히도 "새 릴리스"를 출시하는 현재 시간 프레임이 이 논의를 허용하지 않는다고 생각합니다....(현재)

나는 다른 것을 할 수 없다고 본다. 오 글쎄.

이 상황을 개인적으로/심장하게 받아들이지 마십시오......ok
........... 심호흡
프로젝트에서의 노력의 일부가 새 릴리스를 통해 "주요 대중"을 볼 수 있도록 하십시오. (현재는 여기에 와서 참여/기부/구축 등을 하는 나와 같은 사람들만 볼 수 있습니다.

방금 staging_v4_3_x 분기를 푸시했습니다. 기본적으로 업데이트된 변경 로그가 있는 마스터입니다.
Changelog 를 살펴보고 잘못된 부분이나 놓친 부분이 있으면 알려주세요.
@glassez

1. #13234에 사용자 대면 속성이 있습니까? 변경 로그에 있어야 하는 것? 예: "수백 개의 토렌트로 세션의 로딩 속도 향상".
2. #13395의 목적은 무엇입니까? 그것은 무엇을합니까? 변경 로그에 무언가를 포함해야 합니까?

잠시 후 이 스레드에서 언급된 일부 커밋이 릴리스에 포함되지 않을 수 있는 문제를 살펴보겠습니다. 계속 알려 드리겠습니다.

@sledgehammer999

또한 그 과정에서 PPA를 정리하십시오. 18.04 , 20.04 및 20.10 이외의 Ubuntu 릴리스는 EOL이므로 해당 버전을 대상으로 하는 빌드의 아카이브는 최대한 빨리 제거해야 합니다.

Ubuntu 14.04 및 16.04는 EOL이 아닙니다. 그 목록을 어디서 얻었습니까?
https://wiki.ubuntu.com/Releases

@sledgehammer999 변경 로그에 대해 https://github.com/qbittorrent/qBittorrent/pull/13188 을 놓친 것 같습니다.

또한 변경 로그에 메모를 추가할 수 있습니까?
"이전 테마 번들은 번들 파일 형식의 변경으로 인해 이번 릴리스에서 제대로 작동하지 않습니다. 수정을 위해 테마 제공자에게 문의하십시오. 새 형식에 대한 자세한 내용은 https://github.com/qbittorrent/ 에서 확인할 수 있습니다.
사실 이것은 https://github.com/qbittorrent/qBittorrent/pull/12755/files 때문입니다.

RC1_1 libtorrent에 대한 지원이 중단되었음을 언급해야 한다고 생각합니다.

또한 누군가가 이 버전에서 더 빠른 트래커 알림 속도를 원하거나 더 느린 클라이언트 종료(4.2.x와 비교)를 갖고 있는 경우 고급 설정에서 "최대 동시 HTTP 알림" 제한을 늘리려고 할 수 있습니다.

#13234에 사용자 대면 속성이 있습니까? 변경 로그에 있어야 하는 것? 예: "수백 개의 토렌트로 세션의 로딩 속도 향상".

죄송합니다. 모든 것이 기억나지 않습니다. 대부분 내부 개선 사항이었습니다. PR 설명의 다음 부분은 "사용자 대면 속성"에 맞을 수 있습니다.

예를 들어 "파일 누락" 상태와 같은 일부 상황에서 이력서 데이터를 올바르게 저장할 수 있습니다(이전에 이를 방지하려고 했지만 사용자는 예를 들어 그러한 토렌트의 일부 속성을 변경할 때 실제로 수행할 수 있음).

#13395의 목적은 무엇입니까? 그것은 무엇을합니까? 변경 로그에 무언가를 포함해야 합니까?

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

RC1_1 libtorrent에 대한 지원이 중단되었음을 언급해야 한다고 생각합니다.

👍

기능: v2 토렌트 생성 지원 추가(libtorrent 2.0.x 필요) (Chocobo1)

젠장! qBittorrent는 이미 libtorrent-2.0을 지원합니까? 있는 그대로 언급하는 이유는 무엇입니까? 우리는 이미 그것에 대해 이야기했습니다.

또한 변경 로그에 메모를 추가할 수 있습니까?
"이전 테마 번들은 번들 파일 형식의 변경으로 인해 이번 릴리스에서 제대로 작동하지 않습니다. 수정을 위해 테마 제공자에게 문의하십시오. 새 형식에 대한 자세한 내용은 https://github.com/qbittorrent/ 에서 확인할 수 있습니다.
사실 이것은 https://github.com/qbittorrent/qBittorrent/pull/12755/files 때문입니다.

나는 이것을 웹사이트의 "뉴스" 섹션에 추가할 것이라고 생각합니다. 변경 사항 외부, 소개 텍스트에서.

RC1_1 libtorrent에 대한 지원이 중단되었음을 언급해야 한다고 생각합니다.

좋아요.

또한 누군가가 이 버전에서 더 빠른 트래커 알림 속도를 원하거나 더 느린 클라이언트 종료(4.2.x와 비교)를 갖고 있는 경우 고급 설정에서 "최대 동시 HTTP 알림" 제한을 늘리려고 할 수 있습니다.

이것을 변경 로그에 항목으로 언급해야 합니까?

젠장! qBittorrent는 이미 libtorrent-2.0을 지원합니까? 있는 그대로 언급하는 이유는 무엇입니까? 우리는 이미 그것에 대해 이야기했습니다.

그런 다음 이 항목을 v4.4.0 릴리스 항목(v4.3.0 변경 로그의 일부가 아님) 아래로 이동합니다. 공식 libtorrent-2.0 지원이 더 일찍 도입되지 않는 한. 만족스럽습니까?

업데이트된 변경 로그는 다음과 같습니다. https://github.com/qbittorrent/qBittorrent/commit/0302e8abbc545d13b7be51e011d2795a9bb3ea73

이것을 변경 로그에 항목으로 언급해야 합니까?

뉴스로 올려주시면 더 좋을 것 같아요. 수천 개의 토렌트/토렌트당 많은 트래커를 사용하는 사용자는 느린 알림 동작을 알 수 있습니다.

다시 업데이트됨: https://github.com/qbittorrent/qBittorrent/commit/727dec97540091f891991113299fa38468e13885

발표: 아주 약간의 지연이 예상됩니다. 이메일을 통해 통보받은 보안 문제로 인해 부분적인 툴체인 재컴파일을 수행해야 합니다. 자세한 내용은 출시 후 며칠 후에 제공될 예정입니다. IMO의 경우 악의적인 사람이 로컬 액세스 권한을 갖고 있거나 이미 시스템에서 악성 애플리케이션을 실행해야 하기 때문에 심각도는 경미할 수 있습니다. 두 경우 모두 qbt의 보안 문제가 없어도 이미 망했습니다.

Ubuntu 14.04 및 16.04는 EOL이 아닙니다. 그 목록을 어디서 얻었습니까?

아마도 잘못된 표현일 것입니다. Qt 버전이 최소 요구 사항보다 낮기 때문에 EOL입니다.

좋아요. 이제 모든 것이 설정되었다고 생각하고 빌드를 준비하고 있습니다. v4_3_x 브랜치는 빌드와 함께 푸시됩니다.

@sledgehammer999 댓글이 늦어서 죄송합니다만 (웹사이트의 뉴스 섹션에서) 알려진 메모리 누수, Windows의 잘못된 캐시 설정 로직 등. 영감을 얻기 위해 libtorrent의 1.2.6-1.2.11(1.2.11은 아직 공식적으로 출시되지 않았지만 이미 몇 가지 변경 로그 항목이 있음)을 살펴보고 가장 관련성이 높은 항목을 선택할 수 있습니다.

호기심에 어떤 libtorrent 커밋이 사용됩니까?

좋아, 항상 최신 git 커밋.

@rrrevin

Ubuntu 14.04 및 16.04는 EOL이 아닙니다. 그 목록을 어디서 얻었습니까?
https://wiki.ubuntu.com/Releases

아마도 잘못된 표현일 것입니다. Qt 버전이 최소 요구 사항보다 낮기 때문에 EOL입니다.

글쎄, 나는 정말로 "표준 지원 종료"를 의미했습니다. 어쨌든 정말로 중요한 것입니다. 그 외에는 유료 기업만 지원을 받습니다. 16.04는 기술적으로 아직 "표준 지원 종료" 단계가 아니지만 매우 가깝습니다. 그리고 그에 관계없이 2년 전쯤 qBittorrent가 최소 필수 Qt 버전을 5.9로 충돌시키기 때문에 이에 대한 OOTB 지원이 중단되었습니다.

@sledgehammer999 한 가지 더: https://github.com/qbittorrent/qBittorrent/issues/13492 뉴스에서 알려진 태그 컨텍스트 메뉴 사소한 회귀에 대해 언급하는 것을 고려하십시오.

@sledgehammer999 변경 로그에서 내 PR 중 많은 부분을 신용하지 않았습니다... https://github.com/qbittorrent/qBittorrent/pulls?q=is%3Apr+author%3AFranciscoPombal+is%3Aclosed+milestone%3A4.3.0

@FranciscoPombal 귀하의 모든 CMake PR을 하나의 항목으로 결합했습니다. 내부 코드 정리 PR은 변경 로그에서 언급할 수 없습니다. 여기에는 사용자 대면 수정 사항이 포함되어야 합니다. @Chocobo1의 많은 PR도 마찬가지입니다.
제가 특별히 놓친 부분이 있다면 아래에 언급해주세요. 아직 뒤에서 관리 작업을 하고 있기 때문에 잠시만 기다리겠습니다.

@sledgehammer999

여기에는 사용자 대면 수정 사항이 포함되어야 합니다.

알았어 그래서:

• --> https://github.com/qbittorrent/qBittorrent/pull/13042 는 임베디드 트래커의 공지 버그를 수정하기 때문에 사용자를 대상으로 합니다. <--

• https://github.com/qbittorrent/qBittorrent/pull/12086 , https://github.com/qbittorrent/qBittorrent/pull/13109 및 https://github.com/qbittorrent/qBittorrent/pull/13439 가 아닙니다. 사용자 대면 정리, 그래서 괜찮은 것 같아요.

• https://github.com/qbittorrent/qBittorrent/pull/13288 은 일종의 사용자 대면이라고 생각합니다. 이제 사용자는 CI에서 실험적 빌드를 다운로드할 수 있습니다. 이것이 사용자용으로 간주됩니까?

• 나머지는 CMake 개선 사항(이미 크레딧으로도 제공됨)과 관련되거나 https://github.com/qbittorrent/qBittorrent/pull/13288과 관련하여 이미 크레딧이 적용되었습니다.

/offtopic (다른 시간 동안) - 아마도 비사용자 대면 정리가 "OTHER" 또는 새로운 "CODE HEALTH" 섹션에 포함되어야 합니까? 사용자는 변경 로그에서 그런 종류의 항목을 보고 싶어합니다.

--> #13042는 포함된 추적기의 알림 버그를 수정하기 때문에 사용자에게 표시됩니다. <--

알았어 미안해. 커밋 제목에서 명확하지 않았습니다. 적절한 변경 로그 항목을 제안할 수 있습니까(읽는 사용자를 위해)?

CI 변경 사항은 일반적으로 릴리스와 관련이 없습니다.

/offtopic (다른 시간 동안) - 아마도 비사용자 대면 정리가 "OTHER" 또는 새로운 "CODE HEALTH" 섹션에 포함되어야 합니까? 사용자는 변경 로그에서 그런 종류의 항목을 보고 싶어합니다.

흠, 코드 정리를 위해 OTHER 항목을 추가하겠습니다.

13288은 일종의 사용자 대면이라고 생각합니다. 이제 사용자는 CI에서 실험적 빌드를 다운로드할 수 있습니다. 이것이 사용자용으로 간주됩니까?

IMO, 그런 것은 뉴스에서 대신 언급될 수 있습니다(변경 로그 외부).

IMO, 그런 것은 뉴스에서 대신 언급될 수 있습니다(변경 로그 외부).

어떻게든 다운로드 페이지에 "nightlies" 링크를 넣을 수 있습니다...

~@glassez~ @sledgehammer999

IMO, 그런 것은 뉴스에서 대신 언급될 수 있습니다(변경 로그 외부).

어떻게든 다운로드 페이지에 "nightlies" 링크를 넣을 수 있습니다...

뉴스에서 CI 항목을 언급하기만 하면 실행 파일에 git 기반 버전 관리가 적용되기 전에 "야간" 다운로드 페이지를 더 많은 청중에게 연결하는 것을 주저할 것입니다. 그렇지 않으면 모든 사용자가 다른 모든 야간 버전을 "4.x.xalpha1"로 보고하여 혼란을 야기합니다.

실행 파일의 git 기반 버전 관리. 그렇지 않으면 모든 사용자가 다른 모든 야간 버전을 "4.x.xalpha1"로 보고하여 혼란을 야기합니다.

네, 맞는 말씀입니다.

@sledgehammer999

적절한 변경 로그 항목을 제안할 수 있습니까(읽는 사용자를 위해)?

"일부 경우 실패를 일으키는 임베디드 트래커의 깨진 알림 로직을 수정했습니다."

CI 빌드는 악의적인 목적으로도 사용될 수 있습니다. 악성 PR을 생성하고 나중에 링크를 배포합니다.
나는 웹사이트에 그런 것을 링크하지 않는 것이 좋습니다.

@an0n666

CI 빌드는 악의적인 목적으로도 사용될 수 있습니다. 악성 PR을 생성하고 나중에 링크를 배포합니다.
나는 웹사이트에 그런 것을 링크하지 않는 것이 좋습니다.

이것도 좋은 점입니다. 이전에 이야기한 마스터에서만 빌드하는 야간 빌드용 워크플로 작업을 시작하는 것이 더 나을 것 같습니다. 그러면 그런 일이 일어날 것을 두려워하지 않고 야간 빌드에 연결할 수 있습니다.

릴리스가 이루어집니다.
PPA는 내일 정리될 것입니다.
며칠 후 보안 문제 세부정보를 제공합니다.
조직 변경은 며칠 내로 계획됩니다.

그리고 이 릴리스 주기에 기여해 주신 모든 분들께 항상 감사드립니다.