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