通过补丁或合并提案在启动板上提交错误修复？

Question

我是Launchpad和Bazaar的新手，我正在试图找出提交错误修复的最佳方法。我正在使用一些在Launchpad上托管的相当流行的开源软件，但它不是很稳定。我已经创建了自己的项目分支来稳定它并仅应用我们需要的错误修复，而不会从正在进行的开发中添加其他更改。

当我提交错误然后弄清楚如何自己修复它们时，我将修复程序推送到我们的稳定分支。我该如何将修复程序发布回主项目？我可以创建一个补丁文件并将其附加到bug中，或者我可以为我们的稳定分支建议合并。

如果我修复了多个错误，我可以为每个错误制定单独的合并提案，还是累积？

Answer 1

Answer 2

此类策略（使用合并提议或补丁）应由项目本身的核心开发人员或维护人员定义。但是，对于每个修复使用单独的分支的一般规则是优于纯普通修补程序的方法。

• 因为当树干分支发展向前发展时，普通补丁可能会变得过时。当你保留修复分支时，你可以根据trunk中最近的更改来更新你的修复。
• 分支中的修复程序更易于分析，因为其他开发人员可以看到解决问题的所有中间步骤，或者当主干更改时修复程序的演变过程。
• 此外，错误报告中附带的补丁通常也会被遗漏或遗忘。虽然所有活动合并提案的列表都突出显示在每个项目的“分支”页面上。
• 合并您的分支机构中的修补程序意味着历史记录（和注释）会将您的名称保留为路径作者，而不是应用修补程序的核心开发人员。

将所有修复程序保留在一个分支中不利于在合并提议中使用它。但是，测试所有修复或将其用作稳定分支（例如用于dogfooding）本身很有用。因此，我建议为每个单独的修复使用单独的（功能）分支，为它们提供单独的合并提议文件，并将这些分支合并到您今天的稳定分支中。通过这种方式，您可以完全自由地对每个修复应用其他更改，然后再将其合并到稳定分支。

如果您需要将现有的稳定分支拆分为多个单独的分支，您可以使用John Meinel在其博客中描述的配方：http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html