Qbittorrent: 新しいリリースの準備

作成日 2020年10月12日  ·  80コメント  ·  ソース: qbittorrent/qBittorrent

やあみんな、私は長い間離れていました。 残念ながら、私はこのパンデミックの間に多くのことを扱わなければなりませんでした。 ありがたいことに、ウイルスはありません(そして私はそのようにとどまることを願っています)。

いずれにせよ、新しいリリースは長い間延期されています。
私のメールボックスはいっぱいになり、すべてのメール/通知を実際に読むことはできません。

いつものように、すべての新しいマスターコミットをv4_2_xブランチにバックポートする必要がありますか? 免除されなければならないコミットはありますか?

ローカルツールチェーンを最新の状態にしました。 バックポート/変更ログ/最小限のテストには時間がかかります。 しかし、変更の規模によっては、今週末が実現可能な目標だと思います。

@ qbittorrent/frequent-寄稿者

通常の利用者:ここへの投稿はご遠慮ください。 通知から受信トレイを管理するのに苦労しています。

Project management

最も参考になるコメント

免除されなければならないコミットはありますか?

今は変更をスキップするのは意味がないと思います。

いずれにせよ、新しいリリースは長い間延期されています。

過度に。

いつものように、すべての新しいマスターコミットをv4_2_xブランチにバックポートする必要がありますか?

なぜv4.2.xなのですか? v4.3には十分な変更があります。
さらに、コミットを1つずつ「チェリーピッキング」することでこの不要な作業を行う代わりに、現在のマスターの上にv4_3_xブランチを作成するだけで済みます。

全てのコメント80件

@sledgehammer999これを読む必要があります=> https://github.com/orgs/qbittorrent/teams/bug-handlers/discussions/5

ありがたいことに、ウイルスはありません(そして私はそのようにとどまることを願っています)。

個人的には嬉しいです。

しかし、私はプロジェクトの現状について本当に悲しいです(そして私だけが同じように感じているわけではありません)。 変化の時は非常に重要です。 したがって、プロジェクトの管理/保守を再構築するか、それが自分のおもちゃにすぎないことを明示的に宣言して、他の誰にも誤った希望がないようにする必要があります。

免除されなければならないコミットはありますか?

今は変更をスキップするのは意味がないと思います。

いずれにせよ、新しいリリースは長い間延期されています。

過度に。

いつものように、すべての新しいマスターコミットをv4_2_xブランチにバックポートする必要がありますか?

なぜv4.2.xなのですか? v4.3には十分な変更があります。
さらに、コミットを1つずつ「チェリーピッキング」することでこの不要な作業を行う代わりに、現在のマスターの上にv4_3_xブランチを作成するだけで済みます。

以前のリリースから最新のマスターまでのコミットを確認し終えたところです。 (主にタイトルとPRの説明をコミットします)

なぜv4.2.xなのですか? v4.3には十分な変更があります。

うん。 たくさんのコミットがあります。 そしてlibtorrent1.1.xが削除されたので、それは確かにv4.3.xを保証します。 (そしてlibtorrent2.0.xとc++ 17の場合はv4.4.x!!!)
できるだけ早く、次の変更ログの新しいPRを作成します。

プロジェクト管理について:これについては、週末/次のリリースの後で説明します。

@ sledgehammer999

あなたが戻ってきて、すべてが大丈夫であることをうれしく思います。

いつものように、すべての新しいマスターコミットをv4_2_xブランチにバックポートする必要がありますか? 免除されなければならないコミットはありますか?

新しいバージョン4.3.xにラベルを付けるという提案には無関心です。 決めるのはあなたと他の人次第です。

すべてのコミットは良いAFAIKです。 ただし、非常に重要な修正の多くがlibtorrentにもマージされているため、この新しいリリースでは可能な限り最新のRC_1_2を使用することが重要です。

BitTorrentV2のサポートに関してはすでにいくつかのコミットがあります。 ただし、このリリースは上記のように最新のlibtorrent RC_1_2で構築されると予想されるため、ほとんどのユーザーは実際にはそのいずれも表示されません。 したがって、ユーザーがBitTorrent V2関連のエントリを読んだときに誤った希望を受け取らないように、これを説明するメモを変更ログに入れます。

ローカルツールチェーンを最新の状態にしました。 バックポート/変更ログ/最小限のテストには時間がかかります。 しかし、変更の規模によっては、今週末が実現可能な目標だと思います。

これについて詳しく教えてください。 私はあなたが最新のMSVC2019を持っていると仮定し、依存関係にvcpkgまたは同様のものを使用していることを_願っています_-すべての構築方法のわずかな不一致による奇妙なバグの可能性が少なく、再現性が高くなっています。 インスピレーションを得るために、新しいGitHubActionsCIをチェックアウトできます。 また、今回はCMakeを使用してビルドすることを忘れないでください。これは、新しいデフォルトのビルドシステムになっています。

プロジェクト管理について:これについては、週末/次のリリースの後で説明します。

OK、でも後でではなく早くお願いします。 また、パッケージ化も自動的に行えるように、リリースプロセスの自動化についても引き続き議論する必要があります。

@ sledgehammer999

また、その過程でPPAをクリーンアップしてください。 18.0420.0420.10以外のUbuntuリリースはEOLであるため、これらのバージョンを対象とするビルドのアーカイブはできるだけ早く削除する必要があります。

したがって、この新しいリリースでは、可能な限り最新のRC_1_2を使用することが重要です。

これは言うまでもありません。
Qt 15.1、openssl 1.1.1h、ブースト1.74

RC_2_0はまだ使用されません。 いくつかの公式ベータリリースがないわけではありません。

最新のMSVC2019を使用していると思いますが、vcpkgを使用していることを願っています

いいえ、このリリースではまだmsvc2017を使用しています。 前回msvc2019をチェックしたとき、qbt用の非常に大きな.pdbファイルが生成されました。 後でもう一度確認しますが、このリリースについては確認しません。
残りの依存関係は、私がいつもやってきた方法で構築されています。 ここで多かれ少なかれ説明されています: https ://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019-(static-linkage)

また、今回のビルドにはCMakeを使用することを忘れないでください。これは、新しいデフォルトのビルドシステムになっています

どうやら私はgitログでこれを見逃しました。 私はちょっと困惑していますが、他のすべての人がautotools / qmakeよりもcmakeの使用に慣れているので、実際に反対することはできません。
ただし、当面の間、リリースにはautotools/qmakeを引き続き使用します。 リリースのためにcmakeに慣れるための時間がありません。

誰にも害はありませんが、PPAについてどうするかを見ていきます。

@ sledgehammer999通常のユーザーがここにコメントすることを望まないので、お詫びします......問題やバグなどを潰す目的でここでWindowsビルドを作成しています。

私はMSVC2019でコンパイルし、qBittorrent実行可能ファイルは通常約27 MBで、.pdbは180MBです

/pdbstrippedを使用することを考えましたか?

私はMSVC2019でコンパイルし、qBittorrent実行可能ファイルは通常約27 MBで、.pdbは180MBです

msvc2017および現在のマスターと比較してください:24.4MBのexeおよび98.1MBのpdb。 私が言ったように、pdbはmsvc2017と比較して非常に大きいです。

また、/pdbstrippedは必要ないと思います。 プログラムがクラッシュすると、おそらくあまり役​​に立たないバックトレースが得られます。

また、/pdbstrippedは必要ないと思います。 プログラムがクラッシュすると、おそらくあまり役​​に立たないバックトレースが得られます。

/PDBCompress

@ sledgehammer999

CMake+最新のMSVC2019+ vcpkg(https://github.com/qbittorrent/qBittorrent/actions)を使用する自動CIビルドは、57 MiB(実行可能)+ 122 MiB(pdb)です。

いいえ、このリリースではまだmsvc2017を使用しています。 前回msvc2019をチェックしたとき、qbt用の非常に大きな.pdbファイルが生成されました。 後でもう一度確認しますが、このリリースについては確認しません。

これはIMOの正当な理由ではありません。 MSVC2019には多くの修正が含まれています。 それは(終わりの)2020年です。余分な\〜50 MiBのインストールサイズを気にする人は誰もいません(もしそうなら、あまりにも悪いです笑)。 何かがpdb/実行可能ファイルを肥大化させているかどうかは後でわかりますが、今のところすべてが機能し、追加の\〜50 MiBは、はるかに新しいツールチェーンとのトレードオフです。

また、/pdbstrippedは必要ないと思います。 プログラムがクラッシュすると、おそらくあまり役​​に立たないバックトレースが得られます。

:+1:ですが、これは将来適切に調査することができます。

残りの依存関係は、私がいつもやってきた方法で構築されています。 ここで多かれ少なかれ説明されています: https ://github.com/qbittorrent/qBittorrent/wiki/Compiling-with-MSVC-2019-(static-linkage)

どうやら私はgitログでこれを見逃しました。 私はちょっと困惑していますが、他のすべての人がautotools / qmakeよりもcmakeの使用に慣れているので、実際に反対することはできません。
ただし、当面の間、リリースにはautotools/qmakeを引き続き使用します。 リリースのためにcmakeに慣れるための時間がありません。

:-1 :、これは、ほとんどの人が過去数か月間WindowsでqBittorrentをテストしてきた方法ではありません。 多くの人が私のCIブランチ(CMake + vcpkg)のビルドを使用していましたが、現在はリポジトリ独自のアクションセクションを使用しています。 これを行うと、ビルドプロセスの違いに起因する原因不明のリグレッションが発生する可能性が高いと思います。

@ sledgehammer999リリース前に「ブロッカー」を追加したくありませんが、基本的に準備ができているので、少なくともこれが着陸するのを待ちます: https ://github.com/qbittorrent/qBittorrent/pull/13499

非同期I/Oスレッドのデフォルトの変更は、多くのユーザーにとって有益です。

私はmsvc2019をdissしたくありませんが、あなたは真新しいものすべてをより良いものと見なす上で少し上回っていると思います。 常にそうであるとは限りません。 そして、はい、btクライアントに50MB余分に追加するのは大したことです。 測定可能な利点がなければ、不必要な肥大化はありません(たとえば、プログラムが1.5倍速くなることはありません)。

最後に、ビルドシステムについて:ビルドシステムの変更だけでリグレッションが発生する場合は、コードに重大な問題があります。 ものはそれほど壊れやすいものであってはなりません。

13499は、まだデフォルトではないlibtorrent 2.0.xオプションに関するものであるため、範囲外です。 最後に、週末にカットが行われます。

@ sledgehammer999

私はmsvc2019をdissしたくありませんが、あなたは真新しいものすべてをより良いものと見なす上で少し上回っていると思います。 常にそうであるとは限りません。
そして、はい、btクライアントに50MB余分に追加するのは大したことです。 測定可能な利点がなければ、不必要な肥大化はありません(たとえば、プログラムが1.5倍速くなることはありません)。

私の議論を「新しい=より良い」として単に却下しないでください。 そして、私はあなたが50 MiBのより悪いツールチェーンに固執することで、少し「上を超えている」と思います。 もちろん、ツールチェーンの更新によって「1.5倍」の速度が得られることはありません(または非常にまれです)。 しかし、それは非現実的な基準です。 最近のツールチェーンでは「1.5倍」のスピードアップはないかもしれませんが、常に小さなパフォーマンスの改善、より良い言語サポート、より良いコード生成(時にはバグの減少につながる)があります...オンラインでドキュメント化されたリソースはたくさんありますMSVC2019の改善。

繰り返しになりますが、可能な限り余分な50 MiBを削減する必要があることに同意しますが、次のリリースに間に合うように(またはこれまでに!)それを実行できない場合は、_それで問題ありません_。 また、これがすべてのリリースで再び発生し続けるという意味はありません(その場合もイライラします)。 これは明らかに1回限りの問題です。 ユーザーとして、私は「これがあなたのより悪い品質のバイナリですが、少なくとも私たちはあなたに50 MiB、仲間を節約しました」と聞きたくありません。 50 MiBは、最近の丸め誤差です(とにかく、デスクトッププログラムの場合、もちろん組み込みの世界ではそうではありません)。 申し訳ありませんが、そうでないと考えるとあなたは間違っています。

最後に、ビルドシステムについて:ビルドシステムの変更だけでリグレッションが発生する場合は、コードに重大な問題があります。 ものはそれほど壊れやすいものであってはなりません。

必ずしも。 ビルドシステム自体に重大な問題がある可能性があります。 PRをオーバーホールする前に、CMakeビルドシステムの以前の状態を参照してください。 それ以前は、CMakeでビルドするとかなりの数のバグが発生していました。 いくつかの(時には深刻な!)問題は、実際には正しくない/悪いビルドシステムとビルドレシピに起因します。 コードがどれほど堅牢であっても、間違ってビルドすると壊れてしまい、時には非常に見事ですが、診断が困難になります。

13499は、まだデフォルトではないlibtorrent 2.0.xオプションに関するものであるため、範囲外です。 最後に、週末にカットが行われます。

残りの議論をご覧ください。 このPRは、実際には非同期I / Oスレッドのデフォルト数も変更するため、デフォルトでは、libtorrent1.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に指示する適切なヒントを追加で渡す必要があります。 。 疑わしい場合は、成功するまでconfigureを実行して、各パッケージに関する各エラーメッセージを一度に1つずつ修正します。エラーメッセージは十分に役立つため、何を追加する必要があるかを常に理解して把握することができます。次。

コンパイラについてこれ以上議論するつもりはありません。 特にqbtについては同意しません。 c ++ 17に切り替えると、msvc2019の関連性が大幅に高まります。 最後に、btクライアントユーザーにとって、彼が気にするのは、クライアントがトップダウン/アップスピードを達成できるかどうかだけです。 これは、「より良い」または「より悪い」品質のバイナリのメトリックです。 msvc2017は、余分な肥大化なしにそれを実現します。 --msvc2019でビルドをやり直すまで判断を下します--

-DLibtorrentRasterbar_DIR = C:\ path \ to \ libtorrent-install-dir \ lib \ cmake\LibtorrentRasterbarのように

パッケージのビルド/インストール方法に違いはありますか? 現在、boost、libtorrent、opensslのいずれにもlibの下に$ cmakeフォルダーがありません。 qtのみ。
PS:ブーストとlibtorrentはb2を使用して構築されています。 configureスクリプトを使用した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の気を散らさないでください。次のリリースは通常の方法で実行してください。より高速で、より信頼性が高くなります。 メンバーの1人が長期間失踪したとしても、プロジェクトを浮かび上がらせるには、組織の問題を解決する時間が必要です。
また、libtorrent-2.0はサポートされておらず、いつ完全に実装されるかを予測することさえできないため、今後のリリース(および今後のブランチ全体)のコンテキストでlibtorrent-2.0について説明することは意味がありません。

それは2020年(の終わり)です。誰も余分な〜50 MiBのインストールサイズを気にしません(もしそうなら、あまりにも悪いです笑)。

私の2台のメインコンピューターは9歳と12歳です(最近、SSDをシステムディスクとしてインストールすることでそれらを改善しました)。 多くはさらに古いハードウェアを使用しています。 それは私たちが好きだからではありません。 2〜3年ごとに更新するための財政的/その他の能力がありません。 あなたが私たちを理解することができない場合でも、それはあなたに私たちをからかう権利を与えません。

PSしかし、10年前でも、私はこれらの50メガバイトについてそれほど心配していなかったでしょう。

@ an0n666 @ sledgehammer999 @glassez

sledgehammer999に同意します。
バイナリは小さい方が常に優れています。 過去のリリースの実績を特に考慮。
多くはまだ遅いインターネットを持っています..また、バイナリを提供するウェブサイトは、場所に基づいて一部のユーザーにとって遅い可能性があります。
このような場合、小さなバイナリを使用すると、ダウンロードを高速化できます。 不要なブロートウェアが疑われる場合、更新を思いとどまる可能性があります。

さあ、アプリケーションのダウンロードは1回限りの費用です。 10 Mb / sの場合でも、50MiBを追加すると50秒が追加されます。 これらの人々がそれに悩まされているなら、彼らはここに来て問題を自分で解決するのを手伝うほうがいいです。 約50MiBを訴える強迫神経症の人に押し付けられてはいけません。 そのため、彼らはuT 2.2.1に戻したいですか? 罰金。 ソマリアでも、平均で10 Mb / sを取得できます: https ://www.speedtest.net/global-index、そしてBitTorrentクライアントがほとんどのネイティブソマリアの主な関心事であるとは思えません。 ビルドはFosshubとSourceforgeの両方から提供されますが、Kim KardashianがすべてのファンにqBittorrentなどをダウンロードするように指示しない限り、ボトルネックになる可能性はほとんどありません。

また、

バイナリは小さい方が常に優れています。 過去のリリースの実績を特に考慮。

要出典。 「より良い実績」と「より小さなバイナリサイズ」の間の相関関係はどこにありますか? 何のより良い実績? パフォーマンス? 信頼性?

何のデフォルトのビルドシステム?

彼はqmake/autotoolsが非推奨になると宣言しましたhttps://github.com/qbittorrent/qBittorrent/wiki

この恣意性は本当に激怒し始めています!

ああすごい! したがって、それは実際の決定ではありません! やっぱりバカな感じはしません。

CMakeビルドシステムが未来であることに同意しました。 これまで何度も述べてきたように、2つのビルドシステムを維持し続けるのは間違いです。 これは最近の投稿でも言及されています: https ://github.com/qbittorrent/qBittorrent/pull/13509#issuecomment -708072078

ブロートウェアと言えば、2つのビルドシステムを維持するために私たちが行っている重複した取り組みを見てください。 リポジトリにあるautotoolsの肥大化のいくつかのファイルを見てください。

さまざまなビルドツールやビルドシステムなどについての無駄な会話で@sledgehammer999の気を散らさないでください。次のリリースは通常の方法で実行してください。より高速で、より信頼性が高くなります。

過去数か月間、このリポジトリでおそらく最もアクティブなメンバーに対するさらに別の攻撃であり、特にビルドシステム、ツールなどの分野で重要な貢献をした人。新しいビルドとビルドシステムへの変更はより信頼性が高くなります。 思い出しますが、新しい方法で構築するだけで問題が解消される場合もあります。 私の努力のおかげで、ユーザーの手に渡るより信頼性の高いビルドをはるかに速く取得できるようになりました。 それは確かに役に立たないわけではありません。 私はこれを公式リリースの時点までさらに改善する予定ですが、そのように私の参加を軽蔑し続けるのであれば、私を頼りにしないでください。

私は彼の気を散らすのではなく、過去数ヶ月の重要な進展について彼をスピードアップさせています。 追いつくのは彼の責任です。
そりが戻ってきたので、誰とでも同じようにビルドをドアから出したいのですが、それを_正しく_やりたいと思います。 スレッジが戻ってきたからといって、以前の方法に戻らなければならないわけではありません(このリリースでも妥協のように感じます)。つまり、目的の場所に到達するために_より速く_進化できることを意味するはずです。

メンバーの1人が長期間失踪したとしても、プロジェクトを浮かび上がらせるには、組織の問題を解決する時間が必要です。

問題の一部は、老朽化し​​て保守性の低いビルドシステムを使用してビルドを手動で作成すること、50 MiB(後で解決可能)のためにフープを飛び越えることなどを1人で行うことです。このためだけにCIで使用するツールチェーン。 今はそれほど大きな問題ではありませんが、それは悪い原則であり、前例です。

また、libtorrent-2.0はサポートされておらず、いつ完全に実装されるかを予測することさえできないため、今後のリリース(および今後のブランチ全体)のコンテキストでlibtorrent-2.0について説明することは意味がありません。

libtorrent2.0について話す必要はまったくありません。 V2サポートについてのいくつかの言及が変更ログのコミットメッセージに表示されるという事実にもかかわらず、V2のサポートがまだ存在しないことを説明するほんの小さなメモ。 たとえば、19d77b0881dc777b7930106869854067e5b2fabaです。 (もちろん、4.3.0リリースでこれらのコミットを選択しない限り、IMOは複雑になります)。

私の2台のメインコンピューターは9歳と12歳です(最近、SSDをシステムディスクとしてインストールすることでそれらを改善しました)。 多くはさらに古いハードウェアを使用しています。 それは私たちが好きだからではありません。 2〜3年ごとに更新するための財政的/その他の能力がありません。 あなたが私たちを理解することができない場合でも、それはあなたに私たちをからかう権利を与えません。

PSしかし、10年前でも、私はこれらの50メガバイトについてそれほど心配していなかったでしょう。

私が低スペックのユーザーを「からかった」ところを指摘してください。 私もSSDをインストールした12年前のC2Dラップトップを持っています(接続はSATA IIのみです!)が、今でも頻繁に使用しています。 また、過去3年間に製造されたプロセッサを搭載したマシンを所有していません。将来、AMDRyzenを入手できればと思います。 私は確かに「2〜3年ごとにアップグレードする」わけではありません。 私はあなたを理解し、同意します。 私は最近、デスクトップ/ラップトップで約50 MiBを不平を言う人々をからかったばかりです(読んでください:過去15年以上)。なぜなら、それらの人々はからかわれるに値するからです。

過去数か月間、このリポジトリでおそらく最もアクティブなメンバーに対するさらに別の攻撃

コメントで隠されたサブテキストを探すのはやめてください。 私はちょうど私が言ったことを言いました。 あなたの反応が誰かを混乱させないことを願っています。

私は彼の気を散らすのではなく、過去数ヶ月の重要な進展について彼をスピードアップさせています。 追いつくのは彼の責任です。

すべてに時間と場所があります。
なぜ今ここで@sledgehammer999を押すのか、それが彼が次のリリースを行う時間も、彼が再び消える前にプロジェクトの管理/保守を再構築する時間もないという事実につながるだけであるなら、私たちは彼の不在下で本格的な仕事を続けることができます。

libtorrent2.0について話す必要はまったくありません。 V2サポートについてのいくつかの言及が変更ログのコミットメッセージに表示されるという事実にもかかわらず、V2のサポートがまだ存在しないことを説明するほんの小さなメモ。

変更ログはgit履歴を盲目的にコピーしてはならないことを繰り返し述べました。 次の点に注意してください。

  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

大量のpingを送信して申し訳ありませんが、これもかなり重要なようです。残念ながら、現時点では少し混乱しています(この時点で、実際の問題についても混乱しています): https ://github.com/

1つ確かなことがあります。 最初の4.3.xリリースで全員の*arrセットアップを壊すリスクを冒したくありません。

これもかなり重要なようですが、残念ながら今は少し混乱しています(この時点で、問題が実際に何であるかについても混乱しています):#13389。 たぶんあなたの一人はそれにいくつかの新しい光を当てることができますか?

1つ確かなことがあります。 最初の4.3.xリリースで全員の*arrセットアップを壊すリスクを冒したくありません。

最後からおかしくなり始めないでください。 どうしたの? (アプリケーションロジックの理解に関する問題に加えて。)関連するコードを変更しませんでしたか? 私は確かにスレッド全体を読んでいませんでした。 アプリにバグの明らかな証拠がある場合は、特定のコメントを教えてください。

@glassez

最後からおかしくなり始めないでください。 どうしたの? (アプリケーションロジックの理解に関する問題に加えて。)関連するコードを変更しませんでしたか? 私は確かにスレッド全体を読んでいませんでした。 アプリにバグの明らかな証拠がある場合は、特定のコメントを教えてください。

誰もおかしくなりません。潜在的な結果を認識する必要があります。 重要なのは、他の誰かがスレッドを注意深く、明確な頭で読むことです。 私がそれに取り組んだとき、それが正当な退行なのか、最近の変更のユーザーの不実表示なのか、あるいは最近の言い回しの変更が予期しない欠陥を露呈したのか、それとも何なのかわかりませんでした。 これは、私が実際に*arrソフトウェアを使用したことがないという事実によってさらに複雑になっていますが、多くの人が使用していることを知っています。 とにかく、 *arrリポジトリの元のレポートは次のとおりです: https ://github.com/Radarr/Radarr/issues/5032 https://github.com/Sonarr/Sonarr/issues/3968 、見てみたい。

こんにちはみんな、

以前のコメントで誰かがFOSSHUBについて言及していることに気づきました。 私はスレッドを読み、これを言いたいです。 qBittorrentの容量が約50MBであると仮定すると、それは私たちにとって何の違いもありません。 トラフィックの急増と同じように、誰かがキム・カーダシアンに言及しました。 彼女にqBittorrentを勧めてもらってください。 私たちは下がらないと確信しています。 そのトラフィックを吸収することができます。 たとえば、新しいqBittorrentがリリースされるたびに、1秒あたり数千の更新要求が発生します。

私が言おうとしているのは、これについて心配する必要はないということです。

ありがとう!

私の1.5セントは、何らかの理由でmsvc2019でより適切に構築および実行されます
2020年には50MBのディスクスペースはまったくありません。システムにそのような制約がある場合は、とにかく軽量のクライアントまたはqbt-cliを実行しています。

バグを引き起こさずにプロジェクトを実行できる場合は、プロジェクトを延期しないでください。待機時間が長くなるほど、遅れるリスクが高くなり、サポートされていないコンパイラに固執することは誰にとっても楽しいことではありません。

そりは、インストーラーのサイズがわずか12 MiB増加した後でも、このような問題が発生したことを示していると思います。
https://github.com/qbittorrent/qBittorrent/issues/12247

したがって、発行チケットを作成するのにかかる時間は50 MiBではなく、12MiBだけです。

@sledgehammer999 "IF"次のリリースでQt5.15.0/ 5.15.1を使用する場合は、注意してください(1つのタグを選択するとコンテキストメニューが閉じます)#13492

簡単に言えば、4.3というラベルが付けられるとしたら、インストーラーが大きくなることについて誰も文句を言うことはないでしょう。 時代遅れのツールチェーンを維持することは、qBittorrentのリリースプロセスの適切な表現のように正直に感じます。

ついにこれが起こるのを見て興奮して、私は今年何かを見ることへの希望をほとんどあきらめていました。

そりは、インストーラーのサイズがわずか12 MiB増加した後でも、このような問題が発生したことを示していると思います。

12247

>>

したがって、発行チケットを作成するのにかかる時間は50 MiBではなく、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.5セントは、何らかの理由でmsvc2019でより適切に構築および実行されます

前に述べたように、私はこれに関する他のそのようなアカウントを課題追跡システムまたは他の通信チャネルで思い出します。 私はこれを作り上げていません。

とにかく、そうしない非常に正当な理由がない限り、常に最新のツールチェーンを使用するようにしてください(理由の範囲内ですが、MSVC 2019はこの時点で成熟しています)。 さらに、MSVC 2019ビルドは、私、xavier2k6、または他の人によって提供された、または最近では公式のGitHub Actionsワークフローによって提供された、過去数か月にわたって広範囲にわたるバトルテストが行​​われています。 多くの人があなたに話そうとしているので、50MiBは正当な理由ではありません。 50MiB以上に執着している人にいじめられないように! 私が個人的にそれらのレポートを処理します、あなたはそれらを見る必要さえありません。

MSVC2019へのアップグレードには、かなりの時間がかかりますか? そうでない場合は、それはただの場合ですよね? したがって、このリリースでない場合は、確かに次のリリースであり、特定のリリースは通常、ほぼ数か月離れています。

https://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment -711123971は、最新のライブラリとqbtコードを使用することで影響を受ける可能性が最も高い主観的なレポートの1つにすぎません。 コンパイラのせいではありません。

MSVC2019へのアップグレードには、かなりの時間がかかりますか? そうでない場合は、それはただの場合ですよね? したがって、このリリースでない場合は、確かに次のリリースであり、特定のリリースは通常、ほぼ数か月離れています。

理由はここに記載されていますhttps://github.com/qbittorrent/qBittorrent/issues/13505#issuecomment-708055242

50MiB以上に執着している人にいじめられないように!

「最新で最高」に執着する人たちにもいじめられません。 違いは、実際には68MBの追加ストレージです(ローカル静的ビルドを実行しました)。 msvc2017は正常に機能します! 余分なスペースは必要ありません。

13505(コメント)は、最新のlibsとqbtコードを使用することによって影響を受ける可能性が最も高い主観的なレポートの1つにすぎません。 コンパイラのせいではありません。

また、MSVC 2019がまったくメリットをもたらさないというあなたのコメントも、根拠のない主張です。

「最新で最高」に執着する人たちにもいじめられません。 違いは、実際には68MBの追加ストレージです(ローカル静的ビルドを実行しました)。 msvc2017は正常に機能します! 余分なスペースは必要ありません。

悪いカムバック。 最新のツールチェーンを支持する人は誰もあなたを「いじめ」ません。 最新のツールチェーンに固執することは、客観的にはより良いポリシーです。特に、それに対する唯一の議論が、少し大きなバイナリを生成することである場合(一部の組み込みプラットフォーム用に開発していません)。 さらに、1つのCIとは異なるツールチェーンを使用してリリースを作成することは適切なポリシーではなく、ほとんどのユーザーと寄稿者は過去_か月間_使用しています。 それに加えて、バイナリの肥大化には比較的簡単な修正がある可能性があります-50 MiBの友人に、問題があまりにも気になる場合は、50 MiBについて不平を言うのではなく、問題を見つけるためにエネルギーを投資するように依頼してください。

(msvc2017 => msvc2019)別の問題で議論/議論/議論することができます_WHEN_それが必要になります

c ++ 17に切り替えると、msvc2019の関連性が大幅に高まります。

また、 Qtがmsvc2019ドロップ(Windows 7/8 / 8.1と32ビットのサポート)を必要とする場合、Qt 6.0 / 6.1 / 6.2への移行でより関連性が高くなります(これはまだ実装されていないので、かなり遠いです)

Qt6.0の開発ホストとターゲット

Qt6.0開発ホスト

Qt6.0の開発目標

Qt6.1開発ホスト

Qt6.1の開発目標

コンパイラについてこれ以上議論するつもりはありません。 特にqbtについては同意しません。 c ++ 17に切り替えると、msvc2019の関連性が大幅に高まります。

参照: 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を使用してテストしているときに、リリースの最後の最後にツールチェーンを変更することは率直に言って無責任です過去_か月_。 このレンズから見ると、このリリースでMSVC2019を使用することは非常に「必要」だと思います。

個人的には、このゲームにはたくさんのスキンがあります。何か問題が発生した場合は、「夜間/ CIビルドは正常に機能しましたが、リリースは機能しません」などのタイプのバグレポートの大部分を処理することになります。そして、はい、私はそれに対処する必要がないことを知っています。 しかし、回避できる理由から、リリース後にプロジェクトが新しい問題でいっぱいになることは望ましくありません。 CIと同じまたは同様の方法でコンパイルされたライブラリでリリースが行われないことはすでに十分に悪いことです。

プロジェクトに費やした時間と労力、課題追跡システムの管理など、これらすべてが50MiBを超える人よりも重要ではないことに戸惑います。 これらの人々は誰ですか? 彼らはプロジェクトのために何をしましたか?

@FranciscoPombalここではこれ以上コンパイラについては説明しません。 私の言葉は最後です。 リリースはmsvc2017で行われます。

私が正しく覚えていれば、Qt5.15のみが「公式に」msvc2019をサポートしています。 彼らはQt5.15までmsvc2019でciを実行し始めませんでした
とにかく彼は前述のバグのためにqt5.15でリリースすることはできません。

ほら、私は他の誰とでもこれをやり直したいのですが、あなたを含む他のすべての人がMSVC 2019を使用してテストしているときに、リリースの最後の最後にツールチェーンを変更することは率直に言って無責任です先月。 このレンズから見ると、このリリースでMSVC2019を使用することは非常に「必要」だと思います。

MSVC 2017ビルドは4.2.xリリースサイクル全体でバトルテストされており、とにかくmsvc 2019にはそれほど新しいものはなく、msvc 2017にはまだ主流のリリースサイクルがあります。なぜ、「最新かつ最高」に夢中になっているのか理解できません。 。

@ xavier2k6

さらに、次の「大きな」リリースの前に、余分な50MiBの「問題」を修正しないと仮定します。 それでは、私たち全員がこれと同じ議論をするつもりですか? そのため、Qt 6へのアップグレードを延期しますか? 50 MiBより重要なもの/重要でないものは何ですか? 私たちはカーペットの下で問題を一掃しているだけです、それは悪い前例です。

ヒント、私が他の人から見てきた意見から、Qt6へのアップグレードは、これら3つの理由すべて、場合によってはそれ以上の理由で、合理的よりもはるかに長く延期されることをほぼ保証できます。 50 MiBのインストーラーサイズ、Windows 7のサポートを維持し、32ビットビルドのサポートを維持します。

@jagannatharjunQt5.15.1はmsvc2017で正常にビルドされます。 リンクされている唯一の問題は、タグを選択するときにコンテキストメニューが閉じることです。 IMO、それはブロッカーではありません。 Qt 5.15は、HiDPIサポートを大幅に向上させます。

@FranciscoPombal私はあなたがどこから来ているのか理解できます、そしてここでのあなたの仕事はとても感謝しています!

あなたの指摘には関連性がありますが、残念ながら、「新しいリリース」をリリースする現在の時間枠では、この議論は可能ではないと思います。...(現時点では)

なぜあなたが「最新かつ最高」に夢中になっているのか理解できません。

客観的に優れた政策は「執着」ではありません。 私は他の愚かな執着に対応しないことに夢中になっていると言えるでしょう。 しかし、私に賛成して、これを私に投影するのをやめますか? それはあなたの主張を強化するものではありません。

皆さんは、アップグレード/モダナイゼーションの合理的なペースを「強迫観念」として維持し、インストーラーで50MiBよりも重要ではないことを真剣に検討しています。 イエスは性交する。

@jagannatharjunQt5.15.1はmsvc2017で正常にビルドされます。 リンクされている唯一の問題は、タグを選択するときにコンテキストメニューが閉じることです。 IMO、それはブロッカーではありません。 Qt 5.15は、HiDPIサポートを大幅に向上させます。

同意します。コンテキストメニュータグのバグは残念ですが、HiDPIのバグははるかに深刻であり、時間の経過とともにさらに多くのレポートが生成されます。

@FranciscoPombal私はあなたがどこから来ているのか理解できます、そしてここでのあなたの仕事はとても感謝しています!

ナイスジョーク。

あなたの指摘には関連性がありますが、残念ながら、「新しいリリース」をリリースする現在の時間枠では、この議論は可能ではないと思います。...(現時点では)

他に何もできないようです。 しかたがない。

@FranciscoPombal私はあなたがどこから来ているのか理解できます、そしてここでのあなたの仕事はとても感謝しています!

ナイスジョーク。

@FranciscoPombal真剣に?? -これは冗談ではありませんでした。私は個人的に誠実でした。

あなたの指摘には関連性がありますが、残念ながら、「新しいリリース」をリリースする現在の時間枠では、この議論は可能ではないと思います。...(現時点では)

他に何もできないようです。 しかたがない。

この状況を個人的に/心に留めないでください......わかりました
........一息つく
プロジェクトでのあなたのハードワークの一部に、少なくとも新しいリリースを介して「mainstrempublic」を見てもらいましょう。 (現在、ここに来て参加/貢献/構築などする私のような人々だけが見ることができます

staging_v4_3_xブランチをプッシュしました。 基本的には、変更ログが更新されたマスターです。
Changelogを見て、何かが間違っているか、何かを見逃していないか教えてください。
@glassez

  1. #13234にはユーザー向けの属性がありますか? 変更ログに含める必要があるものはありますか? 例:「数百のトレントを使用したセッションの読み込み速度を向上させる」。
  2. #13395の目的は何ですか。 それは何をするためのものか? 変更ログに何かを含める必要がありますか?

このスレッドで言及されている、リリースに含まれていないコミットを作成する可能性のある問題について少し見ていきます。 新しい情報が入り次第お知らせします。

@ sledgehammer999

また、その過程でPPAをクリーンアップしてください。 18.0420.0420.10以外のUbuntuリリースはEOLであるため、これらのバージョンを対象とするビルドのアーカイブはできるだけ早く削除する必要があります。

Ubuntu14.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_1libtorrentのサポートが終了したことは言及されるべきだと思います。

また、誰かがこのバージョンでより速いトラッカーアナウンスレートを望んでいる場合、またはクライアントの終了が遅い場合(4.2.xと比較して)、詳細設定から「最大同時HTTPアナウンス」制限を増やしてみることができます。

#13234にはユーザー向けの属性がありますか? 変更ログに含める必要があるものはありますか? 例:「数百のトレントを使用したセッションの読み込み速度を向上させる」。

申し訳ありませんが、すべてを覚えているわけではありません...それは主に内部の改善でした。 たぶん、PRの説明の次の部分は「ユーザー向けの属性」に当てはまります。

これにより、たとえば「ファイルがない」状態など、特定の状況で履歴書データを正しく保存できます(これが以前に行われないように試みましたが、ユーザーは、たとえば、そのようなトレントの一部のプロパティを変更するときに実際に保存できます)。

#13395の目的は何ですか。 それは何をするためのものか? 変更ログに何かを含める必要がありますか?

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

RC1_1libtorrentのサポートが廃止されたことに言及する必要があると思います

👍

機能:v2トレントを作成するためのサポートを追加します(libtorrent 2.0.xが必要です)(Chocobo1)

くそ! qBittorrentはすでにlibtorrent-2.0をサポートしていますか? なぜそれがそうであるようにそれを言及するのですか? 私たちはすでにそれについて話しました。

また、変更ログに次のようなメモを追加できますか
「以前のテーマバンドルは、バンドルファイルの形式が変更されたため、このリリースでは正しく機能しません。修正については、テーマプロバイダーにお問い合わせください。新しい形式の詳細については、 https://github.com/qbittorrent/をご覧ください。
実際、これはhttps://github.com/qbittorrent/qBittorrent/pull/12755/filesが原因です

これをウェブサイトの「ニュース」セクションに追加すると思います。 変更の外で、紹介テキストで。

RC1_1libtorrentのサポートが終了したことは言及されるべきだと思います。

わかった。

また、誰かがこのバージョンでより速いトラッカーアナウンスレートを望んでいる場合、またはクライアントの終了が遅い場合(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のセキュリティの問題がなくても、すでに問題が発生しています。

Ubuntu14.04および16.04はEOLではありません。 そのリストはどこから入手しましたか?

おそらく間違った言い回し。 Qtバージョンが最小要件よりも少ないため、これはEOLです。

わかった。 これですべてが設定されたと思います。ビルドを準備しています。 v4_3_xブランチは、ビルドと一緒にプッシュされます。

@ sledgehammer999コメントが遅くなって申し訳ありませんが、(Webサイトのニュースセクションで)前回のリリース以降、既知のメモリリーク、速度の問題など、多くのlibtorrent修正が行われていることを忘れないでください。 Windowsなどのキャッシュ設定ロジックに問題があります。libtorrentの1.2.6-1.2.11(1.2.11はまだ正式にリリースされていませんが、すでにいくつかの変更ログエントリがあります)を見て、最も関連性の高いエントリを選択してください。

好奇心から、どのlibtorrentコミットが使用されますか?

OK、そして最新のgitcommitはいつものように。

@rrrevin

Ubuntu14.04および16.04はEOLではありません。 そのリストはどこから入手しましたか?
https://wiki.ubuntu.com/Releases

おそらく間違った言い回し。 Qtバージョンが最小要件よりも少ないため、これはEOLです。

ええと、私は本当に「標準サポートの終了」を意味したと思います。それはとにかく重要なことです。 それを超えて、有料の企業だけがサポートを受けます。 16.04は、技術的にはまだ「標準サポートの終了」ではありませんが、非常に近いです。 それにもかかわらず、qBittorrentが最低限必要なQtバージョンを5.9に上げたため、OOTBのサポートは2年ほど前に廃止されました。

@ sledgehammer999もう1つ、ニュースで既知のタグコンテキストメニューのマイナーリグレッションについて言及することを検討してください: 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すべてのCMakePRを1つのエントリにまとめました。 内部コードのクリーンアップPRは、変更ログに記載できません。 ユーザー向けの修正が含まれている必要があります。 @Chocobo1の多くのPRと同じ
私が特定の何かを逃した場合は、以下にそれを述べてください。 私はまだ舞台裏で管理タスクを行っているので、しばらく待ちます。

@ sledgehammer999

ユーザー向けの修正が含まれている必要があります。

OK、そう:

/ offtopic(別の機会に)-おそらく、ユーザー向けではないクリーンアップを「その他」または新しい「コードヘルス」セクションに含める必要がありますか? ユーザーは、変更ログでそのようなものを見たいと思っています。

->#13042は、埋め込みトラッカーのアナウンスのバグを修正するため、ユーザー向けです。 <-

すみません。 コミットタイトルからは明らかではありませんでした。 適切な変更ログエントリを提案できますか(それを読んでいるユーザー向け)?

CIの変更は通常、リリースとは無関係です。

/ offtopic(別の機会に)-おそらく、ユーザー向けではないクリーンアップを「その他」または新しい「コードヘルス」セクションに含める必要がありますか? ユーザーは、変更ログでそのようなものを見たいと思っています。

うーん、あなたと@ Chocobo1の両方をクレジットするコードクリーンアップ用の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は明日クリーンアップされます。
数日でセキュリティ問題の詳細。
組織変更は数日で計画されます。

そしていつものように、このリリースサイクルでの貢献に感謝します。

このページは役に立ちましたか?
0 / 5 - 0 評価