在学习 Ubuntu 开发和打包时，有一部分我不太清楚。假设我们在功能冻结之前处于积极开发阶段（例如 Raring），并且我想改进为 Ubuntu 打包的程序 - 例如 Guake。我想修复错误、添加新功能等。现在，我看到两种方法可以做到这一点：
- 上游主干道作业lp:guake，提交合并提案并请求 Ubuntu 的软件包维护者重新同步该软件包
- 处理软件包分支Ubuntu：guake在那里提交我的修复，并让项目或软件包维护者担心将此修复转发到上游或为软件包存储库创建 guake-ubuntu0 修补版本
这两种方法中哪一种更好？这是否取决于具体情况（例如贡献类型 - 错误修复或新功能；开发阶段）？如果是，如何？如果有经验的人能就此主题提供更多指导和建议，那就太好了。
在 GitHub 生态系统中工作时，一切似乎都很清楚 - 一切都以最新开发版本为中心，所有拉取请求都为此提交（至少我从未遇到过有人为项目 X 的旧版本 0.7 提交内容），而在 Launchpad 上，软件包和上游分支之间的这种差异让我感到困惑。我不确定是运行最新的 Ubuntu 开发版本并深入研究那里可用的源代码（通过apt-get source <package>）更好，还是应该将最新的主干代码放入我的稳定 Ubuntu，进行更改，看看我是否能以某种方式让维护者将此更改转发给软件包（重新同步，检查构建是否仍然适用于其他 Ubuntu 库等）。
我阅读了新旧包装指南，但这些问题仍然让我感到困惑。
答案1
您需要从概念上将 Ubuntu 与上游分开，即使上游分支托管在 Launchpad 上。Ubuntu 中的绝大多数软件包的上游分支完全托管在其他地方（即 GitHub 或 SourceForge）。托管在 Launchpad 上的上游项目可能与 Ubuntu 有更密切的关系，但它应该像任何其他上游项目一样对待。
Ubuntu 重新分发上游软件通常仅在需要与我们发布的所有其他软件集成时才进行更改。在大多数情况下，最好的选择是修复上游的错误。这样，修复程序就可以惠及大多数人。这样也减轻了 Ubuntu 的负担，因为无需维护本地修改。
因此，理想情况下，该过程看起来是您的第一选择。您修复上游的错误，上游发布新版本，Ubuntu 更新到该版本。正如您所注意到的，事情并不总是这样运作的。
有时 Ubuntu 和上游项目的发布计划可能不一致。假设您发现并修复了一个错误，希望在下一个 Ubuntu 版本中看到它，但 Ubuntu 将在三个月后发布，而上游不知道下一个版本何时发布。在这种情况下，最好的方法是修复上游的错误，但将其作为 Ubuntu 特定补丁反向移植到 Ubuntu 版本中。在 Ubuntu 的稳定版本中进行修复时也是如此，我们很可能无法包含新的上游版本。
有时 Ubuntu 会将更改发布到上游。如果错误在于这些更改，则修复应该直接发送给 Ubuntu。这包括包装等方面的问题。
新功能极不可能被 Ubuntu 接受，除非它已经被上游接受。为了更大的项目，我们经常会在补丁被上游应用之前接受修复特定问题的补丁，但我们通常不喜欢在设计或功能方面偏离上游。
我知道我基本上只是说这取决于情况，但事实确实如此！