Gitea: Giteaロードマップの議論

giteaを拡張するためのプラグイン（テーマを含む）ソリューション。

ビルドプロセスに適切なOSパッケージを追加することは可能でしょうか？ 私はfedoraのために何かをまとめようとしていますが、goはパッケージ化するのが面倒なようです。 ＃31種類の話ですが、まだオープンのようです。

tarballをDebianシステムにデプロイするためにansibleを使用しています。これはあまり便利ではありませんが、機能します。 最も一般的なディストリビューションのリポジトリがあればいいのですが、配置して維持する必要があります。

いくつかの提案：

• ビルドプロセス中にドローンCI / CDをGiteaに自動的に統合するオプション。
• インストール後のGiteaUIからのサイト管理の構成可能性の向上。 たとえば、_Configuration_ページから_ServiceConfiguration_の内容を変更できるようにしたいと思います。
• ユーザーを[探索]ページから非表示にするオプション。

フェデレーションプルリクエスト/イシュー/フォーク

フェデレーションプルリクエスト/イシュー/フォーク

Fediverseの意味でのフェデレーション（ActivityPub、OStatus、diaspora *など）ではないかもしれませんが、プロジェクトに最適な方法で実装された独自のリモートインスタンスと対話できるようにしたいと思います。

複数のインスタンスにまたがるユーザーで構成されるチームや組織を持つこともクールかもしれませんが、それを実装するのは非常に難しいでしょう。

バグを報告し、UXフィードバックを提供することで、私が使用するオープンソースプロジェクトを支援しようとする最小限のコーディングスキルを持つエンドユーザーのPOVからの2つの提案：
1）ForgeFedの標準化にご協力ください！ Gitea（および他のコミュニティがホストするコードフォージ）のインスタンスでバグをファイリングするUXが、1つの巨大な分散型GHのようになることを望んでいます。
2）プロジェクトの各部分をGitリポジトリにして、問題やWikiなどを簡単に引き出したり、分岐したり、プッシュしたり、フォークしたりできるようにします。 GLとsr.htは、少なくともいくつかのコンポーネントを使用してこれを実行します。 これは単に役立つだけでなく、ポイント1）にも役立つ可能性があります。

電子メールでチケットに返信する機能は、使いやすさの大きな前進になります

UIからすべての構成の編集を許可します（プロセス中に構成ファイルの形式を変更する可能性があります）

たぶん、構成の大部分をデータベース内に保存し、適切なCLIとAPIを提供します

@sapk @tboerger configをviperに切り替える必要があると思います。そうすれば、ini（およびそれに伴うバグのいくつか）を取り除き、Giteaの実行中にconfigをリロードしたり、適切なenv変数を取得したりできます。 。

私はこれに取り組むつもりですが、近い将来に時間を見つけることができるかどうかはわかりません。

私もバイパーです。 私は2年前にそれをやろうとしていましたが、それを終える時間がありませんでした...しかし、私はそれをもう一度試すことができます:)

より最小限の構成ファイルを取得するためです...これらの設定の多くは、静的構成ファイルを介して設定する必要はなく、パフォーマンス上の理由からデータベースに簡単に追加してキャッシュすることができます。

最初にデータベース構成テーブルを追加し、ほとんどの変更可能な構成アイテムをiniファイルから移動し、リロードする必要のあるアイテムのみを残すことができると思います。

@lunny and all：多くの設定をデータベースに移動し、それらをWebインターフェイス（サイト全体またはリポジトリ全体）で構成できるようにすることは、良い一歩のように感じます。 また、teaやgiteaなどのツール自体がコマンドラインからこれらの値を変更できるようにするのも簡単なので、デフォルトの設定をスクリプト化することもできます。

モジュールシステムは素晴らしいですね。 giteaに新しい機能を追加したいと思っている人はたくさんいると思います。

@belliash @sapk IMOプラグイン/モジュールは、モデルパッケージを完全にリファクタリングし、抽象化を追加しない限り、効率的に実装できません。 Goのネイティブプラグインサポートのような複数のテクノロジーをテストしました。

その結果、Giteaバイナリに大きく依存する巨大なバイナリが作成されました。

データベース操作に使用できる静かで成熟したAPIがすでにあるので、Webhookのサポートを改善し、Webhookによってカスタムページを追加する方が現実的だと思います。

@jonasfranz依存関係の多くを削除するために、モデルをリファクタリングすることに非常に賛成です。

go list -f  '{{ .Imports }}' code.gitea.io/gitea/models 

98（！）の直接インポートを明らかにします。 そのうちの50は非goコアです。

go list -f  '{{ .Deps }}' code.gitea.io/gitea/models

437（!!）の推移的な依存関係を明らかにします。 （そのうち304は非goコアです）

ドローンのソースを見てください。Webhookに基づいたプラグ可能なものがたくさんあります。

パッカーのようなプラグインモデルが理にかなっていることに加えて、grpcベースのプラグインシステム。

@tboergerドローンのプラグ可能なものからの例を提供できますか？ Dockerイメージに基づくプラグインシステムを意味しますか？

設定やシークレットなどの拡張機能について話しているので、インターフェースはhttps://github.com/drone/drone/tree/master/pluginで定義する必要があり

私はあなたに同意します、Giteaの次の大きなステップはプラグインシステムであるべきです。 私も最近考えています。 プラグインシステムを試してみます。

ドローンのプラグインシステムと似ているはずですが、もっとあります。 プラグインにUIを許可する必要があり、GiteaのOAuth2で自動的にログインする必要があります。 そして、プラグインにいくつかのセキュリティポリシーを設定する必要があります。 や。。など。

2016年頃に作成した比較表を共有して、オープンソース地理空間財団にどのホスティングプラットフォームを選択するかを_決定_したいと思います。 その表に、私たちにとって重要な機能をリストしました。 Giteaは次の列の1つにあります。

https://wiki.osgeo.org/wiki/GitInfrastructureComparison

2016年に欠けていた重要な機能が今日も欠けていることがわかります：メールでの返信（コメント/返信）---今日の時点で他のいくつかが実装されています。

migrate from githubとComments on diff linesへの@strkツールが実行されます。

メールテンプレートのカスタマイズが必要
＃6037を参照

したがって、テンプレートのカスタマイズはすでにかなり可能です。件名だけが私たちにはないと思います。

ただし、実際に行う必要があるのは、電子メールとgitservフックメッセージに対してi18nを有効にすることです。

プルリクエストを元に戻す必要があります。
＃6375を参照

UIでのタグの完全サポート。 作成、割り当て、変更、削除など。この機能が本当に恋しいです。

私はデータベースの設定（ユーザーの作成や認証のLDAPなどを設定するためのcliまたはapiを使用）とプラグインシステムに賛成です。
これらの2つは、giteaを大きく前進させる必要があります。

LFS

• [x]リポジトリ内のLFSファイルを管理する何らかの方法が必要です-現在、それらは完全に不透明です＃7199はこれを提供する試みです-しかし、効率的にするためにはおそらく必要です...
  
  
  
  • [] BLOBルックアップ用のブルームフィルター-コミットを見つけるための少し効率的な方法と、BLOBを導入したツリーパスがあると非常に便利です。
  
  
• []現在、LFSへのアップロードを再開する信頼できる方法はありません。そのため、非常に大きなアップロードが繰り返し失敗する可能性があります。 ＃1723に従ってtus.ioを実装します
• []ポインターのように見えるファイルがポインターであると想定するのではなく、ファイルがLFSポインターであるかどうかを判断するために.gitattributesを使用するオプションを提供する必要があります。 それは＃7199の機能を非常に難しくする可能性がありますが...
• [] LFSファイルはdiffビューで表示できる必要があります。

硬化

シャットダウンとGiteaを本当にクラスター化できるようにすることの始まり

• []シャットダウンに対するGiteaの応答を強化する必要があります。
  
  
  
  • [x]これは、リスニング接続、特に組み込みSSHの正常なシャットダウンを意味します。これは、現在、突然のシャットダウンによってgitリポジトリの破損を引き起こす可能性があります。 ＃7274はこれを修正する試みの始まりです。
  
  
  • []だけでなく、ジョブなどの通知をシリアル化できる必要があることも意味します。たとえば、インデックス作成キューは、ディスク上またはデータベースキュー、同様にメールキューなどを経由する必要があります。これはすでにいくつかありますが、これらのキューは正常にシャットダウンされません。
  
  
• []上記の結果として、インデックス作成のアクションを検索から分離する必要があります。 いずれの場合も、適切なシャットダウンにはこれが必要ですが、これはクラスタリングに向けたステップの一部です。 どのアーキテクチャを採用すべきかはわかりませんが、複数のオプションがあります。インデクサーを別のプロセスに分離し、Giteaにインデックスを読み取り専用にするか、インデックス全体をエクスポートします。

差分と任意の長さのデータのメモリへの読み取り

• []差分コードはリファクタリングが必要です-壊れやすく、差分全体をメモリに読み込み、ユーザーが応答する前にブラウザで巨大な差分を解析する必要があります。 これには、UIとサーバーの両方の変更が必要です。おそらく、Ajaxに裏打ちされた無限スクロールがこれに対する正しい手法です。 現在、十分に邪悪な大きな差分がサーバーとブラウザの両方をダウンさせる可能性があります。
• []私たちのdiffアーキテクチャは現在、事前にマージされたブランチとオブジェクトでベースリポジトリを汚染しています。
• []一般に、任意の長さのデータをメモリに読み込むのをやめなければなりません。 ブラウザがこれを必要とする可能性がある場所がある場合は、読み取る内容を制限してから、無限スクロール手法またはブラウザレンダリングでのフルリンクを使用するか、パイプラインでレンダリングして、メモリに完全にバッファリングされないようにする必要があります。 比較的新しいコードでさえ、この問題に悩まされています。
• []（任意の長さのデータを返す可能性のあるgitプロセスを実行している場合は、すべてのデータを直接stdoutバッファーに完全に読み込まないようにする必要がありますが、より多くのルーチンパイプラインを実行します。）

マージ

• []現在、マージのためにスパースチェックアウトを行っているため、マージを完全に使用するようにマージをリファクタリングする必要があります。基本的に、gitマージはhttps://git-scm.com/docs/git-merge-one-fileにドロップダウンするためです

エスケープとリポジトリの場所

• []逃げるためにどこでもチェックしなければなりません。 レガシーゴグコードは一般的にうまくエスケープされておらず、複数のセキュリティ問題の原因となっています。
• []ユーザー名とリポジトリ名をエスケープする必要がないという仮定は、私たちに必要のないアーキテクチャの決定を強いています。 git署名に対して適切に保護することすらできなかったため、＃5774になりました。
• []基になるリポジトリの場所をファイルシステムの場所と一致させることはユーザーにとって快適ですが、たとえば$GITEA_ROOT/owner/reponameは、アーキテクチャ上の決定としては不適切であり、ユーザーは、リポジトリがなくてもサーバー上のgitで使用できると想定します。さらに考えた-彼らはすべきではない。 $GITEA_ROOT/repository-$IDに移動する必要があり、おそらくシャーディングされます。 （これを行うと、 repo.MustOwner()またはrepo.GetOwner()への多くの呼び出しを削除できます）
  
  
  
  • []上記に移動し、すべてを適切にエスケープしたら、ユーザー名とリポジトリ名の制約を緩和できます。ただし、これを許可しない方法で実行するように慎重に検討する必要があります。 ＃5774と同様の問題を偽造します。
  
  
• [x]十分なGitea環境で実行する必要があるサーバーgitプロセスを強制する必要があります-Giteaを経由せずにサーバー上でGiteaのリポジトリを使用しようとするユーザーが繰り返されるため、Giteaが更新されないなどと文句を言います。＃6961はこれに必要な手順を実行し、これをマージした後、 https：//github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72を変更して、SSH_ORIGINAL_COMMANDの設定を強制するか、残りの部分を強制します。標準環境のを設定します。
• [] NO_EXECにマウントされたリポジトリに対処できるはずです。実際、おそらくこれをお勧めします。 おそらく実際に行うのは難しいことではありません。 .git/configまたは中央の.gitconfig core.hooksPath変数を変更し、それ以外の場合にフックを配置する場所を考えてください。
• []基本的に、コメント用にコード行をデータベースに直接格納しています。これは、格納されているデータがUTF-8にない場合は機能しません。 これは、UTF8以外のコードにコメントすることはできないことを意味します。

API / SDK

• []私たちがスワッガーをするために全力を尽くすとき、APIを構築するために私たちがしなければならない仕事の量はクレイジーです。 これをSwaggerから自動生成するか、可能な限り自動生成する必要があります
• []開発中のGiteaに対して固定APIバージョンをテストする方法がないため、重大な変更をいつ行っているかがわかりません。
• []自動生成されたAPI / SDKを使用して、簡単なテストハーネスを作成できるはずです。

テスト

• []現在、ユニットテストをTRACEレベルで実行しています。これにより、適切なトレースを追加する機能が制限されます。 https://gitea.com/gitea/log/pulls/3以降、Giteaにバックポートする場合は、makefileからこれを変更できます。
• []より多くの単体テストが必要であり、統合テストの一部が実際に単体であるかどうか、またはその逆かどうかを検討してください。 例： https ：
• []ユーザーストーリーを実行しようとする統合テストがさらに必要です。 つまり、ユーザーがログインし、Xを実行すると、YとZが発生します。 たとえば、物事を個別にテストすることは問題ありません。 https://github.com/go-gitea/gitea/blob/master/integrations/download_test.goしかし、それは実際には統合されておらず、ユーザーエクスペリエンスのテストを見逃しています。 私はこれを言い続けますが、より多くのテストは次のようになります： https ： https://github.com/go-gitea/gitea/blob /master/integrations/git_test.goは、機能が正しく統合されているかどうかを実際にテストします。
• [x]テスト体制に時間がかかりすぎます-CIの実行には現在30〜40分かかります！ これらを並行して実行する必要があります。
• []移行テストを作成する簡単な方法はありません。

パッケージアーキテクチャに移行

モデル

• [] code.gitea.io/gitea/modelsは、これを止めなければならないことが多すぎるかどうかに依存します。
• [] models.xは
• []モデルが多すぎると、どの状態にあるかわからないため、nilポインターの逆参照を引き起こすのは簡単すぎます。ここでgoのタイピングシステムをもう少しうまく使用できますか？
• [x]リポジトリを取得するたびに、OwnerNameをリポジトリテーブルに固定する必要があります。その後、Ownerを取得する必要があります。 それはばかげて時間の無駄です。 リポジトリは所有者を頻繁に変更しないため、それを処理する必要があるコストはそれほど大きくありません。
• []モデルではまだ多くのことが行われているため、さらに多くのことを削除する必要があります。
• []モデルをコアと非コアに分割することは理にかなっているかもしれません。

モジュール

• [x]モジュールには、基本的に2つのタイプがあります。モデルに依存するモジュールとモデルに依存するモジュールです。 これらを分けてみましょう。1つはサービスと呼ぶことができます。

マカロン

• [] @lunnyが提案したジンへの移行を真剣に受け止めるべきだと思います
• []私たちのコードベースはマカロンへの依存関係で飛び散っていますこれはそうではないはずです

設定

• []マカロンにも依存します（！）
• [] go-iniと密接に関連しています。これは、接続を切断することを検討する必要があるもう1つの依存関係です。

国際化

• []電子メールは国際化されていません
• []国際化されていないGitメッセージ
• []国際化されていないエラーメッセージ
• [] CrowdInで国際化できるように、hugoWebサイトのドキュメントの削除を自動化する必要があります
• []言語セレクターリストにfrançais、españolなどの小文字の形式を使用する言語があるのは奇妙です。これは、これらの各言語の文の始まりを表すため、AFAICSを大文字にする必要があります。 Oui、sij'écrisenfrançaisj'écris "français"、maissij'écrisunelisteápuces、j'écris：
  
  
  
  • 英語
  
  
  • フランス語
  
  
  • スペイン語
  
  

Gitea Dump＆Restore

• [] SQLバリアント間の変換でGiteaダンプが壊れている
• []復元コマンドはありません

UIの部分では、2つのUIを提供することをお勧めします。

• 1つのプレーンHTML（jsのない現在のものと同様）
• API呼び出しのみに依存する完全なJS。 これにより、いくつかのAPIを再考する必要がありますが、他の外部アプリからのより多くの対話も可能になります。

• @lunnyによって提案されたジンへの移行を真剣に受け止めるべきだと思います

ジンの代わりにゴーチをお勧めします。

• CrowdInで国際化できるように、hugoWebサイトのドキュメントの削除を自動化する必要があります

私見ウェブサイト/ドキュメントはまったく翻訳されるべきではありません、とにかくそれは常に時代遅れです...

私見ウェブサイト/ドキュメントはまったく翻訳されるべきではありません、とにかくそれは常に時代遅れです...

しかし、crowdinを使用すると、古くなると人々に通知され、現在の翻訳が無効になります。

ビルドプロセスに適切なOSパッケージを追加することは可能でしょうか？ 私

おそらく、GItea開発者によって制御およびバージョン管理されたPPAスタイルのパッケージは良い考えですが、私は、動きの速いプロジェクト（GIteaなど）のバージョン管理のDebianスタイルの「フリーズおよびバックポートセキュリティパッチ」方法のファンではありません。

https://github.com/go-gitea/gitea/issues/3840が
下位互換性で実装できると思います。
ただし、これは、新しいルーティングライブラリの移行が確定した後でのみ明らかになります。
前提条件となる基本的なクリーンアップ/リファクタリングも簡単になります。

まだ＃3840が欲しいのですが。
下位互換性で実装できると思います。
ただし、これは、新しいルーティングライブラリの移行が確定した後でのみ明らかになります。
前提条件となる基本的なクリーンアップ/リファクタリングも簡単になります。

その場合、現在Gitlabにも実装されていないため、ドローンのサポートが失われる可能性があります。

まだ＃3840が欲しいのですが。
下位互換性で実装できると思います。
ただし、これは、新しいルーティングライブラリの移行が確定した後でのみ明らかになります。
前提条件となる基本的なクリーンアップ/リファクタリングも簡単になります。

リポジトリのURLに影響を与えるためにこのグループ機能はおそらく必要ありません。リポジトリを表示するためにフォルダを作成するだけで、リポジトリのURLを現在と同じに保つことができます。

@tboerger
私の考えでは、リポジトリがグループ/ディレクトリにネストされていない場合、URLは同じままである可​​能性があります。
リポジトリがグループ/ディレクトリ機能を使用する場合にのみ、URLを「アップグレード」する必要があります。
しかし、はい、新しいURLのリポジトリでは、Droneをすぐにサポートすることはできなかったでしょう。

@lafriks
良い提案ですね。 この機能の私の使用シナリオは、GitモジュールまたはRepoプロジェクトのサブプロジェクトをホストすることです。 だから、それがその場合をカバーするかどうかはわかりません。

心配ない。 私は、このような大規模な、場合によっては壊れるような変更も行うことに消極的です。

この問題には多くの良いアイデアがあり、それらを保持して対処する必要があります。
しかし、いつ、どのように選ぶべきでしょうか？ この議論は永遠に続く可能性があります。

所有者が主題を選ぶか、それらとメンバーの間で投票することをお勧めします。
どう思いますか？

@DblKそうです。 しかし、gitea.comに移行した後はそれができると思います。 現在、ユーザーからのフィードバックがさらに必要です。

• 水銀サポート
• PRと問題のより良いソートとフィルタリング

• 水銀サポート

いいえ、お願いします。 それは理由から「git」eaと呼ばれています。
より広い範囲を持ちたいという願望は理解していますが
膨張はもうすぐです...

水銀の輸入は代替手段となるでしょう

2019年7月26日午前1時52分50秒PM UTC、上サンドロSantilli [email protected]は書きました：

• 水銀サポート

いいえ、お願いします。 それは理由から「git」eaと呼ばれています。
より広い範囲を持ちたいという願望は理解していますが
膨張はもうすぐです...

-
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/go-gitea/gitea/issues/6998#issuecomment -515461704

フェデレーションプルリクエスト/イシュー/フォーク

Fediverseの意味でのフェデレーション（ActivityPub、OStatus、diaspora *など）ではないかもしれませんが、プロジェクトに最適な方法で実装された独自のリモートインスタンスと対話できるようにしたいと思います。

＃1612でこれについてすでにいくつかの議論があります。 ForgeFedは、Giteaのようなコードフォージにフェデレーションを組み込むためのいくつかの興味深いアイデアを収集します。 これがGiteaの次の大きな機能になるとしたら素晴らしいでしょう！

Githubが提供するものと同様の、グラフィックファイル（JPEG、PNG、PDFだけでなく）用のビジュアル差分ツールが

画像を比較するためのPRはすでにあります

画像を比較するためのPRはすでにあります

本当ですが、それはスワイプやタマネギの皮のプレビューをカバーしておらず、並べて表示するだけです。 また、PDFファイルは対象外だと思います。 ここではグラフィック素材（マニュアルやパンフレットを含む）の開発にGiteaを使用しており、PDFの優れた視覚的差分は人生を変えるでしょう。

捨てたいアイデアがいくつかあります：smile_cat：

1. Cloud KSMを使用して、シークレットを透過的に暗号化/復号化します。 これにより、DBがハッキングされて公開されるのを防ぐことができます。 アイデアは、DBに書き込む前に、XORMエンコード/デコードメソッドでカスタムタイプを使用して秘密データを暗号化できるということです。 ここでデモの例を作成しました： https ：

2. OIDCサポート：Gitea経由でログインすると、oauth2トークンに加えてid_tokenを返します

3. Giteaユーザープロファイルは、検証済みのGitリポジトリ全体でユーザーのプロファイルを表示できます。 例：ユーザーはGithub / Gitlab / BitBuket / Giteaリポジトリを固定できます。 アイデアは、ユーザーが他のものも無視できないということです。 では、giteaを1つのグローバルユーザープロファイルにすることはできますか？

4. リポジトリのカスタムドメインサポート（go）

5. Githubとの完全な互換性（この面でいくつかの作業を見たことがありますが、すでにどれだけ行われているのかわかりません）。

6. オプションの言語サーバー統合。 UIに組み込まれたナビゲーションのようなSourcegraphのようなもの。

短い順番で1＆2に貢献したいと思います。

たぶん、すべての変更が含まれる1つの巨大なページではなく、BitBucketのように、変更されたフォルダーとファイルのツリーの形式で差分を表示できます。 それははるかに読みやすいでしょう。

たぶん、1日または1週間ごとにすべてのリポジトリの通知を集約するオプションです。
先週の活動の要約のようなものです。

カスタムテンプレートと標準変数のプールを介してカスタムWebhookを定義する可能性を追加します。

Giteaの進化ではなく、役立つサイドプロジェクト：＃7853

githubと同等の機能！

または、少なくともwikiの最新のリストには、同等になる前に必要なすべての機能が示されています。 これは、将来の開発努力を構築するための良い方法です。

@ lonix1は、そのリストについてhttps://docs.gitea.io/en-us/comparison/を参照して

@kolaenteは、ほぼすべての目盛りがあるように見えます。 うん！

私はここでは非常に新しいですが、喜んでコーダーもいます。 giteaが要点をサポートしてくれたら嬉しいです。 それは私の使用法の最大の穴の1つです。 簡単に回避できますが、要点システムを導入したいだけです。

要旨の問題はhttps://github.com/go-gitea/gitea/issues/693だと思います）。

HelpリンクからアクセスできるHelpドキュメントも追加します。 このドキュメントの最初のソースは、Gitea固有の変更を加えたGitHubヘルプから入手できます。

@bagasmeヘルプをgithubから

1. 電子メールによる問題の作成（GitLabサービスデスクを参照）。

より多くの人々がオープンソースプロジェクトを共有するためにセルフホスティングを採用し始める場合、未登録のユーザーが各インスタンスでアカウントを作成することなく問題を提出する方法が必要です（ほとんどの人々はバグに登録する可能性が非常に低いです）報告）。

1. GitLabのAutoDevOpsに似たもの。 これは、リポジトリにCIyamlファイルがない場合にデフォルトのCIジョブを定義できることを意味します。

2a。 コンテナレジストリのUIタブと認証。

1. ボット
2. Webコミット用のGPG
3. 条件に基づいてマージをブロックする機能
4. Web UIでファイルを作成する機能（空白の裸のリポジトリを含む）
5. UIを介してリポジトリに添付されたスニペットを管理します（GitLabを参照）
6. Gitプロトコルv2のサポート
7. 改善されたWebIDEオプション
8. Kubernetesの統合（GitLabのUIプラグインを介して）
9. ツールチップがホバーに表示されるまでに400ミリ秒の遅延を追加します
10. より良いCI統合（パイプラインの表示、Concourseサポートなど）
11. UIを洗練する
12. 2FAを適用する
13. ファイルロック
14. PRマージでリンクされた問題を自動クローズします。

ある種のプラグイン/拡張システム。

ほとんどの提案は適切ですが、コアコードベースに問題が発生します。

公式（および非公式）プラグインを用意するのが最善です。 これは、プラグインの作成者がより頻繁にリリースできることも意味します。

@ lonix1ええと、gitフック、webhook、SwaggerAPIはプラグイン接続ポイントと見なすことができます。 プラグインのサポートを増やしたいと思っていますが、詳細を記載したリストを記載すると役立つ場合があります。 たとえば、webhookと同等のコマンドラインのサポートが必要です。

@ guillep2kたとえば、上記のすべてのプロジェクト管理機能。 それらは非常に便利ですが、おそらくコードベースの非常に多くの部分に触れているため、1）これらの機能を使用しない人でも問題が発生する可能性があり、2）そのため、そのような開発は非常に遅いです。新しい機能をマージすると、このシナリオが可能であることがわかっているため、注意が必要です。

これらの新機能を個別にリリースできる場合は、メインブランチにマージする前に、自発的なユーザーが試すことができます。

そして、これらの種類の大きな新機能の他の例があります。上にスクロールするだけです。

＃7631のマージにより、自動生成されたコミットの@brandonkalGPG署名が可能になりました

ロードマップはこれらの4つのカテゴリに分類する必要があると思います（問題の例をいくつか追加しました。完全な：wink：にはほど遠いことは明らかです）。

基本機能

正しく機能していない_基本機能_がまだいくつかあります。
例えば：

• ＃5694＃5277＃3448、＃2967、＃2434、＃8366、＃8386、＃7825などの問題で言及されているように、それでも優れた検索ソリューションが必要です
• PDFビューアが壊れています
• SVGビューアが壊れています
• 使用されている非フリーの依存関係があるようです

安全

いくつかのセキュリティ問題もあります：

• [] [Dockerイメージは引き続きrootとして実行されます]（https://github.com/go-gitea/gitea/issues/1190）ただし、Dockerガイドはそれについて非常に明確であり、 rootを使用する理由はありません
• [] [2FAを強制することはまだ不可能です]（https://github.com/go-gitea/gitea/issues/880）
• [] [インラインスタイルを削除して、より厳密なCSPヘッダーの設定を有効にする]（https://github.com/go-gitea/gitea/issues/305）
• [] [誰かが添付ファイルへのアクセスを許可されているかどうかのチェックはありません]（https://github.com/go-gitea/gitea/issues/7908）

統合

他のアプリケーション/サービスとの統合は一般的に良いことだと思います。
ソフトウェア開発は通常、単一のツールに依存するだけではないからです。
そして、職場でGiteaを使用するように説得するのに役立つでしょう。

これらの2つの問題により、相互運用性が大幅に向上します。

• []ドローンCI / CDを自動的に統合します（以前に提案された@BNoletのように）
• [] [自動PRレビューのためのAPI統合]（https://github.com/go-gitea/gitea/issues/5733） Prontoなどのツールを使用
• [] [コンテナレジストリとの簡単な統合]（https://github.com/go-gitea/gitea/issues/2316）
• []ユーザーがカスタムWebhookを簡単にセットアップできるようにする汎用Webhookソリューション（以前に@bkcsoftによって提案されたように）

また、一般的なWebhookを使用すると、他の人にgiteaの内部を知ってもらう必要がなくなります。 @ guillep2kは、「外部コマンド」統合を一般的なWebhook統合と同様に実行できるという素晴らしいアイデアを持っていました。
：warning：これはおそらく、この問題のほとんどの人が「プラグインサポート」として望んでいる問題のほとんどを解決するでしょう。 これにより、ユーザーが呼び出す必要のあるものをすべて呼び出すことができるようになるためです。 ただし、 @ lunnyは、これはgitフックを介して実際にすでに可能であると述べました。 これが本当に他のツール/プラグイン/サービスを統合するための最良の方法であるかどうかはよくわかりません。

オントップ機能

さらに、競合するアプリケーション（Git [Hub / Lab]など）には明らかにいくつかの優れた機能

• [] [PRを元に戻す]（https://github.com/go-gitea/gitea/issues/6375）
• [] [@ arthur-bauerが言及した非テキストのものの差分の改善]（https://github.com/go-gitea/gitea/issues/6998#issuecomment-516325459）
• [] [メンテナからの編集]（https://github.com/go-gitea/gitea/issues/717）
• [] [機密事項]（https://github.com/go-gitea/gitea/issues/3217）
• []より多くのリポジトリの詳細を表示します（つまり、リポジトリサイズ、寄稿者グラフ、言語バー）
• []いくつかのウィキの改善（＃823＃574）
• [] [@SignumPLで言及されているBitBucketのような差分を持っている]（https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615）（以前は知りませんでしたが、本当に便利に見えます）
• [] [Octotreeのような機能を統合する]（https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388）

オプションとしてOracleデータベースを使用できますか？ 技術的に可能であれば。

@DemiusAcademius xormがオラクルをより適切にサポートしている場合、それは可能だと思います。

ますます多くの人々がGiteaを使い始めています。たとえば、最近のGitLabトラッカーの発表も原因です。 しかし、GitHub / GitLabは依然として彼らの側にネットワーク効果を持っています。

フェデレーションは、異なるGiteaインスタンスのユーザー間でコラボレーションする機能を改善し、それによってGiteaネットワーク全体を増やすための大きな推進力になります。＃1612

UIで大きな差分を表示する機能は、Giteaの採用を制限する要因であると報告されました。
それに対処するチケット：＃7341（機能）、＃7495（クラッシャーバグ）

UIで大きな差分を表示する機能は、Giteaの採用を制限する要因であると報告されました。
それに対処するチケット：＃7341（機能）、＃7495（クラッシャーバグ）

それは_巨大な_制限です。 上記のIMOのすべての@alexanderadamは、これと比較すると見劣りします。 コードのインラインコメントで大きな差分を確認できない場合、それは大きな問題です。

多くのプロジェクトを移行させ、連邦への高い需要を引き起こしたマイクロソフトとGithubへの怒り-Gitlabは最近、陸地と経済で世界最大の国の2つである中国とロシアの従業員を禁止することを提案しました。 米軍は、米国の帝国の拡大/利益に対する障壁を弱めるために、（とりわけ）中国とロシアに焦点を移しました。 宣伝と金銭的インセンティブにより、Microsoft（Github、Azure）、Amazon、Google、Atlassian（Trello、Jira）、さらにはGitlabが戦争、スパイ、宣伝、監視の業界に攻撃的な役割を果たしています。

これは、私たちが使用し、現在も依存している企業およびペンタゴンにリンクされたサービスの欠点がほとんどない、可用性の高いオープンソースのリモートリポジトリに取り組んでいる人々に感謝するためです。歴史上最も強力で敵対的な帝国から遠く離れた場所でインターネットとテクノロジーを使用したい人にとっては姿を消しました。

おそらく、このトピックは、公式Webサイトの別のセクションでこの機能の進捗状況を追跡するのに十分な大きさであり、この需要を取り込むための別の資金調達キャンペーンもあります。 ForgeFedを資金調達に含めることは、これまでの彼らの仕事を見ると、有益で公正かもしれません。 MicrosoftがGithubを買収してから17か月が経ちましたが、さらに17か月間、フェデレーションGiteaを使用できるか、純資産の残りの部分を構築できることを願っています。

ここで政治について話し合うのではなく、主題を守りましょう-みんなのためにGiteaを改善する

@lafriks Giteaの改善とは、代替品では満たされないニッチを定義することを意味します。 マーケティングは外部の機会を見つけるプロセスであり、「政治的」はマーケティング分析の4つの主要なカテゴリーの1つです。 賢明なブランドは、機能、仕様、価格を提供するのと同じくらい、人々の「価値」にアピールします。 Giteaのような代替案には価値に基づく（「政治的」）魅力があり、それを強調して維持しないと、消費者と市場機会を理解できなくなります。

用語としての「政治的」は、人種差別、暴力、搾取についての議論を消し去る、思考を終わらせる決まり文句になりました。 私は単にここに来て、米国の強制収容所、ドラッグネット監視、および業界の大部分が積極的に支援している他の帝国主義者の利益に関連しない代替案の作業を続けてくれた人々に感謝します。私はあなたを間違えました、そして私は去ります。

@OKNoahへのメモ

オープンソースプロジェクトのマーケティング101：

1. 強制収容所を持ち出さないでください
2. 政治については言及しないでください
3. ティンホイルハットを失う
4. 帝国主義などの古風な用語は使用しないでください
5. あなたの製品のエッジを知っています。 Giteaの利点はそのシンプルさです。

GitLab.comの透明性に問題がある場合は、GitLab-FOSSをセルフホストできます。 非常に優れたオールインワン製品です。 ただし、GitLabやGitHub Enterpriseと比較して、簡単なインストールが必要な場合、または必要なメモリ使用量が少ない場合は、Giteaが基本的なWeb機能に適したオプションです。

このスレッドは、単純さを損なうことなくそのギャップを埋めるのに役立つ機能について説明しています。

私の2セント-このスレッドは長すぎたと思います。ここですでに表現されているアイデアを要約した新しい問題を開く時が来ました。 そして、これを閉じます。

これらがGiteaが待機している品質ではないと言っているのなら、私はあなたを間違えたので、私は去ります。

これは言われていることではありません。 言われていることは、このスレッドは、Giteaにどのような変更/改善を加えることができるか（特に技術的なもの）を議論するための場所であるということです。 これらの議論は大歓迎ですが、この特定のスレッドではありません。

@XVilkaが正しく言ったように、リードの1つとしてこのスレッドをロックします。多くのフィードバックを求めたので、次のステップで評価する必要があります。

v2のFHSコンプライアンスへのパスを変更できます。 フラグですでに可能ですが、v2のデフォルトである必要があります。