Gitea: Gitea路线图讨论

用于扩展 gitea 的插件（包括主题）解决方案。

是否可以在构建过程中添加适当的操作系统包？ 我一直在尝试为 Fedora 组合一些东西，但是 go 似乎打包起来有点混乱。 #31 对此进行了讨论，但似乎仍然是开放的。

我们正在使用 ansible 在 Debian 系统上部署 tarball，这不是很方便，但它有效。 最常见发行版的存储库会很好，但它需要到位和维护。

几点建议：

• 在构建过程中自动将 Drone CI/CD 集成到 Gitea 的选项。
• 安装后，来自 Gitea UI 的更多站点管理可配置性。 例如，我希望能够从 _Configuration_ 页面更改 _Service Configuration_ 中的内容。
• 使用户从“探索”页面隐藏的选项。

联合拉取请求/问题/分叉

联合拉取请求/问题/分叉

可能不是 Fediverse 意义上的联合（ActivityPub、OStatus、diaspora* 等），但我希望能够以最适合项目的任何方式与自己实施的远程实例进行交互。

让团队和组织由来自多个实例的用户组成也可能很酷，尽管这可能非常难以实施。

来自具有最低编码技能的最终用户的 POV 的两个建议，他们试图通过报告错误和提供 UX 反馈来帮助我使用的开源项目：
1) 帮助标准化 ForgeFed！ 我希望在 Gitea（和其他社区托管的代码伪造）实例上提交错误的用户体验就像一个巨大的、分散的 GH。
2) 使项目的每个部分都成为 Git 存储库，因此可以轻松地从、分支、推送或分叉中提取问题、维基等。 GL 和 sr.ht 至少用他们的一些组件来做到这一点。 除了有用之外，这可能有助于解决第 1 点）

通过电子邮件回复票证的能力将是可用性的一大进步

允许从 UI 编辑所有配置（并且可能在此过程中更改配置文件格式）

也许将大部分配置存储在数据库中并为其提供适当的 cli 和 api

@sapk @tboerger我想说我们应该切换到viper进行配置，这样我们就可以摆脱 ini（以及我们使用它的一些错误）并获得诸如在 Gitea 运行时重新加载配置和适当的 env 变量之类的东西.

我愿意解决这个问题，但我不确定我是否会在不久的将来找到时间。

我也是为了毒蛇。 2年前我曾尝试这样做，但没有时间完成它......但我可以再试一次:)

我想要一个更小的配置文件......很多这些设置不需要通过静态配置文件设置，可以很容易地添加到数据库中，并出于性能原因被缓存。

我认为我们可以首先添加一个数据库配置表，然后将最易更改的配置项从 ini 文件移到那里，只留下需要重新加载的项。

@lunny和所有人：同意将许多设置移动到数据库并让它们在 Web 界面（站点范围或存储库范围）中进行配置感觉是向前迈出的一大步。 这样也很容易让像 tea 或 gitea 这样的工具本身能够从命令行更改这些值，因此您仍然可以编写默认设置的脚本。

模块系统听起来很棒。 我相信有很多人愿意为 gitea 添加新功能。

@belliash @sapk IMO 插件/模块在不完全重构模型包并添加更多抽象的情况下无法有效实现。 我已经测试了多种技术，比如 Go 的原生插件支持。

结果是巨大的二进制文件，它们严重依赖于 Gitea 二进制文件。

我认为改进 webhook 支持和通过 webhooks 添加自定义页面更现实，因为我们已经有一个安静的成熟 API 可用于数据库操作。

@jonasfranz我非常赞成重构模型以删除它的许多依赖项。

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

揭示了 98 (!) 个直接进口。 其中50个是非走核心。

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

揭示了 437 (!!) 个传递依赖项。 （其中304个是非走核心）

看看无人机源，我们得到了很多基于 webhooks 的可插拔的东西。

除了像packer这样的插件模型有意义之外，还有一个基于grpc的插件系统。

@tboerger你能提供一个无人机可插拔东西的例子吗？ 你是说基于docker镜像的插件系统吗？

我说的是配置、机密等的扩展，接口应该在https://github.com/drone/drone/tree/master/plugin上定义

我同意你的看法，Gitea 的下一步应该是插件系统。 这几天我也在想这个。 我会试试插件系统。

我认为它应该与无人机的插件系统类似，但有更多。 我们必须允许插件具有 UI，并且应该自动使用 Gitea 的 OAuth2 登录。 我们应该对插件制定一些安全政策。 等等。

我想分享一个我们在 2016 年左右制作的比较表，以_决定_为开源地理空间基金会选择哪个托管平台。 在该表中，我们列出了对我们很重要的功能。 Gitea 在其中一列中：

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

您会看到 2016 年缺少的一个重要功能今天仍然缺少：通过邮件回复（评论/回复）——截至今天，其他一些功能已经实现。

@strk工具到migrate from github和Comments on diff lines就完成了。

需要邮件模板定制
见#6037

因此，已经有相当多的模板定制成为可能——主题行是我认为我们唯一没有的东西。

然而，我们真正应该做的是为电子邮件和 git serv 挂钩消息启用 i18n。

需要恢复拉取请求。
见#6375

完全支持 UI 中的标签。 创建、分配、更改、删​​除等。我真的很想念这个功能。

我赞成在数据库中进行配置（使用 cli 或 api 来配置它，例如创建用户和身份验证 ldap 等）和插件系统。
这两个人应该推动 gitea 向前迈出一大步。

LFS

• [x] 我们需要某种方式来管理存储库中的 LFS 文件 - 目前它们是完全不透明的 #7199 是尝试提供这一点 - 但为了高效可能需要......
  
  
  
  • [] 用于 blob 查找的布隆过滤器 - 有一些稍微有效的方法来查找提交以及在什么树路径上引入 blob 会非常好
  
  
• [ ] 目前没有可靠的方法来重新开始上传到 LFS - 所以非常大的上传可能会反复失败。 按照 #1723 实现 tus.io
• [ ] 我们应该提供一个选项，只使用 .gitattributes 来确定文件是否是 LFS 指针，而不是仅仅假设任何看起来像指针的文件都是指针。 尽管这可能会使 #7199 中的功能变得非常困难......
• [ ] LFS 文件应该可以在差异视图中查看。

硬化

关闭并开始使 Gitea 真正可集群

• [ ] 我们需要加强 Gitea 对关闭的响应。
  
  
  
  • [x] 这意味着监听连接的正常关闭，特别是内置的 SSH - 目前可能会通过突然关闭导致 git 存储库损坏。 #7274 是尝试解决此问题的开始。
  
  
  • [ ] 但这也意味着像作业这样的通知需要是可序列化的——例如索引队列应该通过磁盘或数据库队列，类似的邮件队列等。我们已经有了一些，但这些队列不会正常关闭。
  
  
• [ ] 作为上述的推论，我们应该将索引操作与搜索操作分开。 在任何情况下，正常关闭都需要这样做 - 但这是向集群迈进的一部分。 我不确定我们应该采用哪种架构，但是有多种选择 - 将索引器分离到一个单独的进程并让 Gitea 只读索引，或者导出整个索引。

Diff 和读取任意长度的数据到内存中

• [ ] Diff 代码需要重构——它很脆弱，将整个 diff 读入内存，并且需要浏览器在用户响应之前解析巨大的 diff。 这需要 UI 和服务器更改 - 大概用 Ajax 支持的无限滚动是正确的技术。 目前，一个足够邪恶的大差异可能会关闭服务器和浏览器。
• [ ] 我们的 diff 架构目前会用预先合并的分支和对象污染基础存储库。
• [ ] 一般来说，我们必须停止将任意长度的数据读入内存。 如果浏览器可能需要这样的地方 - 我们应该限制我们读取的内容，然后使用无限滚动技术或与浏览器渲染或在管道中渲染的完整链接，以确保它不会完全缓冲在内存中。 即使是相对较新的代码仍然存在这个问题。
• [ ] （如果我们正在运行一个可能返回任意长数据的 git 进程，我们应该尽量避免将所有数据直接完全读入 stdout 缓冲区，而是执行更多的 go-routine 管道。）

合并

• [ ] 我们必须重构合并以完全使用 git 索引，因为我们目前对合并进行稀疏结帐 - 基本上是因为 git merge 将下拉到https://git-scm.com/docs/git-merge-one-file处理非快进合并。 这会强制在服务器上创建半任意路径——这是不必要的并且取决于字符集/文件系统因素。 没有必要这样做 - 我们可以使用临时文件进行这些合并，散列并直接添加到索引中。

转义和存储库位置

• [ ] 我们必须到处检查是否有逃逸。 遗留的 Gogs 代码一般很难逃脱，并且已经对多个安全问题负责。
• [ ] 用户名和存储库名称不需要转义的假设迫使我们做出我们不需要的架构决策。 它甚至没有为 git 签名正确保护我们，因此 #5774。
• [ ] 虽然用户让底层存储库位置与文件系统位置匹配是令人愉快的 - 例如$GITEA_ROOT/owner/reponame恕我直言，这是一个糟糕的架构决策，并导致用户假设我们的存储库仍然可以被服务器上的 git 使用，而无需进一步思考 - 他们不应该。 我们应该转向$GITEA_ROOT/repository-$ID ，可能是分片的。 （这样做将允许删除大量对repo.MustOwner()或repo.GetOwner()的调用）
  
  
  
  • [ ] 一旦我们转到上面并且我们正确地转义了所有内容，我们就可以放宽对用户名和存储库名称的限制 - 尽管必须仔细考虑这一点以确保我们以不允许的方式进行伪造类似于#5774 的问题。
  
  
• [x] 我们应该强制服务器 git 进程必须在足够的 Gitea 环境下运行 - 有重复的用户试图在服务器上使用 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，这真是太疯狂了。 我们应该从 swagger 中自动生成这个，或者尽可能多地自动生成
• [ ] 我们无法针对我们的开发 Gitea 测试固定的 API 版本，因此我们无法判断何时进行了重大更改。
• [ ] 我们应该能够使用自动生成的 API/SDK 来创建简单的测试工具

测试

• [ ] 我们目前在 TRACE 级别运行我们的单元测试 - 这限制了我们向事物添加适当跟踪的能力。 从https://gitea.com/gitea/log/pulls/3 开始，如果我们向后移植到 Gitea，我们可以从我们的 makefile 中更改它。
• [ ] 需要更多单元测试并考虑某些集成测试是否实际上是单元测试，反之亦然。 例如https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
• [ ] 我们需要更多的集成测试来尝试运行用户故事。 也就是说 - 用户登录，执行 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 分钟才能运行！ 我们应该并行运行这些。
• [ ] 没有简单的方法来创建迁移测试。

Go 包架构

楷模

• [ ] code.gitea.io/gitea/models取决于必须停止的太多事情。
• [ ] models.x必须销毁。 这是一个糟糕的架构决定。
• [ ] 对于太多模型，很容易导致 nil 指针取消引用，因为您不知道它处于什么状态。我们可以在这里更好地使用 go 的类型系统吗？
• [x] 我们应该将 OwnerName 放在存储库表中，因为每次我们获得存储库时，我们都必须去获取所有者。 这很愚蠢而且浪费时间。 存储库不会经常更改所有者，因此必须处理的成本并不大。
• [ ] 模型中还有很多事情要做，应该移出更多。
• [ ] 将模型分为核心和非核心可能是有意义的。

模块

• [x] 本质上有两种类型的模块：依赖模型的模块和模型依赖的模块。 让我们把这些分开，一个可以称为服务。

马卡龙

• [ ] 我认为我们应该认真对待@lunny提议的杜松子酒
• [ ] 我们的代码库充满了对 macaron 的依赖，这不应该是这种情况

环境

• [ ] 也取决于马卡龙（！）
• [ ] 与 go-ini 紧密相连，这是另一个我们应该考虑与自己断开连接的依赖项。

国际化

• [ ] 电子邮件未国际化
• [] Git 消息未国际化
• [ ] 错误信息未国际化
• [ ] 我们应该自动剥离我们的 Hugo 网站文档，以便它可以通过 CrowdIn 国际化
• [ ] 奇怪的是，我们在语言选择器列表中使用了小写形式的语言，例如 français、español - 这代表了每种语言中句子的开头，因此 AFAICS 应该将它们大写。 Oui, si j'écris en français j'écris "français", mais si j'écris une liste á puces, j'écris:
  
  
  
  • 英语
  
  
  • 法语
  
  
  • 西班牙语
  
  

Gitea 转储和恢复

• [] Gitea 转储因在 SQL 变体之间转换而损坏
• [ ] 我们没有恢复命令

在 UI 部分，我建议提供两个 UI：

• 一个纯 HTML（类似于当前没有 js 的）
• 仅依赖 API 调用的完整 JS。 这将迫使重新考虑很少的 API，但它也将允许来自其他外部应用程序的更多交互。

• 认为我们应该认真对待@lunny 提议的杜松子酒举措

我建议用 go-chi 而不是杜松子酒。

• 我们应该自动剥离我们的 Hugo 网站文档，以便它可以通过 CrowdIn 国际化

恕我直言，网站/文档根本不应该被翻译，无论如何它总是过时的......

恕我直言，网站/文档根本不应该被翻译，无论如何它总是过时的......

但是对于crowdin，它过时会通知人们并使当前的翻译无效。

是否可以在构建过程中添加适当的操作系统包？ 一世

也许由 GItea 开发人员控制和版本控制的 PPA 风格包是一个好主意，但我不喜欢 Debian 风格的“冻结和向后移植安全补丁”快速移动项目（例如 GItea）的版本控制方式

我仍然想要https://github.com/go-gitea/gitea/issues/3840。
我认为它可以通过向后兼容来实现。
但这只有在新路由库的迁移稳定下来后才会变得清晰。
先决条件的基础清理/重构也会使它更容易。

我仍然想要#3840。
我认为它可以通过向后兼容来实现。
但这只有在新路由库的迁移稳定下来后才会变得清晰。
先决条件的基础清理/重构也会使它更容易。

在这种情况下，您可能会失去对 Drone 的支持，因为它目前还没有为 Gitlab 实现。

我仍然想要#3840。
我认为它可以通过向后兼容来实现。
但这只有在新路由库的迁移稳定下来后才会变得清晰。
先决条件的基础清理/重构也会使它更容易。

我们可能不需要这个组功能来影响存储库 url，我们可以只创建可以显示存储库的文件夹，但保持存储库 url 与现在相同

@tboerger
我的想法是，如果 repo 没有嵌套在组/目录中，则 URL 可以保持不变。
仅当 repo 使用组/目录功能时，才需要“升级”URL。
但是，是的，带有新 URL 的存储库可能无法立即获得 Drone 支持。

@lafriks
这听起来像一个好主意。 我对这个特性的使用场景是托管Git模块或者Repo项目的子项目。 所以，我不确定它是否涵盖了这种情况。

不用担心。 我也不愿意做出如此广泛的，可能是破坏性的改变。

这个问题有很多好主意，我们应该保留它们并解决它们。
然而，我们应该在何时以及如何选择？ 这种讨论可以永远持续下去。

我建议所有者选择主题或在他们和成员之间投票。
你怎么认为？

@DblK没错。 但我认为我们可以在迁移到 gitea.com 后做到这一点。 目前我们需要更多用户的反馈。

• 水银支持
• 更好地对 PR 和问题进行排序和过滤

• 水银支持

不谢谢。 它被称为“git”ea 是有原因的。
我理解扩大范围的愿望，但
膨胀就在眼前……

mercurial import 将是一个替代方案

在2019年7月26日下午一点52分50秒UTC，桑德罗桑蒂利[email protected]写道：

• 水银支持

不谢谢。 它被称为“git”ea 是有原因的。
我理解扩大范围的愿望，但
膨胀就在眼前……

——
您收到此消息是因为您发表了评论。
直接回复此邮件或在 GitHub 上查看：
https://github.com/go-gitea/gitea/issues/6998#issuecomment -515461704

联合拉取请求/问题/分叉

可能不是 Fediverse 意义上的联合（ActivityPub、OStatus、diaspora* 等），但我希望能够以最适合项目的任何方式与自己实施的远程实例进行交互。

在#1612 中已经有一些关于这个的讨论。 ForgeFed 收集了一些有趣的想法，让联邦成为像 Gitea 这样的代码伪造。 如果这能成为 Gitea 的下一个大特色，那就太棒了！

我喜欢图形文件（JPEG、PNG 和 PDF）的视觉差异工具，类似于Github 提供的工具。

我们已经有一个 PR 来区分图像

我们已经有一个 PR 来区分图像

是的，但这不包括滑动或洋葱皮预览，仅并排。 此外，我认为它不包括 PDF 文件。 我们在这里使用 Gitea 来开发图形材料（包括手册和小册子），PDF 的良好视觉差异将改变生活。

我有一些想法，我只想扔掉 :smile_cat:

1. 使用 Cloud KSM 透明地加密/解密任何秘密。 这将防止数据库被黑客攻击和暴露。 这个想法是我们可以在写入数据库之前使用带有 XORM 编码/解码方法的自定义类型来加密秘密数据。 我们在这里做了一个演示示例： https :

2. OIDC 支持：通过 Gitea 登录时，除了 oauth2 令牌外，还返回 id_token

3. Gitea 用户配置文件可以在任何经过​​验证的 Git 存储库中显示用户的配置文件。 示例：用户可以固定 Github/Gitlab/BitBuket/Gitea 存储库。 这个想法是用户也不能忽视其他的。 那么，gitea 可以成为一个全球用户配置文件吗？

4. 对 repos 的自定义域支持 (go)

5. 与Github完全兼容（我在这方面看过一些工作，不知道已经做了多少。）

6. 可选的语言服务器集成。 类似于 Sourcegraph 之类的东西，比如内置于 UI 中的导航。

我想在短时间内为 1 和 2 做出贡献。

也许我们可以以已更改的文件夹和文件树的形式显示差异 - 就像在 BitBucket 中一样，而不是一个包含所有更改的大页面。 它会更易读。

也许可以选择每天或每周在所有存储库上汇总通知。
有点像上周活动的总结。

添加通过自定义模板和标准变量池定义自定义 webhook 的可能性。

不是 Gitea 进化，而是一个有用的辅助项目：#7853

功能与 github 相当！

或者，至少，维基上的最新列表显示了我们在实现平等之前仍然需要的所有功能。 这将是构建未来开发工作的好方法。

@lonix1查看https://docs.gitea.io/en-us/comparison/以获取该列表

@kolaente看起来我们几乎拥有所有的刻度线！ 是的！

我在这里很新，但也是一个愿意编码的人； 如果 gitea 支持 gists，我会喜欢它。 这是我使用中最大的漏洞之一。 很容易解决，但我宁愿只是有一个要点系统。

我认为要点的问题是https://github.com/go-gitea/gitea/issues/693 （链接，因为它似乎还没有从这里被引用）。

还添加Help文档，可以通过Help链接访问。 本文档的初始来源可以来自GitHub 帮助，经过 Gitea 特定的修改。

@bagasme帮助不能从 github 中获取，这将侵犯版权。 有人将不得不从零开始写Gitea帮助

1. 通过电子邮件创建问题（请参阅 GitLab 服务台）。

如果越来越多的人开始采用自托管来共享他们的开源项目，那么需要有一种方法让非注册用户提交问题而无需在每个实例上创建一个帐户（大多数人极不可能注册错误报告）。

1. 类似于 GitLab 的 AutoDevOps。 这意味着可以在存储库中没有 CI yaml 文件时定义默认 CI 作业。

2a. 容器注册表 UI 选项卡和身份验证。

1. 机器人
2. 用于 Web 提交的 GPG
3. 能够根据条件阻止合并
4. 能够在 Web UI 中创建文件（包括在空白的裸仓库中）
5. 通过 UI 管理附加到 repo 的片段（请参阅 GitLab）
6. Git 协议 v2 支持
7. 改进的 Web IDE 选项
8. Kubernetes 集成（通过 UI 插件 a la GitLab）
9. 在悬停时显示工具提示之前添加 400 毫秒的延迟
10. 更好的 CI 集成（显示管道、Concourse 支持等）
11. 优化用户界面
12. 执行 2FA
13. 文件锁定
14. 使用 PR 合并自动关闭链接问题。

某种插件/扩展系统。

大多数建议都很好，但它们会在核心代码库中产生问题。

最好有官方（和非官方）插件。 这也意味着插件作者可以更频繁地发布。

@lonix1好吧，git hooks、webhooks 和 Swagger API 可以被视为插件连接点。 我完全支持更多插件支持，但列出一个包含细节的列表可能会有所帮助。 例如，我希望支持与 webhooks 等效的命令行。

@guillep2k例如上面讨论的所有项目管理功能。 这些将非常有用 - 但它们可能涉及代码库的许多部分，以至于 1) 即使对于那些不使用这些功能的人，它们也可能导致问题，以及 2) 因此，这种开发非常缓慢，因为那些负责合并新功能的人知道这种情况是可能的，所以他们很谨慎。

如果这些新功能可以单独发布，那么在合并到主分支之前，它们可以被有意愿的用户试用。

还有其他此类重大新功能的示例，只需向上滚动即可。

@brandonkal GPG 签署自动生成的提交现在可以通过合并 #7631

我想路线图应该分为这四类（我添加了一些示例问题 - 很明显它远非完整 :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。

这两个问题将大大提高互操作性：

• [] 自动集成 Drone CI/CD（就像之前提出的 ）
• [ ] [自动化 PR 审查的 API 集成](https://github.com/go-gitea/gitea/issues/5733) 通过Pronto 等工具
• [ ] [与容器注册表轻松集成](https://github.com/go-gitea/gitea/issues/2316)
• [] 一个通用的 webhook 解决方案，允许用户轻松设置自定义 webhook（就像之前@bkcsoft提出的那样）

通用的 webhooks 也可以避免让其他人知道 gitea 的内部结构。 @guillep2k有一个绝妙的想法，即可以类似于通用 webhook 集成来完成“外部命令”集成。
：警告：这可能会解决这个问题中大多数人想要的“插件支持”的大部分问题。 因为这将能够呼叫用户需要呼叫的任何内容。 但是， @lunny刚刚提到这实际上已经可以通过 git hooks 实现。 我只是不太确定这是否真的是集成其他工具/插件/服务的最佳方式。

顶级功能

此外，在竞争应用程序（即 Git[Hub/Lab]）中显然有一些不错的功能（其中大多数可能相当不错）：

• [ ] [恢复 PRs](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)
• [] 显示更多存储库详细信息（即存储库大小、贡献者图、语言栏）
• [ ] 一些 wiki 改进（#823 #574）
• [ ] [有一个像@SignumPL 提到的 BitBucket 的差异](https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615)（我之前不知道，但它看起来确实有用)
• [ ] [集成像八叉树这样的功能](https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388)

可以使用 Oracle 数据库作为选项吗？ 如果技术上可行。

@DemiusAcademius如果 xorm 更好地支持 oracle，我认为这是可能的。

越来越多的人开始使用 Gitea，例如最近的 GitLab 跟踪器公告也是引起的。 但是 GitHub/GitLab 仍然有网络效应。

联合将是提高不同 Gitea 实例用户之间协作能力的重要驱动力，从而增加整个 Gitea 网络：#1612

据报道，在 UI 中显示大差异的能力是采用 Gitea 的一个限制因素。
解决它的票证：#7341（功能），#7495（崩溃错误）

据报道，在 UI 中显示大差异的能力是采用 Gitea 的一个限制因素。
解决它的票证：#7341（功能），#7495（崩溃错误）

这是一个_巨大的_限制。 IMO一切@alexanderadam列出上述与此相比就相形见绌了。 如果我不能通过在代码中内联注释来查看大的差异，那是一个大问题。

W/R/T 对微软和 Github 的愤怒导致许多项目迁移并导致对联邦的高需求--Gitlab 最近提议禁止在中国和俄罗斯这两个世界上面积和经济最大的国家的员工。 美国军方已将重点转移到中国和俄罗斯（以及其他国家），以削弱它们对美国帝国扩张/利益构成的障碍。 宣传和财政激励措施使微软（Github、Azure）、亚马逊、谷歌、Atlassian（Trello、Jira）甚至 Gitlab 以进攻性角色进入战争、间谍、宣传和监视行业。

我提出这一点是为了感谢那些致力于高度可用的开源远程存储库的人，这些存储库对我们现在使用并仍然依赖的企业和与五角大楼相关的服务几乎没有什么缺点——并提请您注意快速替代方案对于那些希望在远离历史上最强大和敌对的帝国的地方使用互联网和技术的人来说，它正在消失。

也许这个话题足够大，以至于官方网站的一个单独部分来跟踪这个功能的进展，以及一个单独的筹款活动来捕捉这个需求。 看到 ForgeFed 到目前为止的工作，将 ForgeFed 包括在筹款中可能是有益和公平的。 微软与 Github 交锋至今已经 17 个月了，我希望在另外 17 个月内我们可以使用联合 Gitea，或者让“净资产”的剩余部分建立起来。

请不要在这里讨论政治，让我们继续主题——为大家改进Gitea

@lafriks改进无法满足的东西。 营销是寻找外部机会的过程，“政治”是营销分析的 4 个主要类别之一。 一个明智的品牌对人们的 _values_ 的吸引力与他们提供的功能、规格和价格一样多。 对像 Gitea 这样的替代品有一种基于价值观（“政治”）的吸引力，如果不强调和维护它，将无法理解您的消费者和市场机会。

“政治”作为一个术语已成为一种终结思想的陈词滥调，消除了对种族主义、暴力和剥削的讨论。 我只是来这里感谢人们继续研究与美国集中营、拖网监视和我们行业的大多数积极帮助的其他帝国主义利益无关的替代方案。如果你说这些不是 Gitea 所支持的品质，我误会你了，我要走了。

请注意@OKNoah

开源项目的营销 101：

1. 不要提集中营
2. 不谈政治
3. 丢掉锡纸帽
4. 不要使用诸如帝国主义之类的古老术语
5. 了解您的产品优势。 Gitea 的优势在于它的简单性。

如果 GitLab.com 的透明度冒犯了您，您可以自行托管 GitLab-FOSS。 这是一款非常好的多合一产品。 但是如果你想要一个简单的安装或者需要比 GitLab 或 GitHub Enterprise 更低的内存使用量，Gitea 是基本 Web 功能的一个不错的选择。

该主题是关于讨论可以帮助缩小差距而又不影响简单性的功能。

我的 2 美分 - 我认为这个帖子太长了，是时候开一个新问题来总结这里已经表达的任何想法了。 并关闭这个。

如果你说这些不是 Gitea 所支持的品质，我错了，我会离开。

这不是所说的。 所说的是，该线程是讨论可以对 Gitea 进行哪些更改/改进（特别是技术方面的更改/改进）的地方。 这些讨论非常受欢迎，但不是在这个特定的线程中。

作为领导之一，我将锁定此线程，正如@XVilka所说的那样，我们已经征求了很多反馈，现在应该对下一步进行评估。

我们可以更改 v2 的 FHS 合规性路径。 已经可以使用标志，但它应该是 v2 的默认值。